starland: 2010

아래 레지스트리 정보를 TurnOff_F1.reg 파일로 저장한 후 실행한 후 재부팅 하면 F1 기능은 Disable 됩니다. 이 기능을 원래 상태로 복구하기 위해서는 Scancode Map 키를 삭제하고 시스템을 재시작하면 됩니다. 레지스트리 변경은 항상 주의가 요구됩니다. 아시죠?

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]

"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,00,00,3b,00,00,00,00,00

02 : Scancode Map 정보를 1개 변경 (예를 들어 2개 변경 시 03)

00,00 : Turn off (다른 Key Scan Code 를 입력하면 기능이 바뀌겠지요)

3b, 00 : F1 Scan code

[제거방법]

명령 프롬프트에서 아래 명령을 실행하여 해당 키를 제거할 수 있습니다.

reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout" /v scancode /f

Scancode Map 값에 대한 설명은 아래 KB를 참조하시기 바랍니다.

[참고자료]

Key Scan Codes

http://msdn.microsoft.com/en-us/library/aa299374(VS.60).aspx

Disabling the Windows Key on Microsoft Natural Keyboard

http://support.microsoft.com/kb/181348/en-us

작성자 : Lai Go / 작성일자 : 2010.04.20

2010년 9월 5일 일요일

[ORACLE] ADG 관련

출처 : http://soff.tistory.com/133

Data Guard

Active Data Guard가 어떻게 실시간 쿼리를 통해 스탠바이 환경에 대한 투자를 가치 있게 만들면서, 물리적 스탠바이 데이터베이스를 스냅샷 스탠바이로 변환해, 아카이브 로그 및 많은 새로운 향상된 기능을 인프라에 적용하는지 자세한 정보를 알아 보겠습니다. Oracle Database 11g 다운로드

Oracle Database 11g에는 책 한 권을 채울 수 있을 만큼 많은 Data Guard의 향상된 기능이 있습니다. 따라서 모든 향상된 기능을 자세히 밝히기는 불가능합니다. 대신 가장 흥미롭다고 생각되는 것을 중심으로 설명하도록 하겠습니다.

보다 간편하진 스탠바이 데이터베이스 생성

이제 시작합니다. 먼저 물리적 스탠바이 데이터베이스의 생성입니다. Oracle Database 11g에서, 이 프로세스는 RMAN 커맨드 하나면 족할 정도로 무척 간편해졌습니다. 이전에는, 2대의 머신 사이에 Data Guard를 설정하려면, Grid Control 마법사 인터페이스를 사용했습니다. 이 글을 작성하고 있는 시점 에서는, Oracle Enterprise Manager Grid Control 11g는 아직 사용할 수 없고, Database Control도 Data Guard를 위한 마법사를 가지고 있지 않습니다. 그러나 SQL 커맨드 사용 경험의 유무에 상관없이, Oracle Database 11g에, Data Guard 환경을 설정하는 것은 어렵지 않습니다. 이는 너무 단순해 여기서 모든 단계를 설명할 수 있습니다.

prolin11로 명명된 기본 데이터베이스가 prolin1이라는 서버에서 운영되고 있다고 가정합니다. 스탠바이 데이터베이스는 prolin2라는 서버에 설정하려고 합니다. 스탠바이 데이터베이스 인스턴스의 명칭은 pro11sb입니다. 단계는 다음과 같습니다:

이미 가지고 있는 경우가 아니라면, 우선, prolin1에 spfile을 생성합니다.

SQL> create spfile from pfile;

이 단계는 필수적인 것은 아니지만, 프로세스를 쉽게 해주는 이점이 있습니다. 데이터베이스 생성 후, spfile을 사용하기 위하여 prolin11 데이터베이스를 다시 시작합니다

스탠바이 재실행 로그 생성은 필수적인 것은 아니지만, 그렇게 하는 것이 좋습니다. 스탠바이 재실행 로그는 기본 데이터베이스에 발생하는 변화를 거의 실시간으로 스탠바이에 반영되도록 하는데, 이것이 Real Time Apply (RTA)라는 개념입니다. 따라서, 우리는 여기서 기본 데이터베이스에 스탠바이 재실행 로그를 생성할 것입니다 (스탠바이 재실행 로그는 기본 데이터베이스에 생성된다는 것을 잊지 마십시오. RMAN이 이 일을 할 것입니다):

SQL> alter database add standby redo logfile group 4

2> (‘+DG1/sby_redo01.rdo') size 50M;

SQL> alter database add standby redo logfile group 5

2> (‘+DG1/sby_redo02.rdo') size 50M;

SQL> alter database add standby redo logfile group 6

2> (‘+DG1/sby_redo03.rdo') size 50M;

SQL> alter database add standby redo logfile group 7

2> (‘+DG1/sby_redo04.rdo') size 50M;

이를 통해 4개의 스탠바이 재실행 로그 그룹이 생성됩니다.

prolin2 서버의 listener.ora 파일에 pro11sb를 위한 입력을 합니다:

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = pro11sb)

(ORACLE_HOME = /opt/oracle/product/11g/db1)

(SID_NAME = pro11sb)

)

LISTENER =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521))

)

리스너를 실행하려면 재로딩합니다

prolin1에서, $ORACLE_HOME/network/admin: 하부의 tnsnames.ora 파일에 pro11sb 데이터베이스를 위한 입력을 합니다 :

PRO11SB =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521))

)

(CONNECT_DATA =

(SID = pro11sb)

)

prolin2에서, Oracle Home/dbs 디렉토리에 1 라인을 포함하는 initodba11sb.ora 파일을 생성합니다:

db_name=prolin11

이는 스탠바이 인스턴스를 위한 초기화 파일로 기능할 것입니다; 파라미터의 나머지는 우리가 나중에 보게 될 RMAN 커맨드에 의해 자동 입력됩니다.

prolin2에서, $ORACLE_BASE/admin 디렉토리 갑니다. 여기에 pro11sb라는 이름의 디렉토리를 생성한 다음, 스탠바이 인스턴스에 대한 감사 파일을 보유하기 위하여 pro11sb 내에 adump라는 이름의 디렉토리를 생성합니다.

prolin1의 $ORACLE_HOME/dbs 디렉토리 하부에서, 흔히 orapworadba11로 명명되는 인스턴스 패스워드 파일을 볼 수 있습니다. 이 파일을 볼 수 없다면 (가능성은 희박하지만), 이를 생성합니다. 다음 그 파일을 prolin2의 $ORACLE_HOME/윤 하부로 복사합니다. 이를 orapwodba11sb 파일로 복사합니다. 이렇게 하면 기본 데이터베이스의 sysdba 연결 패스워드를 스탠바이에도 적용할 수 있습니다.

prolin2에서, NOMOUNT 상태의 인스턴스 pro11sb를 실행합니다:

$ sqlplus / as sysdba

SQL> startup nomount

이는 인스턴스를 실행하지만 아무것도 마운팅하지 않습니다.

이제 모든 초기화 준비가 완료되었으므로, 스탠바이 데이터베이스를 생성할 강력한 RMAN 스크립트를 호출합니다. prolin1에서, RMAN을 가동해 다음 스크립트를 실행합니다. 이를 파일에 저장하고 RMAN 프롬프트에서 스크립트를 실행하는 것은 매우 쉽습니다.

connect target sys/oracle123@prolin11

connect auxiliary sys/oracle123@pro11sb

run {

allocate channel c1 type disk;

allocate auxiliary channel s1 type disk;

duplicate target database

for standby

from active database

dorecover

spfile

parameter_value_convert 'prolin11','pro11sb'

set db_unique_name='pro11sb'

set db_file_name_convert='/prolin11/','/pro11sb/'

set log_file_name_convert='/prolin11/','/pro11sb/'

set control_files='/oradata/pro11sb/control01.ctl'

set fal_client='pro11sb'

set fal_server='prolin11'

set standby_file_management='AUTO'

set log_archive_config='dg_config=(prolin11,pro11sb)'

set log_archive_dest_2='service=prolin11 LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb'

set log_archive_dest_state_2='enable'

set log_archive_format='pro11sb_%t_%s_%r.arc'

;

sql channel c1 "alter system archive log current";

sql channel s1 "alter database recover managed standby database using current logfile disconnect";

}

이 스크립트는 스탠바이 데이터베이스를 생성하고, 적절한 파라미터를 스탠바이 데이터베이스를 위한 spfile에 배치하고, 스탠바이 데이터베이스를 위한 진단 데스티네이션을 생성하고, 스탠바이를 다시 시작합니다. 이 작업의 정확한 구조를 이해하려면, 여기서 RMAN 커맨드의 아웃풋을 볼 필요가 있습니다.

아래의 2 라인은 기본 및 스탠바이 인스턴스에 연결됩니다:

connect target sys/oracle123@prolin11;

connect auxiliary sys/oracle123@pro11sb;

패스워드 파일을 스탠바이 호스트에 복사했기 때문에, SYS 패스워드는 동일하게 남아 있으며 따라서 스탠바이 인스턴스에 연결은 (마운팅 데이터베이스가 없지만) 성공적입니다. 다음으로, 다음과 같은 라인들이 실행됩니다:

duplicate target database for standby from active database

spfile

parameter_value_convert 'prolin11','pro11sb'

set 'db_unique_name'='pro11sb'

set 'db_file_name_convert'='/prolin11/','/pro11sb/'

... and so on ...

duplicate target database 커맨드는 우선 원격 서버에 있는 SQL*Net를 통해 기본 데이터베이스의 이미지를 복사함으로써 기본 데이터베이스로부터 스탠바이를 생성합니다. 복사가 완료되면, 내부적으로 커맨드를 발령하여 (switch clone datafile all;), 스탠바이 데이터베이스를 클론으로 만듭니다. 스크립트의 세트 커맨드가 스탠바이 인스턴스를 위한 SPFILE의 파라미터를 설정하며, 이 데이터베이스가 스탠바이 데이터베이스가 됩니다. 다시 말하지만, RMAN 아웃풋은 배후 활동에 대한 모든 정보를 제공합니다.

물리적 스탠바이 데이터베이스를 구축하는 것이 매우 쉽다는 것을 알아 두십시오. 이는 스크립트를 실행하는 것만큼이나 간단합니다!

Active Data Guard

물리적 스탠바이 데이터베이스를 사용하여 Data Guard 환경을 구현할 때 오랫동안 장애로 남아 있던 것 중의 하나는 스탠바이 데이터베이스의 수동성이었습니다. Oracle Database 10g 및 그 이전에는, 물리적 스탠바이 데이터베이스를 복구 프로세스를 멈춘 후에만, 읽기 전용 (말하자면, 리포팅 부담을 줄이기 위해)으로 개방했습니다. 이들 제품에서, Data Guard가 DR 솔루션의 일부이었다면, 뒤처지는 것이 두려워 오랫동안 복구 프로세스를 멈출 수 없었을 것이며, 따라서 물리적 스탠바이 데이터베이스는 읽기 전용을 위한 것이 아니라면, 당연히 무용지물이었을 것입니다

Oracle Database 11g로, 이제 상황이 변했습니다: 물리적 스탠바이 데이터베이스를 읽기 전용 모드로 개방하고 복구 프로세스를 다시 시작할 수 있습니다. 이는 기본 데이터베이스를 지속적으로 사용하면서 리포팅을 위해 스탠바이를 사용할 수 있다는 것을 의미합니다. (이전 버전의 경우와 마찬가지로, 스탠바이에서 백업도 할 수 있습니다.) 이것이 어떻게 이루어지는지 살펴 보겠습니다.

우선, 스탠바이 복구 관리를 취소합니다:

SQL> alter database recover managed standby database cancel;

Database altered.

다음, 데이터베이스를 읽기 전용으로 개방합니다:

SQL> alter database open read only;

Database altered.

여기까지는, 프로세스가 11g 이전 버전과 동일합니다. 이제, 11g의 정점을 살펴 보도록 하겠습니다: 스탠바이 데이터베이스가 읽기 전용으로 개방되어 있는 동안, 복구 프로세스 관리를 다시 시작할 수 있습니다.

SQL> alter database recover managed standby database disconnect;

Database altered.

이제 스탠바이 데이터베이스는 복구 관리 모드로 배치되어, 개방되어 있는 동안, 로그 파일을 적용합니다. 어떻게 이를 확인할 수 있을까요? 간단합니다; 단지 기본 데이터베이스의 최장 시퀀스 번호를 스탠바이의 그 것과 비교하면 됩니다. 기본 데이터베이스에서, 로그 변환을 하여 최장 시퀀스 번호를 확인합니다:

SQL> alter system switch logfile;

System altered.

SQL> select max(Sequence#) from v$log;

MAX(SEQUENCE#)

--------------

로그 변환은 스탠바이가 읽기 전용 모드로 개방되어 있는 동안 진행됩니다. 스탠바이의 최장 시퀀스를 확인합니다:

SQL> select max(Sequence#) from v$log;

MAX(SEQUENCE#)

--------------

이것 역시 79로 기본과 같습니다. 이는 로그 애플리케이션이 여전히 작업 중이라는 것을 보여줍니다. 여기서 이는 단순히 로그가 적용되고 있다는 것만을 보여주는 것이 아니냐는 의문이 생길 수 있습니다. 기본에서 진행되는 변화가 이 모드에서 보일까요? 확인해 보겠습니다. 기본에서, 테이블을 생성합니다:

SQL> create table test2 (col1 number);

Table created.

...그리고 나서 몇 개의 로그 변환을 하고 이들 로그가 스탠바이에 적용될 때까지 기다립니다. 다음으로 스탠바이 데이터베이스를 확인합니다:

SQL> desc test2

Name Null? Type

----------------------------------------- -------- ---------------------------

COL1 NUMBER

Presto! 테이블이 스탠바이에 생성되고, 쿼리가 가능해졌습니다.

이 경우, 기본에서 생긴 변화를, 네트워크가 사용 가능하다면, 스탠바이에 즉각 나타나게 해주는 Real Time Apply를 사용할 수 있었다는 것을 기억하십니까? RTA는 ADG에 필수적인 것은 아니지만, 기본에 생긴 최근의 변화를 보고자 할 때, ADG가 보다 유용한 것이 되도록 해줍니다

보안과 관련해선, 걱정할 것이 없습니다. 데이터베이스는 읽기 전용 모드에 있기 때문에, 아무것도 여기에 쓸 수 없습니다. 만약 audit_trail 파라미터가 기본에서 DB로 설정되어 있다면 (Oracle Database 11g에서의 디폴트), 스탠바이에서도 동일하지만, 일기 전용이기 때문에, 감사 추적을 쓸 수는 없습니다

알림 로그에 나타난 라인을 보십시오:

AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access

아하! 감사 추적은 멈추지 않습니다; 오히려, 데이터베이스가 개방되었을 때, OS 파일로 자동 전환됩니다. 스탠바이 데이터베이스를 활성화하면, audit_trail은 DB로 자동 재설정됩니다.

스냅샷 스탠바이

일반적 시나리오를 생각해 보겠습니다: 새로운 애플리케이션을 데이터베이스에 배치 중이고, 데이터베이스 성능의 영향에 대해 알고 싶다고 합시다. Oracle Database 11g에는, SQL 구문을 캡처하고 이를 재생하는 완벽한 툴이 있지만 (Database Replay), 그 영향력을 직접 실행해 보고 확인해 볼 필요가 있습니다. 테스트 시스템을 캡처하더라도, 프로덕션 시스템에서 재생하는 것은 불가능합니다. 우선, 배치가 되지 않습니다, 또한, 배치된다고 하더라도, 애플리케이션으로 다른 테이블을 변경할 수 없습니다. 그러면 애플리케이션의 영향력을 확인하려면 어떻게 해야 할까요?

완벽한 답은 물리적 스탠바이 데이터베이스를 업데이트가 가능한 스냅샷 스탠바이 데이터베이스로 임시 변환할 수 있는 Oracle Database 11g입니다. 이 모드에서, 애플리케이션을 운영할 수 있고—많은 테이블 변경 가능—그 영향력을 평가할 수 있습니다. 영향력을 평가한 후, 데이터베이스를 정상적 복구가 진행되고 있는 스탠바이로 변환할 수 있습니다. 이는 정해진 지점으로 플래시백하여 모든 변화를 원상 복구하는 플래시백 데이터베이스 기능을 사용하여 데이터베이스 복구 지점을 생성함으로써 가능합니다. 이 작업이 어떻게 진행되는지 알아보겠습니다:

우선, 이미 진행되고 있는 경우가 아니라면, 스탠바이에서 복구를 시작합니다:

SQL> alter database recover managed standby database disconnect;

Database altered.

복구가 몇 개의 로그 파일을 선정할 때까지 기다립니다. 그리고 복구를 중단합니다.

SQL> alter database recover managed standby database cancel;

Database altered.

여기서, 스냅샷 스탠바이 데이터베이스를 생성할 수 있습니다. 이것은 플래시백 로깅을 가능하게 하기 때문에, 플래시 복구 영역을 구성하지 않으면, 다음과 같은 메시지를 받게 됩니다:

ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_01/12/2008

00:23:14'.

ORA-38786: Flash recovery area is not enabled.

이를 피하기 위해서는, 미리 플래시 복구 영역을 생성해야 합니다. 이미 그렇게 하지 않았다 하더라도, 걱정할 필요는 없습니다. 지금 생성하면 되기 때문입니다:

SQL> alter system set db_recovery_file_dest_size = 2G;

System altered.

SQL> alter system set db_recovery_file_dest= '/db_recov';

System altered.

이제 절차를 마쳤으므로, 다음과 같은 간단한 커맨드를 사용해 스탠바이 데이터베이스를 스냅샷 스탠바이로 변환할 수 있습니다:

SQL> alter database convert to snapshot standby;

Database altered.

이제 데이터베이스를 리사이클링합니다:

SQL> shutdown immediate

ORA-01507: database not mounted

...

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

이제 데이터베이스가 읽기/쓰기 작업을 위해 개방되었습니다:

SQL> select open_mode, database_role

2 from v$database;

OPEN_MODE DATABASE_ROLE

---------- ----------------

READ WRITE SNAPSHOT STANDBY

이제 데이터베이스를 변경할 수 있습니다. 여기가 Database Replay를 사용하여 캡처한 작업을 재생할 최적의 지점입니다. 이제 데이터베이스에서 시스템을 변경하고 변화의 영향력을 보기 위하여 몇 차례 재생할 수 있습니다. 이것은 프로덕션 데이터베이스의 복사본이므로, 재생은 해당 작업을 정확하게 재현합니다.

테스트가 완료되면, 스냅샷 스탠바이 데이터베이스를 정상적인 물리적 스탠바이 데이터베이스로 변환합니다. 다음과 같은 단계를 거칩니다:

SQL> connect / as sysdba

Connected.

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

...

Database mounted.

SQL> alter database convert to physical standby;

Database altered.

이제 끄고, 데이터베이스를 마운팅하고 복구 관리를 시작합니다.

SQL> shutdown

ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

...

Database mounted.

Start the managed recovery process:

SQL> alter database recover managed standby database disconnect;

이제 스탠바이 데이터베이스가 복구 관리 모드로 복귀했습니다. 당연히, 데이터베이스가 스냅샷 스탠바이 모드에 있으면, 기본의 아카이브 로그가 적용되지 않습니다. 이것은 지금 적용되며 작업 완료까지 몇 분 걸립니다.

스냅샷 스탠바이 데이터베이스는 스탠바이 데이터베이스를 사용하여 프로덕션 데이터베이스의 변화를 사전에 정확히 예상할 수 있습니다. 그러나 이게 전부가 아닙니다. 또 다른 장점이 있습니다. 기본에서 생긴 변화를, 네트워크가 사용 가능하다면, 스탠바이에 즉각 나타나게 해주는 Real Time Apply를 사용할 수 있었다는 것을 기억하십니까? 누군가 기본 데이터베이스에서 대규모 업데이트를 하거나 일부 코드를 변경하는 등 실수를 한다면 어떻게 될까요? 이전 버전에서, 이 같은 실수가 스탠바이로 확산되는 것을 방지하기 위하여, 신중하게 스탠바이 데이터베이스에서 딜레이를 사용합니다. 그러나 딜레이로 인해, 스탠바이가 올바로 작동하지 않거나 프로덕션의 활성 카피로 사용될 수 없을 수 있습니다.

더 이상은 필요 없습니다. 스탠바이 데이터베이스를 플래시백할 수 있기 때문에, 딜레이를 유지하고 있을 필요가 없습니다. 문제가 있다면, 언제든지 이전 상태로 플래시백할 수 있습니다.

물리적 스탠바이에서 논리적 스탠바이로의 변환

이제 물리적 스탠바이 데이터베이스를 논리적인 것으로 쉽게 변환할 수 있습니다. 다음 단계를 거칩니다:

스탠바이 데이터베이스는 어딘가로부터 데이터 딕셔너리 정보를 가져올 필요가 있습니다. 딕셔너리 정보는 기본의 재실행 스트림에 배치되어야 합니다. 따라서, 기본 데이터베이스에서, 다음과 같이 하여 딕셔너리를 위한 LogMiner 테이블을 만듭니다:

SQL> begin

2 dbms_logstdby.build;

3 end;

4 /

PL/SQL procedure successfully completed.

스탠바이에서, 복구 관리 프로세스를 멈춥니다

SQL> alter database recover managed standby database cancel;

Database altered.

이제, 스탠바이에 커맨드를 입력해 이를 논리적인 것으로 변환합니다:

SQL> alter database recover to logical standby pro11sb;

Database altered.

1 단계를 실행하지 않았다면, 위의 커맨드는 딕셔너리 정보가 없기 때문에, 멈춰 있을 것입니다. 이 경우 여기서 1 단계를 실행하면 됩니다. RTA를 실행했다면, 정보는 스탠바이 데이터베이스에 즉각 정보가 나타날 것입니다.

기본의 몇 가지 로그 변환을 통해 아카이브 로그를 생성해 스탠바이로 보내야 합니다:

SQL> alter system switch logfile;

System altered.

잠시 후, 스탠바이에서, 데이터베이스 변경 커맨드가 완료되는 것을 볼 수 있습니다. 이제 스탠바이가 논리적인 것으로 변했습니다. 알림 로그에서 다음과 같은 것이 나타납니다:

RFS[12]: Identified database type as 'logical standby'

Recycle the database:

SQL> shutdown

ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 1071333376 bytes

...

Database mounted.

SQL> alter database open resetlogs;

Database altered.

이제 논리적 스탠바이로 되었으므로, SQL Apply 프로세스를 시작해야 합니다

SQL> alter database start logical standby apply immediate;

SQL> alter database start logical standby apply immediate; 논리적 스탠바이 데이터베이스가 이제 완전 작동합니다! 일단 물리적 스탠바이를 논리적인 것으로 변환하면, 다음에서 설명할 특수 구문 ("keep identity")을 사용하지 않는 한 ,이를 다시 물리적인 것으로 변환할 수 없습니다.

롤링 업데이트

DBA의 업무에서 어려운 점은 업그레이드를 위해 꽤 오랜 시간 데이터베이스를 내려야 하는 정당성을 밝히는 것입니다. Oracle Database 11g에서는, 롤링 업데이트를 통해 어떠한 유형의 스탠바이 데이터베이스라도 가지고 있다면, 이 일은 매우 쉬어집니다:

스탠바이를 업그레이드합니다.

애플리케이션을 스탠바이로 옮깁니다.

기본을 업그레이드합니다.

애플리케이션을 다시 본래의 기본으로 옮깁니다.

이것이 논리적 스탠바이라면, 스탠바이가 단지 기본의 SQL을 적용하면 되기 때문에, 프로세스가 매우 간편합니다. SQL이 적용되면, 업그레이드는 해당 데이터베이스에서 쉽게 이루어집니다. 복구를 멈추고, 스탠바이를 업그레이드하고, 복구를 진행한 후, 스탠바이를 기본으로 변환할 수 있습니다. 나중에, 본래의 기본을 업그레이드 할 스탠바이로 만들 수 있습니다. 마지막으로, 역할을 바꿔, 본래의 기본을 새로운 기본으로 만들 수 있습니다.

그러나, 많은 스탠바이 데이터베이스는 사용 및 관리의 간편성을 위해 본질적으로 물리적입니다. 스탠바이가 논리적이 아니라 물리적이라면, 단계는 거의 흡사합니다. 스탠바이를 임시로 논리적으로 변환한 후 다시 물리적으로 변환하는 것입니다. 여기서 중요한 것은 영구적이 아니라 임시로라는 것입니다. 따라서, 다음과 같이 "keep identity"구문을 가진 변환 커맨드를 입력합니다:

SQL> alter database recover to logical standby keep identity;

Database altered.

보다 자세한 내용은 문서에서 확인할 수 있습니다.

기타 개선 사항

Data Guard 프로세스 자체에 몇 가지 중요한 개선 내용이 있습니다:

재실행 압축

Data Guard는 기본의 아카이브 로그를 스탠바이 데이터베이스 서버로 옮겨 이를 해당 데이터베이스에 적용한다는 전제를 가지고 있습니다. 기본과 스탠바이 사이의 시간 지체의 핵심 요소의 하나는 아카이브 로그를 옮기는 시간입니다. 이는 재실행 스트림을 압축하면 어느 정도 줄일 수 있습니다.

Oracle Database 11g에서는 TRUE로 설정된 파라미터 압축을 사용하여 SQL*Net를 통해 스탠바이 서버 전체를 경유하는 재실행 스트림을 압축할 수 있습니다. 이는 오로지 갭 해소 중에 옮겨지는 로그를 위한 것입니다. 이 문서의 앞부분에 제시된 사례에서 압축을 할 때 사용할 수 있는 커맨드는 다음과 같습니다.

alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC

valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable'

네트 타임 아웃

Data Guard 환경은 데이터베이스 인스턴스 연결을 통해 재실행 데이터를 스탠바이 서버로 보내 작동시킨다. 인스턴스가 시간 내 응답하지 않으면, 로그 전송 서비스는 지정된 타임 아웃 값을 기다린 후 중단합니다. 이 타임 아웃 값은 Oracle Database에 net_timeout이라는 파라미터를 사용해 설정할 수 있습니다. 최대 보호 모드에서, 로그 전송 서비스는 중단 전 20회의 재시도를 합니다.

그러나 우선 로그 전송에서 얼마만큼의 딜레이가 존재하는지 알아야 합니다. 새로운 뷰 v$redo_dest_resp_histogram에 막대 그래프 모양으로 시간이 나타납니다:

SQL> desc v$redo_dest_resp_histogram

Name Null? Type

---------------------- ------- --------------

DEST_ID NUMBER

TIME VARCHAR2(20)

DURATION NUMBER

FREQUENCY NUMBER

뷰는 해당 버킷에서 전송 시간 측정 결과를 보여줍니다. 작동 후 며칠 후 뷰를 조사해 보면, 타임 아웃에 설정에 대한 구상을 할 수 있을 것입니다. 다음과 같이 하여 타임 아웃 값을 설정할 수 있습니다:

alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC

valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable net_timeout=20'

다시 한 번 말하지만, 이는 앞에서 제시한 사례와 관련된 것입니다. 파라미터 값의 "net_timeout=20" 구문을 기억해 두십시오.

동적 변경 가능 파라미터

논리적 스탠바이 데이터베이스 환경 운영 프로세스에서, 프로세스를 튜닝하고 일부 파라미터 값을 조정할 필요가 있습니다. Oracle Database 11g에서, 이들 대부분의 파라미터는 온라인에서 업데이트할 수 있습니다. 뷰 dba_logstdby_parameters를 쿼리하면 이를 알 수 있습니다.

col name format a30

col value format a10

col unit format a10

col setting a6

col setting format a6

col dynamic format a7

select *

from dba_logstdby_parameters

order by name

NAME VALUE UNIT SETTIN DYNAMIC

------------------------------ ---------- ---------- ------ -------

APPLY_SERVERS 5 SYSTEM YES

EVENT_LOG_DEST DEST_EVENT SYSTEM YES

S_TABLE

LOG_AUTO_DELETE TRUE SYSTEM YES

LOG_AUTO_DEL_RETENTION_TARGET 1440 MINUTE SYSTEM YES

MAX_EVENTS_RECORDED 10000 SYSTEM YES

MAX_SERVERS 9 SYSTEM YES

MAX_SGA 30 MEGABYTE SYSTEM YES

PREPARE_SERVERS 1 SYSTEM YES

PRESERVE_COMMIT_ORDER TRUE SYSTEM NO

RECORD_APPLIED_DDL FALSE SYSTEM YES

RECORD_SKIP_DDL TRUE SYSTEM YES

RECORD_SKIP_ERRORS TRUE SYSTEM YES

RECORD_UNSUPPORTED_OPERATIONS FALSE SYSTEM YES

칼럼 DYNAMIC이 값을 동적으로 변경 가능한지를 보여 준다는 사실을 기억해 두십시오. 거의 모든 파라미터는 동적입니다. 예를 들어, 스탠바이를 멈추지 않고 파라미터 APPLY_SERVERS를 변경하려면, 다음과 같이 합니다.

SQL> begin

2 dbms_logstdby.apply_set('APPLY_SERVERS',2);

3 end;

4 /

이는 apply_servers 값을 2로 설정하는데, 이는 스탠바이를 멈추지 않고 할 수 있습니다.

SQL Apply 이벤트 테이블

Oracle Database 10g에서, SQL Apply와 관련된 이벤트는 알림 로그에 작성되는데, 알림 혹은 리포팅 확인을 위하여 스크립트를 작성하는 편이 좋기 때문에, 그다지 유용한 것이 못됩니다. Oracle Database 11g에서, 이벤트는 디폴트로 SYSTEM 스키마의 새로운 테이블 LOGSTDBY$EVENTS에 작성되도록 되어 있습니다. 다음은 샘플 쿼리입니다:

select event_time, error

from system.logstdby$events

order by 1;

The output:

EVENT_TIME ERROR

----------------------------- -------------------------------------------------

13-JAN-08 11.24.14.296807 PM ORA-16111: log mining and apply setting up

13-JAN-08 11.24.14.320487 PM Apply LWM 2677727, HWM 2677727, SCN 2677727

14-JAN-08 07.22.10.057673 PM APPLY_SET: APPLY_SERVERS changed to 2

14-JAN-08 07.22.11.034029 PM APPLY_SERVERS changed to 2

14-JAN-08 07.45.15.579761 PM APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

14-JAN-08 07.45.16.430027 PM EVENT_LOG_DEST changed to DEST_ALL

여러 가지 이유로, 이 이벤트를 테이블에 가지고 있는 것이 좋습니다. 예를 들면, 조작 및 리포팅이 간편해집니다. 그러나 때로는, 특히 오류 및 메시지 알림 로그를 스캐닝하기 위한 모니터링 툴을 구현했다면, 이를 알림 로그에서 보는 것도 괜찮습니다. 이는 논리적 스탠바이 데이터베이스 적용 파라미터 "event_log_dest"를 "DEST_ALL"로 설정하면 가능해집니다:

begin

dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');

end;

이는 동적으로 이루어지며, 이벤트는 테이블과 알림 로그 모두에 전달됩니다. 이 커맨드를 입력한 후, 알림 로그를 확인할 수 있습니다. 많은 SQL Apply 이벤트와 더불어 최소한 다음의 2 라인이 보일 것입니다:

LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL

결론

우선, 우리는 활성 기본 데이터베이스로부터 물리적 스탠바이 데이터베이스를 구현하는 것이 별 것 아니라는 것을 알게 되었습니다. 또한, 물리적 스탠바이를 논리적으로 변환하는 것이 매우 간단하다는 것도 알게 되었습니다. 이 사실로부터 누릴 수 있는 최대의 장점은 스탠바이 데이터베이스를 어떤 방식으로든 비즈니스 지원을 위해 사용할 수 있다는 것입니다. Active Data Guard 기능은 스탠바이 데이터베이스를 개방해 아카이브 로그가 적용되는 동안 쿼리를 허용합니다. 스냅샷 스탠바이 데이터베이스는 데이터베이스에서 프로덕션 데이터베이스 로딩을 허용한 후 정상적 복구 관리 프로세스를 다시 시작하도록 처음 시작했던 지점으로 플래시백합니다. 이들 2가지 기능은 스탠바이 서버의 프로세싱 기능을 활용할 수 있도록 허용하기 때문에 11g로의 업그레이드를 위한 강력한 촉매 역할을 할 것입니다.

[Oracle] 랜덤값 발생시키기

출처 : http://soff.tistory.com/2

> 100~999 사이의 난수

SELECT ROUND(DBMS_RANDOM.VALUE(100, 999),0) FROM DUAL;

ROUND 함수를 사용하지 않으면 소수점까지 표시되므로, 정수를 만들기 위해 ROUND 함수를 이용한다.

아래의 예제는 1~45까지의 숫자를 이용하여 로또번호를 생성하는 예제이다.

SELECT ROUND(DBMS_RANDOM.VALUE(1, 45),0) AS N1,

ROUND(DBMS_RANDOM.VALUE(1, 45),0) AS N2,

ROUND(DBMS_RANDOM.VALUE(1, 45),0) AS N3,

ROUND(DBMS_RANDOM.VALUE(1, 45),0) AS N4,

ROUND(DBMS_RANDOM.VALUE(1, 45),0) AS N5,

ROUND(DBMS_RANDOM.VALUE(1, 45),0) AS N6

FROM DUAL;

[Oracle] 문자열 함수

출처 : http://soff.tistory.com/3

ASCII ↔ CHAR

SQL: SELECT CHR(65) as "CHR", ASCII('A') as "ASCII" FROM DUAL;

Description: CHR 함수는 ASCII값 65에 해당하는 대문자 "A"를 반환하고,

ASCII 함수는 대문자 "A"에 대한 ASCII 값 65를 반환한다.

Result: CHR ASCII

--- -----

A 65

--------------------------------------------------------------------------------------

CONCAT

SQL: SELECT CONCAT('Good', ' morning') as "Strings" FROM DUAL;

Description: CONCAT 함수는 문자열을 서로 연결해주는 함수로써 "||" 와(과) 같다.

Result: Strings

------------

Good morning

--------------------------------------------------------------------------------------

SUBSTR

SQL: SELECT SUBSTR("Hello World!", 7, 6) as "EX" FROM DUAL;

Description: 이 함수는 source문자열의 지정한 시작점(start)으로부터 길이(length)만큼을 리턴한다.

SUBSTR(source, start, length);

Result: EX

------

World!

--------------------------------------------------------------------------------------

INITCAP

SQL: SELECT INITCAP("hello world!") as "EX" FROM DUAL;

Description: 문자열의 첫번째 단어를 대문자로 변환한다(한글은 당연히 사용안된다).

Result: EX

------------

Hello World!

--------------------------------------------------------------------------------------

UPPER / LOWER

SQL: SELECT UPPER('Hello World') as "EX1",

LOWER('Hello World') as "EX2"

FROM DUAL;

Description: UPPER: 대문자로 변환

LOWER: 소문자로 변환

Result: EX1 EX2

----------- -----------

HELLO WORLD hello world

--------------------------------------------------------------------------------------

LPAD / RPAD

SQL: SELECT LPAD('ABC', 5, '.') as "EX1",

RPAD('ABC', 5, '.') as "EX2"

FROM DUAL;

Description: 채우기를 할 ".(마침표)"가 위치하는 것을 보고 이해를 하자.

Result: EX1 EX2

----- -----

..ABC ABC..

--------------------------------------------------------------------------------------

LENGTH

SQL: SELECT LENGTH('ABCD') as "EX1",

LENGTH('한글') as "EX2",

LENGTHB('한글') as "EX3"

FROM DUAL;

Description: 문자열의 길이를 반환한다.

Result: EX1 EX2 EX3

--- --- ---

4 2 4

--------------------------------------------------------------------------------------

REPLACE

SQL: SELECT REPLACE('ABCD', 'B', 'x') as "EX1" FROM DUAL;

Description: source문자열의 old 문자를 new 문자로 대체한다.

REPLACE(source, old, new)

Result: EX1

----

AxCD

--------------------------------------------------------------------------------------

INSTR

SQL: SELECT INSTR('ABCD', 'C') as "EX1" FROM DUAL;

Description: source문자열로부터 target문자의 위치를 리턴한다.

INSTR(source, target)

Result: EX1

---

--------------------------------------------------------------------------------------

LTRIM / RTRIM / TRIM

SQL: SELECT LTRIM(' ABC') as "EX1",

RTRIM('ABC ') as "EX2",

TRIM(' AB C ') as "EX3"

FROM DUAL;

Description: LTRIM: 왼쪽 공백 제거

RTRIM: 오른쪽 공백 제거

TRIM: 좌우 공백 제거 (가운데 공백은 제거되지 않는다)

Result: EX1 EX2 EX3

--- --- ----

ABC ABC AB C

* 문자열 관련된 오라클 함수는 이정도만 알고 넘어가자!

[Oracle] 11g pivot, unpivot기능

출처 : http://soff.tistory.com/141

대박! 엑셀의 피벗테이블기능따윈이제 필요없다. 쿼리에서 바로 피벗!

[Oracle]11g ADR adrci

출처 : http://soff.tistory.com/142

2010년 9월 4일 토요일

[ORACLE]리스너 프로세스 2개 기동(Intermittent TNS listener hang, new child listener process forked.) [출처] 리스너 프로세스 2개 기동(Intermittent TNS listener hang, new child listener process forked.)

퍼온글입니다.

원문 : http://blog.naver.com/anova91/50013053785

Subject:	Intermittent TNS listener hang, new child listener process forked.
	Doc ID:	Note:340091.1	Type:	PROBLEM
	Last Revision Date:	11-JAN-2007	Status:	PUBLISHED

In this Document
Symptoms
Cause
Solution
References

Applies to:

Oracle Net Services - Version: 10.1.0.2.0 to 10.2.0.3.0
This problem can occur on any platform.
All new connections via TNS listener hang, no errors reported

Symptoms

Intermittently the TNS listener hangs and new connections to the database are not possible.

Listener process can also consume high amount of CPU

Child TNS listener process is seen when doing a ps on the listener process, eg.:

$ ps -ef | grep tnslsnr

ora10g  8909     1  0   Sep 15 ?       902:44  /u05/10GHOME/DBHOME/bin/tnslsnr sales -inherit
ora10g 22685  8909  0 14:19:23 ?        0:00 /u05/10GHOME/DBHOME/bin/tnslsnr sales –inherit

Killing the child process allows new connections to work until the problem reoccurs

Cause

This is a known problem addressed via non-published bug:4518443 (Abstract: Listener Gets Hung Up)

The issue is that the TNS listener can hang under load while spawning a process

Solution

Bug 4518443 is fixed in 10.2.0.3

- OR -

Apply Patch 4518443 for the problem (if a patch is available)

- OR -

As a workaround, the following parameter can be added to listener.ora

SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener_name>=OFF

Where <listener_name> should be replaced with the actual listener name configured in the LISTENER.ORA file.

For example, if the listener name is LISTENER (default), the parameter would be:

SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF

This will prevent the listener from registering against ONS (Oracle Notification Services), which is the area affected by bug:4518443. For more information on ONS, please refer to eg. the Oracle10g Release 2 documentation ("Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide").

Please note, adding SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener_name> to listener.ora file on RAC, will mean that FAN (fast application notification) will not be possible. See Note 220970.1 RAC: Frequently Asked Questions for further information on FAN

References

Keywords

'INTERMITTENTLY' 'RAC' 'NOTIFICATION~SERVICES' 'HIGH~CPU~USAGE' 'LISTENER~HANGS' 'HANGING' 'TNSLSNR'

Help us improve our service. Please email us your comments for this document. .

[출처] 리스너 프로세스 2개 기동(Intermittent TNS listener hang, new child listener process forked.)|작성자 오토맨

2010년 8월 10일 화요일

ORA-01555 snapshot too old

원문 : http://www.ezslookingaround.com/blog/tech/?no=950

-------------------------

안녕하세요...
rollback segment와 관련해서 질문이 한가지 있습니다.
현재 java source를 보면 대략 1000만건을 Select 하고서 조회한 데이타를 테이블에
insert를 합니다.
source를 잠시 보면

rs = stmt.executeQuery(" Select empno, ename, job from emp ");

pstmt = conn.prepareStatement(
" Insert Into Temp (empno, " +
"    ename, " +
"    Job) " +
" Values (?,?,?)");

while(rs.next()) {
pstmt.clearParameters();
pstmt.setString(1, rs.getString("empno"));
pstmt.setString(2, rs.getString("ename"));
pstmt.setString(3, rs.getString("Job"));

try {
pstmt.executeUpdate();
} catch (SQLException se) {
System.out.println( "Message(execute) : " + se.getMessage());
System.out.println( "sql state(execute) : " + se.getSQLState());
System.out.println( "error code(execute) : " + se.getErrorCode());
} catch (Exception e) {
System.out.println( "Insert Exception(execute) Error");
}
}

source는 대략 이러한 방식으로 되어있습니다.
그런데 이렇게 하다보니까 700만건도 못되어서 ORA-0155: snapshot too old" error가
발생하였습니다.

그래서 대량의 데이타를 처리할수 있는 rollback segment를 만들고 나서 다음과 같이
하였습니다.

위의 source에서 select를 하기 이전에 다음을 넣었습니다.

try {
pstmt2 = conn.prepareStatement(
" set transaction use rollback segment TEMPRBS " );

try {
pstmt2.executeUpdate();
} catch (SQLException se) {
System.out.println( "Message(RBS) : " + se.getMessage());
System.out.println( "sql state(RBS) : " + se.getSQLState());
System.out.println( "error code(RBS) : " + se.getErrorCode());
} catch (Exception e) {
System.out.println( "Insert Exception(RBS) Error");
}
} catch (SQLException se) {
System.out.println( "Message(insert : RBS) : " + se.getMessage());
System.out.println( "sql state(insert : RBS) : " + se.getSQLState());
System.out.println( "error code(insert : RBS) : " + se.getErrorCode());
} catch (Exception e) {
System.out.println( "Insert Exception(RBS) Error");
}

그런데 이렇게 하여도 ROLLBACK SEGMENT ERROR가 발생을 하는데 잘못된 부분이 어디 있는지
알고 싶습니다.

감사합니다...

제목 : Re: 2가지 방법...
글쓴이: 손님(guest) 2003/12/09 13:03:17 조회수:375 줄수:16
이게 가능할지는 잘 모르겠네요...

일단 첫번째 방법으로 속도가 조금 떨어질 가능성은 있습니다만...
select를 할 경우에, order by를 사용하지 못할 특별한 이유가 없으면...
order by를 사용해 보는 게 좋을 듯하구요...
이걸로도 해결이 안되면...

두번째 방법은...
이건 오라클 9i일 경우(8i의 경우도 같은지 잘 모르겠네요...)에는...
UNDO_RETENTION을 조금 크게 잡아보심이...
쿼리가 실행되는 데 걸리는 시간 이상의 충분한 시간을 잡아보면 해결이 될지도...

뭐, 확실한 건 아닙니다만...
나쁘지 않다면 한번정도 테스트해 보심이 좋을 듯하네요...

그럼...

제목 : Re: rollback Segment 관리
글쓴이: 손님(claystudio) 2003/12/10 19:18:38 조회수:413 줄수:11

insert 하다가 읽어 왔던 데이터가 바뀐것 같습니다.

"snapshot too old"오류를 자세히 찾아보시면 원인을 더 정확히 알 수 있을듯합니다...

ps. 데이터 양으로 봐서는 웹상에서 돌아가는 프로그램은 아니고 배치성 프로그램인듯 한데
쿼리를 바꿔보심이...
==> Insert into Temp(empno, ename, job)
   Select empno, ename, job from emp;

제목 : Re: OTN에서 퍼왔습니다.
글쓴이: 손님(guest) 2003/12/12 15:43:22 조회수:905 줄수:147
No. 20241

ORA-1555 (SNAPSHOT TOO OLD)의 일반적인 원인 및 조치사항
===========================================

PURPOSE
-------

ORA-1555 (snapshot too old)는 db 관리 업무에 익숙하지 않은 경우, rollback
관련된 오류 중 혼란을 일으키기 쉬운 오류이다.
이미 문서 <bulletin:11152>와 그외 자료가 이 오류를 설명하고 해결하기 위해
만들어져 있지만, ORA-1555 원인 파악을 위해 내용이 다소 길고 복잡하게
구성되어 있는 편이다.
여기에서는 발생 가능한 여러가지 원인 중 일반적인 원을을 위주로, 초보자도
쉽게 이해할 수 있도록 간단히 설명한다.

Explanation
-----------

일반적으로 ORA-1555에 혼란을 일으키는 원인은 한편으로는 오류 메시지 자체에
있다고 볼 수 있다.

ORA-1555: snapshot too old: rollback segment %s too small

이와 같은 오류에서 마치 ora-1555가 rollback segment에 write시 space가
부족해서 발생하는것으로 착각하는 사용자가 많다.

중요한 것은 ORA-1555는 rollback segment에 정보를 write시에 발생하는 것이
아니고 rollback segment로 부터 before image를 읽으려는 시점에서 발생한다는
것이다.

쉬운 예를 들어보자.

(1) 사원이 천명인 회사에서 select한 문장으로 그 전체 사원의 정보를 읽는데
10분이 걸린다고 가정한다.
(2) 100번 사원 정보를 읽는데, 아직 읽지 않은 700번 사원에 대해 다른 session에서
급여를 인상하는 update문장을 수행하고 commit을 한다.
select문장은 lock을 걸지 않기 때문에 select도중 다른 update문장이
수행되고 commit하는데 아무 문제가 없다.
(3) 1번에서 수행중인 select문장이 계속 진행되면서 700번 사원 정보를 읽으려고
하면 이 정보가 수정되어 변경되었음을 알게 된다.
그럼 select문장은 정보의 일관성을 위해 첫번째 사원을 읽기 시작한 시점의
700번 사원에 대한 정보를 읽기 위해, 즉 before image를 읽기 위해
rollback segment를 찾아간다.
(4) rollback segment내에 급여 인상 전 정보가 있으면 읽는다.
단 이때,
이 시스템에 트랜잭션이 매우 많아서 commit이 매우 많이 발생한 경우
이미 2번에서 변경하고 commit한 정보는 다른 트랜잭션에서 overwrite했을
수 있다.
이런 경우 before image를 읽으러 간 select문장은 ora-1555를 만나게 되는
것이다.
(5) 4번에서 ora-1555를 만난 경우 다시 동일한 select문장을 수행하면,
이번에는 이미 급여가 인상된 후의 시점에서 시작하므로 700번 사원을
읽는 경우에도 급여 인상전의 before image가 필요하지 않아 ora-1555는
다시 발생하지 않을 수 있다.
이러한 이유로 ora-1555는 발생했다 안했다 하는 식으로 일정하게 발생되지
않고, 조치 방법이라는것도 100% 안전하기보다는 확률적으로 충분히 만나지
않을 수 있는 환경을 만드는것이라고 볼 수 있다.

결국 ora-1555가 발생하는 것은 읽어야 하는 before image가 다른 트랜잭션에
의해 이미 overwrite되어 읽을 수 없는 경우 발생하므로, 발생하지 않게 하기
위해서는 데이타를 조회시 consistency를 유지해야 하는 시점동안 가능하면
오래 동안 rollback의 image가 유지되어야 하는것이다.

이렇게 이미 기록된 정보를 가능하면 오랜 기간동안 유지한다는 것은 새로운
트랜잭션의 기록을 위해 space를 확보해야 하는 작업과는 반대된다.
즉, ORA-1562와 같이 rollback segment를 write시에 space가 부족하여
space를 확보하기 위한 조치 방법과, 이 ORA-1555의 조치 방법을 서로 상충되어
trade-off가 있음을 주의해야 한다.

두 오류를 모두 피해가기 위해서는 일반적으로 매우 큰 rollback space가
도움이 된다.

ORA-1555의 일반적인 발생 경우 및 해결 방법을 정리한다.

(1) 트랜잭션에 비해 rollback segment 갯수가 적은 경우

rollback segment하나에 동시에 기록 가능한 트랜잭션의 수는 rollback
segment header내의 transaction table의 entry갯수로 제한되어 있다.
이 수는 oracle version마다 다르지만 8i이상부터는 약 20개 정도이다.
(transactions_per_rollback_segment의 지정과는 무관한다.)
기본적으로 install시 생성되는 rollback segment는 4개인데, 이대로 놓고
사용한다면, 결국 80 (20 * 4) 만큼의 commit이 발생하고 난 뒤에는
다시 처음부터 transaction table의 entry 중 commit된 트랜잭션의
정보를 가지는 entry의 정보를 overwrite하게 되는 것이다.

해결 방법: rollback segment갯수를 증가시킨다.
   즉 새로운 rollback segment를 create시킨다.

부작용: 제한된 rollback tablespace공간 내에서, 여러개의 rollback
segment를 유지하는것은 하나의 rollback segment가 평균 가질 수
있는 space가 그만큼 줄어드는 셈이다.
이 부작용까지 줄이려면, rollback tablespace자체가 충분히
커야 하고 space를 많이 요구하는 트랜잭션은 'set transaction
use rollback segment' 문장을 이용하여 큰 rollback을 지정하여
사용하도록 한다.

(2) rollback segment를 shrink하거나 optimal이 설정된 경우

rollback segment를 shrink하거나 optimal을 지정하게 되면 이미 쓰여진
rollback의 before image를 다른 트랜잭션이 overwrite도 하기 전에 미리
지워 버리게 되는 셈이다.
그러므로 이런 경우도 ora-1555의 원인이 된다.

해결 방법: optimal을 너무 적게 지정하지 말고, shrink를 너무 자주
   하지 않는다. shrink를 수행 후 ora-1555가 발생하는 경우,
   단지 다시 조회하는것만으로 앞의 예제 (5)번에서 설명한
   이유로 인해, 해결되는 경우가 많다.

(3) proc와 같은 application에서 loop내의 fetch문장에서 자주 commit을
하는 경우

fetch문장은 loop를 도는 동안 일정하게 read consistency를 유지해야 한다.
그리고 미리 cursor를 정의시에 데이타를 읽어두는것이 아니고, fetch시에
loop를 돌면서 그때그때 데이타를 읽게 된다.
그런데 loop내의 dml에 대해 너무 자주 commit을 하게 되면 그만큼
여러개의 트랜잭션이 처리된 결과로 rollback segment의 transaction table이
빨리 사용되고 overwrite되게 된다.

해결 방법: loop내의 commit횟수를 줄인다. 예를 들어 loop를 돌때마다
   commit하게 하였다면 천번에 한번 혹은 만번 loop를 돈 후
   commit하는 식으로 늘려준다.

이 외에도 rollback tablespace자체의 space가 부족하여 transaction table의
entry들이 아직 overwrite되지도 않았는데, commit된 transaction이 사용한
rollback segment내의 space가 먼저 overwrite되는 경우도 있다.
그러나 일반적으로 rollback segment의 space를 너무 작게 유지하지는 않기
때문에 이렇게 space부족으로 ora-1555를 만나는 경우는 많지 않다.
이렇게 space가 절대적으로 부족한 경우는 rollback에 write하는 시점에서,
ora-1562가 먼저 발생하게 된다.

ora-1562에 대해서는 <bulletin:10823> "ORA-1562 분석 및 해결 방법
(ROLLBACK SEGMENT 크기 문제)"를 참조하고,
좀더 자세한 ora-1555의 개념에 대해서는 <bulletin:11152> "ORA-1555 원인
분석 및 조치 사항" 을 참조한다.

============================================================================

write할 rbs가 모자라서 그런 게 아니랍니다.
제 생각엔 루프안의 SQL에 대한 명시적인 트랜잭션 컨트롤 구문이 없는 것으로 보아
(commit or rollback) autocommit으로 그냥 사용중이신 것같은데요
autocommit을 꺼주시고 트랜잭션에 대한 매뉴얼한 컨트롤을 해주셔야할 듯합니다.
그냥... 명시적으로 commit과 rollback을 해주셔야할 듯하단 말입니다. ^^

직접적인 관련은 없는 듯하지만, rbs가 적다면 적절하게 늘려주시는 게 좋을 듯합니다.

2010년 8월 3일 화요일

[펌]crontab 사용법

http://blog.naver.com/sulucky5/70015357757

http://newposting.tistory.com/tag/crontab

2010년 8월 2일 월요일

[마우스] Logitech 로지텍 퍼포먼스 마우스 M950 충전케이블 녹아버림.ㅡㅡ;

ㅜㅜ 두달된 내 M950.

마우스는 만족하며 사용하고 있는중인데,

충전어댑터가 불량인듯.

어댑터케이스는 틀어지고, 케이블 연결부위는 녹아버렸다.ㅡㅡ;;

무려 14장짜리 비싼 마우스라 정품으로 샀더니, 그닥 A/S도 좋진 않다.

로지텍 홈페이지 http://www.logitech.com/ko-kr?geo=US 내의

고객지원 센터(00798-601-8207) 에는 전화해도 별쓸모 없고(컴스빌 전화번호 알려줌)

로지텍 A/S를 담당하는 컴스빌(http://logiclub.co.kr/, 031-998-7989) 이란 곳에 전화해봤더니

무상/유상 여부 판단을 위해 어댑터랑 케이블을 택배로 보내란다

15일 지났다고 택배비는 반반씩 부담해야 된단다

(내가 착불로 보내면, 내가 받을때 착불 / 내가 선불로 보내면 내가 받을때 선불 이런식

결국 5000원 배송비는 필요)

택배비 5000원에 왔다갔다 일주일넘게(판단하는데 얼마나 소요되는지도 모른단다)

귀찮고 짜증내느니 그냥 사는게 낫지(어댑터 5000원, 케이블 3000원, 택배비 2000원)

결국 http://logiclub.co.kr/ 여기서 소모품 주문 했다.ㅡㅡ;;

마우스 괜찮다고 선배님한테도 추천했는데..ㅡㅡ;; A/S는 그닥인듯.

무튼 어댑터 충전보다는 USB를 PC에 꽂아 충전하는게 더 안정적일듯.

2010년 6월 29일 화요일

[Wish List] 없어서 못파는 아이디어 상품들

http://blog.daum.net/ioigood/15865450

2010년 6월 21일 월요일

[Perl] Can't locate Net/Telnet.pm perl 스크립트 수행시 에러메세지

# ./test.sh

Can't locate Net/Telnet.pm in @INC (@INC contains: /opt/perl_32/lib/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/5.8.8 /opt/perl_32/lib/site_perl/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/site_perl/5.8.8 /opt/perl_32/lib/site_perl /opt/perl_32/lib/vendor_perl/5.8.8/IA64.ARCHREV_0-thread-multi /opt/perl_32/lib/vendor_perl/5.8.8 /opt/perl_32/lib/vendor_perl .) at -e line 2.
BEGIN failed--compilation aborted at -e line 2.

알고보니 Telnet.pm 라이브 러리가 없어서 나는에러

/opt/perl/lib/5.8.8/ 와 같은 perl library 디렉토리밑에

Net 디렉토리 밑에 카피해 주면 된다.(대소문자유의)

/opt/perl/lib/5.8.8/Net/Telnet.pm

2010년 6월 10일 목요일

나로호 관련 트윗글들..^^

‎	ziozzang‎: RT @namhoon: 나로호 잔해및 추진체는 군이나 정부가 찾지말고 쌍끌이 어민들에게 맡겨라. Twitter - 11분 전

‎	chalsahn‎: 아...통신(소통)의 중요성은 "나로호"도 새삼 알려주네요.....ㅠㅠ Twitter - 수 초 전

‎	sun4in‎: @buangun 설마... 나로호 페어링에 '1번'써있는건 아니겠죠? Twitter - 5분 전

‎	evolution911‎: 대박~RT @jilpung 나로호에 <1번>써서 보냈으면 임무 100퍼 완수할텐데... Twitter - 7분 전

‎	acidbanana‎: RT @LJAYOUNG: 나로야...사는게 녹록치 않다 그지. 나로호 이름을 바꿔야할듯 RT @leesongheeil: 이명박도 통신 두절이던데.... 나로호도 통신 두절. Twitter - 8분 전

‎	sun4in‎: @buangun 설마... 나로호 페어링에 '1번'써있는건 아니겠죠? Twitter - 5분 전

‎	Plan2F‎: 으음...멘션도 몇번 못 주고 받았는디... @ohaeng: 자동으로 언팔. 나로호도 우리가 싫었던 모양이죠 @Plan2F: 나로호 리플라이 안 오는건가요? 디엠도 안되고? #fb Twitter - 2분 전

나로호 발사시각이 5시 1분인 것은 이유가 있었네요^^

우주 물체와 충돌을 피하기 위함이었다는^^

2010년 5월 5일 수요일

[아이폰] 3.1.3 해킹!! spirit

http://souldrinker.tistory.com/283

2010년 5월 3일 월요일

[펌]deploy, build 정의

출처 : http://darkmirr.egloos.com/1365149

deploy 정의

- build : 소스를 실행가능한 모듈로 변환하는 것
- deploy : 빌드되어 실행가능한 결과물을 컨테이너에서 인식가능한 곳에 배치하는 것

build는 별로 어렵지 않지만 deploy는 곰곰이 생각할 것이 많다. 내용상으로는 install과 비슷하고,
번역용어가 distribution과도 헷갈린다.
실행가능한 모듈을 실행 가능한 곳에 위치시키고 설정하는 것. install 아닌가?
그러나 OS위에서 작동하는 소프트웨어에 대해서는 대개 install이라 하고,
WAS같은 컨테이너에서 작동하는 어플리케이션이나 재사용 레포지토리에 저장되는
서비스모듈에 대해서는 deploy라고 구별하는 것 같다

deploy 및 관련된 deployables, distribution의 개념에 대해 개인적으로 다시 정리해보았다.

* deployables(deployable application)
- 정의 : WAS같은 컨테이너 상에서 실행가능한 어플리케이션.
- 설명 : 자바 환경이라면 war,ear,jar 같은 것들을 말한다.
deployables는 소프트웨어 distribution의 한가지 형태라고 봐도 될듯하다.
근데 이걸 뭘로 번역할지는? 배포물? 배포가능 어플리케이션?

* deploy (deployment)
- 정의 : deployables를 실제 컨테이너에 배치(arrange? allocate?)하는 작업.
- 설명 : 간단히 말하면 어플리케이션을 WAS 상에 설치(install)하는 것이다.
deploy는 전개,배치,배포 등으로 다양하게 번역되며 보통 디플로이 또는 배포라고 부른다.

* distribution
- 정의: 누군가에게 전달(delivery)하기 위해 패키징된 소프트웨어. (또는 그것을 전달하는 행위)
- 설명 : 사전적으로는 분배,배분,배포의 의미를 가지며 보통 배포본, 배포판으로 번역한다.

2010년 4월 30일 금요일

[jsp] 팝업창 띄우기

출처 : http://www.okjsp.pe.kr/seq/45014

팝업창을 뜨게 하실려면 일단 javascript를 쓰셔야 겠네요~
<A href="javascript:window.open('admin.jsp')">관리자 창</A>
이렇게 하시면 창이 뜨겠죠...
그리고 admin.jsp 팝업 창에서

<script language="javascript">

</script>
<form name = "frm" action="admin_end.jsp">
관리자 번호 : <input type=text name = num>
<a href="javascript:sendit()">확인</a>
</form>

하시면 입력받은 값이 admin_end.jsp로 넘어가죠
admin_end.jsp에서는
String num = request.getParameter("num");
받으셔서 데이터베이스에서 비교하시고
하셔서 값이 있을때는 다음 페이지로(물론 값도 함께 넘겨 줘야죠~~) 없을때는
이전 페이지로 가면 되겠죠..
<%
String num = request.getParameter("num");
String query = "select num from admin where num = '"+num+"'";
rs = stmt.executeQuery(query);
if(rs.next()){
%>
<script language="javascript">

</script>
<%
}else{
%>
<script language="javascript">

</script>
<%
}
%>

[jsp] jsp에서 자기가 만든 class import 하기[펌]

출처 : http://romanticdm.egloos.com/2508766

jsp에서 자기가 만든 class import 하기

jsp에서는 여러가지 java package들을 import 할 수 있는데,
흔히 많이 쓰고 있는.
java.sql.* 이라던가, java.util.*... 등등은 아주 쉽게
jsp 페이지 최상단에

<%@ page import="java.sql.*" %>

위와 같이 입력함으로써 import 할 수 있다.

하지만 본인이 직접 만든 클래스를 import 하는 것은 생각보다 쉽지 않은데,
은근히 여러가지 문제들이 도사리고 있기 때문이다.

여기에.. 그 쉬우면서도 어려운 문제들을 정리함으로써 한방에 깔끔하고 쉽게 jsp 에서 class import 를 완수해보자!!

1. import 하고자 하는 class 파일은 반드시 package화 되어있어야 한다.
어떻게 하는가?.... 매우 쉽다. java 페이지 최상단에 패키지 선언만 해주면 된다. 요렇게!

package myPackage;

그리고 가볍게 compile 하여, class 파일을 생서하자!

2. import 하고자 하는 class 파일을 CLASSPATH에 위치시킨다. 이때, 기본적인 위치는.. 다음과 같다.
TOMCAT_HOME\WEB-INF\classes\myPackage\
여기에 본인이 작성한 MyClass.class 파일을 위치시킨다.

3. jsp 페이지에서 class 파일을 import 한다.
역시 jsp 페이지 최상단에 아래와 같은 내용을 추가한다.

<%@ page import="myPackage.MyClass" %>

이렇게 import 한 class 내의 메소드를 사용하기 위해서는,
java와 똑같다.
예를 들어, static method를 사용하기 위해서는
MyClass.myStaticMethod();
non-static method를 사용하기 위해서는
MyClass mc = new MyClass();
mc.myNonStaticMethod();

이렇게 하면 되는 것이다.

이렇게 해서 jsp 페이지 내에서 직접 만든 클래스 파일의 import 를 문제없이 성공시킬 수 있다.

그렇다면, 여기서 뽀나쓰!!!

조금 더 advantage하게..
본인이 직접 만든 class 내에서 어떤 파일을 읽는 작업을 한다고 해보자.

예를 들어, DB에서 무언가를 읽어오는 jsp 파일이라면,
최악의 경우는..

jsp 파일 내에 DB_IP, DB_NAME, USER_ID, USER_PASSWD 를 모두 지정하여 직접 connect 하는 경우이다.
이럴 경우, 서버를 옮길 때마다 존재하는 모든 jsp 파일의 DB 정보를 갱신해 주어야 하는 문제가 발생한다.

이보다 조금 나은 상황은 DBUtil.java 등의 파일을 만들어, 해당 java 파일 내에서, DB 정보를 입력해주어
jsp 파일 내에서는..
DBUtil.getConnection(); 을 하는 경우이다.
이 때에는.. 서버를 옮길 때마다 존재하는 모든 jsp 파일 내의 DB 정보를 갱신해야 하는 수고는 더는 대신,
이미 컴파일되어 버린 DBUtil.class 의 source 파일인 DBUtil.java 를 수정하여 다시 compile 해야 하는 수고를 거쳐야 한다.

그럼 가장 이상적인 방법은 무엇인가?
DBUtil.java 파일 내에는 어떤 DB 정보도 입력하지 말고,
DB_IP, USER_ID, USER_PASSWD 등의 정보를 담은 텍스트 파일을 DBUtil.java 에서 불러오는 것이다.

일반 java 프로그래밍을 할 때는.. 그냥 java(또는 class) 파일과 읽어서 사용하고자 하는 텍스트 파일을 같은 디렉토리에 넣고 사용하면 되지만, jsp 를 통한 웹프로그래밍을 할 때는 사정이 다르다.

tomcat은 class 파일은 CLASSPATH인... WEB-INF\classes 아래에서 읽어오지만, 해당 클래스 내에서 쓰거나 읽고자 하는 파일은 (상대 또는 절대 경로 없이 썼을 경우) TOMCAT_HOME에서 읽어오기 때문이다.
즉, 본인과 같은 경우에는.. 아래 주소가 되겠다.

C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0

본인의 경우를 정리해보면 다음과 같다.

1. jsp 파일은 tomcat의 webapps ROOT에.
ex) C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0\webapps\ROOT

2. import하고자 하는 class 파일은 CLASSPATH에,
ex) C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0\webapps\ROOT\WEB-INF\classes\myPackage

3. class 파일이 또 다른 파일을 읽을 때, 그 파일은 TOMCAT_HOME에,
C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0

본인 기록용이라.. 내용이 너무 두서없고, 깔끔하지도 못하다..ㅠ

언젠가 예쁘게 정리하리라..