728x90

인포믹스 프로시저에서는 UNLOAD나 OUTPUT 문장을 실행할 수 없습니다. 이를 대체하려면 External Table 기능을 사용해 데이터를 파일로 내려받는 방법이 있습니다.

참고로 External Table 기능은 인포믹스 11.5 버전부터 사용할 수 있습니다.

/work2/INFORMIX/1210FC13/skjeong]cat myproc.sql
DROP PROCEDURE MYPROC();
CREATE PROCEDURE MYPROC()
CREATE EXTERNAL TABLE load_tmp
(
   load_stmt char(1024)
)
USING (
DATAFILES    ("DISK:/tmp/load.sql"),
DELIMITER ";"
);
INSERT INTO load_tmp SELECT 'load from ' || trim(tabname) || ' insert into ' || trim(tabname) FROM systables WHERE tabid > 99 AND tabtype = 'T';
DROP TABLE load_tmp;
END PROCEDURE;
/work2/INFORMIX/1210FC13/skjeong]dbaccess stores_demo myproc.sql
Database selected.
Routine dropped.
Routine created.
Database closed.
/work2/INFORMIX/1210FC13/skjeong]cat /tmp/load.sql
load from customer insert into customer;
load from orders insert into orders;
load from manufact insert into manufact;
load from stock insert into stock;
load from items insert into items;
load from state insert into state;
load from call_type insert into call_type;
load from cust_calls insert into cust_calls;
load from catalog insert into catalog;
...
load from calendarpatterns insert into calendarpatterns;
load from calendartable insert into calendartable;
load from tsinstancetable insert into tsinstancetable;
load from tscontainertable insert into tscontainertable;
load from tscontainerusageactivewindowvti insert into tscontainerusageactivewindowvti;
load from tscontainerusagedormantwindowvti insert into tscontainerusagedormantwindowvti;
load from tscontainerwindowtable insert into tscontainerwindowtable;
load from ts_data insert into ts_data;
load from customer_ts_data insert into customer_ts_data;
load from ts_data_v insert into ts_data_v;
load from ts_data_multiplier_v insert into ts_data_multiplier_v;
load from spatial_references insert into spatial_references;
load from geometry_columns insert into geometry_columns;
load from st_units_of_measure insert into st_units_of_measure;
load from se_metadatatable insert into se_metadatatable;
load from se_views insert into se_views;
load from ts_data_location insert into ts_data_location;
load from tab insert into tab;
load from warehouses insert into warehouses;
load from classes insert into classes;
load from dbms_alert_events insert into dbms_alert_events;
load from dbms_alert_registered insert into dbms_alert_registered;
load from dbms_alert_signaled insert into dbms_alert_signaled;
load from employee insert into employee;
load from employee3 insert into employee3;
load from tab0 insert into tab0;
load from l_nextval insert into l_nextval;
load from stock3 insert into stock3;
load from test_bk insert into test_bk;
load from test4 insert into test4;
load from test1 insert into test1;
load from stock2_trans insert into stock2_trans;
load from catcopy insert into catcopy;
load from test insert into test;
load from test2 insert into test2;
load from test3 insert into test3;
load from stock2 insert into stock2;

 

프로시저 작성은 아래 문서를 참고했습니다.

https://stackoverflow.com/questions/31992388/using-an-unload-statement-in-an-informix-stored-procedure

728x90
728x90

By specifying the CURSOR file type when using the LOAD command, you can load the results of an SQL query directly into a target table without creating an intermediate exported file.

Additionally, you can load data from another database by referencing a nickname within the SQL query, by using the DATABASE option within the DECLARE CURSOR statement, or by using the sqlu_remotefetch_entry media entry when using the API interface.

There are three approaches for moving data using the CURSOR file type. The first approach uses the Command Line Processor (CLP), the second the API, and the third uses the ADMIN_CMD procedure. The key differences between the CLP and the ADMIN_CMD procedure are outlined in the following table.

Table 1. Differences between the CLP and ADMIN_CMD procedure.
DifferencesCLPADMIN_CMD_procedure
SyntaxThe query statement as well as the source database used by the cursor are defined outside of the LOAD command using a DECLARE CURSOR statement.The query statement as well as the source database used by the cursor is defined within the LOAD command using the LOAD from (DATABASE database-alias query-statement)
User authorization for accessing a different databaseIf the data is in a different database than the one you currently connect to, the DATABASE keyword must be used in the DECLARE CURSOR statement. You can specify the user id and password in the same statement as well. If the user id and password are not specified in the DECLARE CURSOR statement, the user id and password explicitly specified for the source database connection are used to access the target database.If the data is in a different database than the one you are currently connected to, the DATABASE keyword must be used in the LOAD command before the query statement. The user id and password explicitly specified for the source database connection are required to access the target database. You cannot specify a userid or password for the source database. Therefore, if no userid and password were specified when the connection to the target database was made, or the userid and password specified cannot be used to authenticate against the source database, the ADMIN_CMD procedure cannot be used to perform the load.

To execute a LOAD FROM CURSOR operation from the CLP, a cursor must first be declared against an SQL query. once this is declared, you can issue the LOAD command using the declared cursor's name as the cursorname and CURSOR as the file type.

For example:

  1. Suppose a source and target table both reside in the same database with the following definitions:
    Table ABC.TABLE1 has 3 columns:
    • ONE INT
    • TWO CHAR(10)
    • THREE DATE
    Table ABC.TABLE2 has 3 columns:
    • ONE VARCHAR
    • TWO INT
    • THREE DATE
    Executing the following CLP commands will load all the data from ABC.TABLE1 into ABC.TABLE2:
    DECLARE mycurs CURSOR FOR SELECT TWO, onE, THREE FROM abc.table1
       LOAD FROM mycurs OF cursor INSERT INTO abc.table2
    Note: The above example shows how to load from an SQL query through the CLP. However, loading from an SQL query can also be accomplished through the db2Load API. Define the piSourceList of the sqlu_media_list structure to use the sqlu_statement_entry structure and SQLU_SQL_STMT media type and define the piFileType value as SQL_CURSOR.
  2. Suppose the source and target tables reside in different databases with the following definitions:
Table ABC.TABLE1 in database 'dbsource' has 3 columns:
  • ONE INT
  • TWO CHAR(10)
  • THREE DATE
Table ABC.TABLE2 in database 'dbtarget' has 3 columns:
  • ONE VARCHAR
  • TWO INT
  • THREE DATE
Provided that you have enabled federation and cataloged the data source ('dsdbsource'), you can declare a nickname against the source database, then declare a cursor against this nickname, and invoke the LOAD command with the FROM CURSOR option, as demonstrated in the following example:
CREATE NICKNAME myschema1.table1 FOR dsdbsource.abc.table1 
DECLARE mycurs CURSOR FOR SELECT TWO,ONE,THREE FROM myschema1.table1 
LOAD FROM mycurs OF cursor INSERT INTO abc.table2 
Or, you can use the DATABASE option of the DECLARE CURSOR statement, as demonstrated in the following example:
DECLARE mycurs CURSOR DATABASE dbsource USER dsciaraf USING mypasswd 
FOR SELECT TWO,ONE,THREE FROM abc.table1 
LOAD FROM mycurs OF cursor INSERT INTO abc.table2

Using the DATABASE option of the DECLARE CURSOR statement (also known as the remotefetch media type when using the Load API) has some benefits over the nickname approach:

Performance

Fetching of data using the remotefetch media type is tightly integrated within a load operation. There are fewer layers of transition to fetch a record compared to the nickname approach. Additionally, when source and target tables are distributed identically in a multi-partition database, the load utility can parallelize the fetching of data, which can further improve performance.

Ease of use

There is no need to enable federation, define a remote datasource, or declare a nickname. Specifying the DATABASE option (and the USER andUSING options if necessary) is all that is required.

While this method can be used with cataloged databases, the use of nicknames provides a robust facility for fetching from various data sources which cannot simply be cataloged.

To support this remotefetch functionality, the load utility makes use of infrastructure which supports the SOURCEUSEREXIT facility. The load utility spawns a process which executes as an application to manage the connection to the source database and perform the fetch. This application is associated with its own transaction and is not associated with the transaction under which the load utility is running.

Note:
  1. The previous example shows how to load from an SQL query against a cataloged database through the CLP using the DATABASE option of the DECLARE CURSOR statement. However, loading from an SQL query against a cataloged database can also be done through the db2LoadAPI, by defining the piSourceList and piFileTypevalues of the db2LoadStruct structure to use the sqlu_remotefetch_entry media entry and SQLU_REMOTEFETCH media type respectively.
  2. As demonstrated in the previous example, the source column types of the SQL query do not need to be identical to their target column types, although they do have to be compatible.

Restrictions

When loading from a cursor defined using the DATABASE option (or equivalently when using the sqlu_remotefetch_entry media entry with thedb2Load API), the following restrictions apply:
  1. The SOURCEUSEREXIT option cannot be specified concurrently.
  2. The METHOD N option is not supported.
  3. The usedefaults file type modifier is not supported.



http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dm.doc/doc/c0005437.html

728x90
728x90

다중 데이터베이스 파티션을 스캔하는 테이블을 걸쳐 컬럼 식별자 없는 ASCII(ASC) 및 컬럼 식별자가 있는 ASCII(DEL) 파일만을 파티션할 수 있습니다. PC/IXF 파일은 분배할 수 없습니다. PC/IXF 파일을 다중 데이터베이스 파티션에 걸쳐 있는 테이블로 로드하기 위해 먼저 DB2_PARTITIONEDLOAD_DEFAULT=NO 환경 변수를 설정한 후 LOAD_ONLY_VERIFY_PART 모드를 사용하여 단일 데이터베이스 파티션에 있는 테이블로 파일을 로드할 수 있습니다. 그런 다음, CURSOR 파일 유형을 사용하여 로드 조작을 수행하여 데이터를 다중 데이터베이스 파티션을 통해 분산된 테이블로 이동할 수 있습니다. 또한 LOAD_ONLY_VERIFY_PART 모드에서 로드 조작을 사용하여 다중 데이터베이스 파티션을 통해 분산된 테이블로 PC/IXF 파일을 로드할 수도 있습니다.


http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0004613.htm

728x90

'Db2 > Db2 reference' 카테고리의 다른 글

DB2_COMPATIBILITY_VECTOR registry variable  (0) 2011.04.21
HADR - 고가용성 재해복구  (0) 2011.04.18
db2 link  (0) 2011.04.07
[교육정리] transaction log  (0) 2011.03.17
[교육정리] 데이터 이관  (0) 2011.03.17
728x90

SQL*LOADER 사용시에 여러가지 적절한 옵션 사용과 테이블에 대한 설정값들을 변경시켜줌으로써 
많은 성능 향상을 가져올수 있다.

다음은 그 권장되는 설정법들을 설명한 것이다.

1. DIRECT PATH LOAD를 사용한다. Direct path load는 load되는 테이블이나 파티션에 exclusive access를 요구한다. 
추가적으로 트리거는 자동으로 disable되고 제약조건은 로드가 완료될때까지 defer(연기) 된다.
 

2. direct path load로 데이타를 로드시에 모든 CHECK 와 REFERENCE 무결성 제약조건은 자동으로 DISABLE된다. 
그러나 그밖의 다른 타입의 제약조건 NOT NULL, UNIQUE, PRIMARY KEY 조건들은 반드시 DISABLE 시켜준다. 
작업 완료후에 수동으로 enable시켜준다. 
 

3. 정렬된 순서로 데이타를 load한다. 미리 sorting 된 데이타는 정렬에 필요한 공간temporary 영역 사용을 최소화한다. 
SQL*LOADER 옵션에서 SORTED INDEXES 를 CONTROL파일에 기술한다.
 

4. 인덱스 MAINTANCE 를 연기(DEFERRING)하라. 인덱스는 데이타가 insert하거나 delete 또는 key 컬럼이 업데이트 
될때마다 자동으로 maintance 를 실시한다.따라서 많은 양의 데이타를 load할때 작업이 종료된 후에 maintance를 한다면 
좀더 빠를 것이다. SKIP_INDEX_MAINTENANCE = TRUE  를 설정하면 인덱스 세그먼트의 상태가 “ INDEX UNUSABLE”상태가 
되어있더라도 LOADER시작시에 인덱스 MAINTANCE를 SKIP한다. 
 

5. UNRECOVERABLE 을 사용해서 REDO 생성을 DISABLE시킨다. 모든 recover 시에는 redo log파일이 필요하다. 
그러나 redo log 생성은 부하가 많기 때문에 disable시키면 그만큼 속도는 빠르게 된다. 
그러나 LOADER 작업 중간에 FAILURE 가 발생한다면 처음부터 load작업을 다시 해야한다. 
따라서 리두로그를 생성하지 않기때문에 loader 작업 후에는 반드시 백업하도록 한다.
 

6. 단일 파티션에 loading 하도록 한다. 파티션 테이블에 데이타 load시 기타 사용자는 다른 파티션 에 접근 할 수 있다. 
APRIL 파티션을 로드시에 jan 에서 april 까지 쿼리를 실행하는 유저를 차단하지 못한다. 따라서 부하가 증가한다. 
 

7. Parallel 로 로드를 한다. 파티션으로 구성되어 있다면 parallel 로 다중 파티션을 로드할 수 있다. 
 

8. STREAMSIZE 파라미터는 SQL*LOADER client 에서 oracle server로 direct path stream buffer 의 크기(bytes)를 
지정한다. 기본값은 256000 bytes 이다.  
또한 columnarrayrows 또한 direct path column array 에 전송하는 row의 갯수를 지정한다.기본값은 5000이다.


9. 만일 load되는 데이타가 중복되는 날자값을 많이 가지고 있다면 DATE_CACHE 파라미터를 설정해서 DIRECT PATH LOAD
시에 더 나은 성능을 보장할 수 있다. CACHE에 CONVERION 되는 DATE 의 사이즈(엔트리)를 지정한다. (기본값은 1000) 

728x90

+ Recent posts