Sql_Trace File Identifier

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

這樣你的session產(chǎn)生的trace file就會以設置的identifier為后綴。

 

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

Sample Block

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

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

也可以在視圖上使用SAMPLE。

Kimball在他的ETL Toolkit一書中，一直強調(diào)：對于有外鍵約束的表，為了提高load的速度，可以先將外鍵約束disable，加載完成后再enable（當然另外一個原因是進入數(shù)據(jù)倉庫的數(shù)據(jù)都是規(guī)范的，甚至可以考慮不使用外鍵約束，即違反約束的數(shù)據(jù)在Transformation部分就應該解決掉，當然這是設計問題了）。ps:另外兩個提高load速度的方法分別為使用sql loader和insert、update分離。當時還不是明白這個過程怎么具體實現(xiàn)，今天看《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這點上做的比較完善，還可以將違反完整性約束的數(shù)據(jù)自動記錄到一個exception表中。

今天google分析函數(shù)row_number()的時候發(fā)現(xiàn)的，覺得很好：

表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秒，適合大數(shù)據(jù)量的情況，產(chǎn)生更少回滾量；

學到了分析函數(shù)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中調(diào)用DSExecute sed -e '$d' -e '1d'。當然Basic中也有專門對sequential file處理的函數(shù)。

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了，這與實際業(yè)務不符合，非主鍵字段為空并不能就把這條記錄drop了。我們可以通過寫一個判斷來解決該問題：if LK_1.EMAIL <> '' then trim(LK_1.EMAIL) else LK_1.EMAIL

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

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

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

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

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

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