pajama

시스템 환경

O/S : Windows 2003 Enterprise Edition (5.20.3790 SP2)

CPU : x86 Family 15 Mode 6 Stepping 8 GenuineIntel - 3333Mhz * 8EA (dual core)

RAM : 32 GB

S/W : IBM Optim 7.3.1

대상 

O/S : IA64/HPUX 64.0.9.0.1

DBMS : Oracle Database 10g Enterprise Edition Release 10.2.0.4 - 64bit Production

대상 데이터 크기

TABLE : 360 GB

INDEX : 200 GB

LOB SEGMENT : 1 TB

-Extract Process

1. Client-Side OCI Error id=Unknown RC value

=> DB Alias의 코드셋 설정을 확인한다.

2. Snapshot too old

=> 데이터 추출이 길어지는 경우에 오류가 발생할 수 있다. 추출하는 범위를 축소해본다.

(데이터 변경으로 인한 언두(롤백) 테이블 스페이스가 부족하거나 undo_retention 파라미터 값이 낮아서 발생할 수 있다.)

3. ORA-00904: "X"."USER_PROP"."GETCLOBVAL": 부적합한 식별자

=> 큐테이블을 추출하려는 경우에 오류가 발생한다.

4. The following unexpected error occurred: RC=17423.

=> Post Compression 옵션을 적용할 때 Extract가 끝날 때 오류가 발생한다.

5. ORA-24381: error(s) in array DML

=> Database Connections 파라미터를 1로 조정해본다. 

6. The Extract Request has validation errors.

The data type of column 'TEXTKEY' in table

'PORTALDB.KM_USER.DR$CTX_TKM_KID_01$K' is not supported.

=> 데이터 타입이 ROWID인 경우 발생한다. (Extract 수행 불가)

-Load Process

1. There are insufficient resources available for Optim to run the request. Review the Resource Estimation Analysis section of the report and make additional resources available and rerun the request. 

=> Load Request를 실행하였을 때 디스크 또는 스토리지 여유 공간이 부족할 때 오류가 발생한다.

Compressㅇ File 옵션에서 Delimiter를 지정하면 된다.

특이사항

LOB 컬럼을 포함한 테이블을 로드할 경우, 또는 건수, 사이즈가 작아도 오류가 발생하는데 정확한 원인을 알 수 없다.

실행이 될 때도 있다가 안되기도 한다.

2. Loader ended with ExitCode 1(또는 Loader ended with ExitCode 2)

=> 테이블 스키마 형상이 다르거나 제약조건, 테이블 락 등을 의심해 볼 수 있다.

또는 로드 중 constraint 위배 등 sql loader의 오류를 확인한다.

3. Error while writting to F:\OptimData\data\TEST_BOSS\PROD_BOSS_ORABRM_ZST_SETTL_BW_RAWCDR.000 (Reason:It caused an unexpected error while writing to the drive.)

=> 디스크 쓰기 경합이 심각한 수준이거나 디스크에 여유 공간이 부족한 경우 오류가 발생한다.

4. The LOB-type column 'HEAD2' length is zero. This is not accepted by the Oracle Loader.

=> Load Request의 General 탭에서 File Attachments에서 Process as Columns를 선택한다.

이 옵션을 적용하면 LOB 컬럼별로 파일을 생성하지 않는다. LOB 컬럼 사이즈가 4,000 바이트를 초과하면 LOB 컬럼별로 파일을 생성한다.

도움말 발췌)File Attachments

If the source file contains file attachment pseudocolumns, indicate how the Load Process should proceed.

Fail

If a source file contains file attachment pseudocolumns, fail the Load Process.

Process As Columns

Process file attachment pseudocolumns as normal table columns.

If matching columns do not exist in the table, the pseudocolumns are ignored.

5. inline LOBs

=> Load Request에서 CLOB 또는 BLOB의 크기가 4,000 바이트를 넘지 않는다면 적용하는 것이 유리하다.

이 옵션을 적용하지 않으면 LOB 타입의 컬럼 데이터 개수만큼 파일이 생성된다. (Process as Columns 옵션 선택했을 때 제외)

Note. LOB 컬럼을 포함한 테이블 건수가 매우 많다면 조건을 지정해 받는 것이 최선이다. 범위를 축소하여 건수가 줄었다면 LOB 컬럼 크기가 4,000 바이트인지 확인하여 수십만건 이상일 경우 INSERT를 수행하거나 범위를 더욱 축소하여 LOAD를 시도해본다. 

6. Load Request was cancelled by the user. Can not create file .

=> LOB 컬럼을 로딩하면서 레코드 개수만큼 파일이 생성되어 오류가 발생하는 것으로 추정.

7. 예외처리시 Additional Parameter에 errors 파라미터를 명시하여 오류제한을 최대한 높여 작업한다. (기본 값 50)

=> 예. errors=999999999

8. SQL*Loader-951: Error calling once/load initialization

ORA-00604: error occurred at recursive SQL level 1

ORA-01031: insufficient privileges

=> Direct Path 로드 수행시 DBA ROLE 또는 LOCK ANY TABLE 권한이 필요하다.

9. Error converting data into loader file format.

=> Column Map을 지정하여 데이터 로드를 수행할 때 간혹 발생하는 오류. Convert Request를 수행하여 로드하면 해결된다.

10. /ERROR Unexpected response from internal component, RC:-1

=> 테이블 스페이스 공간이 부족한 경우 발생할 수 있는 오류.

11. The Server process for the Load Request has abnormally terminated.

Optim Server OPTIMSVR abnormally terminated or was cancelled by user

=> LOB컬럼이 있는 데이터를 로드할 때 Compressed Files (Delimiter 지정) 옵션 적용시 오류 발생,

다른 Delimiter를 선택하거나, Compressed Files 옵션을 적용하지 않고 수행한다.

12. The selected character delimiter was found in Table/Column

TEST_BOSS.ORABRM.EVENT_T:NAME, Row: 14911568.

Please respecify a delimiter which is not in any column data.

Error converting data into loader file format.

-Insert Process

1. Data Base Error Detected in OPTIMDB.USMART.SS_COMM_FEEDBACK:

ORA-04098: 'USMART.TR_AFT_CUD_SS_CO_FEEDBACK' 트리거가 부적합하며 재검증을 실패했습니다

=> 트리거를 비활성화하지 않았을 때 발생하는 오류. IMP_FULL_DATABASE ROLE 또는 ALTER ANY TRIGGER 권한이 필요하다.

archecker 유틸리티는 onbar/ontape 드라이버를 통해 아카이브(archive)에서 테이블을 추출(extract)한다.

복원을 수행하기 위해서는 다음 내용을 지정한 스키마 커맨드 파일(schema command file)을 사용한다.

• 원본 테이블
• 대상 테이블
• 테이블 스키마
• 데이터베이스
• 외부 테이블(external table)
• 특정 시점으로 테이블 복원
• 기타 옵션

스키마 커맨드 파일을 설정하기 위한 두 가지 방법 :

1. archecker 구성 파일(ac_config)에 AC_SCHEMA 구성 매개 변수를 설정한다. 

2. -f cmdname 옵션을 사용하며 AC_SCHEMA 구성 매개 변수는 무시한다. (우선 순위 높음)

스키마 커맨드 파일은 다음 구문을 사용하여 작성할 수 있다.

• CREATE TABLE
• DATABASE
• INSERT INTO
• RESTORE
• SET

CREATE TABLE은 원본 테이블과 대상 테이블을 지정하는 구문이다. 구문 형식은 IBM Informix SQL 형식을 따른다.

원본 테이블에 대한 구문은 백업을 수행했을 당시의 테이블 형상과 동일해야 한다.

원본 테이블에는 동의어(synonym)나 뷰(view)를 지정할 수 없다. 원본 테이블의 형상에는 컬럼과 스토리지 옵션만이 필요하다. 익스텐트(extent) 크기, 잠금(lock) 모드 같은 옵션은 무시된다. 

원본 테이블이 분할(fragmented)되어 있다면, 원본 테이블의 데이터가 있는 모든 dbspace를 지정해야 한다. archecker 유틸리티는 스키마 커맨드 파일에 지정한 dbspace에서만 데이터를 추출한다. 원본 테이블에 제약조건(constraints), 인덱스, 트리거 등이 포함되어 있으면 복원하는 동안에는 자동으로 비활성화된다. 외래키(foreign constraints)의 경우에는 참조하는 테이블의 제약조건 또한 비활성화된다. 복원이 완료되면 제약조건, 인덱스, 트리거가 활성화된다. 빠른 성능으로 복원을 수행하려면 복원하기 전에 제약조건, 인덱스, 트리거를 생성하지 않도록 한다.

마찬가지로 대상 테이블도 커맨드 파일에 지정해야 한다. 대상 테이블이 복원 시점에 존재하지 않으면, 커맨드 파일에 지정한 구문이 실행된다. 대상 테이블이 존재한다면 커맨드 파일에 지정한 형상과 일치해야 한다. 데이터는 기존 테이블에 추가된다.

Examples

원본 테이블과 대상 테이블의 형상은 동일하지 않아도 된다. 다음 예제는 원본 데이터를 추출하여 대상 테이블을 분할 형태로 구성하는 방법이다. 

CREATE TABLE source (col1 integer, ...) IN dbspace1;
CREATE TABLE target (col1 integer, ...) 
   FRAGMENT BY ｅxpression
      MOD(col1, 3) = 0 in dbspace3),
      MOD(col1, 3) = 1 in dbspace4),
      MOD(col1, 3) = 2 in dbspace5);
INSERT INTO target SELECT * FROM source;

테이블을 외부 테이블로 구성하려면 CREATE EXTERNAL TABLE 구문을 사용한다.

Syntax

스키마 커맨드 파일의 CREATE EXTERNAL TABLE 구문은 Informix SQL 구문과 다르다.

                                   .-,-----------------.
                                   V                   |
>>-CREATE EXTERNAL TABLE--name--(----column--data_type-+--)----->
>--USING--(--"filename"--+------------------+--)--;------------><
                         '-,--+-DELIMITED-+-'
                              '-INFORMIX--'

CREATE EXTERNAL TABLE 구문은 데이터를 외부 테이블로 복사할 때 사용한다. level-0 아카이브 데이터만 가능하며, 논리 로그(logical log)는 적용되지 않는다.

다음은 외부 테이블의 포맷을 지정하는 옵션이다.

• DELIMITED: ASCII 구분자 파일. 기본 포맷
• INFORMIX: 이진 포맷.

외부 테이블의 경우 성능을 최적화를 위해 조건을 적용하지 않는다. 조건을 지정해도 무시된다.

DATABASE 구문은 사용할 데이터베이스를 지정한다. 

Syntax

>>-DATABASE--dbname--+-----------+--;--------------------------><
                     '-MODE ANSI-'

Examples

다음 예제는 dbs 데이터베이스에 원본 테이블과 대상테이블이 모두 존재하는 경우의 구문이다.

DATABASE dbs;
CREATE TABLE source (...);
CREATE TABLE target (...);
INSERT INTO target SELECT * from source;

어떤 데이터베이스에서 테이블을 추출하여 다른 데이터베이스로 복사할 때는 여러개의 DATABASE 구문을 사용한다.

DATABASE dbs1;
CREATE TABLE source (...) IN dbspace1;
DATABASE dbs2;
CREATE TABLE target (...) IN dbspace2;
INSERT INTO dbs2:target SELECT * FROM dbs1:source;

INSERT 구문은 아카이브에서 추출한 데이터를 어느 테이블에 넣을지 지정한다. 

Syntax

>>-INSERT INTO--target_table--+-----------------------+--------->
                              |   .-,-------------.   |
                              |   V               |   |
                              '-(---target_column-+-)-'
             .-,----------.
             V            |
>--SELECT--+---src_column-+-+--FROM--src_table------------------>
           '-*--------------'
>--+---------------+-------------------------------------------><
   '-WHERE--filter-'

Examples

다음 구문으로 원본 테이블의 모든 데이터를 대상 테이블에 입력할 수 있다.

INSERT INTO target SELECT * FROM source;

원본 테이블의 일부 컬럼만을 추출할 수도 있다. 다음 예제는 원본 테이블의 두 컬럼을 대상 테이블에 입력하는 구문이다.

CREATE TABLE source (col1 integer, col2 integer, col3 integer, col4 integer);
CREATE TABLE target (col1 integer, col2 integer);
INSERT INTO target (col1, col2) SELECT (col3, col4) FROM source;

RESTORE는 선택적 명령으로 테이블을 특정 시점으로 복원할 때 사용한다.

Syntax

>>-RESTORE--+----------------------------------+---------------><
            '-TO--+-"time"--+--+-------------+-'
                  '-CURRENT-'  '-WITH NO LOG-'

Usage

TO절에서 테이블을 복원할 특정 시점을 지정한다. 날짜와 시간 또는 CURRENT 키워드를 사용할 수 있다.

RESTORE 구문은 커맨드 파일에서 한 번만 사용할 수 있다. 커맨드 파일에 RESTORE를 명시하지 않으면 복원시 현재 시점의 논리 로그까지 적용한다. WITH NO LOG 절을 명시하면 물리(physical) 복원만 수행된다. 물리 복원은 level-0 아카이브만을 사용한다.

Example

RESTORE TO CURRENT WITH NO LOG;

SET 구문을 사용하여 테이블 레벨 로드(unload,load) 라이브러리의 다양한 기능을 제어할 수 있다.

Syntax

>>-SET--+-COMMIT TO--number------------------+-----------------><
        |               .-,----------------. |
        |               V                  | |
        '-WORKSPACE TO----+-dbspace------+-+-'
                          |         (1)  |
                          '-dbslice------'

1. Extended Parallel Server only

archecker 유틸리티는 논리 복원을 수행하는 동안 논리 로그 레코드를 준비하기 위한 테이블을 여러개 만든다. 이 테이블들은 sysutils 데이터베이스에 생성되며 작업 저장 공간(dbspace)에 저장된다.

Examples

SET COMMIT TO 20000;
SET WORKSPACE to dbspace1;

SQL Server 2005부터 각 개체는 데이터베이스 스키마에 속해 있습니다. 데이터베이스 스키마는 데이터베이스 사용자와 다른 고유 네임스페이스입니다. 스키마를 개체 컨테이너로 간주할 수 있습니다. 데이터베이스에서 스키마를 만들고 변경할 수 있으며 사용자에게 스키마에 대한 액세스 권한을 부여할 수 있습니다. 사용자가 스키마를 소유할 수 있으며 스키마 소유권은 양도할 수 있습니다.

참고:
데이터베이스 스키마는 XML 스키마와 다릅니다. XML 스키마에 대한 자세한 내용은 서버에서 XML 스키마 컬렉션 관리를 참조하십시오.

데이터베이스 개체 스키마를 만드는 방법은 CREATE SCHEMA(Transact-SQL)를 참조하십시오.

새 동작

---

이전 버전의 SQL Server에서는 데이터베이스 사용자와 스키마가 개념상 동일한 개체였습니다. SQL Server 2005부터 사용자와 스키마는 서로 다르며 스키마가 개체 컨테이너 역할을 합니다.

스키마에서 소유권을 분리하면 중요한 이점이 있습니다. 다음과 같은 방식으로 데이터베이스 스키마를 통해 보다 강력하게 데이터베이스 개체의 보안을 제어할 수 있습니다.

• 스키마 및 스키마에 포함된 보안 개체에 대한 사용 권한을 이전 버전보다 더욱 세부적으로 관리할 수 있습니다. 자세한 내용은 GRANT 스키마 권한(Transact-SQL) 및 GRANT 개체 권한(Transact-SQL)을 참조하십시오.
  
• 스키마와 스키마 범위 보안 개체에 대한 소유권을 양도할 수 있습니다. 자세한 내용은 ALTER AUTHORIZATION(Transact-SQL)을 참조하십시오.
  
• 스키마 간에 개체를 이동할 수 있습니다. 자세한 내용은 ALTER SCHEMA(Transact-SQL)를 참조하십시오.
  
• 하나의 스키마에 여러 데이터베이스 사용자가 소유하는 개체가 포함될 수 있습니다.
  
• 여러 데이터베이스 사용자가 하나의 기본 스키마를 공유할 수 있습니다.
  
• 역할, 응용 프로그램 역할 등의 데이터베이스 보안 주체가 스키마를 소유할 수 있습니다.
  
• 해당되는 스키마에서 개체를 삭제하지 않고 데이터베이스 사용자를 삭제할 수 있습니다.
  

데이터베이스 스키마를 통해 이전 버전에서 변경된 기타 중요한 보안 관련 사항은 다음과 같습니다.

• 코드가 스키마는 데이터베이스 사용자와 동일하다고 가정하는 경우 이전 버전의 SQL Server에서 작성된 코드가 잘못된 결과를 반환할 수 있습니다.
  
• 이전 버전의 SQL Server용으로 제작된 sysobjects 등의 카탈로그 뷰는 잘못된 결과를 반환할 수 있습니다.
  
• 사용자가 여러 개의 스키마를 소유할 수 있으므로 이제 소유권 체인과 사용자 컨텍스트 전환이 다르게 동작할 수 있습니다. 소유권 체인에 대한 자세한 내용은 소유권 체인 및 사용 권한 계층을 참조하십시오. 컨텍스트 전환에 대한 자세한 내용은 컨텍스트 전환을 참조하십시오.
  
• SQL Server 2000에서는 사용자가 데이터베이스 개체를 소유했습니다. SQL Server 2000에서 네 부분으로 구성된 데이터베이스 개체 참조는 [DatabaseServer].[DatabaseName].[ObjectOwner].[DatabaseObject]였습니다. SQL Server 2005부터 네 부분으로 구성된 데이터베이스 개체 참조는 [DatabaseServer].[DatabaseName].[DatabaseSchema].[DatabaseObject]입니다.
  

개체 소유권 변경 내용

다음 개체의 소유자 속성은 사용자가 아니라 스키마를 참조합니다.

• CREATE TABLE
  
• ALTER TABLE
  
• CREATE VIEW
  
• ALTER VIEW
  
• CREATE INDEX
  
• ALTER INDEX
  
• CREATE FUNCTION
  
• ALTER FUNCTION
  
• DROP FUNCTION
  
• VIEW_TABLE_USAGE
  
• VIEW_COLUMN_USAGE
  
• TABLE_CONSTRAINTS
  
• REFERENTIAL_CONSTRAINTS
  
• KEY_COLUMN_USAGE
  
• CONSTRAINT_TABLE_USAGE
  
• CONSTRAINT_COLUMN_USAGE
  
• CHECK_CONSTRAINTS
  
• COLUMN_DOMAIN_USAGE
  
• COLUMNS
  
• DOMAIN_CONSTRAINTS
  
• ROUTINE_COLUMNS
  

사용자 메타데이터 및 스키마 메타데이터 비교를 반환하는 열에 대한 자세한 내용은 아래의 "스키마 카탈로그 뷰 및 함수" 섹션을 참조하십시오.

카탈로그 뷰 및 함수로 대체된 시스템 테이블

SQL Server 2005에서는 250개 이상의 새 카탈로그 뷰를 제공하며, 일부는 SQL Server 2000 시스템 테이블을 대체하는 데이터베이스 사용자 및 스키마 개체를 다룹니다. 메타데이터에 액세스하려면 카탈로그 뷰를 사용하는 것이 좋습니다. 자세한 내용은 카탈로그 뷰(Transact-SQL)를 참조하십시오.

다음 표에서는 SQL Server 2000 시스템 테이블 및 이와 동등한 SQL Server 2005 카탈로그 뷰 간의 매핑을 보여 줍니다.

SQL Server 2000 시스템 테이블	SQL Server 2005 카탈로그 뷰
Sysusers	sys.database_principals(Transact-SQL) sys.schemas(Transact-SQL)
Syslogins	sys.server_principals(Transact-SQL)

기본 스키마

정규화되지 않은 보안 개체의 이름을 확인하기 위해 SQL Server 2000에서는 이름 확인을 사용하여 호출하는 데이터베이스 사용자가 소유한 스키마 및 dbo가 소유한 스키마를 확인했습니다.

SQL Server 2005의 각 사용자에게는 기본 스키마가 할당될 수 있습니다. CREATE USER 또는 ALTER USER의 DEFAULT_SCHEMA 옵션을 사용하여 기본 스키마를 설정하고 변경할 수 있습니다. DEFAULT_SCHEMA가 정의되어 있지 않으면 SQL Server 2005에서는 dbo 스키마를 기본 스키마로 가정합니다.

참고:
Windows 인증 그룹을 통해 연결하는 사용자에게는 기본 스키마 연결이 없습니다. 이러한 사용자가 스키마를 사용하여 정규화되지 않은 개체를 만드는 경우 새 스키마가 생성되고 해당 이름이 현재 사용자 이름으로 설정되며 사용자 이름이 지정된 새 네임스페이스에 테이블 개체가 생성됩니다.

새로운 DDL(데이터 정의 언어) 문은 sysobjects와 같은 이전 시스템 테이블에 정확하게 반영되어 있지 않은 시스템 메타데이터에 대한 복잡한 메타데이터를 제공할 수 있습니다. 이 예에서는 sysobjects에서 반환한 사용자 ID 및 스키마 이름이 동기화되어 있지 않으며 SQL Server 2005에서 제공하는 스키마와 사용자 간 구분을 반영합니다.

USE tempdb
GO
CREATE LOGIN u1 WITH PASSWORD = 'Mdfjd$sakj943857l7sdfh##30'
CREATE USER u1 WITH DEFAULT_SCHEMA = u1
GO
GRANT CREATE TABLE TO u1 
GO
CREATE SCHEMA sch1
GO
CREATE SCHEMA u1 AUTHORIZATION u1
GO
EXECUTE AS USER = 'u1'
GO
CREATE TABLE t1(c1 int)
GO
REVERT
GO
SELECT user_name(uid) , * FROM sysobjects WHERE name = 't1'
GO

주의:
CREATE/ALTER/DROP SCHEMA; CREATE/ALTER/DROP USER; CREATE/ALTER/DROP ROLE; CREATE/ALTER/DROP APPROLE; ALTER AUTHORIZATION 등의 DDL 문이 사용된 데이터베이스에서 새 카탈로그 뷰를 사용해야 합니다.

스키마 카탈로그 뷰 및 함수

---

SQL Server 2005부터 스키마는 메타데이터에 반영되는 명시적 엔터티입니다. 따라서 각 스키마에 하나의 소유자만 있을 수 있지만 한 명의 사용자가 스키마를 하나 이상 소유할 수 있습니다. SQL Server 2000 시스템 테이블에는 이 복잡한 관계가 반영되지 않으므로 SQL Server 2005에서는 새 메타데이터를 정확하게 반영하는 새 카탈로그 뷰를 제공합니다.

다음 표에서는 SQL Server 2005의 스키마에 대한 카탈로그 뷰, 메타데이터 및 함수를 보여 줍니다.

내용	참고
일반 스키마 메타데이터	sys.schemas(Transact-SQL)
정보 스키마 뷰	정보 스키마 뷰(Transact-SQL)
INFORMATION_SCHEMA.SCHEMATA 뷰에서 반환된 열 정의	SCHEMATA(Transact-SQL)

예

---

1. 스키마 만들기 및 사용자에게 소유권 할당

다음 예에서는 Marjorie라는 SQL Server 로그인 및 사용자와 Auditing이라는 새 스키마를 AdventureWorks 데이터베이스에 추가합니다. Marjorie는 Auditing 스키마의 소유자로 할당됩니다.

CREATE LOGIN Marjorie
    WITH PASSWORD = '8fdKJl3$nlNv3049jsKK';
USE AdventureWorks;
CREATE USER Marjorie FOR LOGIN Marjorie
GO
CREATE SCHEMA Auditing AUTHORIZATION Marjorie;
GO

2. 다른 스키마에 사용자 권한 부여

다음 예에서는 Marjorie라는 사용자에게 AdventureWorks 데이터베이스의 Purchasing 스키마에 대한 SELECT 권한을 부여합니다.

USE AdventureWorks;
GO
GRANT SELECT on SCHEMA::Purchasing TO Marjorie;
GO

3. 스키마의 소유권 변경

다음 예에서는 Jon이라는 새 사용자가 AdventureWorks 데이터베이스에서 생성됩니다. Jon에게는 AdventureWorks 데이터베이스의 Auditing 스키마 소유권이 부여됩니다. 그런 다음 Marjorie라는 사용자가 AdventureWorks 데이터베이스에서 삭제됩니다.

USE AdventureWorks;
GO
/* Create a new user in the database */
CREATE LOGIN Jon
    WITH PASSWORD = '1fdKJl3$nlNv3049jsBB';
USE AdventureWorks;
CREATE USER Jon FOR LOGIN Jon
GO
ALTER AUTHORIZATION on SCHEMA::Auditing TO Jon;
GO
/* Removes the user from the system */
DROP LOGIN Marjorie;
GO
DROP USER Marjorie;
GO

4. 스키마의 소유권 표시

다음 예에서는 AdventureWorks 데이터베이스의 Auditing 스키마 소유자를 표시합니다.

USE AdventureWorks;
GO
/* This method uses the INFORMATION_SCHEMA views */
SELECT * 
FROM INFORMATION_SCHEMA.SCHEMATA
WHERE SCHEMA_NAME = 'Auditing';
GO
/* This method uses the sys.schemas catalog and links
   the names of the database users and server logins */
SELECT s.name AS 'Schema Name'
, db.name AS 'Database User Name'
, svr.name AS 'SQL Server Login Name'
FROM sys.schemas s
/* Obtains the name of the database user */
   INNER JOIN sys.database_principals db
      on s.principal_id = db.principal_id
/* Obtains the name of the server login */
      INNER JOIN sys.server_principals svr
         on db.sid = svr.sid
WHERE s.name = 'Auditing'
ORDER BY s.name

http://msdn.microsoft.com/ko-kr/library/ms190387(v=SQL.90).aspx

In this Document

  Purpose
  Scope and Application
  Parameter DIRECT: Conventional Path Export Versus Direct Path Export
     1. Introduction.
     2. Performance issues.
     3. Restrictions. 
     4. Security considerations. 
     5. Typical errors.
     6. Known defects. 
  References

Applies to:

Purpose

Scope and Application

Parameter DIRECT: Conventional Path Export Versus Direct Path Export

1. Introduction.

1.1. Starting with Oracle7 release 7.3, the Export utility provides two methods for exporting table data: 
- Conventional Path Export 
- Direct Path Export 

1.2. Conventional path Export. 
Conventional path Export uses the SQL SELECT statement to extract data from tables. Data is read from disk into the buffer cache, and rows are transferred to the evaluating buffer. The data, after passing ｅxpression evaluation, is transferred to the Export client, which then writes the data into the export file. 

1.3. Direct path Export. 
When using a Direct path Export, the data is read from disk directly into the export session's program global area (PGA): the rows are transferred directly to the Export session's private buffer. This also means that the SQL command-processing layer (evaluation buffer) can be bypassed, because the data is already in the format that Export expects. As a result, unnecessary data conversion is avoided. The data is transferred to the Export client, which then writes the data into the export file. 

1.4. The parameter DIRECT specifies whether you use the direct path Export (DIRECT=Y) or the conventional path Export (DIRECT=N). 

1.5. To use direct path Export, specify the DIRECT=Y parameter on the command line or in the parameter file. The default is DIRECT=N, which extracts the table data using the conventional path. 

1.6. This parameter is only applicable to the original export client. Export DataPump (expdp) uses a Direct Path unload by default and switches to External Table mode if required.

2. Performance issues.

2.1. Direct path Export can be much faster than Conventional path Export because the SQL command-processing layer is bypassed.

2.2. You may be able to improve performance by increasing the value of the RECORDLENGTH parameter when you invoke a direct path Export.  Your exact performance gain depends upon the following factors: 
- DB_BLOCK_SIZE 
- the types of columns in your table 
- your I/O layout (the drive receiving the export file should be separate from the disk drive where the database files reside) 

The following values are generally recommended for RECORDLENGTH: 
- multiples of the file system I/O block size 
- multiples of DB_BLOCK_SIZE 

For example, invoking a Direct path Export with a maximum I/O buffer of 64kb can improve the performance of the Export with almost 50%. This can be achieved by specifying the additional Export parameters DIRECT and RECORDLENGTH. E.g.:

2.3. A Direct path Export does not influence the time it takes to Import the data. That is, an export file created using Direct path Export or Conventional path Export, will take the same amount of time to Import. 

3. Restrictions.

3.1. Command-line versus interactive. 
You cannot invoke a direct path Export using the interactive method. To invoke a direct path Export, you must use either the command-line method or a parameter file. 

3.2. Export mode. 
You cannot use the DIRECT=Y parameter when exporting in tablespace-mode  (i.e. when specifying the parameter TRANSPORT_TABLESPACES=Y).  You can use the DIRECT=Y parameter when exporting in full, user or table mode (i.e.: when specifying FULL=Y or OWNER=scott or TABLES=scott.emp). 

3.3. Objects and LOBs. 
In versions of Export prior to 8.1.5, you could not use direct path Export for tables containing objects and LOBs. If you tried to, their rows were not exported. This behavior has changed in Oracle8i and Oracle9i. Rows in tables that contain objects and LOBs will now be exported using conventional path, even if direct path was specified. Import will correctly handle these conventional path tables within direct path dump files. 
Note that when you use Export release 8.0 on an Oracle9i database, then Export doesn't export rows from tables containing objects and LOBs when you have specified a direct path load (DIRECT=y). 

3.4. Export parameter QUERY. 
The parameter QUERY applies onLY to conventional path Export. It cannot be specified in a direct path export (DIRECT=Y).  This QUERY parameter allows you to select a subset of rows from a set of tables when doing a table mode export. For example, if user scott wants to export only those employees whose job title is salesman and whose salary is less than 1600, he could do the following (this example is UNIX-based):

3.5. Export parameter BUFFER. 
The BUFFER parameter applies onLY to conventional path Export. It has no effect on a direct path Export. This BUFFER parameter specifies the size (in bytes) of the buffer used to fetch rows. It determines the maximum number of rows in an array, fetched by Export.  For direct path Export, use the RECORDLENGTH parameter to specify the size of the buffer that Export uses for writing to the export file. 

3.6. Export parameter RECORDLENGTH. 
The RECORDLENGTH parameter specifies the length (in bytes) of the file record. You can use this parameter to specify the size of the Export I/O buffer (highest value is 64 kb). Changing the RECORDLENGTH parameter affects only the size of data that accumulates before writing to disk.  It does not affect the operating system file block size.  If you do not define this parameter, it defaults to your platform-dependent value for BUFSIZ (1024 bytes in most cases). 

3.7. Character Set Conversion. 
A Direct path Export can only export the data when the NLS_LANG environment variable of the session who is invoking the export, is equal to the database characterset. If NLS_LANG is not set (default is AMERICAN_AMERICA.US7ASCII) and/or NLS_LANG is different, Export will display the warning EXP-41 and abort with EXP-0. For example:

Setting NLS_LANG to the same value as the database character set (e.g.: NLS_LANG=AMERICAN_AMERICA.UTF8 in previous example), and retrying the export, will resolve this error. 
Note that this restriction only applies when exporting with an Oracle8i and below export utility. 

3.8. Compatibility. 
When using an Oracle7 or lower EXPORT release on an Oracle8i or higher release database, you have to use the default CONVENTIONAL path export (i.e.: do not specify DIRECT=YES in the export command statement).
Also beware that export does not export rows from tables containing objects and LOBs when you use Export release 8.0 on an Oracle8i or higher release database and have specified a direct path load (DIRECT=Y). 

4. Security considerations.

4.1. Virtual Private Database (VPD) and Oracle Label Security are enforced during a Conventional Path Export. The export will terminate successfully, but with the warning: EXP-79 "Data in table %s is protected. Conventional path may only be exporting partial table." 
VPD and Oracle Label Security (Fine Grained Access Control - FGAC) are not enforced during Direct Path Exports. 

4.2. The following users are exempt from Virtual Private Database and Oracle Label Security enforcement regardless of the export mode (Direct or Conventional), application, or utility used to extract data from the database:
a. the database user SYS; 
b. database users granted the Oracle9i EXEMPT ACCESS POLICY privilege, either directly or through a database role. 
WARNING! 
- Any user who is granted the Oracle9i EXEMPT ACCESS POLICY privilege is completely free from the enforcement of VPD and Oracle Label Security. This is a powerful privilege and should be carefully managed. 
- The Oracle9i EXEMPT ACCESS POLICY privilege does not affect the enforcement of traditional object privileges such as SELECT, INSERT, UPDATE, and DELETE. These privileges are enforced even if a user has been granted the EXEMPT ACCESS POLICY privilege. 

5. Typical errors.

5.1. EXP-00067 
Meaning: "Direct path cannot export %s which contains object or lob data." 
An Oracle7 and Oracle8 Direct Path export give EXP-67 because of tables with LOB datatype. Workaround: use Conventional Path export. 
Advanced Queueing (AQ) tables with LOB datatypes can also cause EXP-67 When these AQ tables are not being used, then dropping these tables could be another workaround (see references). 

5.2. EXP-00041 
Meaning: "Export done in server's %s, different from user's character set %s" 
A Direct Path export gives EXP-41 and EXP-0 when the export session characterset (NLS_LANG) is different than the database characterset. 
Solution: make the user session NLS_LANG equal to database characterset (when problem persists: re-run script catexp.sql). 

5.3. EXP-00079 
Meaning: "Data in table %s is protected. Conventional path may only be exporting partial table" 
A Conventional Path export uses the SQL SELECT statement to extract the data. As a result, the "Fine Grained Access Control" policies also apply during the Conventional Path export. 
Solution: in Oracle8i perform the export as user SYS or perform a Direct Path Export. In Oracle9i the privilege EXEMPT ACCESS POLICY can be used, regardless of the export mode. 

6. Known defects.

Below an overview of known DIRECT path related defects in the various export releases:

Bug:498891 Direct Export can use excessive private memory
Fixed: 7.3.4.0 Workaround: use Conventional Path export 

Bug:514344 Direct EXPORT may omit trailing NULLs causing IMP-9 for very long rows.
Fixed: 7.3.4.0 Workaround: Use larger RECORDLENGTH (64000). 

Bug:558511 Direct Export generated on platform with totally different code page (e.g. EBCDIC) will cause IMP-10 (e.g. when importing on ASCII platform).
Fixed: 8.0.6.0 Workaround: use Conventional Path export 

Bug:690413 Direct Export could raise ORA-600 [729] (space leak) if it fails due to running out of disk space, or similar problem. 
Fixed: 8.0.6.0 Workaround: use Conventional Path export or ensure that Export does not fail (disk or similar cause). 

Bug:1092638 Direct Export with MTS may result in a dump (ORA-7445). 
Fixed: 8.1.7.0 Workaround: don't use MTS for Direct export. 

Bug 1324748 Direct Export of an IOT may yield ORA-600 [2845] if the primary key ends with a ROWID column (not a public bug)
Fixed: 8.1.7.1 Workaround: use Conventional Path export 

Bug:1672945 Direct Export causes ORA-600 [729] when tablespace is offline 
Fixed: 9.0.1.0 Workaround: use Conventional Path export or make sure tablespace if online when starting Export. 

Bug:1477959 Direct Export for a table containing columns of type ROWID could fail with ORA-600 [6193] or ORA-600 [6190] or ORA-4030 
Fixed: 8.1.7.4 and 9.0.1.3 and 9.2.0.1 
Workaround: use Conventional Path export 

Bug 1820663 Direct Export of a table can generate duplicate column names (not a public bug) 
Fixed: 9.2.0 Workaround: use Conventional Path export 

Bug 1686987 Direct Export can result in ORA-600 [6191] with a possible stack: kdeuwrd kdeuprd kdeuscn kueuld (not a public bug)
Fixed: 8.1.7.4 and 9.0.1.3 and 9.2.0 
Workaround: use Conventional Path export 

Bug 1805146 DROP Functional index does not clean up dictionary - Can cause corrupt export file (not a pubic bug). 
Fixed: 8.1.7.3 9.0.1.3 9.2.0.1 
Workaround: re-run export in Conventional path mode 
See also alert in:
Note:148740.1 "ALERT: Export Of Table With Dropped Functional Index May Cause IMP-20 on Import" 

Bug:2666174 Export in direct path mode can produce a corrupt export dump file if an ORA-1555 (snapshot too old) error occurs. 
Fixed: 9.2.0.5 and Oracle10g (= export will now terminate unsuccessfully with EXP-0 error) 
Workaround: Ensure that no other transaction is updating the same table, and that the size of the rollback segment is sufficient. Or use Conventional Path export. 

Bug:2308033 Direct Export of a long row and with an 8k or larger database blocksize, can result in ORA-600 [6191] or ORA-600 [6193] 
Fixed: 9.0.1.4 and 9.2.0.2 and Oracle10g 
Workaround: use Conventional Path export 

Bug:3083560 ORA-1410 / ORA-8103 from direct path export if concurrent DML occurs. 
Fixed: 9.2.0.5 and Oracle10g 
Workaround: use Conventional Path export 

Bug:3230116 Direct Export of Compressed table fails with: ORA-600 [6193] 
Fixed: 9.2.0.5 and Oracle10g 
Workaround: use Conventional Path export 

Bug:3579567 9.2.0.5 Import of Compressed table fails: IMP-9 (IMP-00009) 
Fixed: 9.2.0.6 and 10.1.0.4 and 10.2.0.1 
Workaround: use Conventional Path export 

Bug:3596139 10.1.0.2 ORA-10632 on direct path export of IOT 
Fixed: 10.1.0.4 and 10.2.0.1 
Workaround: use Conventional Path export 

Bug:3868753 ORA-1410 / ORA-8103 from direct path export if concurrent inserts against ASSM tables occur. 
Fixed: 9.2.0.7 and 10.1.0.5 and 10.2.0.1 
Workaround: use Conventional Path export 

Bug:4085785 9.2.0.6 Export of Compressed Partition: ORA-600 [6191] 
Fixed: 10.2.0.1 
Workaround: use Conventional Path export 

References

KAZER사에서 제작한 스마트폰용 애플리케이션.

인포믹스 파라미터, 모니터링 명령어가 카테고리별로 정리되어 있다. 인포믹스 버전 11.70 기준.

안드로이드용 애플리케이션

http://www.kazer.com/android.html

아이폰용 애플리케이션

http://www.kazer.com/iphone.html

append 힌트의 효용성에 대한 논란이 잠시 있어 막간을 이용, 확인차 테스트해봤습니다..

아래 링크를 차례대로 읽어보세요...

i) NOLOGGING이 아닌 테이블에는 INSERT /*+ APPEND */ 효과가 없다? 
   : "APPEND 힌트의 진실과 거짓" --> http://blog.naver.com/addibuddi/22476554

ii) http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5280714813869

위 사이트에서 Kyte는 다음과 같이 정리함..

Table Mode    Insert Mode     ArchiveLog mode      result
-----------   -------------   -----------------    ----------
LOGGING       APPEND          ARCHIVE LOG          redo generated
NOLOGGING     APPEND          ARCHIVE LOG          no redo
LOGGING       no append       ""                   redo generated
NOLOGGING     no append       ""                   redo generated
LOGGING       APPEND          noarchive log mode   no redo
NOLOGGING     APPEND          noarchive log mode   no redo
LOGGING       no append       noarchive log mode   redo generated
NOLOGGING     no append       noarchive log mode   redo generated

이제 테스트를 시작합니다..

############################################
### 1. logging 테이블에 conventional INSERT
############################################

SQL> conn scott
Enter password: 
Connected.

SQL> create table tab3 logging
as select * from all_objects
where 1=2;

Table created.

SQL> insert into tab3
select * from all_objects
;

36013 rows created.

SQL> commit;

Commit complete.

SQL> select * from v$sesstat
where sid = (select sid from v$mystat where rownum = 1)
and STATISTIC# = (
select STATISTIC# from v$statname
where name = 'redo entries') ;

       SID STATISTIC#      VALUE
---------- ---------- ----------
       282        133       3420   <====

SQL> explain plan for insert into tab3   
  2  select * from tab3 ;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1925526863

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | INSERT STATEMENT  |      | 37070 |  4633K|   129  (14)| 00:00:02 |    <====
|   1 |  TABLE ACCESS FULL| TAB3 | 37070 |  4633K|   129  (14)| 00:00:02 |
--------------------------------------------------------------------------

#######################################
### 2. logging 테이블에 Direct Insert
#######################################

SQL> conn scott
Enter password: 
Connected.

SQL> create table tab1 logging
as select * from all_objects
where 1=2;

Table created.

SQL> insert /*+  append */ into tab1
select * from all_objects
; 

36011 rows created.

SQL> commit;

Commit complete.

SQL> select * from v$sesstat
where sid = (select sid from v$mystat where rownum = 1)
and STATISTIC# = (
select STATISTIC# from v$statname
where name = 'redo entries') ; 

       SID STATISTIC#      VALUE
---------- ---------- ----------
       240        133        866   <====

SQL> explain plan for insert /*+  append */ into tab1
  2  select * from tab1;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1481117511

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | INSERT STATEMENT   |      | 32454 |  4056K|   126  (12)| 00:00:02 |
|   1 |  LOAD AS SELECT    | TAB1 |       |       |            |          |    <====
|   2 |   TABLE ACCESS FULL| TAB1 | 32454 |  4056K|   126  (12)| 00:00:02 |
---------------------------------------------------------------------------

#######################################
### 3. nologging 테이블에 Direct Insert
#######################################

SQL> conn scott
Enter password: 
Connected.

SQL> create table tab2 nologging
as select * from all_objects
where 1=2;

Table created.

SQL> insert /*+  append */ into tab2
select * from all_objects
;

36012 rows created.

SQL> commit;

Commit complete.

SQL> select * from v$sesstat
where sid = (select sid from v$mystat where rownum = 1)
and STATISTIC# = (
select STATISTIC# from v$statname
where name = 'redo entries') ; 

       SID STATISTIC#      VALUE
---------- ---------- ----------
       118        133        363  <====

SQL> explain plan for insert /*+  append */ into tab2
  2  select * from tab2;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 4264119061

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | INSERT STATEMENT   |      | 36080 |  4510K|   128  (14)| 00:00:02 |
|   1 |  LOAD AS SELECT    | TAB2 |       |       |            |          |    <====
|   2 |   TABLE ACCESS FULL| TAB2 | 36080 |  4510K|   128  (14)| 00:00:02 |
---------------------------------------------------------------------------

** 테스트 결과, logging 속성의 테이블이더라도 APPEND 힌트에 의한 REDO감소 효과는 큰것으로 나타남.

3420  > 866 > 363

이정도의 차이라면 Production환경에서는 recovery를 포기하고 테이블까지 nologging으로 해야 한다는 우를 범하지 않고서라도 충분히 append 힌트의 효용성을 누릴수 있을 것이다.

답글 ->

속도 빠른건 좋죠.. 하지만 스토리지 용량을 더 많이 잡아 먹는다는 단점 정도가 있겠네요~

핵심은 배치작업 수행시 주로 사용되는 append 힌트가 redo로그를 감소시켜서 결국 log switching관련 대기이벤트를 감소시키고, 전체적인 야간배치작업 성능을 향상시킨다는 점입니다. 
HWM 이후에 append시킨다는 점은 물론 delete가 빈번한 테이블일 경우 공간활용의 비효율성으로 연결될수 있으므로 그러한 예외적인 경우에는 table shrink등의 리오그 대책이 뒤따라야 할것입니다.. 
하지만 대부분의 대형사이트라면, 요즘은 (저렴해진)스토리지에 투자하는 비용보다는 성능개선이 우선시되니까요~

[출처] http://blog.naver.com/lalaboy/40051083359

spool 명령으로 테이블의 데이터를 파일로 출력하는 방법이다.

다음의 내용을 sql 확장자 파일로 저장한다.

set echo off  // 실행하는 SQL문을 출력하지 않는다.

set pages 0  // 한페이지로 지정할 라인 수. 0으로 입력시 heading, page break, title을 표시하지 않는다.

set trimspool on  // 라인 뒤 공백을 제거한다.

set colsep ','  // 컬럼 간 데이터 구분자

set lines 30000  // 한 라인에 표시할 글자 수

set termout off  // SQL문으로 실행한 결과를 표시하지 않는다.

set feed off  // SQL문으로 실행한 결과 건수를 표시하지 않는다.

spool /경로/test.csv;

select * from 테이블명;

spool off

quit

http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698970

http://ss64.com/ora/syntax-sqlplus-set.html

http://www.inturi.net/coranto/viewnews.cgi?id=EkpuAFpkkyOKeKEaaY

제품 : ORACLE SERVER

Oracle Database Isolation Levels

Informix Isolation Levels

SET TRANSACTION correlates with	SET ISOLATION
Read Uncommitted (nologging default)	Dirty Read
Read Committed (logging default)	Committed Read
Not Supported	Cursor Stability
(ANSI) Repeatable Read Serializable	(IBM Informix) Repeatable Read (IBM Informix) Repeatable Read

Oracle

http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/consist.htm#BABIJEJI

http://blog.naver.com/PostView.nhn?blogId=joonaha&logNo=70105748469&viewDate=¤tPage=1&listtype=0

http://e-jooyoung.net/tc/76?TSSESSIONejooyoungnettc=17b13c012d47fb0d3f66e5d4755bdbc4

DB2

http://publib.boulder.ibm.com/infocenter/iwedhelp/v6r0/index.jsp?topic=%2Fcom.ibm.db2e.doc%2Fdb2e_iso_levels.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.wn.doc/doc/i0056249.html

Informix

http://www.database.sarang.net/?inc=read&aid=571&criteria=informix&subcrit=&id=947&limit=20&keyword=&page=70

http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlt.doc/sqltmst239.htm

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.sqlt.doc/ids_sqt_389.htm