意外解掉Oracle 10g統計值匯入緩慢的問題

還記得之前遇到的 Oracle 10g 統計值匯入緩慢的問題 嗎? 這個情況在我在測試區上了patch後(10.2.0.4 64bit)，情況已經大幅改善。

原本我是在fund 這邊export出一個 10.2.0.1版本的 dump檔，以適用於當時尚未升級的測試區DB。後來加了統計值，並且匯到64bit windows & 64-bit Oracle 10.2.0.1的環境時，整個作業需要12~13小時。但上禮拜我將這個測試區升級到 10.2.0.4後，意外發現整個作業只需要3小時又40分鍾左右，真的有给它驚訝到。

難道是版本搞的鬼???

真是意外的收穫。

解決SQL Server改變Hostname後無法安裝訂閱服務的問題

你遇過改掉SQL Server主機名稱後，就無法繼續安裝訂閱服務之類的事嗎？不管你怎樣試，都會得到一個無法辨識主機名稱之類的錯誤訊息，並且告訴你最好給定SQL Server一個hostname。但事實上這個錯誤來自於SQL Server內部仍記著原來舊的主機名稱，而與instancename不一致所引起的。至於為何如此，目前我尚未有結論，等精神好點再去追根究底一番；目前先請Google大神提供一個解決方案，原理是透過修改@@servername的方式，讓SQL Server重新取得修改過的hostname即可。

修正後請重新啟動SQL Server服務，之後就可以正確的安裝訂閱服務囉。

Oracle中一次編譯無效物件之方法

最近工作需要，翻出了用來重新編譯無效物件的 DBMS_UTILITY.compile_schema 套件(package)，參數就只有一個schema name，只要指定好後就可以輕鬆寫意的完成無效物件的編譯。相關的文章則可參考 Recompiling Invalid Schema Objects 。但好巧不巧，前幾天在升級完 Oracle 後，意外的發現到用來更新 Dictionary 的指令檔尾註解中(D:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\catupgrd.sql)，會強烈的建議我們利用 utlrp.sql 指令檔案將無效的物件再recompile 一次，以避免當使用到無效的物件時，Oracle自動先行編譯而產生的不必要的延遲(latency)。

該指令檔 Utlsp.sql 位於 D:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlrp.sql，指令只有短短個幾行，主要就是利用 utl_recomp.recomp_parallel(threads) 自動判斷主機上有幾個CPU後，以平行方式進行compile的作業。很簡單也很好用。如果你已經懶到指定schema name的話，那這個就絕對是你的最佳懶人包。不過，使用前請先用sqlplus / as sysdba的方式登入後再執行。

p.s 後話，在Recompiling Invalid Schema Object 文章末端，也提到了utlsp.sql的用法，而現在我才發現..@@ 。這證明我文章沒讀透啊......

從VBA到T-SQL

Database Journal 今天分享了一篇 T-SQL Equivalents for Microsoft Access VBA Functions，這篇文章的重點在於提醒那些與MS Access共舞許久，Access SQL程式中也到處使用自訂或內建VBA函式的人，若日後有需要再度將這些焚膏繼晷的工作移轉到SQL上的時候，可就別夢想有什麼拖拖拉拉的工具可以直接幫你移轉了。更別提微軟提供的Upsize Wizard 根本就懶得幫你自動轉換那些內嵌在Aceess SQL中的VBA 函式。你得自己把所有內建的函式用T-SQL全部寫一次。

文章裡列出了T-SQL與VBA對應的函式表，以方便實作T-SQL時轉譯用。對應的函式名稱大體上是大同小異的，應該不會造成太大的困擾才對。還不錯的小品，分享囉...

Orakill也有失靈的時候

如果您遇到Orakill也砍不掉的Session，那建議你查閱一下Alert.log裡是否有以下的訊息：

orakill: ssthreadkill(tid=1988) unable to get the thread list mutex: err=0

如果有，那恭喜諸公，您又中Bug了。查詢過 Metalink後，確認為 Bug. 5753801，需要上10.2.0.3 Patch 21 or later後才能解決。

Oracle 10g 統計值匯入緩慢的問題

每天我都會以Data Pump的方式Export 一個約30G左右的 dump檔，然後再以Import (Content = ALL)到另外一台等級相同的的主機上；但令人訝異的，Schema的建立、Data 的 Import、以及Index的建立也僅大約花了三小時，而統計值的匯入卻足足花了8小時左右。查閱了metalink後，有個 Bug 5076838: IMPDP TAKES OVER 16 HOURS TO IMPORT TABLE_STATISTICS 指出了相同的問題，並且要到11g才會修正。Oracle對此也無workaround 解法。根據其他人的測試，主要原因可能是出在於 remap_* 的參數使然，只要target 的tablespace或schema不一樣，就會造成long~~long~~long~的等待。 對此，11g似乎才是磐涅之道。

就測試目的來說，remap_*是很常見的需求，正式區的資料也因此可restore到各式schema或tablespace內，以供各種測試目的專案執行。這種基本功都沒做好，真會讓人傷心的又訝異低。

SPOOL小技巧--砍掉欄位跟完成的提示訊息

工作上常透過SPOOL指令產出SQL指令批次檔，但如果只是簡單的將SPOOL ON/OFF的指令開關話，輸出的指令通常會有你不想要的額外訊息；舉例來說，

SPOOL D:\Autojob\Restore\ALTER.TXT;

select 'ALTER SYSTEM KILL SESSION' || ' ''' || sid || ',' || serial# || ''';' from v$session where username='SCHEMA_USER';

SPOOL OFF;

@D:\Autojob\Restore\ALTER.TXT;

exit;

ALERT.TXT通常會長成這樣：

'ALTERSYSTEMKILLSESSION'||''''||SID||','||SERIAL#||''';'

--------------------------------------------------------------------------------

ALTER SYSTEM KILL SESSION '521,415';

ALTER SYSTEM KILL SESSION '522,2428';

ALTER SYSTEM KILL SESSION '529,4564';

ALTER SYSTEM KILL SESSION '531,8493';

ALTER SYSTEM KILL SESSION '534,8057';

ALTER SYSTEM KILL SESSION '545,3068';

ALTER SYSTEM KILL SESSION '550,2691';

已選取 7 個資料列.

檔案內容裡我們就只要中間的 alter 指令，但檔案頭尾的訊息卻最好給我眼不見為淨。要避免產出頭尾的訊息，再另外加上 SET HEADING OFF 以及 SET FEED OFF 兩個指令即可：

SPOOL D:\Autojob\Restore\ALTER.TXT;

SET HEADING OFF;

SET FEED OFF;

SELECT 'ALTER SYSTEM KILL SESSION' || ' ''' || sid || ',' || serial# || ''';' from v$session where username='SCHEMA_USER';

SPOOL OFF;

@D:\Autojob\Restore\ALTER.TXT;

exit;

產出的結果就會得到漂亮的純指令內容了：

ALTER SYSTEM KILL SESSION '521,415';

ALTER SYSTEM KILL SESSION '522,2428';

ALTER SYSTEM KILL SESSION '529,4564';

ALTER SYSTEM KILL SESSION '531,8493';

ALTER SYSTEM KILL SESSION '534,8057';

ALTER SYSTEM KILL SESSION '545,3068';

ALTER SYSTEM KILL SESSION '550,2691';