ORACLE/11G2014. 8. 27. 20:23

오라클 스탠다드 엔터프라이즈 옵션 비교 Oracle 11.2 (문서 ID 1084132.1)

반응형



In this Document

Purpose
Details
References

Applies to:

Oracle Database - Enterprise Edition - Version 11.2.0.1.0 to 11.2.0.3 [Release 11.2]
Information in this document applies to any platform.
***Checked for relevance on 19-Jun-2012***

Purpose

To show the option differences between the different editions of Oracle 11.2 server

SOURCE:

Oracle® Database Licensing Information 11g Release 2 (11.2) Part Number E10594-04

      Chapter 1 Oracle Database Editions

Details

Feature/OptionSE1SEEENotes

High Availability

        

Oracle Fail Safe

Y

Y

Y

Windows only

Oracle RAC One Node

N

N

Y

Extra cost option

Oracle Data Guard—Redo Apply

N

N

Y

  

Oracle Data Guard—SQL Apply

N

N

Y

  

Oracle Data Guard—Snapshot Standby

N

N

Y

  

Oracle Active Data Guard

N

N

Y

Extra cost option

Rolling Upgrades—Patch Set, Database, and Operating System

N

N

Y

  

Online index rebuild

N

N

Y

  

Online index-organized table organization

N

N

Y

ALTERTABLE...MOVEONLINEoperations

Online table redefinition

N

N

Y

Using theDBMS_REDEFINITIONpackage

Duplexed backup sets

N

N

Y

  

Block change tracking for fast incremental backup

N

N

Y

  

Unused block compression in backups

N

N

Y

  

Block-level media recovery

N

N

Y

  

Lost Write Protection

N

N

Y

  

Automatic Block Repair

N

N

Y

Requires Active Data Guard option

Parallel backup and recovery

N

N

Y

  

Tablespace point-in-time recovery

N

N

Y

  

Trial recovery

N

N

Y

  

Fast-start fault recovery

N

N

Y

  

Flashback Table

N

N

Y

  

Flashback Database

N

N

Y

  

Flashback Transaction

N

N

Y

  

Flashback Transaction Query

N

N

Y

  

Oracle Total Recall

N

N

Y

Extra cost option

Scalability

        

Oracle Real Application Clusters

N

Y

Y

Extra cost with EE, included with SE

Automatic Workload Management

N

Y

Y

Requires Oracle Real Application Clusters

Performance

        

Client Side Query Cache

N

N

Y

  

Query Results Cache

N

N

Y

  

PL/SQL Function Result Cache

N

N

Y

  

In-Memory Database Cache

N

N

Y

Extra cost option

Database Smart Flash Cache

N

N

Y

Solaris and Oracle Enterprise Linux only

Support for Oracle Exadata Storage Server Software

N

N

Y

  

Security

        

Advanced Security Option

N

N

Y

Extra cost option

Oracle Label Security

N

N

Y

Extra cost option

Virtual Private Database

N

N

Y

  

Fine-grained auditing

N

N

Y

  

Oracle Database Vault

N

N

Y

Extra cost option

Secure External Password Store

N

N

Y

  

Development Platform

        

SQLJ

Y

Y

Y

Requires Oracle Programmer

Oracle Developer Tools for Visual Studio .NET

Y

Y

Y

Windows only

Microsoft Distributed Transaction Coordinator support

Y

Y

Y

Windows only

Active Directory integration

Y

Y

Y

Windows only

Native .NET Data Provider—ODP.NET

Y

Y

Y

Windows only

.NET Stored Procedures

Y

Y

Y

Windows only

Manageability

        

Oracle Change Management Pack

N

N

Y

Extra cost option

Oracle Configuration Management Pack

N

N

Y

Extra cost option

Oracle Diagnostic Pack

N

N

Y

Extra cost option

Oracle Tuning Pack

N

N

Y

Extra cost option, also requires the Diagnostic Pack

Oracle Provisioning and Patch Automation Pack

N

N

Y

Extra cost option

Oracle Real Application Testing

N

N

Y

Extra cost option

Database Resource Manager

N

N

Y

  

Instance Caging

N

N

Y

  

SQL Plan Management

N

N

Y

  

VLDB, Data Warehousing, Business Intelligence

        

Oracle Partitioning

N

N

Y

Extra cost option

Oracle OLAP

N

N

Y

Extra cost option

Oracle Data Mining

N

N

Y

Extra cost option

Oracle Data Profiling and Quality

N

N

Y

Extra cost option

Oracle Data Watch and Repair Connector

N

N

Y

Extra cost option

Oracle Advanced Compression

N

N

Y

Extra cost option

Basic Table Compression

N

N

Y

  

Bitmapped index, bitmapped join index, and bitmap plan conversions

N

N

Y

  

Parallel query/DML

N

N

Y

  

Parallel statistics gathering

N

N

Y

  

Parallel index build/scans

N

N

Y

  

Parallel Data Pump Export/Import

N

N

Y

  

In-memory Parallel Execution

N

N

Y

  

Parallel Statement Queuing

N

N

Y

  

Transportable tablespaces, including cross-platform

N

N

Y

Import of transportable tablespaces supported into SE, SE1, and EE

Summary management—Materialized View Query Rewrite

N

N

Y

  

Asynchronous Change Data Capture

N

N

Y

  

Integration

        

Basic Replication

Y

Y

Y

SE1/SE: read-only, updateable materialized view

Advanced Replication

N

N

Y

Multi-master replication

Oracle Streams

Y

Y

Y

SE1/SE: no capture from redo

Database Gateways

Y

Y

Y

Separate product license

Messaging Gateway

N

N

Y

  

Networking

        

Oracle Connection Manager

N

N

Y

Available via a custom install of the Oracle Database client, usually installed on a separate machine

See "Oracle Connection Manager" for more information

Infiniband Support

N

N

Y

  

Content Management

        

Oracle Spatial

N

N

Y

Extra cost option

Semantic Technologies (RDF/OWL)

N

N

Y

Requires Oracle Spatial and the Oracle Partitioning option

References

NOTE:465465.1 - Differences Between Enterprise, Standard and Personal Editions on Oracle 10.2
NOTE:269040.1 - Differences Between Enterprise, Standard and Personal Editions on Oracle 9.2
NOTE:465460.1 - Differences Between Enterprise, Standard and Personal Editions on Oracle 11.1

반응형
저작자표시 비영리

'ORACLE > 11G' 카테고리의 다른 글

11.2.0.N 이전 버전에서 최신 11.2.0.N 패치셋으로 out-of-place 수동 업그레이드에 대한 전체 확인 목록. (문서 ID 1608337.1)  (2) 2014.07.02
11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
oracle 11g에 추가된 파티션  (0) 2013.08.20
ADR  (0) 2013.05.19
11g 데이타베이스 에러수집방법  (0) 2012.05.11
Posted by [PineTree]
ORACLE/11G2014. 7. 2. 15:44

11.2.0.N 이전 버전에서 최신 11.2.0.N 패치셋으로 out-of-place 수동 업그레이드에 대한 전체 확인 목록. (문서 ID 1608337.1)

반응형
목적
해결책
참고

적용 대상:

Oracle Database - Enterprise Edition - 버전 11.2.0.1 to 11.2.0.4 [릴리즈 11.2]
이 문서의 내용은 모든 플랫폼에 적용됩니다.

목적

이 문서에는 11.2.0.1에서 11.2.0.2 또는 11.2.0.N  이후 버전으로 out-of-place 수동 데이터베이스 업그레이드를 수행하는 방법이 나와 있습니다.

문의하기, 도움 받기 및 이 문서로 경험 공유

다른 Oracle 고객, Oracle 직원 및 업계 전문가와 함께 이 주제에 대해서 자세히 살펴보고 싶습니까?

Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article.
여기를 눌러 기타 문서 및 도움이 될 만한 주제에 대한 토론을 찾아보고 데이터베이스 조정을 위한 기본 My Oracle Support Community 페이지에 액세스하십시오.

해결책

11.2.0.2 및 이후 패치셋은 전체 릴리스입니다. 11.2 패치셋 설치 프로그램은 기존 11.2 설치를 업데이트하지 않습니다. 
설치 프로세스는 out-of-place 업그레이드를 수행하든 in-place 업그레이드를 수행하든 새 설치를 수행합니다. 
(11.2 Upgrade Guide 3장 "Known Issue When Starting an In-Place Upgrade for Release 11.2.0.2" 참조)


11.2.0.2부터 패치셋을 두 가지 방법으로 적용할 수 있습니다:

  • Out-of-place 업그레이드 (권장)
  • In-place 업그레이드
  •  
    "In-Place" 업그레이드는 옵션이지만 권장되지 않습니다.
    이 업그레이드는 수행할 수 있지만 11.2.0.2 용 설치 프로그램을 실행하는 것만으로 11.2.0.1을 가리킬 수 없습니다. 

    "In-Place" 업그레이드 단계는 업그레이드 가이드(아래 참조)에 설명되어 있습니다.
    http://download.oracle.com/docs/cd/E11882_01/server.112/e17222.pdf
    섹션 3-39

자세한 내용은 다음 노트를 참조하십시오:

Note 1189783.1 Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2
Note 1320966.1 Things to Consider before upgrading to 11.2.0.2.x regarding performance/wrong results


참조: 이 문서에서 참조가 11.2.0.1을 나타낼 때 현재 설치된 11.2(11.2.0.1-11.2.0.N) 버전을 나타내는 것일 수 있습니다. 참조가 11.2.0.2를 나타낼 때 11.2 패치셋(11.2.0.2-11.2.0.N)의 새 버전일 수 있습니다.


 1 단계
======
11.2.0.2 이상 RDBMS 소프트웨어를 다운로드합니다.
See NOTE:753736.1 - Quick Reference to Patchset Patch Numbers 를 참조하십시오.
여러 파일이 필요할 수 있으므로 패치셋 추가 정보에서 다운로드에 필요한 파일에 대한 전체 지침을 검토합니다. 각 패치셋에 대한 추가 정보에는 특정 지침이 나와 있습니다.

다음도 검토하십시오:

Note 549617.1 : How To Verify The Integrity Of A Patch/Software Download? [Video]
Note 169706.1 : Oracle Database Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2)


2 단계
======
최신 11.2 RDBMS 소프트웨어를 새로운ORACLE_HOME에 설치합니다..

11.2 설치부터 모든 기본 RDBMS 구성 요소가 설치됩니다. 유일한 옵션은 구성 요소가 링크 설정되거나 링크 해제(활성 상태이며 사용할 수 있는지)되었는지 여부입니다. 사용자 정의 설치는 사용할 수 없습니다.

데이터베이스가 Oracle 텍스트 테마를 사용 중이거나 Oracle Multimedia 데모 및 기타 데모를 설치하려는 경우 이 항목은 기본 설치에 포함되어 있지 않기 때문에 11.2.0.2 예제 CD(이전에는 Companion CD)를 설치해야 합니다.

"opatch lsinventory -detail" 을 이전 및 새로운 ORACLE_HOME 에 대해 실행하여 설치된 제품을 비교할 수 있습니다.

다음 사항도 참조하십시오.
/opt/oracle 을 ORACLE_BASE 로 사용 중인 경우 rootupgrade.sh 가 실패합니다. 자세한 내용은 다음을 참조하십시오:

Note: 1281913.1 Root Script Fails if ORACLE_BASE is set to /opt/oracle


3 단계
======
최신 11.2 RDBMS 소프트웨어를 설치한 후 실행 중인 이전 인스턴스에 대해 11.2.0.1 인스턴스를 이전 ORACLE_HOME 및 spool/run 11.2.0.2 $ORACLE_HOME/rdbms/admin/utlu112i.sql 스크립트를 사용하여 시작합니다.

사전 업그레이드 정보툴 실행은 DBUA 를 사용하여 업그레이드하거나 수동으로 업그레이드하는 경우 필수 항목입니다. 그렇지 않은 경우 오류가 발생할 수 있습니다:

SQL> SELECT TO_NUMBER('MUST_BE_SAME_TIMEZONE_FILE_VERSION')
2 FROM registry$database
3 WHERE tz_version != (SELECT version from v$timezone_file);
SELECT TO_NUMBER('MUST_BE_SAME_TIMEZONE_FILE_VERSION')
*
ERROR at line 1:
ORA-01722: invalid number

 

최신 11.2 릴리스로 업그레이드하기 전에 11.2 사전 업그레이드 스크립트 스풀 파일을 검토하고 문제를 수정해야 합니다.


알려진 문제
++++++++++++++++
11.2.0.2 는 시간대 버전 14 를 사용합니다. 11.2.0.1 은 시간대 버전 11 을 사용합니다. 이후 버전은 시간대 데이터 이후 버전에서도 사용될 수 있습니다.

최신 홈의 DBUA 는 "시간대 버전 및 TIMESTAMP WITH TIME ZONE 데이터 업그레이드" 상자체크박스가 선택된 경우 포함된 버전으로 시간대를 자동으로 업그레이드합니다.

수동으로 업그레이드하는 경우:
BMS_DST 패키지를 사용하여 최신 11.2 버전으로 업그레이드한 후 시간대 버전을 업그레이드하거나 11.2.0.1 시간대를 해당 시간대 버전으로 업그레이드합니다. 업그레이드하기 전에 11.2.0.1 시간대 버전을 다른 버전으로 업그레이드하려는 경우 utlu112i.sql 을 재실행해야 합니다.

다음을 참조하십시오:

 Note 1201253.1 Actions For DST Updates When Upgrading To Or Applying The 11.2.0.2 Patchset


4 단계
======
dba_registry 의 모든 구성 요소가 적합하며 부적합한 데이터 딕셔너리 객체가 dba_objects 에 없는지를 확인하려면 아래 My Oracle Support 에서 dbupgdiag.sql 스크립트를 실행합니다.

Note 556610.1 Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)


dbupgdiag.sql 스크립트에서 부적합한 객체를 보고하는 경우 $ORACLE_HOME/rdbms/admin/utlrp.sql 을 여러 번 실행하여 부적합한 객체 수에 변경이 없을 때까지 데이터베이스의 부적합한 객체를 검증합니다.

$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus "/ as sysdba"
SQL> @utlrp.sql


부적합한 객체를 검증한 후 데이터베이스에서 dbupgdiag.sql 을 다시 한 번 재실행하고 모두 정상인지 확인합니다.

5 단계
======
일괄 처리 및 cron 작업 모두를 사용 안함으로 설정한 다음 데이터베이스 전체 백업을 수행합니다.

예제
----------
데이터베이스의 전체 백업을 수행하려면 다음 단계를 완료합니다:

1. RMAN 으로 사인온:
rman "target / nocatalog"
2. 다음의 RMAN 명령어들을 수행하라:
RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT 'some_backup_directory%U' TAG before_upgrade;
BACKUP CURRENT CONTROLFILE FORMAT 'controlfile location and name';
}


참조: Oracle Database Backup and Recovery User's Guide

참고: 전체 콜드 백업의 경우 먼저 데이터베이스를 종료하십시오.

6 단계
=======
데이터베이스를 정상적으로 종료합니다.


7 단계 (윈도우즈 플랫폼만 해당)
========================

1) 환경 변수 ORACLE_HOME 이 11.2.0.1 설치를 가리키도록 설정합니다.

2) ORACLE_HOME 셋으로 11.2.0.1 Oracle Database 서비스를 정지하여 11.2.0.1 설치를 가리키도록 합니다.

  C:\> NET STOP OracleServiceORCL


3) %ORACLE_HOME%\bin\ ORADIM 이진을 사용하여 11.2.0.1 Oracle 서비스를 삭제합니다.

C:\> ORADIM -DELETE -SID ORCL


4) 환경 변수 ORACLE_HOME 이 11.2.0.2 설치를 가리키도록 설정합니다.

5) 11.2.0.1%ORACLE_HOME%/database 에서 11.2.0.2 %ORACLE_HOME%/database 로 init.ora/spfile 및 비밀번호 파일(orapw<sid>.ora)을 복사합니다.

6) 11.2.0.1 %ORACLE_HOME%\network\admin(또는 $TNS_ADMIN) 위치에서 11.2.0.2 %ORACLE_HOME%\network\admin(또는 %TNS_ADMIN%) 위치로 구성 파일(listener.ora, sqlnet.ora, tnsnames.ora 등)을 복사합니다.

7) DB 콘솔/DB 콘트롤이 구성되어 있고 사용되는 경우 다음 디렉토리 두 개와 해당 콘텐츠를 11.2.0.1에서 11.2.0.2로 복사합니다. DB 콘솔/DB 콘트롤이 구성되지 않은 경우 이 디렉토리가 존재하지 않을 수 있습니다.
           ORACLE_HOME/<hostname_dbname>
           ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_<hostname_dbname>


8) 11.2.0.2 를 사용하여 명령 프롬프트에서 Oracle 11.2.0.2 서비스를 생성합니다.

%ORACLE_HOME%\bin\ ORADIM 
C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -STARTMODE AUTO -PFILE %ORACLE_HOME%\DATABASE\INIT<SID>.ORA


예제:

C:\> ORADIM -NEW -SID ORCL -SYSPWD  pass_with_sysdba_priv  -STARTMODE AUTO -PFILE %ORACLE_HOME%\DATABASE\INIT<SID>.ORA

 

PASSWORD = 새 Oracle Database 11g 릴리스 2(11.2) 
데이터베이스 인스턴스에 대한 비밀번호입니다. 이는 
SYSDBA 권한에 접속한 사용자의 비밀번호입니다. -SYSPWD 옵션은 필수가 아닙니다. 
지정하지 않는 경우 운영 체제 인증이 사용되며 
비밀번호가 필요하지 않습니다.



8 단계 (Unix 및 Linux)
=================
대상 11.2.0.2 ORACLE_HOME을 구성합니다.

1) 환경 변수 ORACLE_BASE, ORACLE_HOME, PATH, NLS_10 및 LIBRARY_PATH 가 11.2.0.2 설치를 가리키도록 설정되었는지 확인합니다.

ORACLE_SID 를 업그레이드 할 11.2.0.1 DB 이름으로 설정합니다.

etc/oratab 파일은 Oracle Database 11g 릴리스 2(11.2.0.2) Oracle 홈을 가리킵니다.

2) Database Vault 를 사용 안함으로 설정합니다.

Note 453903.1 - Enabling and Disabling Oracle Database Vault in UNIX


3) 11.2.0.1 $ORACLE_HOME/dbs 에서  11.2.0.2 $ORACLE_HOME/dbs 로 init.ora/spfile 및 비밀번호 파일(orapw<sid>.ora)을 복사합니다.

4) 11.2.0.1 $ORACLE_HOME/network/admin(또는 $TNS_ADMIN) 위치에서 11.2.0.2 $ORACLE_HOME/network/admin(또는 $TNS_ADMIN) 위치로 구성 파일(listener.ora, sqlnet.ora, tnsnames.ora 등)을 복사합니다.

5) DB 콘솔/DB 콘트롤이 구성되어 있고 사용되는 경우 다음 디렉토리 두 개와 해당 콘텐츠를 11.2.0.1 에서 11.2.0.2 로 복사합니다. DB 콘솔/DB 콘트롤이 구성되지 않은 경우 이 디렉토리가 존재하지 않을 수 있습니다.
           ORACLE_HOME/<hostname_dbname>
           ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_<hostname_dbname>

<hostname_dbname>의 실제 이름을 지정합니다.

6) Oracle Database 11g 릴리스 2(11.2)에 대해 COMPATIBLE 초기화 파라미터가 올바르게 설정되어 있는지 확인하십시오. COMPATIBLE 이 올바로 설정되어 있지 않을 경우 사전 업그레이드 정보 툴에서 데이터베이스 섹션에 경고가 표시됩니다.

7) 초기화 파라미터의 값을 사전 업그레이드 정보툴에서 가리키는 최소값 이상으로 조정합니다. JVM 을 설치한 고객의 경우 업그레이드하기 전에 java_pool_size 및 shared_pool_size 를 250MB 이상으로 설정해야 합니다. 그렇지 않으면 다음 오류와 함께 JVM 업그레이드가 실패할 수 있습니다:

ORA-07445: exception encountered: core dump [qmkmgetConfig()+52] [SIGSEGV] [ADDR:0x18] [PC:0x103FFEC34] [Address not mapped to object] []


9 단계
======
데이터베이스를 수동으로 업그레이드합니다.

1) sqlplus 를 시작하고 새롭게 설치된 (타겟) $ORACLE_HOME/rdbms/admin 의 catupgrd.sql 스크립트를 실행합니다.

sqlplus " / as sysdba "
SQL> spool /tmp/upgrade.log
SQL> startup upgrade
SQL> set echo on
SQL> @catupgrd.sql;
SQL> spool off
SQL> Shutdown immediate


2) catupgrd.sql 스풀 파일에 오류가 있는지 확인합니다.

3) 일반 모드에서 데이터베이스를 재시작합니다.

4) SQL> @$ORACLE_HOME/rdbms/admin/catuppst.sql;

5) SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql;

6) dbupgdiag.sql 스크립트를 실행(Note: 556610.1 참조)하고 dba_registry 의 모든 구성 요소가 적합하며 dba_objects 에 부적합한 객체가 없는지 확인합니다.



사후 업그레이드 단계
===================

1) 오라클 클러스터웨어 구성을 업그레이드 합니다.

당신이 오라클 클러스터웨어를 사용한다면, 데이터베이스에 대한 오라클 클러스터웨어 요소들을 업그레이드 해야만 합니다.

오라클 데이터베이스 11g 릴리즈 2 (11.2.0.2) 가 출시되면서, 업그레이드 명령은 실행되고 있는 소프트웨어의 버전을 업그레이드하여 구성합니다.

업그레이드 할 릴리즈에 대해서 srvctl 을 수행하십시오. 예를 들면,

srvctl upgrade database
srvctl upgrade 데이터베이스 명령어는 데이터베이스의 구성과 명령어가 수행된 데이터베이스 홈 버전에 대한 모든 서비스들을 업그레이드 합니다.


구문과 옵션
다음과 같이 srvctl upgrade database command 를 사용하십시오:

srvctl upgrade database -d db_unique_name -o Oracle_home
Table A-161 srvctl upgrade database Options

옵션에 대한 설명
-d db_unique_name
 데이터베이스에 대한 유일한 이름
 
-o Oracle_home
ORACLE_HOME 의 위치

2) DBMS_DST를 사용하여 시간대를 최신 버전으로 업그레이드 합니다.

Note 1201253.1
Title: Actions For DST Updates When Upgrading To Or Applying The 11.2.0.2 Patchset


3) 복구 카탈로그를 업그레이드합니다.
복구 카탈로그 업그레이드 및 UPGRADE
CATALOG 명령에 대한 전체 정보는 Oracle Database Backup and Recovery User's Guide 에서 
프로시저를 설명하는 항목을 참조하십시오.

4) DBMS_STATS 패키지에서 생성한 통계 자료 테이블 업그레이드

프로시저를 사용하여 통계 자료 테이블을 생성한 경우 다음 프로시저를 실행하여 이 테이블을 업그레이드합니다:

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('scott', 'stat_table');


예제에서 SCOTT 은 통계 자료 테이블의 소유자이며 STAT_TABLE 은 
통계 자료 테이블 이름입니다. 각 통계 자료 테이블에 대해 이 프로시저를 수행합니다.

5) Oracle Database Vault 를 사용으로 설정하고 DV_PATCH_ADMIN 롤을 취소합니다.
Oracle Database Vault 를 사용하는 경우 데이터베이스를 업그레이드하기 전에 
사용 안함으로 설정하도록 지침이 제공됩니다. 이제:

Database Vault 를 사용으로 설정합니다.

Note 453903.1 - Enabling and Disabling Oracle Database Vault in UNIX


SYS 계정에 대한 Database Vault DV_PATCH_ADMIN 롤을 취소합니다.

참조
===========
Oracle Database
Upgrade Guide
11g Release 2 (11.2)
E17222-06                             <October 2010                         <
Chapter 3
       Upgrading to the New Release

http://download.oracle.com/docs/cd/E11882_01/server.112/e17222.pdf

5. Oracle Warehouse Builder (OWB) component in database will not be upgraded as part of database upgrade. There are few post upgrade steps to be carried to upgrade the component.

Details in Oracle® Warehouse Builder Release Notes 11g Release 2 (11.2)

반응형
저작자표시 비영리

'ORACLE > 11G' 카테고리의 다른 글

오라클 스탠다드 엔터프라이즈 옵션 비교 Oracle 11.2 (문서 ID 1084132.1)  (0) 2014.08.27
11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
oracle 11g에 추가된 파티션  (0) 2013.08.20
ADR  (0) 2013.05.19
11g 데이타베이스 에러수집방법  (0) 2012.05.11
Posted by [PineTree]
ORACLE/11G2014. 6. 14. 20:52

11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)

반응형

소개


오라클 11g 데이터베이스에는 사전에 정의된 세 가지 자동화된 유지 관리 작업이 있다 :

자동 최적기 통계 수집(Automatic Optimizer Statistics Collection)

통계가 없거나 오래된 통계를 가지고 있는 데이터베이스 안의 모든 스키마 객체에 대해 최적기 통계를 수집한다.이 작업에 의해 생성되어지는 통계는 SQL 실행 시 성능을 향상시키기 위하여 SQL 쿼리 최적기에 의해서 사용되어 진다.

자동 세그먼트 권고자 (Automatic Segment Advisor)

회수 가능한 공간을 가지는 세그먼트를 구별하고, 해당 세그먼트를 어떻게 조각모음 할 건지에 대한 권장 사항을 만든다. 최신의 권장 사항을 확보하거나 자동 세그먼트 권고자가 회수 가능한 공간을 검토 하지 않은 세그먼트의 권장 사항을 확보하기 위하여 수동으로 세그먼트 권고자를 실행할 수 있다.

자동 SQL 튜닝 권고자(Automatic SQL Tuning Advisor)

높은 부하를 가지는 SQL 문장의 성능을 검사하고, 그 문장을 어떻게 튜닝 할 것인지에 대한 권장 사항을 만든다. SQL 프로파일 권장 사항을 자동으로 구현하기 위하여 이 권고자를 구성할 수 있다.
Note 466920.1 - 11g New Feature: Health Monitor


Note 755838.1 - New 11g Default Jobs

구현


Oracle10g에서 이 작업들은 별도의 작업으로 생성 되었으며 DBA_SCHEDULER_JOBS.JOB_NAME에서 볼 수 있었다.

오라클 11g에서 변경되었다. 관련된 뷰는 DBA_AUTOTASK_WINDOW_CLIENTS이다.
이제 이 작업들은 시스템에서 실제로 실행 되고 난 후 생성된 이름을 DBA_SCHEDULER_JOBS에서 볼 수 있다.

SQL> desc DBA_AUTOTASK_WINDOW_CLIENTS
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 WINDOW_NAME                               NOT NULL VARCHAR2(30)
 WINDOW_NEXT_TIME                                   TIMESTAMP(6) WITH TIME ZONE
 WINDOW_ACTIVE                                      VARCHAR2(5)
 AUTOTASK_STATUS                                    VARCHAR2(8)
 OPTIMIZER_STATS                                    VARCHAR2(8)
 SEGMENT_ADVISOR                                    VARCHAR2(8)
 SQL_TUNE_ADVISOR                                   VARCHAR2(8)
 HEALTH_MONITOR                                     VARCHAR2(8)

 select * from DBA_AUTOTASK_WINDOW_CLIENTS;

WINDOW_NAME
------------------------------
WINDOW_NEXT_TIME
---------------------------------------------------------------------------
WINDO AUTOTASK OPTIMIZE SEGMENT_ SQL_TUNE HEALTH_M
----- -------- -------- -------- -------- --------
MONDAY_WINDOW
08-DEC-08 10.00.00.000000 PM EUROPE/VIENNA
FALSE ENABLED ENABLED ENABLED ENABLED DISABLED

...

SUNDAY_WINDOW
07-DEC-08 06.00.00.000000 AM EUROPE/VIENNA
FALSE ENABLED ENABLED ENABLED ENABLED DISABLED
7 rows selected.


모든 윈도들의 모든 자동화된 유지 관리 작업을 설정하거나 해제하려면 인수 없이 설정 또는 해제 프로시저를 호출한다.

SQL> execute DBMS_AUTO_TASK_ADMIN.DISABLE;


특정한 유지 관리 작업을 해제하기 위하여 다음과 같이 해제 프로시저를 사용한다 :

SQL> BEGIN
       dbms_auto_task_admin.disable(
       client_name => 'sql tuning advisor',
       operation => NULL,
       window_name => NULL);
     END;  
    /


특정한 유지 관리 작업을 다시 설정하기 위하여 다음과 같이 설정 프로시저를 사용한다 :

SQL> BEGIN
       dbms_auto_task_admin.enable(
       client_name => 'sql tuning advisor',
       operation => NULL,
       window_name => NULL);
     END;
     /



client_name 인수에 사용할 작업 이름은 DBA_AUTOTASK_CLIENT 데이터베이스 딕셔너리 뷰 안에 나열되어 있다.

예제：
auto optimizer stats collection
auto space advisor
sql tuning advisor



또 다른 차이점은 사전에 정의된 스케줄러 윈도다 :

  •   Oracle10g : WEEKNIGHT_WINDOW and WEEKEND_WINDOW
  •   Oracle11g : MONDAY_WINDOW .... SUNDAY_WINDOW. 

WEEKNIGHT_WINDOW와 WEEKEND_WINDOW는 이전 버전과의 호환성을 위해 아직 존재한다.

윈도가 열릴 때 지속 시간은 11g에서 변경되었다. 월요일 - 금요일은 오후 10시에서 오전 2시까지이며 토요일 - 일요일은 오전 6시에서 오전 2시까지다.

DBMS_SCHEDULER.SET_ATTRIBUTE 프로시저를 사용하여 데이터베이스 환경에 적절한 시간으로 사전에 정의된 유지 관리 윈도를 조절할 수 있다.
예제 : 다음 스크립트는 WEEKNIGHT_WINDOW를 자정부터 모든 평일 오전 8시로 변경하도록 한다. (윈도 기간은 8시간으로 변경되지 않는다) :
EXECUTE DBMS_SCHEDULER.SET_ATTRIBUTE(
'WEEKNIGHT_WINDOW', 
'repeat_interval',
'freq=daily;byday=MON, TUE, WED, THU, FRI;byhour=0;byminute=0;bysecond=0');

각각의 평일 윈도는 DEFAULT_MAINTENANCE_PLAN이라는 사전에 정의된 리소스 계획을 가지고 있으며 관련 윈도가 열릴 때 활성화 될 것이다. 이것은 10g와 11g 간의 또 다른 차이점이다.


SQL> select window_name, resource_plan from dba_scheduler_windows;

WINDOW_NAME                    RESOURCE_PLAN
------------------------------ ------------------------------
MONDAY_WINDOW                  DEFAULT_MAINTENANCE_PLAN
TUESDAY_WINDOW                 DEFAULT_MAINTENANCE_PLAN
WEDNESDAY_WINDOW               DEFAULT_MAINTENANCE_PLAN
THURSDAY_WINDOW                DEFAULT_MAINTENANCE_PLAN
FRIDAY_WINDOW                  DEFAULT_MAINTENANCE_PLAN
SATURDAY_WINDOW                DEFAULT_MAINTENANCE_PLAN
SUNDAY_WINDOW                  DEFAULT_MAINTENANCE_PLAN
WEEKNIGHT_WINDOW
WEEKEND_WINDOW

9 rows selected.


SQL> select * from dba_rsrc_plans where plan='DEFAULT_MAINTENANCE_PLAN'
PLAN_ID PLAN NUM_PLAN_DIRECTIVES
---------- ------------------------------ -------------------
CPU_METHOD MGMT_METHOD
------------------------------ ------------------------------
ACTIVE_SESS_POOL_MTH PARALLEL_DEGREE_LIMIT_MTH
------------------------------ ------------------------------
QUEUEING_MTH SUB
------------------------------ ---
COMMENTS
--------------------------------------------------------------------------------
STATUS MAN
------------------------------ ---
11187 DEFAULT_MAINTENANCE_PLAN 4
EMPHASIS EMPHASIS
ACTIVE_SESS_POOL_ABSOLUTE PARALLEL_DEGREE_LIMIT_ABSOLUTE
FIFO_TIMEOUT NO
Default plan for maintenance windows that prioritizes SYS_GROUP operations and a
llocates the remaining 5% to diagnostic operations and 25% to automated maintena
nce operations.
YES


SQL> select * from DBA_RSRC_PLAN_DIRECTIVES where plan='DEFAULT_MAINTENANCE_PLAN';

PLAN GROUP_OR_SUBPLAN TYPE
------------------------------ ------------------------------ --------------
CPU_P1 CPU_P2 CPU_P3 CPU_P4 CPU_P5 CPU_P6 CPU_P7
---------- ---------- ---------- ---------- ---------- ---------- ----------
CPU_P8 MGMT_P1 MGMT_P2 MGMT_P3 MGMT_P4 MGMT_P5 MGMT_P6
---------- ---------- ---------- ---------- ---------- ---------- ----------
MGMT_P7 MGMT_P8 ACTIVE_SESS_POOL_P1 QUEUEING_P1 PARALLEL_DEGREE_LIMIT_P1
---------- ---------- ------------------- ----------- ------------------------
SWITCH_GROUP SWITC SWITCH_TIME SWITCH_IO_MEGABYTES
------------------------------ ----- ----------- -------------------
SWITCH_IO_REQS SWITC MAX_EST_EXEC_TIME UNDO_POOL MAX_IDLE_TIME
-------------- ----- ----------------- ---------- -------------
MAX_IDLE_BLOCKER_TIME SWITCH_TIME_IN_CALL
--------------------- -------------------
COMMENTS
--------------------------------------------------------------------------------
STATUS MAN
------------------------------ ---
DEFAULT_MAINTENANCE_PLAN SYS_GROUP CONSUMER_GROUP
100 0 0 0 0 0 0
0 100 0 0 0 0 0
0 0
FALSE
FALSE

Directive for system operations
NO

DEFAULT_MAINTENANCE_PLAN OTHER_GROUPS CONSUMER_GROUP
0 70 0 0 0 0 0
0 0 70 0 0 0 0
0 0
FALSE
FALSE

Directive for all other operations
NO

DEFAULT_MAINTENANCE_PLAN ORA$AUTOTASK_SUB_PLAN PLAN
0 25 0 0 0 0 0
0 0 25 0 0 0 0
0 0
FALSE
FALSE

Directive for automated maintenance tasks
NO

DEFAULT_MAINTENANCE_PLAN ORA$DIAGNOSTICS CONSUMER_GROUP
0 5 0 0 0 0 0
0 0 5 0 0 0 0
0 0
FALSE
FALSE

Directive for automated diagnostic tasks
NO

10g와 11g의 변경사항 요약 : 

제목10g11g
작업DBA_SCHEDULER_JOBS에서 별도의 작업AUTOTASKS는 접두사 'ORA$AT'라는 이름을 가지며 실행되었을 때 작업처럼 볼 수 있다.
유지 관리 윈도2개의 윈도, 평일 밤과 주말매일 자신의 윈도를 가진다.
자원 관리자(Resource manager)기본으로 설정되지 않음모든 평일 윈도를 위한 사전 정의된 자원 계획
   


관련된 뷰：


DBA_AUTOTASK_CLIENT
DBA_AUTOTASK_CLIENT_HISTORY
DBA_AUTOTASK_CLIENT_JOB
DBA_AUTOTASK_JOB_HISTORY
DBA_AUTOTASK_OPERATION
DBA_AUTOTASK_SCHEDULE
DBA_AUTOTASK_TASK
DBA_AUTOTASK_WINDOW_CLIENTS
DBA_AUTOTASK_WINDOW_HISTORY

참고

NOTE:466920.1 - 11g New Feature: Health monitor
NOTE:755838.1 - New 11g Default Jobs

NOTE:858852.1 - DBA_AUTOTASK_TASK and DBA_AUTOTASK_CLIENT Shows Different Status For Auto Optimizer Stats Collection


반응형
저작자표시 비영리

'ORACLE > 11G' 카테고리의 다른 글

오라클 스탠다드 엔터프라이즈 옵션 비교 Oracle 11.2 (문서 ID 1084132.1)  (0) 2014.08.27
11.2.0.N 이전 버전에서 최신 11.2.0.N 패치셋으로 out-of-place 수동 업그레이드에 대한 전체 확인 목록. (문서 ID 1608337.1)  (2) 2014.07.02
oracle 11g에 추가된 파티션  (0) 2013.08.20
ADR  (0) 2013.05.19
11g 데이타베이스 에러수집방법  (0) 2012.05.11
Posted by [PineTree]
ORACLE/11G2013. 8. 20. 13:47

oracle 11g에 추가된 파티션

반응형

11g에 추가된 파티션 유형


Reference 파티셔닝

  • 상품 테이블을 상품대분류 기준으로 리스트 파티셔닝하고, 일별상품거래 테이블도 부모 테이블인 상품과 똑 같은 방식과 기준으로 파티셔닝
  • 이럴 때 10g 까지는 상품에 있는 상품대분류 컬럼을 일별 상품거래 테이블에 반정규화
  • 11g에서 부모 테이블 파티션 키를 이용해 자식 테이블을 파티셔닝하는 기능

Create table 상품 {
상품번호 number NOT NULL PRIMARY KEY
, 상품명 varchar2(50) not null
, 현재가격 number not null
, 상품대분류 varchar2(4) not null
, 등록일시 date not null
)
Partition by list(상품대분류) (
 Partition p1 values ('의류')
,partition p2 values ('식품')
,partition p3 values ('가전')
,partition 4 values ('컴퓨터')
);

create table 일별상품거래 (
  상품번호   number  NOT NULL, 거래일자   varchar2(8)
, 판매가격   number
, 판매수량   number
, 판매금액   number
, constraint 일별상품거래_fk foreign key(상품번호) references 상품
)
partition by reference (일별상품거래_fk);


Interval 파티셔닝

  • 11g 부터는 Range 파티션을 생성할 대 아래와 같이 interval, 기준을 정의함으로써 정해진 간격으로 파티션이 자동 추가되도록 할 수 있다.
  • 테이블을 일단위로 파티셔닝 했을때 유용하다.


create table 주문일자 (주문번호 number, 주문일시 date, ... )
partition by range(주문일시) INTERVAL(NUMTOYMINTERVAL(1, 'MONTH')) 
(
, partition p200907 values less than(to_date('2009/08/01', 'yyyy/mm/dd'))
, partition p200908 values less than(to_date('2009/09/01', 'yyyy/mm/dd'))
, partition p200909 values less than(to_date('2009/10/01', 'yyyy/mm/dd'))
, partition p200910 values less than(to_date('2009/11/01', 'yyyy/mm/dd'))
);

 

create table 고객 (고객번호 number, 고객명 varchar2(20), ... )
partition by range(고객번호) INTERVAL (100000)
( partition p_cust1 values less than ( 100001 )
, partition p_cust2 values less than ( 200001 )
, partition p_cust3 values less than ( 300001 )
) ;

 

[출처] 추가된 파티션 유형|작성자 에이스

[출처] [ORACLE] 11g에 추가된 파티션 유형|작성자 장미

반응형
저작자표시 비영리

'ORACLE > 11G' 카테고리의 다른 글

11.2.0.N 이전 버전에서 최신 11.2.0.N 패치셋으로 out-of-place 수동 업그레이드에 대한 전체 확인 목록. (문서 ID 1608337.1)  (2) 2014.07.02
11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
ADR  (0) 2013.05.19
11g 데이타베이스 에러수집방법  (0) 2012.05.11
기준선 및 개선된 계획  (0) 2009.08.25
Posted by [PineTree]
ORACLE/11G2013. 5. 19. 21:10

ADR

반응형

제품 : Database

작성날짜 : 2008-01-07

PURPOSE
================================
기존 제품에서와 달리, 11g 는 alert log 를 text file 뿐만 아니라 XML-formatted file 로도 기록합니다. 또한 그 위치가 기존의 BDUMP가 아니므로, 어떤 문제가 발생하거나 INSTANCE의 상태를 확인하려 할 때 혼란스러울 수 있습니다.

-- 차례 --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. ADR 의 개념과 11g에서 ALERTLOG의 위치
1-1. ADR BASE
1-2. ADR HOME
1-3. ALERTLOG의 새로운 위치
1-4. 기타 '기존 경로'와 '새로운 경로' 안내

2. PROBLEM과 INCIDENT
2-1. What is a Problem?
2-2. What is an Incident?

3. ADRCI
3-1. ALERTLOG 살펴보기
3-2. Server Trace File 찾기
3-3. Listener Trace File 찾기
3-4. 옛날 방법을 통해 Trace File에 접근하기
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


EXPLANATION
================================
1. ADR 의 개념과 11g에서 ALERTLOG의 위치

1-1. ADR BASE

11g에서는 BDUMP와 UDUMP와 같은 구분이 없어지며, ADR(Automatic Diagnostic Repository)이라는 concept으로 관리됩니다. ADR은 기존에 BDUMP와 UDUMP로 나뉘어 관리되던 Diagnostic 정보를 한 곳에 모아 관리하고 손쉽게 Oracle Support에 그 Data를 전달할 수 있도록 도와줍니다.

먼저 ADR_BASE의 위치는 INSTANCE에서 DIAGNOSTIC_DEST 파라미터로 확인할 수 있습니다.

(1) $ORACLE_BASE가 설정되어 있다면, DIAGNOSTIC_DEST 의 위치는 $ORACLE_BASE 입니다.
(2) $ORACLE_BASE가 설정되어 있지 않다면, DIAGNOSTIC_DEST 의 위치는 $ORACLE_HOME/log 입니다.

현재 설정위치는, 다음과 같이 INSTANCE 상에서 DIAGNOSTIC_DEST 를 확인할 수 있습니다. 아래의 경우 $ORACLE_BASE 가 ADR_BASE 인 것을 볼 수 있습니다. ($ORACLE_HOME이 설정되지 않음)

SQL> show parameter diagno

NAME TYPE VALUE

-----------

diagnostic_dest string /opt/oracle/product

다음 query를 통해, 관련 정보를 자세히 확인할 수 있습니다.

SQL> select * from v$diag_info


1-2. ADR HOME

설치된 ORACLE PRODUCT별 INSTANCE의 ADR 위치를, ADR HOME이라고 합니다. 다음과 형태로, 그 위치가 결정됩니다.

ADR_BASE/diag/product_type/product_id/instance_id

예들 들어, ADR_BASE가 /opt/oracle/product 라면 ADR_HOME은 다음과 같습니다.

/opt/oracle/product/diag/rdbms/ora11/ORA11


1-3. ALERTLOG의 새로운 위치

(1) XML 형태의 ALERT
XML 형태의 ALERTLOG는 다음 위치에서 찾을 수 있으며, 이를 열기 위해서는 ADRCI라는 별도의 Utility가 필요합니다.

ADR_HOME/diag/product_type/product_id/instance_id/alert

다음과 같은 방법을 통해서도 그 위치를 확인할 수 있습니다.

SQL> select value from v$diag_info where name ='Diag Alert';

VALUE

/opt/oracle/product/diag/rdbms/ora11/ORA11/alert

(2) TEXT 형태의 ALERT
일반 ALERTLOG는 다음 위치에서 찾을 수 있습니다.

ADR_HOME/diag/product_type/product_id/instance_id/trace

다음과 같은 방법을 통해서도 그 위치를 확인할 수 있습니다.

SQL> select value from v$diag_info where name ='Diag Trace';

VALUE

/opt/oracle/product/diag/rdbms/ora11/ORA11/trace


1-4. 기타 '기존 경로'와 '새로운 경로' 안내

(1) Foreground Process Trace Files
USER_DUMP_DEST
-> ADR HOME/trace

(2) Background Process Trace Files
BACKGROUND_DUMP_DEST
-> ADR HOME/trace

(3) Database Alert log File
BACKGROUND_DUMP_DEST
-> ADR HOME/alert/log.xml OR ADR HOME/trace/alert_<SID>.log

(4) SQL*Net Listener Log File
LOG_DIRECTORY_LISTENER -

ADR HOME/alert/log.xml


(5) Core Dump Files
CORE_DUMP_DEST
-> ADR HOME/cdump

(6) Incident Dump Files (아래에서 n은 정수)
USER_DUMP_DEST AND BACKGROUND_DUMP_DEST
-> ADR HOME/incident/incdir_n


2. PROBLEM과 INCIDENT

11g를 관리하기 위해서는 PROBLEM과 INCIDENT라는 개념을 인지해야 합니다.

2-1. What is a Problem?

먼저 PROBLEM이란 DATABASE상의 critical error 를 일컫습니다. 예를 들어, ORA-600 / ORA-7445 / ORA-4031 / ORA-1578 과 같은 MESSAGE를 예로 들 수 있습니다. 이러한 PROBLEM들은 ADR내에 그 정보가 기록됩니다.


2-2. What is an Incident?

INCIDENT라 함은, 'PROBLEM의 1회 발생' 을 말합니다.

다시 말해 'ORA-1578 메세지가 여러번 기록되는 경우라면, ORA-1578이라는 '하나의 PROBLEM'에 대해 '여러 INCIDENT'가 ADR내에 생성됨을 의미합니다.


3. ADRCI

- 새롭게 등장한 ADR 관련 정보를 다루기 위해서는, ADR Commandline Interface (ADRCI)를 사용합니다.

다음과 같이 adrci 를 기동시킵니다.

oracle@prdsup5:~> adrci

ADRCI: Release 11.1.0.6.0 - Beta on Mon Dec 31 18:48:38 2007

Copyright (c) 1982, 2007, Oracle. All rights reserved.

ADR base = "/opt/oracle/product"
adrci>

- ADRCI에서 SHOW 명령어를 실행할 경우, default Editor가 실행됩니다. 만약 이 부분에 문제가 있다면 다음과 같이, Editor를 지정할 수 있습니다.

adrci> set editor vi

3-1. ALERTLOG 살펴보기

- 기본적으로 'SHOW ALERT' command를 사용합니다만, 다음과 같이 TAIL 옵션을 사용하여 최신 정보만 살펴볼 수도 있습니다.

adrci> SHOW ALERT -TAIL
adrci> SHOW ALERT -TAIL 50 // 마지막 50라인만 살펴보기

- 특정 terminal에서 alertlog의 "live monitoring"이 가능합니다.

adrci> SPOOL /home/steve/MYALERT.LOG
adrci> SHOW ALERT -TERM
adrci> SPOOL OFF

- ORA-600에 관련된 메세지만 살펴볼 수도 있습니다.

adrci> SHOW ALERT -P "MESSAGE_TEXT LIKE '%ORA-600%'"

3-2. Server Trace File 찾기
- 기본적으로 'SHOW TRACEFILE' command를 사용합니다.

adrci> show tracefile
adrci> show trace <trace file.trc>

- 특정 KEYWORD를 사용하여 찾을 수 있습니다.

adrci> SHOW TRACEFILE %mmon%

- 특정 PROCESS ID를 사용하여 찾을 수 있습니다.

adrci> SHOW TRACEFILE -I 1681

3-3. Listener Trace File 찾기

- 기본적으로 'SHOW TRACEFILE' command를 사용합니다.

adrci> show tracefile
adrci> show trace <trace file.trc>

3-4. 옛날 방법을 통해 Trace File에 접근하기

(1) Server Trace File 찾기
cd $HOME/oradiag_oracle/diag/lsnrctl/$HOSTNAME/$HOSTNAME/trace

(2) Listener Trace File 찾기
cd $HOME/oradiag_oracle/diag/lsnrctl/$HOSTNAME/$HOSTNAME/trace

REFERENCES
================================
ADRCI: ADR Command Interpreter
http://download.oracle.com/docs/cd/B28359_01/server.111/b28319/adrci.htm#insertedID0

Note 454927.1
Using and Disabling the Automatic Diagnostic Repository (ADR) with Oracle Net for 11g

Note 453125.1
11g Diagnosability: Frequently Asked Questions

Note 415733.1
ADRCI Reference guide

반응형
저작자표시 비영리

'ORACLE > 11G' 카테고리의 다른 글

11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
oracle 11g에 추가된 파티션  (0) 2013.08.20
11g 데이타베이스 에러수집방법  (0) 2012.05.11
기준선 및 개선된 계획  (0) 2009.08.25
Oracle Advanced Compression  (0) 2009.04.02
Posted by [PineTree]
ORACLE/11G2012. 5. 11. 10:54

11g 데이타베이스 에러수집방법

반응형
OTN펌
  • 목적 :
    Oracle 11g 부터 Alert.log 와 trace file 은 새로운 형식으로 생성이 되며, 이는 ADR (Automatic Diagnotic Repository) 에 생성이 된다.
    본 문서에서는 Database 에 심각한 에러가 발생한 경우, ADRCI 명령어를 이용하여 에러를 확인하고 관련된 alert.log 및 trace file 을 오라클 고객지원센터로 전송하는 방법에 대해서 설명한다.

  • IPS 사용법 :
    ORACLE 11g 는 problem (Database 에서 발생한 에러코드)과 incident (에러가 발생한 기록)에 관련된 trace file 들을 자동으로 수집해주는 기능을 제공한다.
    이 기능을 IPS (Incident Packaging Service) 라고 하며, 인터페이스로 GUI 환경과 ADRCI command 를 제공한다.
    Database 에 발생한 모든 심각한 에러들은 각각의 incident 를 생성한다.
    IPS 를 통해서 생성된 압축 파일은 에러에 대한 alert.log file, 모든 trace file 과 진단 정보를 포함하고 있기 때문에, 해당 error 에 대한 정보수집을 간편히 수행할 수 있다.

    Database 의 에러 확인 및 관련 file을 오라클 고객지원센터로 전송하는 방법 :

    1. Database 에서 발생한 심각한 에러 발생

    SQL> select * from atab;
    select * from atab
    *
    ERROR at line 1:
    ORA-01578: ORACLE data block corrupted (file # 6, block # 11)
    ORA-01110: data file 6: '/opt/oracle/oradata/db11g/tt.dbf'

    2. ADR과 Alert.log 에서 에러를 확인한다.

    ADR에서 에러를 확인하기 위하여 11g 환경의 OS prompt에서 adrci를 실행한다.

    %] adrci

    ADR 홈 경로를 확인한다.

    adrci> show home
    --> 모든 ADR HOME 을 보여준다. 확인하고자 하는 ADR HOME 을 지정한다.

    adrci> set homepath <ADR HOME>

    에러 코드를 problem 이라고 하며, 이를 확인하기 위해서 다음을 실행한다.

    adrci> show problem

    ADR Home = /opt/oracle/diag/rdbms/db11g/db11g:
    *************************************************************************
    PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    1 ORA 1578 18104 2009-06-01 22:06:19.501207 +10:00
    1 rows fetched

    Database 에 문제가 되고 있는 에러 코드를 확인할 수 있다.
    이 중, 분석이 필요한 에러코드에 대하여 압축파일을 생성할 수 있다.

    3. 분석이 필요한 에러의 발생 기록을 확인한다.

    에러의 발생 기록들은 Incident 라고 하며, 모든 incident 는 Alert.log 에 기록된다.
    각각의 incident 는 유일한 incident ID 를 가진다.

    ADR 에서 'show incident' 명령을 수행하여 에러 발생 기록을 확인할 수가 있으며,
    에러에 대한 problem key를 확인하기 위해서는 'show problem' 을 수행한다.

    adrci> show incident -p "problem_key='ORA 1578'"

    ADR Home = /opt/oracle/diag/rdbms/db11g/db11g:
    *************************************************************************
    INCIDENT_ID PROBLEM_KEY CREATE_TIME
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    18147 ORA 1578 2009-06-01 22:02:08.805002 +10:00

    동일한 problem에 대한 incidnet는 여러 건이 발생할 수 있다.

    4. IPS (incident packaging service) 를 수행하여 alert.log , trace file 및 diag 정보에 대한 압축 파일 생성.

    압축 파일을 생성하기 위해서는 특정 경로를 포함한 'IPS pack' 명령을 사용한다.
    다음의 예는 incident 관련 file들을 /tmp directory 에 압축 파일로 생성하는 방법이다.

    adrci> ips pack incident 18147 in /tmp
    Generated package 9 in file /tmp/ORA1578_20090602113045_COM_1.zip, mode complete

    IPS pack 의 예제)

    ips pack problem 100 in /tmp
    -- problem id 100 에 관련된 trace file 들을 /tmp directory 에 압축파일로 생성한다.

    ips pack incident 6439 in /tmp
    -- incident id 6439 에 관련된 trace file 들을 /tmp directory 에 압축파일로 생성한다.

    ips pack problemkey "ORA 1578"
    -- problem_key 'ORA 1578' 를 가지는 모든 problem 에 관련된 trace file 들을 현재 directory 에 압축파일로 생성한다.

    ips pack seconds 8
    -- 최근 8 초 이내에 발생한 incident 에 대한 압축 파일을 생성한다.

    ips pack time '2007-05-01 10:00:00.00' to '2007-05-01 23:00:00.00'
    -- 특정 시간대의 incident 에 대한 압축파일을 생성한다.

    'IPS pack' 명령은 'IPC create' 와 'IPS generage' 명령을 일괄적으로 수행할 수 있는 명령이다.

    이와 같이 생성된 압축 파일을 SR (service request)을 통해 오라클 고객지원센터로 전송하면 된다.

    동영상 참조 :
    IPS package 를 생성하는 방법 (동영상 자료 02:30)
    (My Oracle Support 접속 필요)

    참고자료 :
    DOC ID : 443529.1
    11g Quick Steps to Package and Send Critical Error Diagnostic Information to Support (Video)

    DOC ID: 738732.1
    ADR Different Methods to Create IPS Package

    • 엮인글 주소 : http://support.dbworks.co.kr/8730/8e3/trackback
     
     

    추가적으로 trace file정리시

    adrci>purge -age 30

    하면 됩니다.

     

    반응형
    저작자표시 비영리

    'ORACLE > 11G' 카테고리의 다른 글

    11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
    oracle 11g에 추가된 파티션  (0) 2013.08.20
    ADR  (0) 2013.05.19
    기준선 및 개선된 계획  (0) 2009.08.25
    Oracle Advanced Compression  (0) 2009.04.02
    Posted by [PineTree]
    ORACLE/11G2009. 8. 25. 08:00

    기준선 및 개선된 계획

    반응형


     

    실행 계획을 최적화하기 위해 Oracle Database 11 g 의 SQL 계획 관리 기능 사용

     

    제대로 작동하던 데이터베이스 쿼리의 성능이 갑자기 떨어지는 상황이 발생한 적이 있습니까? 여러분의 십중팔구는 실행 계획의 변경사항에서 그 원인을 찾으려 했을 것입니다. 더 자세한 분석에서는 이러한 성능 변화가 해당 쿼리에서 참조한 테이블과 인덱스에 대해 새로 수집된 옵티마이저 통계 때문인 것으로 밝혀졌을 수도 있을 것입니다.

     

    이런 상황에 당황하여 통계 수집을 중단하기로 성급하게 결정한 적이 있으십니까? 그러한 조치는 실행 계획을 해당 쿼리에 대해 거의 동일하게 유지시키지만 다른 것들은 더욱 악화시킬 수 있습니다. 오래된 통계를 통해 생성된 차선의 실행 계획은 다른 쿼리의 성능 또는 다른 술어(WHERE 절)를 가진 동일한 쿼리의 성능을 악화시킵니다.

     

    다음에 어떤 조치를 취하든 여기에는 일부 위험이 따르기 마련입니다. 따라서 어떻게 하면 위험을 완화하고, 옵티마이저 통계가 정기적으로 수집되고, 모든 SQL문을 크게 변경하지 않고도(힌트 추가 등) 제대로 수행할 수 있는 정상적인 환경을 유지하면서, 생성된 SQL문에 대한 실행 계획을 최적으로 유지할 수 있겠습니까? 여러분 중에는 저장된 개요를 사용하여 계획을 유지하려 하는 분도 있을 것입니다. 하지만 그러한 행동은 옵티마이저가 도움이 될만한 실행 계획을 생성하는 것을 방해할 뿐입니다.

     

    Oracle Database 11g에서는 새로운 SQL 계획 관리 기능을 사용하여 실행 계획이 계속해서 어떻게 변하는지 확인하고, 실행 계획을 사용하기 전에 먼저 데이터베이스에서 실행하여 계획을 확인하며, 통제된 방식으로 계획이 더 나아지도록 점차 개선할 수 있습니다.

     

    SQL 계획 관리

     

    SQL 계획 관리를 사용하는 경우, 옵티마이저는 특별 저장소인 SQL 관리 베이스에 생성된 실행 계획을 저장합니다. 특정 SQL문에 대해 저장된 모든 계획은 해당 SQL문의 계획 내역의 일부가 됩니다.

     

    내역의 일부 계획은 "수락됨(Accepted)"으로 표시될 수 있습니다. SQL문이 재분석될 경우 옵티마이저는 내역 중 수락된 계획만을 고려합니다. 해당 SQL문에 대해 수락된 계획 세트를 SQL 계획 기준선 (SQL Plan Baseline) 또는 줄여서 기준선 (Baseline)이라고 합니다.

     

    그러나 옵티마이저는 계속해서 더 나은 계획을 생성하기 위해 노력합니다. 옵티마이저가 새로운 계획을 생성한 경우, 계획 내역에 해당 계획을 추가하지만, 이 계획이 기준선의 수락된 모든 계획보다 더 나은 경우가 아니라면 SQL을 재분석할 때 고려하지 않습니다. 따라서 SQL 계획 관리를 사용하면 SQL문이 갑자기 효과가 떨어지는 계획을 가져와서 성능이 떨어지는 결과를 초래하는 현상이 발생하지 않습니다.

    SQL 계획 관리를 사용하면 SQL문의 계획 내역에서 사용 가능한 모든 계획을 검사하고, 상대적인 효율성을 비교할 수 있습니다. 또한 특정 계획이 수락 상태로 되도록 하기도 하며 심지어 계획을 영구(고정) 계획이 되게 할 수도 있습니다.

     

    이 문서에서는 SQL문의 최적 성능을 보장하기 위해 명령 행에서 Oracle Enterprise Manager 및 SQL을 사용하여 기준선의 캡처, 선택 및 개선을 포함한 SQL 계획 기준선의 관리 방법에 대해 알아봅니다.

     

    캡처

     

    SQL 계획 관리의 캡처 기능은 SQL문에서 사용한 다양한 옵티마이저 계획을 캡처합니다. 기본적으로 캡처 기능은 비활성화되어 있습니다. 즉, SQL 계획 관리에서 분석 또는 재분석중인 SQL문의 내역을 캡처하지 않습니다.

     

    한 세션에서 파생된 몇몇 SQL문 예제에 대한 기준선을 캡처해 보겠습니다. 여기서는 Oracle Database 11 g 과 함께 제공된 샘플 스키마(SH)와 SALES 테이블을 사용할 것입니다.

     

    먼저 세션에서 기준선 캡처 기능을 활성화합니다.

     

    alter session <br /> set optimizer_capture_sql_plan_baselines = true;<br />

     

    이제 이 세션에서 실행된 모든 SQL문이 해당 최적화 계획과 함께 SQL 관리 베이스에 캡처됩니다. SQL문의 계획은 변경될 때마다 계획 내역에 저장됩니다. 이를 확인하려면 목록 1에 표시된 스크립트를 실행해 보십시오. 이 스크립트는 완전히 동일한 SQL을 다른 환경에서 실행합니다. 먼저, SQL이 모든 기본값으로 실행됩니다(암시적 기본값 optimizer_mode = all_rows 포함). 다음 실행 시, optimizer_mode 매개 변수 값은 first_rows로 설정되어 있습니다. SQL의 세 번째 실행 전에 테이블 및 인덱스에 대한 새로운 통계를 수집합니다.

     

    코드 목록 1: SQL 계획 기준선 캡처

    alter session set optimizer_capture_sql_plan_baselines = true;<br /> -- First execution. Default Environment<br /> select * /* ARUP */ from sales<br /> where quantity_sold &gt; 1 order by cust_id;<br /> -- Change the optimizer mode<br /> alter session set optimizer_mode = first_rows;<br /> -- Second execution. Opt Mode changed<br /> select * /* ARUP */ from sales<br /> where quantity_sold &gt; 1 order by cust_id;<br /> -- Gather stats now<br /> begin<br /> dbms_stats.gather_table_stats (<br /> ownname =&gt; 'SH',<br /> tabname =&gt; 'SALES',<br /> cascade =&gt; TRUE,<br /> no_invalidate =&gt; FALSE,<br /> method_opt =&gt; 'FOR ALL INDEXED COLUMNS SIZE AUTO',<br /> granularity =&gt; 'GLOBAL AND PARTITION',<br /> estimate_percent =&gt; 10,<br /> degree =&gt; 4<br /> );<br /> end;<br /> /<br /> -- Third execution. After stats<br /> select * /* ARUP */ from sales<br /> where quantity_sold &gt; 1 order by cust_id;<br />

     

    목록 1의 SQL 실행마다 계획이 변경될 경우, 해당 SQL문의 계획 내역에 다른 계획이 캡처됩니다. (/* ARUP */ 코멘트는 공유 풀의 특정 SQL문을 쉽게 식별합니다.)

    계획 내역을 확인하는 가장 쉬운 방법은 Oracle Enterprise Manager를 사용하는 것입니다. Database 기본 페이지에서 Server 탭을 선택한 다음 SQL Plan Control을 클릭합니다. 페이지에서 SQL Plan Baseline 탭을 선택합니다. 그림 1처럼 해당 페이지에서 ARUP 이름이 포함된 SQL문을 검색합니다. 그러면 화면의 하단부에 SQL문에 대한 계획 내역이 표시됩니다.

     

    그림 1: SQL 계획 내역

    SQL 계획 이름(예: SYS_SQL_PLAN_27a47aa154bc8843)을 클릭하면 계획 내역에 저장된 계획의 세부 정보를 확인할 수 있습니다. 화면의 중요한 열은 다음과 같습니다.

    • Enabled는 계획의 활성 여부를 나타냅니다.
    • Accepted는 옵티마이저에서 계획을 고려하는지 여부를 나타냅니다. 하나 이상의 계획이 수락된 경우 옵티마이저는 최적의 계획을 선택합니다.
    • Fixed는 계획이 해당 SQL문에 영구적으로 사용될 것인지 여부를 나타냅니다. 하나 이상의 계획이 고정된 경우 옵티마이저는 최적의 계획을 선택합니다.
    • Auto Purge는 계획이 사용되지 않는 경우, 일정 기간 후에 계획 내역에서 해당 계획이 자동으로 삭제되는지 여부를 나타냅니다. 자동 삭제가 활성화된 경우, 지정한 기간 후에 계획 내역에서 사용되지 않는 계획이 자동으로 삭제됩니다. 사용되지 않는 계획이 삭제되도록 지정한 기간은 그림 1의 Plan Retention(Weeks) 레이블 옆에 표시되어 있습니다. 이 경우 53주로 설정되어 있지만 Configure 버튼을 클릭하여 변경할 수 있습니다.

    또한 Settings 섹션에서 적절한 링크를 통해 이 Oracle Enterprise Manager 화면에서 SQL 계획 기준선의 캡처 및 사용을 활성화할 수도 있습니다.

     

    커서 캐시 또는 SQL 튜닝 세트에서 SQL 계획 기준선에 계획을 로드할 수도 있다는 것을 참고하십시오. 계획을 SQL 계획 기준선에 수동으로 로드한 경우, 이 로드된 계획은 수락된 계획으로 추가됩니다. 자세한 내용은 Oracle Database Performance Tuning Guide의 15장 "Using SQL Plan Management"를 참조하십시오.

     

    기준선 사용

     

    SQL 계획 기준선을 캡처한 경우, 옵티마이저를 활성화하여 해당 기준선을 사용할 수 있습니다.

     

    alter session set <br /> optimizer_use_sql_plan_baselines = true;<br />

     

    기준선 사용이 활성화된 경우, 옵티마이저가 SQL문을 재분석할 때 해당 SQL문의 기준선에 저장된 계획을 검사하고 최적의 계획을 선택합니다. 이것이 바로 기준선의 가장 중요한 이점입니다. 또한 옵티마이저는 SQL문을 계속 재분석하며(기준선의 존재가 이를 방해하지 않음), SQL의 계획 내역에 새로 생성된 계획이 없는 경우, 이 계획을 추가하지만 “Accepted” 상태로 추가하지는 않습니다. 따라서 새로 생성된 계획이 더 나쁜 경우에도 그 계획은 사용되지 않기 때문에 SQL 성능은 영향을 받지 않습니다. 그러나 데이터 배포 및 애플리케이션 논리에 관한 개인적인 지식에 따라 새 계획이 더 낫다고 결정하는 경우도 있습니다. 예를 들어, 테이블이 실제로 비어 있을 때 계획이 캡처됐다고 가정해 봅시다. 이 경우 옵티마이저는 인덱스 검색을 선택합니다. 그러나 여러분은 나중에 SQL문을 호출하기 전에 애플리케이션이 테이블을 채운다는 것과 전체 테이블 검색이 계획에는 결국에는 더 좋다는 것을 알고 있습니다. 이런 상황에서는 새 계획을 검사하여 더 나은 경우 이를 수락할 수 있습니다. 그리고 옵티마이저는 그 후에 이 계획을 고려하게 됩니다. 이 경우 좋은 점은 항상 좋은 계획이 사용되고, 옵티마이저가 더 나은 계획을 생성한 경우에는 비교하여 사용할 수 있다는 것입니다.

    SQL문의 기준선의 계획을 사용하지 않고자 하는 경우에는 SQL문을 호출하기 전에 세션에서 다음과 같은 문을 사용하여 기준선 사용을 비활성화할 수 있습니다.

     

    alter session set <br /> optimizer_use_sql_plan_baselines = false;<br />

     

    목록 2에서는 동일한 쿼리를 두 번 실행합니다. 먼저 기준선을 활성화하여 실행한 다음, 기준선을 비활성화하고 실행합니다. 여기서 기준선을 비활성화한 후 계획이 어떻게 변경되는지 확인할 수 있습니다. 맨 처음 옵티마이저는 SALES_TIME_BIX 인덱스에서 BITMAP INDEX FULL SCAN을 선택했습니다. 기준선을 비활성화한 후에는 계획이 SALES 테이블의 TABLE ACCESS FULL로 바뀌었습니다. 이는 이 계획이 옵티마이저 통계와 옵티마이저에 지금 당장 영향을 미치는 다른 변수를 기준으로 최적의 계획으로 여겨지기 때문입니다. 먼저 기준선을 활성화한 경우에서는 옵티마이저가 기준선에 저장된 수락된 계획 세트에서 최적의 계획을 선택했습니다.

    코드 목록 2: SQL 계획 기준선 사용

    SQL&gt; explain plan for select * /* ARUP */ from sales<br /> 2 where quantity_sold &gt; 1 order by cust_id;<br /> Explained.<br /> SQL&gt; select * from table(dbms_xplan.display(null, null, 'basic'));<br /> PLAN_TABLE_OUTPUT<br /> ---------------------------<br /> Plan hash value: 143117509<br /> --------------------------------------------------------------<br /> | Id | Operation | Name |<br /> --------------------------------------------------------------<br /> | 0 | SELECT STATEMENT | |<br /> | 1 | SORT ORDER BY | |<br /> | 2 | PARTITION RANGE ALL | |<br /> | 3 | TABLE ACCESS BY LOCAL INDEX ROWID| SALES |<br /> | 4 | BITMAP CONVERSION TO ROWIDS | |<br /> | 5 | BITMAP INDEX FULL SCAN | SALES_TIME_BIX |<br /> --------------------------------------------------------------<br /> -- Now disable baselines and look at the latest plan<br /> SQL&gt; alter session set optimizer_use_sql_plan_baselines = false;<br /> Session altered.<br /> SQL&gt; explain plan for select * /* ARUP */ from sales<br /> 2 where quantity_sold &gt; 1 order by cust_id;<br /> Explained.<br /> SQL&gt; select * from table(dbms_xplan.display(null, null, 'basic'));<br /> PLAN_TABLE_OUTPUT<br /> ----------------------------<br /> Plan hash value: 3803407550<br /> --------------------------------------<br /> | Id | Operation | Name |<br /> --------------------------------------<br /> | 0 | SELECT STATEMENT | |<br /> | 1 | SORT ORDER BY | |<br /> | 2 | PARTITION RANGE ALL | |<br /> | 3 | TABLE ACCESS FULL | SALES |<br /> --------------------------------------<br />

     

    관리 및 개선

     

    특정 SQL문에 대한 기준선을 만든 후, 그림 1에 표시된 Oracle Enterprise Manager 화면에서 연관된 계획 이름을 클릭하여 (Oracle Enterprise Manager -> SQL Plan Control page -> SQL Plan Baseline tab) 기준선을 검사하고 계획의 세부 정보를 확인할 수 있습니다. 특정 계획이 좋아지지 않을 경우, Disable 버튼을 클릭하여 계획을 완전히 비활성화할 수 있습니다. 나중에 생각이 바뀔 경우에는 다시 Enable 버튼을 클릭할 수 있습니다.. Drop 버튼을 사용하면 SQL 관리 베이스에서 계획이 완전히 삭제됩니다. 계획이 사용되지 않고 보관 기간이 경과하면 해당 계획은 자동으로 삭제된다는 점을 참고 하십시오.

     

    현재 기준선의 계획이 최적이 아니고 계획 내역의 다른 계획이 더 낫다고 생각되는 경우, 진화 함수(Evolve Function)를 사용하여 계획의 성능을 비교해볼 수 있습니다(Oracle Enterprise Manager -> SQL Plan Control page -> SQL Plan Baseline 탭 또는 명령 행에서 DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE 함수 사용). 진화 함수를 사용하려면 그림 1의 Oracle Enterprise Manager 화면에서 비교할 계획을 선택한 다음 Evolve 버튼을 클릭합니다. 그러면 옵티마이저가 선택한 최고의 계획과 여러분이 선택한 계획 간의 비교가 수행됩니다. 이 기능으로 목록 3에서 보여지는 것과 같은 보고서가 생성됩니다. 목록 상단의 다음 행을 주목하십시오:

     

    코드 목록 3: 기준선 개선 보고서

    -----------------------------------------------------<br /> Evolve SQL Plan Baseline Report<br /> -----------------------------------------------------<br /> Inputs:<br /> ----<br /> PLAN_LIST = SYS_SQL_PLAN_27a47aa15003759b<br /> TIME_LIMIT = DBMS_SPM.AUTO_LIMIT<br /> VERIFY = YES<br /> COMMIT = YES<br /> Plan: SYS_SQL_PLAN_27a47aa15003759b<br /> ----------------------<br /> Plan was verified: Time used 41.06 seconds.<br /> Failed performance criterion: Compound improvement ratio &lt; .36<br /> Baseline Plan Test Plan Improv. Ratio<br /> -------------- --------- ------------- <br /> Execution Status: COMPLETE COMPLETE<br /> Rows Processed: 0 0<br /> Elapsed Time(ms): 5036 1033 4.88<br /> CPU Time(ms): 254 700 .36<br /> Buffer Gets: 1728 43945 .04<br /> Disk Reads: 254 22 11.55<br /> Direct Writes: 0 0<br /> Fetches: 49 22 2.23<br /> Executions: 1 1<br /> --------------------------------------------------------------------<br /> Report Summary<br /> --------------------------------------------------------------------<br /> Number of SQL plan baselines verified: 1.<br /> Number of SQL plan baselines evolved: 0.<br /> Failed performance criterion: <br /> Compound improvement ratio &lt; .36. <br />

     

    이 행에서는 새로 고려된 계획이 원래 계획보다 성능이 떨어지는 것으로 표시됩니다. 따라서 옵티마이저의 최적 계획 선택을 위한 대체 항목으로서 거부되었습니다. 비교로 인해 개선 요인이 1보다 큰 것으로 드러나면 SQL 계획 관리에서는 해당 계획을 옵티마이저가 고려할 후보로 수락했을 것입니다.

    진화 함수를 통한 결정이 정확하지 않다고 생각되어 옵티마이저가 한 특정 계획을 사용하도록 하고 싶은 경우에는 어떻게 하시겠습니까? 이는 계획이 기준선에 고정되도록 함으로써 할 수 있습니다. 목록 4처럼 dbms_spm 패키지에서 alter_sql_plan_baseline 함수를 실행하여 계획이 고정되게 할 수 있습니다.

     

    코드 목록 4: 계획 기준선 고정

    declare<br /> l_plans pls_integer;<br /> begin<br /> l_plans := dbms_spm.alter_sql_plan_baseline (<br /> sql_handle =&gt; 'SYS_SQL_f6b17b4c27a47aa1',<br /> plan_name =&gt; 'SYS_SQL_PLAN_27a47aa15003759b',<br /> attribute_name =&gt; 'fixed',<br /> attribute_value =&gt; 'YES'<br /> );<br /> end;<br /> -- Now examine the plan:<br /> SQL&gt; explain plan for select * /* ARUP */ from sales<br /> 2 where quantity_sold &gt; 1 order by cust_id;<br /> Explained.<br /> SQL&gt; select * from table(dbms_xplan.display(null, null, 'basic'));<br /> Plan hash value: 143117509<br /> --------------------------------------------------------------<br /> | Id | Operation | Name |<br /> --------------------------------------------------------------<br /> | 0 | SELECT STATEMENT | |<br /> | 1 | SORT ORDER BY | |<br /> | 2 | PARTITION RANGE ALL | |<br /> | 3 | TABLE ACCESS BY LOCAL INDEX ROWID| SALES |<br /> | 4 | BITMAP CONVERSION TO ROWIDS | |<br /> | 5 | BITMAP INDEX FULL SCAN | SALES_PROMO_BIX |<br /> --------------------------------------------------------------<br />

    출력 결과로부터 새로운 계획에서 이전 계획에서 사용되었던 (그리고 목록 2에서 보여진) SALES_TIME_BIX 인덱스 대신 SALES_PROMO_BIX 인덱스를 사용한 것을 알 수 있습니다. 이제 새 계획이 고정됩니다.

    그렇다면 고정된 계획을 어디서 사용할 수 있을까요? SQL문의 계획이 최적이 아니며 (예를 들어, 계획이 SALES_TIME_BIX 인덱스를 사용할 경우 더 효율적일 수 있는데 SALES_PROMO_BIX 인덱스를 사용하는 계획) 코드를 변경하여 힌트를 배치할 수 없는 상황을 가정해 보십시오. 이 경우 다음 단계를 수행할 수 있습니다.

     

    1. 다른 세션에서 optimizer_mode 매개 변수를 목록 1에서 보여진 것처럼 원하는 계획을 생성하는 값으로 변경합니다.

    2. SQL문을 실행하고, 목록 1처럼 기준선을 캡처한 다음, 세션의 연결을 끊습니다.

    3. 목록 4에서 보여진 것처럼 SALES_TIME_BIX 인덱스를 사용하여 계획을 고정으로 표시합니다. SQL 핸들과 계획 이름을 여러분의 케이스에 해당하는 이름으로 바꾸는 것을 기억하십시오.

     

    계획이 고정으로 표시되고 나면 SQL문은 옵티마이저가 생성한 계획이 아닌 해당 계획만을 사용하게 됩니다. 하나 이상의 고정된 계획이 존재하는 경우, 옵티마이저는 최적의 계획을 선택합니다.

     

    동일한 방법을 사용하여 데이터베이스 업그레이드 중 SQL문의 안정적인 실행 경로를 보장할 수도 있습니다. 먼저 시스템 매개 변수 optimizer_capture_sql_plan_baselines를 true로 설정하여 데이터베이스에서 모든 SQL문에 대한 기준선을 수집한 다음, 중요한 SQL문마다 하나의 계획만 고정으로 표시되도록 합니다. 그런 다음 점진적으로 계획을 "고정 해제"하고 진화 함수를 사용하여 다른 최적의 계획이 있는지 확인합니다. 옵티마이저가 나중에 생성한 계획이 더 나쁠 경우에는 항상 이전의 고정된 계획으로 되돌릴 수 있습니다.

     

    결론

     

    저장된 개요 또한 계획을 안정적으로 만들지만 융통성이 없게 합니다. 옵티마이저는 SQL문에 대한 개요가 있는지 확인하고 새로운 계획 생성을 중지합니다. 한편 기준선은 옵티마이저가 새로운 계획을 생성하는 것을 절대 중단하지 않습니다.

     

    SQL 계획 관리 기능을 사용하면 SQL문에 대한 검증된 계획이나 잘 알려진 계획을 기준선의 형식으로 저장할 수 있습니다. 그러면 갑작스런 성능 저하를 진단할 때 매우 유용합니다. 기준선(및 해당 계획)이 저장소에 저장되기 때문에 기준선 및 계획을 비교하여 가장 효율적으로 사용할 수 있도록 결정할 수 있습니다.

     

    필자소개

     

    Arup Nanda ( arup@proligence.com ) 는 성능 조정에서 보안 및 재해 복구에 이르기까지 모든 데이터베이스 관리 측면을 관리하는 Oracle DBA로서 14년 이상 근무해 왔습니다. 그리고 2003년 Oracle Magazine에 의해 올해의 DBA로 선정된 바 있습니다

     

    출처 : 한국 오라클

    제공 : DB포탈사이트 DBguide.net

    반응형
    저작자표시 비영리

    'ORACLE > 11G' 카테고리의 다른 글

    11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
    oracle 11g에 추가된 파티션  (0) 2013.08.20
    ADR  (0) 2013.05.19
    11g 데이타베이스 에러수집방법  (0) 2012.05.11
    Oracle Advanced Compression  (0) 2009.04.02
    Posted by [PineTree]
    ORACLE/11G2009. 4. 2. 15:31

    Oracle Advanced Compression

    반응형

    Oracle Advanced Compression

     

     

    도입

     

    효과적인 사업 운영에 필요한 데이터 용량의 폭발적 증가로 기업이 골치를 앓고 있 습니다. 이런 데이터 증가 추세의 원인으로 몇 가지 중대한 요인을 들 수 있습니다. 우선, 사베인스 옥슬리와 HIPP 등 최근에 분 규제 환경의 변화가 이런 추세를 일으 키고 있습니다. 그러면서 방대한 정보를 장기간 보유하도록 기업에 요구하고 있습니 다. 광대역 기술의 발전으로 가능해진 리치 멀티미디어 컨텐츠의 인터넷 대량 배포 역시 전체 데이터 용량의 증가에 한몫 하고 있습니다. 기하급수적인 데이터 증가 추 세를 더욱 촉발시킨 것은 웹 2.0의 도래입니다. 웹 2.0에서는 협업 애플리케이션이 엄청난 양의 사용자 생성 컨텐츠(UGC)를 선전합니다. 여러 자료를 살펴 보면 데이 터 용량이 2-3년마다 거의 두 배로 증가하고 있습니다.

     

    이같은 데이터 용량의 급격한 증가는 IT 관리자에게 위협적인 관리 문제를 던져줍 니다. 무엇보다 가장 큰 문제는 스토리지 비용의 상승입니다. MB당 스토리지 비용 이 지난 몇 년간 큰 폭으로 떨어지고 있긴 하지만, 온라인에 보관해야 하는 데이터 용량이 엄청나게 증가하면서 스토리지가 IT 예산의 최대 지출 항목이 되었습니다. 게다가 데이터 용량이 급증하는데 따른 애플리케이션의 확장성과 성능도 지속적으 로 사업상 요구에 맞춰 증가해야 합니다.

     

    Oracle Database 11g는 Advanced Compression 옵션을 도입하여 고객이 이 문제 에 대처할 수 있게 지원합니다. 오라클 압축 기술의 혁신 덕택에 고객은 대량의 데이 터 관리에 따르는 자원과 비용을 절감할 수 있습니다. 한때는 신기하게 생각했던 테 라바이트 규모의 데이터베이스가 기업 데이터 센터에 널리 확산되고 있어 이같은 신기술의 도입은 시기 적절합니다.

     

    Oracle Advanced Compression

     

    Oracle Database 11g의 Advanced Compression 옵션은 고객이 자원 활용을 극대 화하고 비용을 절감할 수 있게 지원하는 광범위한 압축 기능 세트를 가지고 있습니 다. 정규 관계형(체계화) 데이터, 비체계화 데이터 (문서, 스프레드시트 등), 백업 데 이터를 비롯한 모든 데이터 유형의 압축을 지원하므로 IT 관리자는 전체 데이터베 이스 저장 용량을 크게 줄일 수 있습니다. 그리고 사람들은 압축의 가장 확실한 이점 이 스토리지 비용의 감소라고 생각하지만, Advanced Compression 옵션에 포함된 혁신적인 기술들은 메모리와 네트워크 대역폭을 비롯하여 IT 인프라의 모든 구성요 소에 대한 자원 요구와 기술 비용을 낮출 수 있게 고안되어 있습니다.

     

    관계형 데이터의 압축

     

    오라클은 데이터베이스 압축 기술 도입의 선구자 중 하나입니다. Oracle Database 9i는 Direct path loading 과 CREATE TABLE AS SELECT…(CTAS) 등의 대량 로딩 작업 중에 데이터를 압축할 수 있게 해주는 테이블 압축을 여러 해 전에 도입했 습니다. 이런 압축 형태는 일괄 처리를 통해 데이터베이스에 대부분의 데이터를 로 딩하는 데이터웨어하우징 환경에 가장 적합했습니다. Oracle Database 11g는 OLTP 테이블 압축이라는 새로운 기능을 도입하고 있는데, 이는 INSERT, UPDATE, DELETE와 같이 전통적인 DML (데이터 조작어)을 포함하여 모든 유형 의 데이터 조작 작업 중에 데이터를 압축할 수 있는 기능입니다. 또한 이 기능은 쓰 기 작업의 오버헤드를 낮춰서 성능을 크게 향상시키기 때문에 데이터웨어하우징 환 경이나 OLTP 환경에도 적합합니다. 이 획기적인 신기능은 모든 애플리케이션 작업 에 압축의 이점을 제공합니다.

     

    Oracle Database 9i에 도입된 테이블 압축 기능이Enterprise Edition (EE)의 기본 기능이며 Database 11g에서도 기본 기능이라는 데 주목할 필요가 있습니다. 하지만 새로운 OLTP 테이블 압축 기능은 엔터프라이즈 에디션에 추가로 라이센스를 받아 야 하는 Oracle Advanced Compression 옵션의 일부입니다.

     

    혁신적인 알고리즘

     

    오라클은 관계형 데이터와 함께 실행할 수 있게 특별 설계된 고유한 압축 알고리즘 을 사용합니다. 이 알고리즘을 실행하면 데이터베이스 블록 내부에서, 그것도 여러 줄(column)을 가로지르며 중복 값을 제거합니다. 압축 블록에는 압축 메타데이터를 보존하는 심볼 테이블(symbol table)이란 구조가 있는데, 블록을 압축할 때 제일 먼 저 중복 값의 복사본 하나를 심볼 테이블에 추가하여 중복 값을 제거합니다. 그런 다 음 각 중복 값을 심볼 테이블의 해당 항목에 대한 짧은 참조로 대체합니다. 압축 데 이터를 원상태로 바꾸는 데 사용하는 메타데이터가 블록 내부에 들어 있기 때문에, 이 혁신적 설계의 압축 데이터는 데이터베이스 블록 내부에 독립적으로 존재합니다. 전역 데이터베이스 심볼 테이블을 유지하는 경쟁 압축 알고리즘과 비교할 때, 압축 데이터 이용 시 추가 I/O를 도입하지 않는 오라클의 고유한 방식이 이롭습니다.

     

     

    그림 1. 압축 블록 對비압축 블록

     

    테이블 압축의 이점

     

    일정 환경에서 추출한 압축비는 압축하는 데이터의 성향, 특히 데이터의 개체 수에 따라 달라집니다. 일반적으로, 테이블 압축 기능을 이용하여 고객이 압축 데이터의 저장 공간 사용을 2-3배 줄일 수 있다고 예상할 수 있습니다. 즉, 비압축 데이터가 사용하는 공간 용량이 압축 데이터의 그것보다 2-3배 많아지게 됩니다. 압축의 이 점은 단순히 디스크 저장 공간의 절약에 그치지 않습니다. 처음에 블록의 압축을 해 제하지 않고도 오라클이 압축 블록을 직접 읽을 수 있다는 것이 한 가지 중요한 장점 입니다. 그래서 압축 데이터를 이용해도 눈에 띄는 성능 저하가 없습니다. 사실, 많 은 경우 이용하는 블록 수가 줄기 때문에 I/O 감소로 인해 성능이 향상될 수도 있습 니다. 게다가, 메모리 공간을 늘리지 않고도 캐시에 더 많은 데이터를 저장할 수 있 어 버퍼 캐시의 효율성이 높아질 수 있습니다.

     

    최소 성능 오버헤드

     

    앞서 설명했듯이, 테이블 압축 기능은 읽기 작업에 악영향을 끼치지 않습니다. 그러 나 데이터 작성 시에는 쓰기 작업에 대한 성능 오버헤드가 제거되는 것이 불가피한 반면 압축 시에는 추가 작업이 필요합니다. 하지만 오라클은 OLTP 테이블 압축에 대한 오버헤드를 최소화하기 위해 많은 연구를 했습니다. 오라클은 쓰기 작업이 발 생할 때마다 데이터를 압축하기보다는 일괄 방식으로 블록을 압축합니다. 새롭게 초 기화된 블록은 블록의 데이터가 내부에서 통제되는 임계에 도달할 때까지 압축되지 않고 그대로 있습니다. 트랜잭션으로 인해 블록 내 데이터가 이 임계에 도달하면, 해 당 블록의 모든 컨텐츠가 압축됩니다. 이후 더 많은 데이터가 블록에 추가되어 다시 임계에 도달하면 블록 전체가 재압축되면서 압축 수준이 최고 수준에 이르게 됩니 다. 더 이상 압축하면 블록에 이로울 수 없다고 오라클이 판단할 때까지 이 프로세스 가 반복됩니다. 블록의 압축을 유발하는 트랜잭션만 압축 오버헤드가 최소화 됩니 다. 때문에 압축된 블록에 있는 대부분의 OLTP 트랜잭션이 압축되지 않은 블록의 트랜잭션과 동일한 성능을 갖게 되는 것입니다.

     

    그림 2. 블록 압축 프로세스

     

    비체계화 데이터의 압축

     

    Oracle Database 11g의 새로운 기능인 SecureFiles는 문서, 스프레드시트 및 XML 파일과 같은 비체계화 컨텐츠의 저장에“두 세계의 최고 장점”을 지닌 아키텍처를 지원합니다. SecureFiles 은 오라클 데이터베이스의 장점을 모두 갖고 있으면서 전 통적인 시스템과 비교하여 파일 데이터에 대해 뛰어난 성능을 구현하도록 특별 설 계되어 있습니다. SecureFiles는 ANSI 표준 대형 객체(LOB)의 수퍼세트 용으로, 기존의 LOB나 베이직 파일 (BasicFiles)에서 수월하게 마이그레이션할 수 있게 지 원합니다. 이제 IT 조직들은 SecureFiles 로 오라클의 관계형 데이터와 관련 파일 데이터 모두를 관리할 수 있습니다. Oracle Database 11g의 Advanced Compression 옵션에는 SecureFiles 데이터의 저장 공간을 크게 감소시키는 기술이 적용되어 있습니다.

     

    SecureFiles 복제

     

    애플리케이션에서 똑같은 파일 사본을 저장하는 일은 매우 흔합니다. 한 가지 일반 적인 예가 이메일 애플리케이션입니다. 이메일 애플리케이션에서는 사용자가 똑같 은 첨부 파일을 수신할 수 있습니다. SecureFiles 복제는 SecureFiles 데이터의 복 사본을 제거하는 지능형 기술입니다. 오라클은 SecureFiles 데이터의 한 이미지를 저장하고서 복사본을 이 이미지의 참조로 대체합니다. 10명의 사용자가 1MB의 똑 같은 파일이 첨부된 이메일을 받는 이메일 애플리케이션에 대해 생각해 보십시오.

     

    SecureFiles 복제가 없다면 시스템에서 10명의 사용자 한명 한명에 대해 파일 사본 을 하나씩 저장할 것이고 그러면 10MB의 저장 공간이 필요할 것입니다. 이 경우 이 메일 애플리케이션에서 SecureFiles 복제 기술을 사용했다면, 1MB의 첨부 파일을 한번만 저장하면 됐을 것입니다. 그러면 스토리지 요구량이 90% 절약될 것입니다. 스토리지 절약 외에 SecureFiles 복제 기술은 애플리케이션 성능을 높이기도 합니다. 구체적으로 말해서, SecureFiles 이미지의 참조만 작성하기 때문에 쓰기와 복사 작업의 효율성이 높아집니다. 게다가, 똑같은 SecureFiles 데이터가 이미 버퍼 캐시 에 존재하면, 읽기 작업이 향상될 수도 있습니다.

     

    그림 3. SecureFiles 복제

     

    SecureFiles 압축

     

    Oracle Database 11g의 Advanced Compression 옵션은 SecureFiles 데이터의 크 기를 제어하는 또 다른 메카니즘을 제공합니다. 앞서 논의한 복제 외에, SecureFiles 압축(SecureFiles Compression)은 업계 표준의 압축 알고리즘을 활용하여 SecureFiles 데이터의 스토리지 요구량을 더욱 최소화합니다. 문서나 XML 파일과 같은 일반 파일을 압축하면 크기가 2-3배 줄어듭니다. 내장된 지능형 기술을 이용 하는 SecureFiles 압축은 압축의 이점이 없는 데이터의 경우 압축을 피합니다. SecureFiles 자격으로 데이터베이스에 끼워 넣기 전에 타사 도구를 통해 압축된 문 서가 그 예입니다.

     

    현재 지원하는 압축 수준은 두 종류이며, 그 중 높은 쪽의 경우 압축률이 높지만 대 신 CPU 사용이 더 많이 요구됩니다. SecureFiles 압축의 일반적인 CPU 오버헤드는 3%와 5% 사이입니다. 애플리케이션에서는 압축된 SecureFiles 데이터에 대한 무 작위 읽기/쓰기를 여전히 수행할 수 있습니다. 압축된 데이터가 더 작은 크기의 데이 터로 분해되기 때문입니다. 이렇게 하면, 전체 파일을 데이터베이스에 끼워 넣기 전 에 압축할 때와 비교하여 성능을 크게 향상시킬 수 있습니다.

     

    백업 데이터의 압축

     

    데이터베이스 내부에 저장된 데이터를 압축하는 것 외에, Oracle Advanced Compression은 백업 데이터를 압축하는 기능도 있습니다. Recovery Manager (RMAN)와 Data Pump는 오라클 데이터베이스에 저장된 데이터를 백업할 때 가장 많이 사용하는 도구 두 가지입니다. RMAN은 데이터베이스 데이터를 블록별로 백 업하는데, 이를 일명“물리적”백업이라고 합니다. 이 물리적 백업은 데이터베이스, 테이블 공간 또는 블록 단위 복구를 수행할 때 사용할 수 있습니다. 반면, Data Pump는“논리적”백업을 수행할 때 사용하며, 하나 이상의 테이블에 있는 데이터를 플랫 파일(flat file)에 오프로딩합니다. Oracle Advanced Compression은 두 도구 중 하나에 의해 생성된 백업 데이터를 압축하는 기능이 있습니다.

     

    Data Pump 압축

     

    Data Pump와 관련된 메타데이터를 압축하는 기능은 Oracle Database 10g Release 2에서 제공합니다. Oracle Database 11g에서는 내보내기할 테이블 데이터를 압축 할 수 있도록 이 압축 기능을 확장했습니다. Data Pump 압축은 인라인 작업이므로파일 크기가 감소하면 디스크 공간이 크게 절약됩니다. 운영 체제나 파일 시스템의 압축 유틸리티와 달리, Data Pump 압축은 가져오기 측면에서 볼 때 완전히 인라인 방식입니다. 따라서 덤프 파일(dump file)을 가져오기 전에 압축을 해제하지 않아도 됩니다. 압축된 덤프 파일 집합은 데이터베이스 관리자가 추가 절차를 밟지 않아도 가져오기 작업 중에 자동으로 압축이 풀립니다.

     

    오라클 샘플 데이터베이스에 있는 다음의 압축 예에서, 모든 데이터와 메타데이터를 동시에 압축하면서 OE 및 SH 스키마를 내보냈습니다. 그 결과, 덤프 파일의 크기가 74.67% 감소했습니다.

     

    3가지 버전의 gzip (GNU zip) 유틸리티와 한 가지 UNIX 압축 유틸리티를 6.0MB의 덤프 파일 집합을 압축하는 데 사용했습니다. 덤프 파일 크기의 감소가 Data Pump 압축과 비슷했습니다. 덤프 파일 크기의 감소폭은 데이터 유형과 기타 요인에 따라 달라진다는 점에 유의하십시오.

     

    압축 파일을 이용하여 Data Pump 기능을 충분히 사용할 수 있습니다. 정규 파일에 서 사용하는 모든 명령어는 압축 파일에서도 효력을 발휘합니다. 덤프 파일 집합에 서 어떤 부분을 압축해야 할지는 사용자가 다음의 옵션으로 결정할 수 있습니다.

    • ALL: 모든 내보내기 작업의 압축을 지원합니다.

    • DATA-OLNY: 모든 데이터가 덤프 파일에 압축 포맷으로 작성됩니다.

    • METADATA-ONLY: 모든 메타데이터가 덤프 파일에 압축 포맷으로 작 성됩니다. 이것이 기본값입니다.

    • NONE: 전체 내보내기 작업의 압축을 사용 안 함으로 합니다.

    Recovery Manager 압축

     

    기업 데이터베이스의 지속적인 팽창은 데이터베이스 관리자에게 커다란 도전입니 다. 데이터베이스 백업을 보존하는 스토리지 요구량과 백업 절차의 수행은 데이터베 이스 크기의 영향을 직접적으로 받습니다. 오라클의 백업 및 복구 유틸리티인 Recovery Manager (RMAN)는 Oracle Database 10g에 압축 기능을 도입했습니 다. RMAN 압축을 이용하면 백업에 필요한 스토리지가 대폭 줄어듭니다. RMAN이 오라클 데이터베이스와 긴밀하게 통합되어 있어서 디스크나 테이프에 기록하기 전 에 백업 데이터가 압축되므로 복구에 앞서 압축을 풀 필요가 없습니다. 이렇게 하면 스토리지 비용이 상당히 줄어듭니다. 그러나 엄청난 압축비로 인해 백업 성능이 영 향을 받아 백업 창이 길어질 수 있습니다.

     

    Oracle Advanced Compression은 백업에 쓰이는 스토리지 요구량을 크게 감소시키 면서 RMAN 성능을 향상시키는 RMAN 압축 기능을 도입하고 있습니다. 업계 표준 의 ZLIB 압축 알고리즘에 기반한 RMAN 압축 백업은 Oracle Database 10g의 압축 백업보다 최대 40% 빠릅니다. 오라클은 압축비의 감소폭을 약 20%로 하여 이런 급 격한 성능 향상을 달성하고 있습니다. 빠른 RMAN 압축은 정상 근무 시간에 행하는 점증 백업을 위한 완벽한 솔루션입니다.

     

    네트워크 트래픽의 압축

     

    Data Guard는 관리, 모니터링 및 자동화 소프트웨어 인프라를 지원하여 하나 이상 의 스탠바이 데이터베이스를 생성, 유지, 모니터링함으로써 기업 데이터의 고장, 재 해, 오류, 데이터 손상을 방지합니다. Data Guard는 리두 데이터 (트랜잭션 복구에 필요한 정보)를 이용하여 기본 데이터베이스와 스탠바이 데이터베이스의 동기화를 유지합니다. 트랜잭션이 기본 데이터베이스에서 발생하면, 리두 데이터가 생성되어 로컬 리두 로그 파일에 작성됩니다. Data Guard의 리두 전송 서비스 (Redo Transport Services)는 이 리두 데이터를 스탠바이 데이터베이스로 전송하는 데 사 용합니다.

     

    네트워크나 스탠바이 서비스의 작동이 중단되면 리두 데이터가 스탠바이 서버에 전 송되는 것이 차단됩니다. 작동 중단이 해결되면, 오라클이 스탠바이 데이터베이스의 동기화에 필요한 모든 리두 데이터를 전송하는 식으로 Redo gap resolution을 자동 수행합니다. Oracle Advanced Compression에는 Redo gap resolution 도중에 리두 데이터가 네트워크에서 전송될 때 이를 압축하는 기능이 있습니다. 이 압축을 통해 네트워크 대역폭이 극대화되어 Redo gap resolution 처리량이 증가합니다. 압축으 로 Redo gap resolution이 최대 2배까지 빨라질 수 있으며, 그러면 스탠바이 데이터 베이스가 신속하게 동기화되고 고가용성이 구현됩니다.

     

    결론

     

    데이터 용량의 폭발적 증가가 기업에 심각한 위협이 되고 있습니다. 기업은 순익에 영향을 끼치지 않는 범위에서 변화하는 비즈니스 환경에 빠르게 적응해야 합니다. 그리고 IT 관리자는 비용 억제를 위해 기존 인프라를 효율적으로 관리하되, 높은 애 플리케이션 성능을 계속 구현해야 합니다.

     

    Oracle Database 11g의 Advanced Compression 옵션은 IT 관리자가 복잡한 환경 에서 성공할 수 있게 견고한 압축 기능 세트를 지원합니다. Advanced Compression 옵션을 이용하여 기업은 데이터 센터의 모든 구성요소 전반에 걸쳐 늘어나는 데이 터 요구량을 효율적으로 관리할 수 있습니다. 이를 통해 최고 수준의 애플리케이션 성능을 계속 구현하면서 비용을 최소화할 수 있습니다.

     

     

    출처 : 한국 오라클

    제공 : DB포탈사이트 DBguide.net

    출처명 : 한국 오라클
    반응형
    저작자표시 비영리

    'ORACLE > 11G' 카테고리의 다른 글

    11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
    oracle 11g에 추가된 파티션  (0) 2013.08.20
    ADR  (0) 2013.05.19
    11g 데이타베이스 에러수집방법  (0) 2012.05.11
    기준선 및 개선된 계획  (0) 2009.08.25
    Posted by [PineTree]

    티스토리툴바