最近的幾個技術問題總結和答疑（二)

最近積累了幾個問題，我就湊在一起做一個統一的答覆，微信後臺的留言回覆超過24小時就無法回覆了，有時候看到的時候已經過了時間點了，實在抱歉。
有時候有些朋友是通過qq或者微信來問我問題，有時候運氣好能夠馬上定位，感覺非常僥倖。
今天回答5個小問題。
第一個問題是在昨天晚上準備睡覺前，一個微信好友的提問。說自己的DG備庫上啟動了兩個一模一樣的例項，感覺比較奇怪。
當時的截圖如下。

一看這個問題，真是運氣好，馬上就知道原委了，我讓他把當前環境變數的ORACLE_HOME提供給我。
然後找到兩個PMON的程式的程式號，發給我。
稍作等待，就收到了相應的程式號為5261 5550，其實不一定選用PMON,SMON,LGWR這些程式都可以。
我提供了兩個命令，讓他把結果發給我。
cat /proc/5261/environ|xargs -0 -n1 |grep ORACLE_HOME
cat /proc/5550/environ|xargs -0 -n1 |grep ORACLE_HOME
收到的結果如下，

仔細看ORACLE_HOME的值就會發現唯一的差別就是末尾的斜槓。
至於原因也非常簡單，在Unix,Linux系統中，SID和ORACLE_HOME在一起雜湊後會得到一個唯一的值作為SGA的key。當oracle例項啟動時，在作業系統上的fork程式會根據Oracle_SID來建立相關後臺程式。
在這個例子裡面，Oracle認為ORACLE_HOME是不同的，所以才可以啟動到nomount狀態，但是肯定啟動不到mount狀態，因為控制檔案已經被佔用了。

第二個問題是微信中的留言：
有個adg備庫問題困擾我很久，正好請教一下，adg備庫處於只讀開啟模式應用歸檔日誌，我們在上面執行包含dblink的複雜查詢，查詢存在多個本地表和遠端表關聯，會報一個這是隻讀資料庫的錯，這好像是和通過dblink查遠端表會啟動一個事務有關，不知道你有沒有遇到這樣的問題(O_O)？
這個也是運氣好，我還真碰到過。而且碰到的例子比他還特殊一些。
使用db link在備庫查詢，可能會觸發這個問題，可以參見MOS  參考連結如下：

Dblink on Physical standby - ORA-16000 (Doc ID 1296288.1)

ORA-16000 With A Semantic Query On A Read-only Database (Doc ID 1928638.1)

而我碰到的這個問題略微不同，是因為失效的物件導致的這類問題，可以參考我的部落格。備庫批量查詢失敗的原因分析 http://blog.itpub.net/23718752/viewspace-2052930/

第三個問題是微信中的留言
主鍵和唯一鍵索引必須是全域性索引吧？如果原表存在怎麼處理呢？去掉嗎？還是做分割槽操作的時候update global indexes呢？另外分割槽是手動增加，還是寫job自動增加呢？
幾個欄位組成唯一約束，請問約束的順序和唯一索引的順序可以不一樣嗎
我的回答：其實這個我也寫過一篇文章做過一些解釋，其實可以認為是獨立的。不一定啊，預設是全域性，不能這麼幹，大分割槽表一般都是先建約束，然後繫結本地索引。
可以參考我之前寫的一篇  很多人比較糾結的約束和索引的關係 http://blog.itpub.net/23718752/viewspace-1975057/

第四個問題來自PUB的私信：
目前我在做一個資料遷移專案。由源系統歷史資料需要全部遷移至目標系統，而兩套系統的表結構是完全不同的。
目前我們即將進入資料對照階段。麻煩我想問一下，這個階段您有什麼好的建議麼。還有資料對照時候有什麼模版或者好的工具能讓資料對照工作有效進行。。非常渴望您的指導！另外，我們這次資料遷移的表中。有十幾張千萬條以上的大表，有些達到5000萬條。麻煩問一下這些超大表在設計遷移指令碼的時候一些需要注意的設計策略。以及是否可有工具輔助呢

這位朋友現在碰到的資料遷移應該算是異構增量資料遷移，應該是遷移裡面比較折騰的一種。
我的回答如下：你說的這種方式的遷移物理遷移，普通的邏輯遷移都不可用，資料對照階段你說的是比較表結構資訊是吧，這種遷移應該是邏輯增量的方式吧，這種方式我的感覺還是推薦用外部表來遷移，優點非常明顯就是資料可插撥，而且可以靈活的指定列對映關係，當然需要提前呢準備好對映關係的部分，我覺得對增量資料遷移來說，這個方案比較可行的是，可以在遷移前做到資料的比對，對於約束衝突，主鍵衝突的資料就可以提前預警。

第五個問題是今天的社群文章。原文可以參考 http://dbaplus.cn/news-10-340-1.html
有個群友留言提問：運維注重細節，如何提升價值和跟客戶交流增加運維服務價值？
我覺得這個問題特別難得，其實這些細節有些看似不經意，不起眼，對於運維服務的價值來說，可以辯證的來看，首先碰到的一個看似簡單的問題，正因為簡單，很可能是一個通用的錯誤，徹底解決了一個問題，其它環境都有的同樣問題都會引刃而解。很多歷史問題，遺留問題，或者難題，其實拆分來看，都是因為這樣那樣的原因，歸根接底都是很細小的問題導致的，解決了這類問題，本身就會解決已經存在的問題，規避即將發生的問題。這些問題還是在一定程度上坦誠和客戶去溝通去互相瞭解，理解，這樣我們解決的問題的意義就在於此，而不是有些時候藏著捂著。最後就是對個人的提升，對自己全方位都是一個鍛鍊，過程雖然痛苦，但是回想起來還是值得的。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2074012/，如需轉載，請註明出處，否則將追究法律責任。