今天處理的三個小問題——20160120

今天處理了幾件事情，有幾件還比較有意思，我拿出三件來說說。
首先是早上有一個同學打電話求助一個問題，給我的反饋是他們目前有一個表，資料量越來越大，目前資料插入變得很慢。想問問我該怎麼分析。對於這個問題，聽起來還是有些模糊，稍後想他明確了資料庫是10gR2的版本。至於他說的資料量是很大，目前是百萬資料量，其實還可以了，不算很大，那麼他說的速度很慢，到底有多慢，是1秒鐘變為2秒鐘還是更大，他說大概有30秒。
透過這個問題，可以簡單猜想能讓insert很慢的場景其實還是比較少的，至少對於增量資料的插入這一點上很難和鎖聯絡起來了。簡答和他確認了問題表的資料頻率，他說主要就是insert。
然後簡單瞭解了情況之後，我讓他發了一個awr報告，然後給他打電話指導他完成了awr報告的生成。當然報告因為網路原因是沒法發給我的。我簡單貼出來幾個後續的截圖。

透過這個可以看出來,資料庫還是初始版本，DB time可以大體看出來負載其實也不高。其實整個系統的負載也不高，從TPS，redo這些可以看出來。不過其中的一個亮點就是 物理讀比較高，還有一個是硬解析比較高。如果放下看，buffer hit實在是很低，當然這個和本身的配置有一定的關係，就給了500M的sga，還是有一定的壓力的。
當然這些是一個概要，我又要了一個等待事件的截圖。可以看到排在首位的是scattered read，這個和大量的物理讀還是可以印證出似乎有全表掃描。

當然關於全表掃描和索引掃描，我也給同學簡單解釋了一下。接著就是從sql入手了，我提供了關鍵字，sql order by elapsed讓他把截圖發給我。
得到的報告內容如下：

透過這個可以看到其實他這個伺服器還是預設安裝了OEM，估計他也沒意識到這個工具的存在，當然主要的就是關心他所說的Insert相關的語句，但是沒有相符的，但是找到了兩條update。和他確認了一下，就是目前反饋插入慢的表，所以透過這個我可以簡單得出結論，這個表沒有索引，後續的結果想必大家也可以猜到了，加上索引這類的語句可能會飛起來。這也就見解說明了，得到的反饋不一定準確，還是需要一些簡單的分析。當然這也算幫了同學一個小忙。後續可以繼續跟進。

然後是公司處理問題的時候碰到了一個問題，目前存在兩個資料庫環境A和B,目前根據需求需要把A庫中的一張表資料同步到資料庫B中，表的資料其實還是非常少的，不到100條。看起來是一個非常簡單的需求了，當然兩個資料庫環境還是大大不同的，資料庫A是solaris環境10gR2,資料庫B是linux環境11gR2.
一種很簡單的思路就是使用db link來同步了，但是目前的情況是應用賬戶的密碼都是加密，在屬主賬號中使用db link還是受限的。
那麼我就嘗試exp/imp這種檔案級的同步方式，但是這個時候exp卻報錯了。看起來是哪裡不一致了。
$ exp XXX/XXX@XXXX file=XXXX_new.dmp tables=XXX.XXXX
Export: Release 11.2.0.3.0 - Production on Wed Jan 20 18:26:49 2016
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set
About to export specified tables via Conventional Path ...
Current user changed to XXXX
EXP-00008: ORACLE error 904 encountered
ORA-00904: "POLTYP": invalid identifier
EXP-00000: Export terminated unsuccessfully
看錯誤應該是缺少了一個欄位。至於這個欄位從哪裡而來，發現是屬於sys.exu9rls的。
sh findcols.sh POLTYP
#################################
OWNER                TABLE_NAME                 COLUMN_ID COLUMN_NAME                    DATA_TYPE       DATA_LENGTH NULLABLE 
-------------------- ------------------------- ---------- ------------------------------ --------------- ----------- ---------- --------------------
SYS                  EXU9RLS                           12 POLTYP                         VARCHAR2(33)             33 Y
對於這個問題事後查詢原因，發現是一個相關的小bug.
The Fix For Bug 7568350 Generates ORA-00904: "POLTYP" Error At Export Client (Doc ID 784038.1)
當然對這個問題我們打補丁還是不顯示的，那麼怎麼辦呢，還是得靠db link了，不過這個時候我們可以建立一個臨時的public db link來做。
create public database link xxxxx 指向資料庫A
然後使用insert xxxx select * from xxxx@link 的方式插入資料
然後刪除public daabase link即可。

然後第三個問題比較有意思，目前的情況是運營的同學反饋有一個統計應用在某些天沒有資料。然後開發同學就找到了我，然後想讓我幫忙看看，按理說我應該直接推回去。不過還是為了配合工作，我從我的角度進行了檢查，首先他提供的這個表test_storage中的資料來源對於DBA來說也是黑盒的。開發同學反饋說缺少12月半個月的資料，之後這部分資料又不上了，這個時候就讓我有些意外，這都過去了一個月了，之前怎麼沒有發現，當然也是牢騷之言，得到答覆和沒有答覆是一樣的效果，還是需要查明原因。至於這部分資料的插入邏輯，看來還得靠自己了來摸清楚了，首先這是一個統計業務，那麼這部分的資料應該來源於線上業務，所以說資料來源是線上系統，資料需要同步到這個表中，目前是有一定的頻率，主要是設定頻度來完成同步，可能每天會定時來同步等，透過這些簡單的資訊就可以從系統級，資料庫級進行排查，當然這個過程也是很順利的，幾分鐘就去會出結果，發現一個儲存過程會在每天的指定時間去同步資料到test_storage這個表裡。
同步的邏輯是從線上的一個資料庫去取得資料，然後使用遊標的方式過濾得到，然後直接insert插入資料。看起來邏輯還是比較簡單的。
那麼問題來了，如果每天定時去同步資料，怎麼會丟失了近半個月的資料，這個還得從一個小故障說起，線上的那個業務在12月初有了當機的情況，然後切換到了備庫，這個時候把防火牆的一個設定給弄丟了。導致這個統計庫的資料同步被阻塞。當然也是耽誤了好些天，也是在業務的推動下，問題反饋到了我這裡，當時對其中的部分表的資料進行了追加。這張表當時沒有提供，所以也沒有進行處理，這不拖了些日子，最終還是浮出水面了。
當然解決的思路就很簡單了，就是從指定的儲存過程中找到相應的邏輯部分，然後改裝一下，拼裝成一個insert xxxx select xxx from xx where 的形式的語句來搞定。其實整個過程也就不到10分鐘，但是還是需要對很多的背景情況進行了解，要不還是很難定位的。