一次資料變更的稽核過程

   今天正在做一個資料變更操作，突然一個開發的同學找到我，看起來比較著急的樣子，說想讓我做一個資料變更。
   當然在這種時候，我正在做的資料變更操作已經被打斷了，已經有一些不願意了，而且還要緊急變更，在沒有得到指令碼，沒有環境，沒有指令碼說明，對於這種三無要求我一向都是比較排斥的。所以我靜下來，讓他提供這些資訊，這些是資料變更的必備條件，哪怕再緊急，這些資訊也需要有基本的流程規範。
   所以這位同學就這樣無功而返，當然換誰都一樣。很快他就確認了環境，是一個使用率不高的線上業務庫，當我得到他提供的語句的時候，我已經有些崩潰了，因為開啟檔案的時候，發現指令碼註釋都是亂碼，所以我還是選擇打回。然後等開發的這位同學再次發過來檔案的時候，我終於耐著性子開始稽核指令碼。
    可以從指令碼的內容和註釋看出，這是透過一個工具匯出的指令碼，當然了這種指令碼還是有很多的問題。
    首先就是匯出的指令碼中的使用者是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)
其實這些資訊都是實際的應用來說沒有特別的使用者，從上面的內容可以裡面有11g的特性segment creation的設定，如果是在10g肯定會報錯。而且後面的屬性資訊也都不需要，完全可以根據當前的資料設定來取得預設值。
    然後看著後面的幾行語句，我不禁皺起了眉頭，因為這位同學自己新增了幾行指令碼，DML末尾沒有commit。
    當然這個時候我也不能怪這位開發同學的不專業，我需要告訴他的我的建議，於是我從頭按照我的建議改了一遍檔案，告訴他哪些是要注意的，而不是簡單的拿到檔案就交給DBA執行。
問題解決了之後，大家都相安無事，他也從中學到了東西。但是下午的時候，他又找到我說，他們訪問的時候有個報錯是table or view does not exist，然後想問問我早上的變更是否成功，為了儘快平息這種疑問，我就直接登入系統給他看了一下，所以這位同學帶著結果又回去了。但是讓我快爆發的是，他過了會又找到我說，這個表的變更應該是在另外一個線上庫中，這個時候我還是希望得到一個肯定的答覆，當初為什麼確認是之前的資料庫地址？看著這位同學也是模稜兩可，我覺得還是需要儘快把這件事情弄清楚，因為儘管確定是這個庫，我需要一個清楚的解釋，這次他提供的環境是一個非常重要的核心庫，一旦出現問題，那就是牽一髮而動全身。顯然這位同學不知道這個風險。於是我就找到了這個開發的負責同學，向他確認這個需求，業務上大體是什麼樣的情況，大體瞭解了下，原來他們有一個業務會涉及兩個庫，這個業務有一些功能點，有些需要連線資料庫1，有些需要連線資料庫2，而經過他們的確認，這個功能點是隻在資料庫2中會被應用呼叫，所以資料庫1的變更是不需要的了。反覆確認，開發的同學重新走流程，終於這個問題才算完整解決。
     看起來確實是一個挺讓人糾結的問題處理過程，當然我也理解那位開發同學的苦衷，但是不知者無畏，在不瞭解整個環境的前提下，貿然改動，留給系統的是數不盡的後患，作為DBA是需要嚴格稽核資料的變更和訴求，對於資料變化敏感的操作，需要保留備份，保留操作日誌，考慮影響範圍等等，也希望在工作中大家都更加專業，儘可能減少一些返工，過度交流的情況。