一次資料變更的稽核過程(r8筆記第95天)
今天正在做一個數據變更操作,突然一個開發的同學找到我,看起來比較著急的樣子,說想讓我做一個數據變更。
當然在這種時候,我正在做的資料變更操作已經被打斷了,已經有一些不願意了,而且還要緊急變更,在沒有得到指令碼,沒有環境,沒有指令碼說明,對於這種三無要 求我一向都是比較排斥的。所以我靜下來,讓他提供這些資訊,這些是資料變更的必備條件,哪怕再緊急,這些資訊也需要有基本的流程規範。
所以這位同學就這樣無功而返,當然換誰都一樣。很快他就確認了環境,是一個使用率不高的線上業務庫,當我得到他提供的語句的時候,我已經有些崩潰了,因為 開啟檔案的時候,發現指令碼註釋都是亂碼,所以我還是選擇打回。然後等開發的這位同學再次發過來檔案的時候,我終於耐著性子開始稽核指令碼。
可以從指令碼的內容和註釋看出,這是通過一個工具匯出的指令碼,當然了這種指令碼還是有很多的問題。
首先就是匯出的指令碼中的使用者是TEST
指令碼中是類似"TEST"."TABLE1"的形式,而我要匯入的環境的使用者為TEST_OPER,這就給我帶來了一些困擾。
其次是匯出的指令碼中的表空間在目標庫中不存在,如果開發的同學不確定,其實這個地方就可以直接省略,而作為DBA會做權衡,當然使用者的預設表空間就是相關的表空間。
再次就是匯出的環境中的段屬性,索引段屬性等,其實在目標環境中大部分都不需要。
比如下面的段儲存屬性:
SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)