今天正在做乙個資料變更操作，突然乙個開發的同學找到我，看起來比較著急的樣子，說想讓我做乙個資料變更。
當然在這種時候，我正在做的資料變更操作已經被打斷了，已經有一些不願意了，而且還要緊急變更，在沒有得到指令碼，沒有環境，沒有指令碼說明，對於這種三無要求我一向都是比較排斥的。所以我靜下來，讓他提供這些資訊，這些是資料變更的必備條件，哪怕再緊急，這些資訊也需要有基本的流程規範。
可以從指令碼的內容和注釋看出，這是通過乙個工具匯出的指令碼，當然了這種指令碼還是有很多的問題。
首先就是匯出的指令碼中的使用者是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是需要嚴格審核資料的變更和訴求，對於資料變化敏感的操作，需要保留備份，保留操作日誌，考慮影響範圍等等，也希望在工作中大家都更加專業，盡可能減少一些返工，過度交流的情況。
記一次資料提取過程
某次需要乙個中文電碼本，然而網上搜到的要麼收費，要麼不行，所以打算自己做乙份，但是看了下資料量實在太大只能放棄，那麼怎麼辦呢。收到乙個軟體teleccodetool 可以查詢漢字對應的電碼，隨即準備提取，過程記錄如下。無關的檔案已經刪除了，只剩三個核心檔案 乙個個看，第乙個配置檔案開啟沒啥有用的訊息...
阿里RDS一次資料異常的定位過程
系統有部分資料放在阿里的rds上，今天發現某些資料查詢不出來 先檢查rds的日誌，可以看到當時的insert語句，但是select就查不到，所以一開始懷疑是rds的資料丟失。後來用mysqlbinlog命令檢查binlog檔案，才發現真正的原因 原來是insert的字段有33位，而該字段的型別是va...
阿里RDS一次資料異常的定位過程
系統有部分資料放在阿里的rds上，今天發現某些資料查詢不出來 先檢查rds的日誌，可以看到當時的insert語句，但是select就查不到，所以一開始懷疑是rds的資料丟失。後來用mysqlbinlog命令檢查binlog檔案，才發現真正的原因 原來是insert的字段有33位，而該字段的型別是va...