Amazon RDS Custom for Oracle의 DB 문제 해결 - Amazon Relational Database Service

Amazon RDS Custom for Oracle의 DB 문제 해결

RDS Custom의 공동 책임 모델은 OS 셸 수준 액세스 권한과 데이터베이스 관리자 액세스 권한을 제공합니다. RDS Custom은 시스템 계정에서 리소스를 실행하는 Amazon RDS와 달리 계정에서 리소스를 실행합니다. 접근 권한이 높을수록 책임도 커집니다. Amazon RDS Custom DB 인스턴스의 문제를 해결하는 방법을 알아볼 수 있습니다.

참고

이 섹션에서는 RDS Custom for Oracle 관련 문제를 해결하는 방법을 설명합니다. RDS Custom for SQL Server의 문제 해결 방법을 알아보려면 Amazon RDS Custom for SQL Server의 DB 문제 해결 섹션을 참조하세요.

RDS Custom 이벤트 보기

RDS Custom 및 Amazon RDS DB 인스턴스의 이벤트 보기 절차는 동일합니다. 자세한 내용은 Amazon RDS 이벤트 보기 섹션을 참조하세요.

describe-events 명령을 사용하여 AWS CLI를 통해 RDS Custom 이벤트 알림을 볼 수 있습니다. RDS Custom에서는 몇 가지 새로운 이벤트가 도입되었습니다. 이벤트 카테고리는 Amazon RDS와 동일합니다. 이벤트 목록은 Amazon RDS 이벤트 범주 및 이벤트 메시지 섹션을 참조하세요.

다음 예제에서는 지정된 RDS Custom DB 인스턴스에 대해 발생한 이벤트의 세부 정보를 검색합니다.

aws rds describe-events \ --source-identifier my-custom-instance \ --source-type db-instance

RDS Custom 이벤트 구독

RDS Custom 및 Amazon RDS DB 인스턴스의 이벤트 구독 절차는 동일합니다. 자세한 내용은 Amazon RDS 이벤트 알림 구독 단원을 참조하십시오.

CLI를 사용하여 RDS Custom 이벤트 알림을 구독하려면 create-event-subscription 명령을 사용하면 되며, 다음 필수 파라미터를 포함합니다.

  • --subscription-name

  • --sns-topic-arn

다음 예제에서는 현재 AWS 계정에서 RDS Custom DB 인스턴스의 백업 및 복구 이벤트에 대한 구독을 생성합니다. 알림은 --sns-topic-arn에서 지정한 Amazon Simple Notification Service(Amazon SNS) 주제로 전송됩니다.

aws rds create-event-subscription \ --subscription-name my-instance-events \ --source-type db-instance \ --event-categories '["backup","recovery"]' \ --sns-topic-arn arn:aws:sns:us-east-1:123456789012:interesting-events

Oracle용 RDS Custom에 대한 사용자 지정 엔진 버전 생성 문제 해결

CEV 생성이 실패하면 RDS Custom에서 Creation failed for custom engine version major-engine-version.cev_name 메시지와 함께 RDS-EVENT-0198 오류가 발생하며, 실패 관련 세부 정보가 표시됩니다. 예를 들어, 이벤트는 누락된 파일을 인쇄합니다.

다음 문제로 인해 CEV 생성에 실패할 수 있습니다.

  • 설치 파일이 포함된 Amazon S3 버킷이 CEV와 동일한 AWS 리전에 있지 않습니다.

  • AWS 리전에서 CEV 생성을 처음으로 요청하면 RDS Custom이 CEV 아티팩트, AWS CloudTrail 로그 및 트랜잭션 로그와 같은 RDS Custom 리소스를 저장하기 위한 S3 버킷을 생성합니다.

    RDS Custom에서 S3 버킷을 생성할 수 없는 경우 CEV 생성에 실패합니다. 발신자에게 5단계: IAM 사용자 또는 역할에 필요한 권한 부여에 설명된 대로 S3 사용 권한이 없거나 S3 버킷 수가 한도에 도달한 것일 수 있습니다.

  • 발신자에게 설치 미디어 파일이 포함된 S3 버킷에서 파일을 가져올 수 있는 권한이 없습니다. 이러한 권한은 7단계: 필요한 IAM 권한 추가에 설명되어 있습니다.

  • IAM 정책에 aws:SourceIp 조건이 있습니다. AWS Identity and Access Management 사용 설명서소스 IP를 바탕으로 AWS에 대한 AWS 액세스 거부의 권장 사항을 따라야 합니다. 또한 5단계: IAM 사용자 또는 역할에 필요한 권한 부여에 설명된 S3 권한이 호출자에게 있는지 확인합니다.

  • CEV 매니페스트에 나열된 설치 미디어 파일이 S3 버킷에 없습니다.

  • RDS Custom에서 설치 파일의 SHA-256 체크섬을 알 수 없습니다.

    제공된 파일의 SHA-256 체크섬이 Oracle 웹 사이트의 SHA-256 체크섬과 일치하는지 확인해야 합니다. 체크섬이 일치하는 경우 AWS 지원팀에 문의하여 실패한 CEV 이름, 파일 이름 및 체크섬을 제공합니다.

  • OPatch 버전이 패치 파일과 호환되지 않습니다. 다음과 같은 메시지가 표시될 수 있습니다. OPatch is lower than minimum required version. Check that the version meets the requirements for all patches, and try again. Oracle 패치를 적용하려면 호환되는 버전의 OPatch 유틸리티를 사용해야 합니다. 패치의 추가 정보 파일에서 필요한 Opatch 유틸리티의 버전을 찾을 수 있습니다. My Oracle 지원에서 최신 OPatch 유틸리티를 다운로드하고 CEV를 다시 생성해 보세요.

  • CEV 매니페스트에 지정된 패치의 순서가 잘못되었습니다.

RDS 이벤트는 RDS 콘솔(탐색 창에서 이벤트(Events) 선택)에서 보거나 describe-events AWS CLI 명령을 사용하여 볼 수 있습니다. 기본 지속 시간은 60분입니다. 이벤트가 반환되지 않으면 다음 예제와 같이 기간이 더 길게 지정됩니다.

aws rds describe-events --duration 360

현재 Amazon S3에서 파일을 가져와 CEV를 생성하는 MediaImport 서비스가 AWS CloudTrail에 통합되어 있지 않습니다. 이로 인해 CloudTrail에서 Amazon RDS에 대한 데이터 로깅을 설정하면 CreateCustomDbEngineVersion 이벤트와 같이 MediaImport 서비스에 대한 호출이 로깅되지 않습니다.

단, Amazon S3 버킷에 액세스하는 API 게이트웨이에서의 호출은 확인할 수 있습니다. 이러한 호출은 CreateCustomDbEngineVersion 이벤트의 MediaImport 서비스에서 전송됩니다.

RDS Custom for Oracle에서 지원되지 않는 구성 문제 해결

공유 책임 모델에서는 RDS Custom for Oracle DB 인스턴스를 unsupported-configuration 상태로 전환시키는 구성 문제는 사용자가 해결해야 합니다. AWS 인프라와 관련된 문제인 경우 콘솔 또는 AWS CLI를 사용하여 해결할 수 있습니다. 운영 체제 또는 데이터베이스 구성에 문제가 있는 경우 호스트에 로그인하여 해결하면 됩니다.

참고

이 섹션에서는 RDS Custom for Oracle에서 지원되지 않는 구성 문제를 해결하는 방법을 알아봅니다. RDS Custom for SQL Server에 관한 자세한 내용은 RDS Custom for SQL Server에서 지원되지 않는 구성 문제 해결 섹션을 참조하세요.

다음 테이블에는 지원 경계에서 보내는 알림 이벤트와 이를 해결하는 방법에 대한 설명이 나와 있습니다. 이러한 알림과 지원 경계는 변경될 수 있습니다. 지원 경계의 배경은 RDS Custom 지원 범위 섹션을 참조하세요. 이벤트 설명은 Amazon RDS 이벤트 범주 및 이벤트 메시지 섹션을 참조하세요.

이벤트 ID 구성 RDS 이벤트 메시지 작업

SP-O0000

지원되지 않는 수동 구성

RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성]으로 설정된 이유는 다음과 같습니다. 이유.

이 문제를 해결하려면 AWS Support 사례를 생성하세요.

AWS 리소스(인프라)

SP-O1001

Amazon Elastic Block Store(Amazon EBS) 볼륨

volume_id EBS 볼륨이 EC2 인스턴스 ec2_id에 추가되었습니다. 이 문제를 해결하려면 인스턴스에서 지정된 볼륨을 분리하세요.

RDS Custom은 Amazon Machine Image(AMI)에서 생성된 루트 볼륨 외에 2가지 유형의 EBS 볼륨을 생성하여 EC2 인스턴스에 연결합니다.

  • 데이터베이스 소프트웨어 바이너리가 있는 바이너리 볼륨

  • 데이터베이스 파일이 있는 데이터 볼륨

DB 인스턴스를 생성할 때 지정한 스토리지 구성이 데이터 볼륨을 구성합니다.

지원 경계는 다음을 모니터링합니다.

  • DB 인스턴스와 함께 생성된 초기 EBS 볼륨은 여전히 인스턴스와 연결되어 있습니다.

  • 초기 EBS 볼륨에 스토리지 유형, 크기, 프로비저닝된 IOPS 및 스토리지 처리량 등 초기 설정과 동일한 구성이 그대로 적용되어 있습니다.

  • DB 인스턴스에 연결된 추가 EBS 볼륨이 없습니다.

EBS 볼륨 세부 정보와 RDS Custom for Oracle DB 인스턴스 세부 정보의 볼륨 유형을 비교하려면 다음 CLI 명령을 사용합니다.

aws rds describe-db-instances \ --db-instance-identifier db-instance-name | grep StorageType

SP-O1002

Amazon Elastic Block Store(Amazon EBS) 볼륨

EBS 볼륨 volume_id가 EC2 인스턴스 [ec2_id]에서 분리되었습니다. 이 인스턴스에서 원본 볼륨을 분리할 수 없습니다. 이 문제를 해결하려면 volume_idec2_id에 다시 연결하세요.

RDS Custom은 Amazon Machine Image(AMI)에서 생성된 루트 볼륨 외에 2가지 유형의 EBS 볼륨을 생성하여 EC2 인스턴스에 연결합니다.

  • 데이터베이스 소프트웨어 바이너리가 있는 바이너리 볼륨

  • 데이터베이스 파일이 있는 데이터 볼륨

DB 인스턴스를 생성할 때 지정한 스토리지 구성이 데이터 볼륨을 구성합니다.

지원 경계는 다음을 모니터링합니다.

  • DB 인스턴스와 함께 생성된 초기 EBS 볼륨은 여전히 인스턴스와 연결되어 있습니다.

  • 초기 EBS 볼륨에 스토리지 유형, 크기, 프로비저닝된 IOPS 및 스토리지 처리량 등 초기 설정과 동일한 구성이 그대로 적용되어 있습니다.

  • DB 인스턴스에 연결된 추가 EBS 볼륨이 없습니다.

EBS 볼륨 세부 정보와 RDS Custom for Oracle DB 인스턴스 세부 정보의 볼륨 유형을 비교하려면 다음 CLI 명령을 사용합니다.

aws rds describe-db-instances \ --db-instance-identifier db-instance-name | grep StorageType

SP-O1003

Amazon Elastic Block Store(Amazon EBS) 볼륨

EC2 인스턴스 ec2_id에 연결된 원래 EBS volume_id가 크기는 [X]에서 [Y]로, 유형은 [N]에서 [M]으로, 혹은 IOPS는 [J]에서 [K]로 수정되었습니다. 이 문제를 해결하려면 수정 내용을 되돌리세요.

RDS Custom은 Amazon Machine Image(AMI)에서 생성된 루트 볼륨 외에 2가지 유형의 EBS 볼륨을 생성하여 EC2 인스턴스에 연결합니다.

  • 데이터베이스 소프트웨어 바이너리가 있는 바이너리 볼륨

  • 데이터베이스 파일이 있는 데이터 볼륨

DB 인스턴스를 생성할 때 지정한 스토리지 구성이 데이터 볼륨을 구성합니다.

지원 경계는 다음을 모니터링합니다.

  • DB 인스턴스와 함께 생성된 초기 EBS 볼륨은 여전히 인스턴스와 연결되어 있습니다.

  • 초기 EBS 볼륨에 스토리지 유형, 크기, 프로비저닝된 IOPS 및 스토리지 처리량 등 초기 설정과 동일한 구성이 그대로 적용되어 있습니다.

  • DB 인스턴스에 연결된 추가 EBS 볼륨이 없습니다.

EBS 볼륨 세부 정보와 RDS Custom for Oracle DB 인스턴스 세부 정보의 볼륨 유형을 비교하려면 다음 CLI 명령을 사용합니다.

aws rds describe-db-instances \ --db-instance-identifier db-instance-name | grep StorageType

SP-O1004

Amazon EC2 인스턴스 상태

자동 복구로 인해 EC2 인스턴스 [ec2_id]가 손상된 상태가 되었습니다. 이 문제를 해결하려면 인스턴스 복구 실패 문제 해결을 참조하세요.

DB 인스턴스의 상태를 확인하려면 콘솔을 사용하거나 다음 AWS CLI 명령을 실행합니다.

aws rds describe-db-instances \ --db-instance-identifier db-instance-name |grep DBInstanceStatus

SP-O1005

Amazon EC2 인스턴스 속성

EC2 인스턴스 [ec2_id]가 [att1] 속성이 [val-old]에서 [val-new]로, [att2] 속성이 [val-old]에서 [val-new]로 수정되었습니다. 이 문제를 해결하려면 원래 값으로 되돌리세요.

SP-O1006

Amazon EC2 인스턴스 상태

EC2 인스턴스 [ec2_id]가 종료되었거나 찾을 수 없습니다. 이 문제를 해결하려면 RDS Custom DB 인스턴스를 삭제하세요.

지원 경계는 EC2 인스턴스 상태 변경 알림을 모니터링합니다. EC2 인스턴스는 항상 실행 중이어야 합니다.

DB 인스턴스를 삭제하려면
  1. DB 인스턴스의 상태를 확인하려면 콘솔을 사용하거나 다음 AWS CLI 명령을 실행합니다.

    aws rds describe-db-instances \ --db-instance-identifier db-instance-name |grep DBInstanceStatus
  2. RDS Custom for Oracle DB 인스턴스를 삭제합니다.

SP-O1007

Amazon EC2 인스턴스 상태

EC2 인스턴스 [ec2_id]가 중지되었습니다. 이 문제를 해결하려면 인스턴스를 시작하세요.

지원 경계는 EC2 인스턴스 상태 변경 알림을 모니터링합니다. EC2 인스턴스는 항상 실행 중이어야 합니다.

DB 인스턴스를 다시 시작하려면
  1. DB 인스턴스의 상태를 확인하려면 콘솔을 사용하거나 다음 AWS CLI 명령을 실행합니다.

    aws rds describe-db-instances \ --db-instance-identifier db-instance-name |grep DBInstanceStatus
  2. DB 인스턴스를 시작합니다.

  3. 바이너리 및 데이터 볼륨을 다시 탑재합니다.

운영 체제

SP-O2001

RDS Custom 에이전트 상태

RDS Custom 에이전트가 EC2 인스턴스 [ec2_id]에서 실행되지 않습니다. 에이전트가 [ec2_id]에서 실행되고 있는지 확인하세요.

RDS Custom for Oracle에서 DB 인스턴스는 RDS Custom 에이전트가 중지되면 지원 경계를 벗어나게 됩니다. 에이전트는 30초마다 IamAlive 지표를 Amazon CloudWatch에 게시합니다. 지표가 30초 동안 게시되지 않은 경우 경보가 트리거됩니다. 또한, 지원 경계는 호스트의 RDS Custom 에이전트 프로세스 상태를 30분마다 모니터링합니다.

RDS Custom 에이전트를 다시 시작하려면
  1. 호스트에 로그인하고 RDS Custom 에이전트가 실행 중인지 확인합니다.

  2. 다음 명령을 실행하여 에이전트 상태를 찾습니다.

    service rdscustomagent status
  3. 다음 명령을 사용하여 에이전트를 시작합니다.

    service rdscustomagent start

RDS Custom 에이전트가 다시 실행되면 IamAlive 지표가 Amazon CloudWatch에 게시되고 경보가 OK 상태로 전환됩니다. 이 스위치는 지원 경계에 에이전트가 실행 중임을 알립니다.

SP-O2002

AWS Systems Manager 에이전트(SSM 에이전트) 상태

EC2 인스턴스 [ec2_id]의 Systems Manager 에이전트에 연결할 수 없습니다. 네트워크, 에이전트 및 IAM 권한을 올바르게 구성했는지 확인하세요.

SSM 에이전트는 항상 실행 중이어야 합니다. RDS Custom 에이전트는 Systems Manager 에이전트가 실행 중인지 확인하는 역할을 합니다. SSM 에이전트가 종료되었다가 다시 시작된 경우 RDS Custom 에이전트는 CloudWatch에 지표를 게시합니다. RDS Custom 에이전트에는 이전 3분 동안 재시작된 경우 경보가 트리거되도록 설정된 지표 경보가 지정되어 있습니다. 또한 지원 경계는 호스트의 SSM 에이전트 프로세스 상태를 30분마다 모니터링합니다.

자세한 내용은 SSM Agent 문제 해결을 참조하세요.

SP-O2003

AWS Systems Manager 에이전트(SSM 에이전트) 상태

EC2 인스턴스 [ec2_id]의 Systems Manager 에이전트가 여러 번 충돌했습니다. 자세한 내용은 SSM 에이전트 문제 해결 문서를 참조하세요.

자세한 내용은 SSM Agent 문제 해결을 참조하세요.

SP-O2004

OS 시간대

EC2 인스턴스 [ec2_id]의 시간대가 변경되었습니다. 이 문제를 해결하려면 시간대를 이전 설정인 [previous-time-zone]으로 되돌리세요. 그런 다음 RDS 옵션 그룹을 사용하여 시간대를 변경합니다.

RDS 자동화가 옵션 그룹을 사용하지 않고 호스트의 시간대가 변경되었음을 감지했습니다. 이러한 호스트 수준 변경으로 인해 RDS 자동화가 실패하여 EC2 인스턴스가 unsupported-configuration 상태로 전환될 수 있습니다.

시간대 설정을 수정하려면
  1. EC2 호스트에 로그인하고 다음과 같이 OS 시간대를 확인합니다.

    timedatectl
  2. RDS Custom 자동화를 일시 중지합니다. 자세한 내용은 RDS Custom DB 인스턴스 일시 중지 및 재개 단원을 참조하십시오.

  3. DB 인스턴스를 중지합니다.

  4. 운영 체제의 시간대 변경을 되돌립니다.

  5. DB 인스턴스를 시작합니다.

  6. RDS Custom 자동화를 다시 시작합니다.

DB 인스턴스를 30분 안에 사용할 수 있게 됩니다. 나중에 범위를 벗어나지 않도록 하려면 옵션 그룹을 통해 시간대를 수정하세요. 자세한 내용은 Oracle 시간대 단원을 참조하십시오.

SP-O2005

sudo 구성

EC2 인스턴스 [ec2_id]의 sudo 구성에 필요한 권한이 없습니다. 이 문제를 해결하려면 sudo 구성의 최근 변경 사항을 되돌리세요.

지원 경계는 특정 OS 사용자가 상자에서 특정 명령을 실행할 수 있는지 모니터링합니다. 지원되는 상태를 기준으로 sudo 구성을 모니터링합니다.

sudo 구성이 지원되지 않으면 RDS Custom은 해당 구성을 지원되는 이전 상태로 다시 덮어쓰려고 시도합니다. 성공하면 다음 알림이 전송됩니다.

RDS Custom이 구성을 성공적으로 덮어썼습니다.

sudo 구성의 변경 사항을 조사하려면
  1. 호스트에 로그인합니다.

  2. 다음 명령을 실행합니다.

    visudo -c -f /etc/sudoers.d/individual_sudo_files
  3. 필요에 따라 sudo 구성을 수정합니다.

지원 경계에서 지원되는 sudo 구성이 확인되면 30분 이내에 RDS Custom for Oracle DB 인스턴스를 사용할 수 있습니다.

SP-O2006

S3 버킷 접근성

RDS Custom 자동화가 EC2 인스턴스 [ec2_id]의 S3 버킷에서 파일을 다운로드할 수 없습니다. 네트워킹 구성을 확인하고 인스턴스가 S3와의 연결을 허용하는지 확인하세요.

데이터베이스

SP-O3001

데이터베이스 보관 지연 대상

EC2 인스턴스 [ec2_id]의 ARCHIVE_LAG_TARGET 파라미터가 권장 범위 value_range를 벗어났습니다. 이 문제를 해결하려면 파라미터를 value_range 내의 값으로 설정하세요.

지원 경계는 ARCHIVE_LAG_TARGET 데이터베이스 파라미터를 모니터링하여 DB 인스턴스의 최신 복원 가능 시간이 적절한 범위 내에 있는지 확인합니다.

아카이브된 다시 실행 로그의 지연 대상을 변경하려면
  1. EC2 호스트에 로그인합니다.

  2. RDS Custom for Oracle DB 인스턴스에 연결합니다.

  3. ARCHIVE_LAG_TARGET 파라미터를 60~7,200 사이의 값으로 변경합니다. 예를 들어, 다음 SQL 문을 사용합니다.

    ALTER SYSTEM SET ARCHIVE_LAG_TARGET=300 SCOPE=BOTH;

DB 인스턴스를 30분 안에 사용할 수 있게 됩니다.

SP-O3002

Oracle Data Guard 역할

데이터베이스 역할 [role_name]이 EC2 인스턴스 [ec2_id]의 Oracle Data Guard에서 지원되지 않습니다. 이 문제를 해결하려면 DATABASE_ROLE 파라미터를 PRIMARY 또는 PHYSICAL STANDBY로 설정하세요.

지원 경계는 15초마다 현재 데이터베이스 역할을 모니터링하고 데이터베이스 역할이 변경된 경우 CloudWatch 알림을 보냅니다. Oracle Data Guard DATABASE_ROLE 파라미터는 PRIMARY 또는 PHYSICAL STANDBY여야 합니다.

Oracle Data Guard 데이터베이스 역할을 지원되는 값으로 복원하려면
  1. 아래의 문을 실행하여 Oracle Data Guard 역할을 확인합니다.

    SELECT DATABASE_ROLE FROM V$DATABASE;
  2. DB 인스턴스가 독립 실행형인 경우 다음 문 중 하나를 사용하여 인스턴스를 다시 PRIMARY 역할로 변경합니다.

    ALTER DATABASE COMMIT TO SWITCHOVER PRIMARY; ALTER DATABASE ACTIVATE STANDBY DATABASE;

    DB 인스턴스가 복제본인 경우 다음 문을 사용하여 해당 인스턴스를 PHYSICAL STANDBY 역할로 다시 변경합니다.

    ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

지원 경계에서 데이터베이스 역할이 지원됨이 확인되면 15초 이내에 RDS Custom for Oracle DB 인스턴스를 사용할 수 있게 됩니다.

SP-O3003

데이터베이스 상태

Oracle 데이터베이스의 SMON 프로세스가 좀비 상태입니다. 이 문제를 해결하려면 EC2 인스턴스 [ec2_id]에서 데이터베이스를 수동으로 복구하고 데이터베이스를 연 다음 즉시 백업하세요. 도움이 더 필요하면 AWS Support에 문의하세요.

지원 경계는 DB 인스턴스 상태를 모니터링하며, 1시간 전과 하루 동안의 재시작 횟수를 모니터링합니다. 인스턴스가 여전히 존재하더라도 인스턴스와 상호 작용할 수 없는 경우 알림이 표시됩니다.

지원 경계에서 인스턴스 상태를 평가하도록 하려면
  1. 호스트에 로그인하고 데이터베이스 상태를 파악합니다.

    ps -eo pid,state,command | grep smon
  2. 필요한 경우 DB 인스턴스를 다시 시작합니다. 다시 시작에 실패하는 경우 다음 단계를 진행합니다.

  3. 필요한 경우 EC2 호스트를 다시 시작합니다.

DB 인스턴스가 다시 시작된 후 RDS Custom 에이전트는 DB 인스턴스가 더 이상 응답하지 않는 상태가 아님을 감지합니다. 지원 경계에 DB 인스턴스 상태를 재평가하도록 알립니다.

SP-O3004

데이터베이스 로그 모드

EC2 인스턴스 [ec2_id]의 데이터베이스 로그 모드가 [value_b]로 변경되었습니다. 이 문제를 해결하려면 로그 모드를 [value_a]로 설정하세요.

DB 인스턴스 로그 모드를 ARCHIVELOG로 변경하려면
  1. EC2 호스트에 로그인합니다.

  2. 데이터베이스에 연결하고 다음 문을 실행합니다.

    SELECT LOG_MODE FROM V$DATABASE;

    또는 SQL*Plus에서 다음 명령을 실행할 수 있습니다.

    ARCHIVE LOG LIST
  3. 다음 SQL*Plus 명령을 실행하여 일관성 있게 종료가 시작되도록 설정합니다.

    SHUTDOWN IMMEDIATE

RDS Custom 에이전트가 DB 인스턴스를 자동으로 다시 시작하고 로그 모드를 ARCHIVELOG로 설정합니다. DB 인스턴스를 30분 안에 사용할 수 있게 됩니다.

SP-O3005

Oracle home path

EC2 인스턴스 [ec2_id]의 Oracle home이 new_path로 변경되었습니다. 이 문제를 해결하려면 설정을 old_path로 되돌리세요.

SP-O3006

데이터베이스 고유 이름

EC2 인스턴스 [ec2_id]의 데이터베이스 고유 이름이 new_value로 변경되었습니다. 이 문제를 해결하려면 이름을 old_value로 되돌리세요.

DB 인스턴스의 데이터베이스 고유 이름을 변경하려면
  1. EC2 호스트에 로그인합니다.

  2. 데이터베이스에 연결하고 다음 문을 실행합니다.

    SELECT DB_UNIQUE_NAME FROM V$DATABASE;
  3. ALTER SYSTEM SET DB_UNIQUE_NAME 명령을 사용하여 원래 데이터베이스 고유 이름을 지정합니다.

  4. 다음 SQL 문을 실행하여 일관성 있게 종료가 시작되도록 설정합니다.

    SHUTDOWN IMMEDIATE;

RDS Custom 에이전트가 DB 인스턴스를 자동으로 다시 시작하고 로그 모드를 ARCHIVELOG로 설정합니다. DB 인스턴스를 30분 안에 사용할 수 있게 됩니다.

RDS Custom for Oracle 업그레이드 문제 해결

RDS Custom for Oracle 인스턴스 업그레이드에 실패할 수 있습니다. 아래에는 RDS Custom DB for Oracle DB 인스턴스를 업그레이드하는 중에 사용할 수 있는 몇 가지 중요한 기술, 파일 및 명령이 나와 있습니다.

  • DB 인스턴스의 /tmp 디렉터리에 있는 업그레이드 출력 로그 파일을 검토합니다. 로그 이름은 DB 엔진 버전에 따라 다릅니다. 예를 들어 catupgrd 또는 catup 문자열이 포함된 로그가 표시될 수 있습니다.

  • /rdsdbdata/log/trace 디렉터리에 있는 alert.log 파일을 검토합니다.

  • root 디렉터리에서 다음 grep 명령을 실행하여 업그레이드 OS 프로세스를 추적합니다. 이 명령은 로그 파일이 기록되는 위치를 표시하고 업그레이드 프로세스의 상태를 확인합니다.

    ps -aux | grep upg

    다음은 샘플 출력을 보여줍니다.

    root 18884 0.0 0.0 235428 8172 ? S< 17:03 0:00 /usr/bin/sudo -u rdsdb /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh rdsdb 18886 0.0 0.0 153968 12164 ? S< 17:03 0:00 /usr/bin/perl -T -w /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh rdsdb 18887 0.0 0.0 113196 3032 ? S< 17:03 0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh rdsdb 18900 0.0 0.0 113196 1812 ? S< 17:03 0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh rdsdb 18901 0.1 0.0 167652 20620 ? S< 17:03 0:07 /rdsdbbin/oracle/perl/bin/perl catctl.pl -n 4 -d /rdsdbbin/oracle/rdbms/admin -l /tmp catupgrd.sql root 29944 0.0 0.0 112724 2316 pts/0 S+ 18:43 0:00 grep --color=auto upg
  • 다음 SQL 쿼리를 실행하여 구성 요소의 현재 상태를 확인하고 데이터베이스 버전 및 DB 인스턴스에 설치된 옵션을 찾습니다.

    SET LINESIZE 180 COLUMN COMP_ID FORMAT A15 COLUMN COMP_NAME FORMAT A40 TRUNC COLUMN STATUS FORMAT A15 TRUNC SELECT COMP_ID, COMP_NAME, VERSION, STATUS FROM DBA_REGISTRY ORDER BY 1;

    다음과 유사하게 출력됩니다.

    COMP_NAME STATUS PROCEDURE ---------------------------------------- -------------------- -------------------------------------------------- Oracle Database Catalog Views VALID DBMS_REGISTRY_SYS.VALIDATE_CATALOG Oracle Database Packages and Types VALID DBMS_REGISTRY_SYS.VALIDATE_CATPROC Oracle Text VALID VALIDATE_CONTEXT Oracle XML Database VALID DBMS_REGXDB.VALIDATEXDB 4 rows selected.
  • 다음 SQL 쿼리를 실행하여 업그레이드 프로세스를 방해할 수 있는 유효하지 않은 객체가 있는지 확인합니다.

    SET PAGES 1000 LINES 2000 COL OBJECT FOR A40 SELECT SUBSTR(OWNER,1,12) OWNER, SUBSTR(OBJECT_NAME,1,30) OBJECT, SUBSTR(OBJECT_TYPE,1,30) TYPE, STATUS, CREATED FROM DBA_OBJECTS WHERE STATUS <>'VALID' AND OWNER IN ('SYS','SYSTEM','RDSADMIN','XDB');

RDS Custom for Oracle 복제본 승격 문제 해결

콘솔, promote-read-replica AWS CLI 명령 또는 PromoteReadReplica API를 사용하여 RDS Custom for Oracle의 관리형 Oracle 복제본을 승격할 수 있습니다. 기본 DB 인스턴스를 삭제하고 모든 복제본이 정상이면 RDS Custom for Oracle은 관리형 복제본을 독립 실행형 인스턴스로 자동 승격합니다. 복제본이 자동화를 일시 중지했거나 지원 경계 밖에 있는 경우 RDS Custom이 자동으로 승격할 수 있으려면 먼저 복제본을 수정해야 합니다. 자세한 내용은 RDS Custom for Oracle의 복제본 승격 제한 사항을 참조하세요.

다음 상황에서는 복제본 프로모션 워크플로가 중단될 수 있습니다.

  • 기본 DB 인스턴스가 STORAGE_FULL 상태입니다.

  • 기본 DB는 모든 온라인 다시 실행 로그를 아카이브할 수 없습니다.

  • Oracle 복제본에서 아카이브된 다시 실행 로그 파일과 기본 데이터베이스 간에 차이가 있습니다.

중단된 워크플로우에 응답하려면 다음 단계를 수행하세요.

  1. Oracle 복제본 DB 인스턴스의 다시 실행 로그 간격을 동기화합니다.

  2. 읽기 전용 복제본을 적용된 최신 다시 실행 로그로 강제 승격시킵니다. SQL*Plus에서 다음 명령을 실행합니다.

    ALTER DATABASE ACTIVATE STANDBY DATABASE; SHUTDOWN IMMEDIATE STARTUP
  3. AWS Support에 연락하여 DB 인스턴스를 사용 가능한 상태로 전환하도록 요청하세요.