Sql_Trace File Identifier

我們設置了sql_trace為true之后，trace file會dump到udump中，但是該目錄下也許已經有很多trace file了，或者其他session也設置了sql_trace為true，也在產生trace file。如何能迅速找到你的session產生的trace file呢？我們可以通過如下語句設置Sql_Trace File Identifier：

這樣你的session產生的trace file就會以設置的identifier為后綴。

 

然后我們可以看到udump下生成的trace file文件名為：test_ora_4168_test_identifier.trc

Sample Block

抽樣表掃描（sample table scan）只讀取一個表的部分數據。其實我們只選擇表的部分數據的話，可以用rownum來限制也很方便。但是考慮如下情況：
A表和B表join，我只想A表的部分數據去連接B表，此時用sample就方便的多。如果用rownum就需要用一個subquery。

抽樣表掃描有兩種形式，一種是抽樣表中行數的一個百分比，一個是抽樣表中塊數的一個百分比。注意都是百分比。語法如下：

也可以在視圖上使用SAMPLE。

Kimball在他的ETL Toolkit一書中，一直強調：對于有外鍵約束的表，為了提高load的速度，可以先將外鍵約束disable，加載完成后再enable（當然另外一個原因是進入數據倉庫的數據都是規范的，甚至可以考慮不使用外鍵約束，即違反約束的數據在Transformation部分就應該解決掉，當然這是設計問題了）。ps:另外兩個提高load速度的方法分別為使用sql loader和insert、update分離。當時還不是明白這個過程怎么具體實現，今天看《oracle concept》看到下面話終于明白了一些：
Flexibility for Data Loads and Identification of Integrity Violations
You can disable integrity constraints temporarily so that large amounts of data can be loaded without the overhead of constraint checking. When the data load is complete,you can easily enable the integrity constraints, and you can automatically report any new rows that violate integrity constraints to a separate exceptions table.
看來oracle這點上做的比較完善，還可以將違反完整性約束的數據自動記錄到一個exception表中。

今天google分析函數row_number()的時候發現的，覺得很好：

表demo是重復拷貝自dba_objects，有88萬左右，不重復的是27323，沒有索引
方法一：delete from demo a where a.rowid <> (select max(rowid) from demo b where
b.object_id=a.object_id);
耗時：幾個小時以上
方法二： delete from demo where rowid in
(select rid from
(select rowid rid,row_number() over(partition by object_id order by rowid) rn
from demo)
where rn <> 1 );
耗時：30秒
方法三： create table demo2 as
select object_id,owner... from
(select demo.*,row_number() over(partition by object_id order by rowid) rn from demo)
where rn = 1;
truncate table demo; insert into demo select * from demo2; drop table demo2;
共耗時： 10秒，適合大數據量的情況，產生更少回滾量；

學到了分析函數row_number(),對于object_id和rowid也有了一些認識。oracle要學的東西太多了，什么時候是個頭啊。上面的方法不是很難理解，但也還沒有完全理解，有機會實際試試。