紫糯米

2009年9月2日星期三

10g2 無解的排程工作建立問題

晚上在測試區根據 segment advisor 建立排程工作，希望將佔著茅坑不拉屎的多餘空間給釋放出來。但EM這傢伙建議了一堆(132個table)可以釋放空間的table，在我想當然爾全選後，卻在建立工作排程時出現了 Failed to commit: ORA-16612: 屬性 "job_action" 的字串值太長...的錯誤。心中頓時一陣無力，大佬啊~，晚上八點了ㄌㄟ，你還這樣搞我有沒有人性哪？哀，上 metalink找了一下，Oracle說(779137.1, Issues Running EM Advisors Recommendations)此題無解，請等到11g時再幫我解。其主要原因是儲存執行工作所需的SQL語句變數，其型態為VARCHAR2，所以最大只能容納4,000bytes，超過這個大小的字串就死給你看。

哀，大佬啊~八點半了ㄌㄟ

看了workaround建議的分批建立工作，只好這樣啦。

2009年7月29日星期三

手癢的後果-- MAX_SGA_SIZE 的惡夢

今日根據OEM的建議結果，調整DB速度瓶頸之一的方式就是增加 SGA_TARGET 的 Size。SGA_TARGET 建議值為2G多的大小，好大喜功的我心癢手也癢，很自然的就給他照建議調下去了。但Oracle預設的MAX_SGA_SIZE只有1G，所以得再回頭調整 MAX_SGA_SIZE 之後才能再繼續調整SGA_TARGET的大小。

手癢繼續驅動著我，懷疑精神絲毫沒在我腦袋裡閃過，於是我又很自然的透過OEM先將MAX_SGA_SIZE改成2G，然後喜孜孜的重新啟動Oracle後，期待接下來的調整步驟。但是，惡運總是來得比想像中的快，Oracle冷靜的回覆我：

ORA-27100: shared memory realm already exits

果然，手癢沒好下場。

好吧，Google了一下解決方案，作法比想像中的簡單，幾個步驟就行：

找到spfile的位置，將spfile改名
登入成sysdba，以預設的Oracle ini檔啟動DB，指令可能長得如下：

startup pfile='D:\oracle\product\10.2.0\admin\myDB\pfile\init.ora.226200920330'

資料庫就呼嚕呼嚕的起來了。這件事告訴我們，沒把握的事盡量在一個夜深人靜的時候做比較好，否則一堆眼睛可憐兮兮的看著你的時候，壓力可真的不是開玩笑的。 ><"

2009年7月24日星期五

設定SQL 2005 Net Send 服務

說穿了 SQL 2005的Net Send就是執行 Windows 的 Messenger 服務，要啟動它簡單幾個步驟就搞定：

啟動SQL Server主機的Messenger 服務
新增操作員
設定操作員的Net Send的主機位址(IP也可)
開啟操作員登入的Client端主機的Messenger 服務

四個步驟就可以搞定通知服務了。

Transaction log 吃掉你的硬碟時怎麼辦?

前幾天剛好遇到交易紀錄檔長滿了(700多GB)，搞到硬碟空間一滴不剩，相依的應用系統陸續掛點。最後判斷log不重要後，解決的方式就採破釜沉舟的方式進行：

1. 對交易紀錄檔作截斷處理(這動作還不會釋放空間)

backup log mydb with truncate_only

參考：http://technet.microsoft.com/zh-tw/library/ms189085.aspx

2. 壓縮交易紀錄檔空間(這個才會釋放空間)

dbcc shrinkfile(‘mydb_log’,2)　//給我縮到2mb!

參考：http://technet.microsoft.com/zh-tw/library/ms189493.aspx

2009年7月23日星期四

檢閱 Oracle Enterprise Manager Data Control的port number

由於我常記不住這麼簡單的東西，只好再拿來充數了。

關於Oracel Enterprise Manager Data Control的portal number，可以打開$ORACLE_HOME/install/portlist.ini檔的HTTP連接埠設定：

iSQL*Plus HTTP 連接埠號碼 =5560
Enterprise Manager 主控台 HTTP 連接埠 (MyOracleDB) = 5500　//就是這個光～
Enterprise Manager 代理程式連接埠 (MyOracleDB) = 3938

連接到Data Control時就可打上 http://myDBHostName:5500/em 就可連上了~

參考：Accessing the Oracle Enterprise Manager Data Control

2009年6月24日星期三

如何解決Data Pump匯入中途因空間不足而暫停的問題

今天凌晨六點爬起來看Import的結果，結果我一個粗心大意，竟然沒發現Data File空間不足，導致工作Hang在那邊，一副事不關己的等我解決。錯誤的代碼分別ORA-39171為提示你說工作已經暫停（廢話，我用眼睛看不來嗎？），另一個是ORA-01653告訴你空間已經不足。解決的方式很簡單，只要另外再加一個Data File就可。

不過，有趣的是Data File本身的設定引起我的興趣。Data File本身的大小限制乃是受限於DB_BLOCK_SIZE(metalink:Doc ID: 468096.1)，每個版本的Oracle各不同的設定：

以10.2版來說，DB_BLOCK_SIZE就是4096~8192 bytes間的值。而每個Data File的檔案大小以 Maximum Blocks x Maximum DB_BLOCK_SIZE計算。所以10.2版Data File的最大Size = (4194303 x 8192) /1024 /1024 /1024 = 32GB。因此在新增Data File的時候，就要注意到Data File的最大上限為何，否則就會收到 ORA-01144的錯誤（換句話說，並沒有所謂的檔案大小無上限，且其所在的作業系統也會有對檔案的物理限制）。

2009年6月16日星期二

讓你的 SQL 指令斷行吧

常會為了輸出某些管理指令而使用spool 指令，但困擾的是如果需要同一個SQL內產出兩行不同指令，那麼分行就會是個問題。例如像是以下產出的指令就會連成一行：

SELECT 'TRUNCATE TABLE ' || table_name || ' drop usage; ' ||
'UPDATE myTableList SET status = ''F'' WHERE table_name = ''' || table_name || ''';'
FROM dba_tables
WHERE table_name like 'MGM%';

產出結果：

TRUNCATE TABLE MGM01 drop usage; UPDATE myTableList SET status = 'F' WHERE table_name = 'MGM01';

除了醜之外，command mode執行時還會因為兩個指令中間的分號出現 '字元錯誤'的錯誤提示。如果硬是拆分成兩個SQL指令分別產出 truncate table 跟 update 指令，想想就覺得很討厭。所以，最好的方式就是將兩個SQL指令字串斷行即可。

方法很簡單，加上 chr(13)就可了。改變如下：

SELECT 'TRUNCATE TABLE ' || table_name || ' drop usage; ' || chr(13)
'UPDATE myTableList SET status = ''F'' WHERE table_name = ''' || table_name || ''';'
FROM dba_tables
WHERE table_name like 'MGM%';

結案~

2009年9月2日 星期三