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要學的東西太多了，什么時候是個頭啊。上面的方法不是很難理解，但也還沒有完全理解，有機會實際試試。

今天在論壇看到的方法，先記錄下來：
方法一：
在sequential file stage中有個屬性可以ignore第一行。對于footer，如果footer使用了與正文不同的格式，可以用使用transformer stage和 @INROWNUM stage來將footer去掉。
方法二：
在sequential file的filter option中使用sed -e '$d' -e '1d'來講header和footer去掉。
方法三：
寫個before job subroutine，可以先對這個文件做各種處理，不過我想也是subroutine中調用DSExecute sed -e '$d' -e '1d'。當然Basic中也有專門對sequential file處理的函數。

Orchadmin is a command line utility provided by datastage to research on data sets.
The general callable format is : $orchadmin [options] [descriptor file]

1. Before using orchadmin, you should make sure that either the working directory or the $APT_ORCHHOME/etc contains the file “config.apt” OR

The environment variable $APT_CONFIG_FILE should be defined for your session.
Orchadmin commands

The various commands available with orchadmin are
1. CHECK: $orchadmin check

Validates the configuration file contents like , accesibility of all nodes defined in the configuration file, scratch disk definitions and accesibility of all the nodes etc. Throws an error when config file is not found or not defined properly

2. COPY : $orchadmin copy
Makes a complete copy of the datasets of source with new destination descriptor file name. Please not that

a. You cannot use UNIX cp command as it justs copies the config file to a new name. The data is not copied.

b. The new datasets will be arranged in the form of the config file that is in use but not according to the old confing file that was in use with the source.

3. DELETE : $orchadmin <> [-f -x] descriptorfiles….
The unix rm utility cannot be used to delete the datasets. The orchadmin delete or rm command should be used to delete one or more persistent data sets.
-f options makes a force delete. If some nodes are not accesible then -f forces to delete the dataset partitions from accessible nodes and leave the other partitions in inaccesible nodes as orphans.
-x forces to use the current config file to be used while deleting than the one stored in data set.

4. DESCRIBE: $orchadmin describe [options] descriptorfile.ds
This is the single most important command.
1. Without any option lists the no.of.partitions, no.of.segments, valid segments, and preserve partitioning flag details of the persistent dataset.
-c : Print the configuration file that is written in the dataset if any
-p: Lists down the partition level information.
-f: Lists down the file level information in each partition
-e: List down the segment level information .
-s: List down the meta-data schema of the information.
-v: Lists all segemnts , valid or otherwise
-l : Long listing. Equivalent to -f -p -s -v -e

5. DUMP: $orchadmin dump [options] descriptorfile.ds
The dump command is used to dump(extract) the records from the dataset.
Without any options the dump command lists down all the records starting from first record from first partition till last record in last partition.
-delim ‘’ : Uses the given string as delimtor for fields instead of space.
-field : Lists only the given field instead of all fields.
-name : List all the values preceded by field name and a colon
-n numrecs : List only the given number of records per partition.
-p period(N) : Lists every Nth record from each partition starting from first record.
-skip N: Skip the first N records from each partition.
-x : Use the current system configuration file rather than the one stored in dataset.

6. TRUNCATE: $orchadmin truncate [options] descriptorfile.ds
Without options deletes all the data(ie Segments) from the dataset.
-f: Uses force truncate. Truncate accessible segments and leave the inaccesible ones.
-x: Uses current system config file rather than the default one stored in the dataset.
-n N: Leaves the first N segments in each partition and truncates the remaining.

7. HELP: $orchadmin -help OR $orchadmin -help
Help manual about the usage of orchadmin or orchadmin commands

當一條記錄過來，某個字段為空，而在transformer中又對該字段trim了，由于該字段為空，不能trim，所以DataStage會認為這是個錯誤，從而把這個記錄drop了，這與實際業務不符合，非主鍵字段為空并不能就把這條記錄drop了。我們可以通過寫一個判斷來解決該問題：if LK_1.EMAIL <> '' then trim(LK_1.EMAIL) else LK_1.EMAIL

1 before/after job和before/after stage,可以執行shell，命令行以及一些DataStage API，如DSJobReport
2 job sequence中有個stage，可以在里面寫控制job調度的地方
3 每個job的properties中有個job control tab
4 命令行可以執行、導入job等，它通過dsjob實現，在DS Manager的文檔中還講了有專門的命令行來導入job
5 可以編寫shell來控制job，對dsjob命令做封裝，可以傳入參數等。
對于上面這些概念還是很模糊，先記錄在此。

今天又碰到新問題，在transformer中，進去是有很多record，出來之后為0條record，用peek，看了一下，進去的數據的某個字段數據全為null，而在transformer中對此字段trim了，改為不trim就可以了。

今天遇到一個問題，job不停的在那里運行，然后link上的數據顯示各個環節都是正確的，包括最后插入數據庫的link上也顯示了數據，但是最后數據庫里并沒有數據。在Director的log中，日志在從兩個源文件把所有數據load出來完之后，日志就死在那里了。
以前這個job是正確的，昨天由于重新load其中一個源文件的元數據，所以出現了上述問題。所以先前以為是由于load的新的源數據有問題，就從此處來找問題的原因，并且認為可能是改了元數據，在其他地方映射的時候有位置不對的地方，所以整了很久。因為以前是好好的，然后又以為是服務器的問題。

這都是定勢思維的錯誤，然后又一急，所以浪費了很多時間，其實很多時候都是這樣，出了問題我們不能理性的好好思考。

其實問題很簡單：
如果我們按照正常邏輯來分析的話，既然不能讀入數據庫，肯定是數據不符合數據庫對數據的約束，包括主鍵啊，非空啊，本問題就是由于在stage的不斷流轉中產生了很多空格，使得最后待插入的數據長度遠遠大于數據庫中定義的字段長度。由于在那里不斷reject，所以影響了速度，job一直在那里運行。最后用APT_STRING_PADDER,將其設為0x0（用null代替空格）搞定。
ps：在插入數據庫時使用一個reject文件對查錯有好處，這樣能看到reject是些什么數據，然后就能知道為什么被reject了。
同時我們可以得出如果最后插入數據庫時很多數據被reject，但是你并沒有用一個reject文件來接收這些reject掉的數據，將使得job基本處于停滯狀態。

當一個Job跑到一半終止了要還原，在DS Director中主要有三種方法來還原：
1 Job-----Reset
2 Job-----Clear Status File
3 Job-----Cleanup Resource
具體細節也不懂，有時間慢慢研究