意外解掉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時轉譯用。對應的函式名稱大體上是大同小異的，應該不會造成太大的困擾才對。還不錯的小品，分享囉...