3 1 INDEX(T1 T1_I1)
很不幸,我們還將注意到它現在包含3行如下形式的提示:
2 1 NOREWRITE
1 2 NOREWRITE
1 1 NOREWRITE
而原來我們只有兩行:
2 1 NOREWRITE
1 1 NOREWRITE
我們引入了一個新的提示,也就是”Stage 1,Node 2″.我不敢說我確切的知道這是什么意思,但是它一定與這樣一個事實有關,為了在另外一個Schema解析優化這個查詢,Oracle執行了一個額外的步驟來將視圖引用轉換成基礎表的引用.
雖然目前這不會導致存儲概要無法正確使用(或者如同它在這個簡單的例子中這樣),誰又能說Oracle在將來的版本又會有多挑剔呢.
舊方法(2)
因為視圖引入了一個可能在將來版本變成錯誤的異常,我們不得不更加挑剔. 讓我們試試下面的這種方法:
Create a new schema.
Create table T1 in that schema.
Create ONLY the index T1_I1.
Rebuild the outline in that schema
如果比較存儲概要重建前后user_outline_hints的詳細內容(必須重新登錄到原來的Schema來做這件事),我們將發現除了我們想要改變的那一行,它們是完全一樣的.重新登錄回原來的Schema,通過清空共享池以及打開存儲概要做一個常規檢查,我們將會發現修改后的存儲概要已經被使用了.
然而,還有一個潛在的威脅,不過這一次更加隱蔽.再回去看圖-2中出現在Oracle 9中的新字段的定義-你認為字段user_table_name中保存的值將會是什么啊?它應該是有限制的表名稱,例如:
{User_name}.{table_name}
在我們的例子中,這將告訴Oracle表T1實際上是一個屬于新的Schema的表,而不是原來的Schema下面的表.即使Oracle確實在使用這個存儲概要,這個表里的信息也充分說明Oracle是在錯誤的對象上面應用這個存儲概要.
另外,它現在現在有效,但是為什么有這個信息在這兒呢-可能是為了將來的版本增強做準備呢.
可靠的賭注
看來,要生成存儲概要,而又不面臨將來的風險就只有一種方法了,那就是盡可能的真實.
在這個示例中,你需要刪除主鍵索引,生成執行計劃,然后替換掉主鍵.
當然,你可能不想在生產環境做這件事,即使你在生產環境做了,存儲概要也有可能選擇走全表掃描(而不是走你想要的那個索引).
底線是你必須至少在另一個數據庫中有一個這個Schema的空閑拷貝,接著需要非常小心的操作這個拷貝以得到需要的存儲概要.一旦得到這個存儲概要,你就可以從一個數據庫導出它并將其導入另外一個數據庫.
例如:在這個空閑的數據庫上,刪除主鍵以避免PK唯一掃描就是可行的.如果Oracle并沒有自動的采用另外一個索引,你可以對系統說各種謊言,諸如:
將optimizer_mode改成first_rows_1
構造數據使得列N1上的數據是唯一的.(不過,不要將其改成唯一索引,這樣生成出來的存儲概要將是unique scan而不是range scan了).
使用dbms_stats來使這個索引獲得一個難以置信的clustering_factor.
調整參數optimiser_index_caching來告訴系統,這個索引已經完全被緩存.
調整optimiser_index_cost_adj來告訴系統,多塊讀要比單塊讀要慢100倍.
使用dbms_stats修改aux_stats$表來達到上一條同樣的宣稱效果,并且添加這樣一個事實,一次多塊讀的典型大小為2個塊.
重建這個索引以包含where從句中的所有字段.
給定存儲概要表中的內容,假使表的所有者不變,對象類型不變以及不改變索引的唯一度,幾乎任何事情都可以做. 如果你可以構造一個數據集與環境來生成一份與生產系統沒有內部不一致的存儲概要,那么你就可以以任何方式來欺騙系統.
結論
相對于Oracle 8來講,在Oracle 9中進入存儲概要的信息變更更加精細了.之前可以非常容易也很明顯無風險的”調整”存儲概要的方法,現在還仍然可以工作,但是Oracle 9中收集的巨量的附加信息表明,之前的那種方法現在可能會給將來留下隱患.
雖然Oracle 9中引入了一個編輯存儲概要的包,但它當前還只是局限在交換表的連接順序.除了使用第二套系統來調整索引(通過改變環境參數以及人造的統計信息)外, 看似不存在安全的干預存儲概要的方法.
參考文獻
Oracle 9i Release 2: Database Performance Tuning Guide and Reference - Chapter 7.
Oracle 9I Release 2: Supplied PL/SQL Packages and Types Reference - Chapters 41 - 42
原文轉自:http://blogread.cn/it/article/1030