알려진 문제

이 문서에서는 Base Database 서비스의 알려진 문제에 대한 정보를 제공합니다.

이러한 알려진 문제는 Base Database Service에서 식별됩니다.

관련 항목

새 데이터베이스에 기존 플러거블 데이터베이스

세부정보

기존 PDB(플러거블 데이터베이스)는 새로 생성된 데이터베이스에 나타나지 않으며, OCI 콘솔에 표시되기까지 최대 몇 시간이 걸릴 수 있습니다. 여기에는 새 데이터베이스에 대한 기본 PDB 및 복제되거나 복원된 데이터베이스에 대한 기존 PDB가 포함됩니다. 이전 버전에 대한 내부 복구의 경우 PDB 목록이 유사하게 업데이트되고 약간의 지연이 있을 수 있습니다.

임시해결책

없음

기존 Data Guard 구성의 PDB

세부정보

OCI 콘솔 또는 API를 통해는 기본 데이터베이스에서 PDB 생성 및 복제가 허용되지 않습니다.

임시해결책

SQL*Plus를 사용하여 기본 데이터베이스에서 PDB를 생성하거나 복제할 수 있으며, PDB는 나중에 OCI 콘솔에서 동기화됩니다.

라이센스 유형 변경 시 청구 이슈

세부정보

데이터베이스 또는 DB 시스템의 라이센스 유형을 BYOL에서 포함된 라이센스 또는 다른 방법으로 변경하는 경우 첫 1시간 동안 두 유형의 라이센스에 대해 비용이 청구됩니다. 이후에는 업데이트된 라이센스 유형에 따라 비용이 청구됩니다.

임시해결책

해결 방법을 위해 노력하고 있습니다.

인증서 변경으로 인해 dbcli를 사용하여 오브젝트 스토리지에 백업 실패

세부정보

데이터베이스 CLI(dbcli)를 사용한 오브젝트 스토리지로의 관리되지 않는 백업이 다음 오류와 함께 실패합니다.

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Symantec 인증서와 관련하여 두 개의 공통 웹 브라우저에서 구현한 정책에 대한 응답으로 Oracle은 최근 Oracle Cloud Infrastructure에 사용되는 인증 기관을 변경했습니다. SSL 인증서가 변경되면 Oracle Database Cloud Backup Module이 여전히 이전 인증서를 가리키는 경우 Object Storage에 대한 백업이 실패할 수 있습니다.

임시해결책

로그 파일에서 나열된 오류를 확인하고 발견된 경우 백업 모듈을 갱신합니다.

  1. RMAN 백업 로그 파일에서 위에 나열된 오류를 검토합니다.

    1. 다음 명령을 실행하여 실패한 백업 작업의 ID를 확인합니다.

      dbcli list-jobs

      이 출력 예에서 실패한 백업 작업 ID는 "f59d8470-6c37-49e4-a372-4788c984ea59"입니다.

      root@<node name> ~]# dbcli list-jobs
 
ID                                       Description                                                                     Created                             Status
---------------------------------------- ------------------------------------------------------------------------------- ----------------------------------- ----------
cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                         March 30, 2018 4:10:21 AM UTC       Success
db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                                   March 30, 2018 4:12:01 AM UTC       Success
c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                                 March 30, 2018 4:48:24 AM UTC       Success
22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                                  March 30, 2018 4:50:02 AM UTC       Success
6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                        March 30, 2018 5:33:38 AM UTC       Success
0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                    March 30, 2018 5:33:49 AM UTC       Success
e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                         March 30, 2018 5:34:04 AM UTC       Success
1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure

    2. 실패한 작업의 ID를 사용하여 검토할 로그 파일의 위치를 가져옵니다.

      dbcli describe-job -i <failed_job_ID>

      describe-job 명령의 관련 출력은 다음과 같아야 합니다. 

      Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

  2. Oracle Database Cloud Backup 모듈 업데이트:

    1. 데이터베이스가 백업에 사용 중인 Swift 객체 저장소 ID 및 사용자를 확인합니다.

      1. dbcli list-databases 명령을 실행하여 데이터베이스의 ID를 확인합니다.

      2. 데이터베이스 ID를 사용하여 백업 구성 ID(backupConfigId)를 확인합니다. 

        dbcli list-databases
dbcli describe-database -i <database_ID> -j

      3. 이전 단계에서 기록한 백업 구성 ID를 사용하여 객체 저장소 ID(objectStoreId)를 확인합니다. 

        dbcli list-backupconfigs
dbcli describe-backupconfig –i <backupconfig_ID> -j

      4. 이전 단계에서 기록한 객체 저장소 ID를 사용하여 객체 저장소 사용자(userName)를 확인합니다. 

        dbcli list-objectstoreswifts
dbcli describe-objectstoreswift –i <objectstore_ID> -j

    2. 1단계에서 얻은 객체 저장소 인증서를 사용하여 백업 모듈을 갱신합니다.

      dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>

인증서 변경으로 인해 RMAN를 사용하여 오브젝트 스토리지에 백업 실패

세부정보

RMAN를 사용한 Object Storage로의 관리되지 않는 백업이 다음 오류와 함께 실패합니다.

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Symantec 인증서와 관련하여 두 개의 공통 웹 브라우저에서 구현한 정책에 대한 응답으로 Oracle은 최근 Oracle Cloud Infrastructure에 사용되는 인증 기관을 변경했습니다. SSL 인증서가 변경되면 Oracle Database Cloud Backup Module이 여전히 이전 인증서를 가리키는 경우 Object Storage에 대한 백업이 실패할 수 있습니다.

임시해결책

RMAN 로그 파일에서 나열된 오류 메시지를 확인합니다. 찾은 경우 oracle 유저로 호스트에 로그온하고 Swift 인증서를 사용하여 백업 모듈을 다시 설치합니다.

주:

Swift 암호는 이제 "Auth 토큰"이라고합니다. 자세한 내용은 Managing User Credentials를 참조하십시오. 
java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

다중 노드 DB 시스템의 경우 클러스터의 모든 노드에서 임시해결책을 수행합니다.

Oracle Database Cloud Backup 모듈에 대한 자세한 내용은 Oracle Database Backup Cloud Service 사용을 참조하십시오.

데이터베이스 서비스 SDK의 변경 중단

세부정보

2018년 10월 18일에 출시된 SDK에는 데이터베이스 백업 API에서 데이터베이스 크기 및 데이터베이스 에디션 속성에 대한 코드 구분 변경 사항이 도입되었습니다.

임시해결책

변경 위반에 대한 자세한 내용은 언어별 설명서를 참조하고 적용 가능한 경우 기존 코드를 업데이트하십시오.

DB 시스템에서 관리 백업을 사용할 수 없습니다.

세부정보

OCI 콘솔 또는 API를 사용하는 경우 DB 시스템에서 백업 및 복원 작업이 작동하지 않을 수 있습니다.

임시해결책

Oracle Database Cloud Backup Module을 설치한 다음 추가 지침은 Oracle Support Services에 문의하십시오.

Oracle Database Cloud Backup 모듈을 설치하려면 다음 단계를 수행하십시오.

  1. DB 시스템에 SSH로 접속하고 opc로 로그인합니다. 

    ssh -i <SSH_key> opc@<DB_system_IP address>
login as: opc

    또는 opc@<DB_system_hostname>를 사용하여 로그인할 수 있습니다.

  2. Oracle Database Cloud Backup Module에서 Oracle Database Cloud Backup Module을 다운로드합니다.
  3. opc_installer.zip의 컨텐츠를 대상 디렉토리(예: /home/opc)로 추출합니다.
  4. 테넌시에서 임시 사용자를 생성하고 테넌시의 오브젝트 스토리지에 액세스할 수 있는 권한을 부여합니다.
  5. 이 임시 사용자의 경우 인증 토큰을 만들고 암호를 적어 둡니다. 인증 토큰 만들기에 대한 자세한 내용은 Managing User Credentials를 참조하십시오.

    주:

    Swift 암호는 이제 "Auth 토큰"이라고합니다.

  6. 다음 curl 명령을 실행하여 인증서가 작동하는지 확인합니다.

    curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

    올바른 영역을 확인하려면 오브젝트 스토리지 FAQ를 참조하십시오.

    이 명령은 HTTP 200 또는 HTTP 204 No Content 성공 상태 응답 코드를 반환해야 합니다. 다른 상태 코드는 오브젝트 스토리지에 연결하는 데 문제가 있음을 나타냅니다.

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

    java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt

    <target_dir>은 3단계에서 opc_installer.zip를 추출한 디렉토리입니다.

    이 명령은 libopc.so 및 기타 파일을 다운로드하므로 완료하는 데 몇 분 정도 걸릴 수 있습니다. 명령이 완료되면 대상 디렉토리에 여러 파일(libopc.so 포함)이 표시됩니다.

  8. 디렉토리를 대상 디렉토리로 변경하고 lipopc.so 및 opc_install.jar 파일을 /opt/oracle/oak/pkgrepos/oss/odbcs 디렉토리에 복사합니다. 

    cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs
    cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs

    (root로 실행하려면 복사 명령과 함께 sudo를 사용해야 할 수 있습니다.)

  9. 다음 명령을 실행하여 표시된 디렉토리가 존재하는지 확인합니다.

    ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

    이 디렉토리가 있는 경우 다음 단계를 수행합니다.

    1. /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs 디렉토리의 파일을 백업합니다.

    2. 다음 두 명령을 실행하여 해당 디렉토리의 기존 libopc.so 및 opc_install.jar 파일을 바꿉니다. 

      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs 
cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

  10. opc_install.jar의 버전을 확인합니다. 

    java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

    /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs가 있는 경우 다음 명령도 실행합니다. 

    java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

    두 명령은 다음 출력을 반환해야 합니다.

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.
  11. (선택 사항) 백업 모듈 설치에 사용한 임시 사용자 및 대상 디렉토리를 삭제합니다.

절차를 완료한 후 추가 지침은 Oracle Support 또는 테넌트 관리자에게 문의하십시오. 백업을 사용으로 설정할 DB 시스템의 OCID를 제공해야 합니다.

프로세스 충돌로 인해 VM.Standard1.1 구성에서 관리되는 자동 백업이 실패함

세부정보

VM.Standard1.1 구성을 실행하는 호스트 시스템의 메모리 제한으로 인해 Oracle Cloud Infrastructure에서 관리하는 자동 데이터베이스 백업 작업(OCI 콘솔 또는 API를 사용하여 관리되는 작업)이 실패할 수 있습니다. 시스템의 메모리 매개변수를 변경하여 이 문제를 해결할 수 있습니다.

임시해결책

다음과 같이 시스템의 메모리 매개변수를 변경합니다.

  1. 운영 체제에서 oracle 유저로 전환합니다.

    [opc@hostname ~]$ sudo su - oracle

  2. 환경 변수를 설정하여 데이터베이스 인스턴스에 로그인합니다. 예:

    oracle@hostname ~]$ . oraenv 
ORACLE_SID = [oracle] ? orcl

  3. SQL*Plus를 시작합니다.

    [oracle@hostname ~]$ sqlplus / as sysdba

  4. 초기 메모리 파라미터를 다음과 같이 변경합니다.

    SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile; 
SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M; 
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M; 
SQL> exit

  5. 데이터베이스 instance를 다시 시작합니다.

    [oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate 
[oracle@hostname ~]$ srvctl start database -d db_unique_name -o open

Oracle Data Pump 작업에서 "ORA-00439: 기능이 사용으로 설정되지 않음"을 반환합니다.

세부정보

고성능 및 초고성능 DB 시스템에서 압축 및/또는 병렬화를 사용하는 Data Pump 유틸리티 작업은 실패하고 ORA-00439: feature not enabled 오류를 반환할 수 있습니다. 이 문제는 데이터베이스 버전 12.1.0.2.161018 및 12.1.0.2.170117에 영향을 줍니다.

임시해결책

각각 데이터베이스 버전 12.1.0.2.161018 또는 12.1.0.2.170117에 대해 Oracle Database 홈에 패치 25579568 또는 25891266을 적용합니다. 또는 OCI 콘솔을 사용하여 2017년 4월 패치를 DB 시스템 및 데이터베이스 홈에 적용합니다.

주:

데이터베이스 홈의 데이터베이스 버전을 확인하려면 oracle 사용자로 $ORACLE_HOME/OPatch/opatch lspatches를 실행하거나 root 사용자로 dbcli list-dbhomes를 실행합니다.

1노드 DB 시스템에서 EM Express 콘솔에 접속할 수 없습니다.

세부정보

올바른 권한이 자동으로 적용되지 않았기 때문에 1노드 DB 시스템에서 EM Express 콘솔에 연결하려고 하면 "Secure Connection Failed" 오류 메시지가 표시될 수 있습니다.

임시해결책

DB 시스템의 전자 지갑 디렉토리에 asmadmin 그룹에 대한 읽기 권한을 추가한 다음 접속을 재시도하십시오. 읽기 권한을 추가하려면 다음 단계를 수행합니다.

  1. DB 시스템 호스트에 SSH로 접속하고 opc 및 sudo로 grid 사용자에게 로그인합니다. 

    [opc@dbsysHost ~]$ sudo su - grid
[grid@dbsysHost ~]$ . oraenv
ORACLE_SID = [+ASM1] ?
The Oracle base has been set to /u01/app/grid

  2. wallet 디렉토리의 위치를 가져옵니다. 다음 명령 출력에서 my_wallet_directory의 값입니다. 

    [grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW))

  3. opc 사용자로 돌아가서 oracle 사용자로 전환하고 wallet 디렉토리로 변경합니다. 

    [opc@dbsysHost ~]$ sudo su - oracle
[oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

  4. 디렉토리 내용을 나열하고 사용 권한을 기록합니다.

    [oracle@dbsysHost xdb_wallet]$ ls -ltr
total 8
-rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
-rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso

  5. 사용 권한을 변경합니다.

    [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

  6. 읽기 권한이 추가되었는지 확인합니다.

    [oracle@dbsysHost xdb_wallet]$ ls -ltr
total 8
-rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
-rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso

dbaascli를 사용할 때 Data Guard 사용 데이터베이스에 대한 OCI 콘솔 정보가 동기화되지 않음

세부정보

OCI 콘솔은 dbaasapi 및 dbaascli 유틸리티를 사용하여 생성 및 관리되는 데이터베이스에 대한 정보를 동기화하고 표시합니다. 그러나 Data Guard가 구성된 데이터베이스는 다음 조건에서 OCI 콘솔에 올바른 정보를 표시하지 않습니다.

  • OCI 콘솔을 사용하여 Data Guard가 사용으로 설정된 경우 dbaascli(예: 데이터베이스를 다른 홈으로 이동)을 사용하여 primary 또는 standby database가 변경되면 결과는 OCI 콘솔에 반영되지 않습니다.
  • Data Guard가 수동으로 구성된 경우 OCI 콘솔에는 두 데이터베이스 간의 Data Guard 연관이 표시되지 않습니다.

임시해결책

문제를 파악하여 해결을 위해 노력하고 있습니다 그 동안 Oracle은 OCI 콘솔 또는 명령행 유틸리티만 사용하여 Data Guard 사용 데이터베이스를 관리할 것을 권장합니다.

디스크 오프라인 전환 및 온라인 전환 후 Grid Infrastructure가 시작되지 않음

세부정보

이 문제는 Oracle Grid Infrastructure(GI) 버전이 번들 패치 없이 12.2.0.1인 경우에만 발생하는 클러스터웨어 문제입니다. 이 문제는 디스크를 오프라인으로 전환한 후 온라인 상태로 전환한 후 Voting Disk가 손상되어 발생합니다.

임시해결책

GI 버전 및 선호 디스크가 손상되었는지 확인합니다. 해당하는 경우 디스크를 복구한 다음 최신 GI 번들을 적용합니다.

다음 단계를 수행하십시오.

  1. 적용된 번들 패치 없이 GI 버전이 12.2.0.1인지 확인합니다.

    [root@rmstest-udaau1 ~]# su - grid
[grid@rmstest-udaau1 ~]$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base has been set to /u01/app/grid
[grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
Oracle Interim Patch Installer version 12.2.0.1.6
Copyright (c) 2018, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/12.2.0.1/grid
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/12.2.0.1/grid/oraInst.loc
OPatch version    : 12.2.0.1.6
OUI version       : 12.2.0.1.4
Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log

Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt

--------------------------------------------------------------------------------
Local Machine Information::
Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
ARU platform id: 226
ARU platform description:: Linux x86-64

Installed Top-level Products (1):

Oracle Grid Infrastructure 12c                                       12.2.0.1.0
There are 1 products installed in this Oracle Home.

There are no Interim patches installed in this Oracle Home.

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

OPatch succeeded.

  2. /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc 파일에서 선호 디스크 손상으로 인해 GI가 시작되지 않았는지 확인합니다. 

    ocssd.trc
 
2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured 
Sites = 1, Incative sites = 1, Mininum Sites required = 1 
2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: 
Aborting, 2 of 5 configured voting disks available, need 3 
...... 
. 
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure: 
skipping 31 defined 0 
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, 
slcc05db08 terminated. Removing from its own member and connected bitmaps 
2017-01-17 23:45:11.956 :    CSSD:3807860480: 
################################### 
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from 
thread clssnmvDiskPingMonitorThread 
2017-01-17 23:45:11.956 :    CSSD:3807860480: 
################################### 
2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A 
fatal error occurred and the CSS daemon is terminating abnormally 
 
------------
 
2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks 
queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 
cbd]), 
found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c 
bd]), is not corrupted 
2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation: 
Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted

  3. 또한 SQL*Plus를 사용하여 Voting Disk가 손상되었는지 확인할 수 있습니다.

    1. Grid 유저로 로그인하여 환경을 ASM으로 설정합니다.

      [root@rmstest-udaau1 ~]# su - grid
[grid@rmstest-udaau1 ~]$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base has been set to /u01/app/grid

    2. SQL*Plus에 SYSASM로 로그인합니다. 

      $ORACLE_HOME/bin/sqlplus / as sysasm

    3. 다음 두 개의 query를 실행합니다.

      SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

      시스템이 정상이면 결과는 다음 예와 같아야 합니다.

      Query 1 Results
NAME                           VOTING_FILE
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        Y
DBFSC3_CD_09_SLCLCX0787        Y
DBFSC3_CD_04_SLCLCX0786        Y

Query 2 Results
NAME                           COUNT(*)
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        8
DBFSC3_CD_09_SLCLCX0787        8
DBFSC3_CD_04_SLCLCX0786        8

      정상 시스템에서는 첫번째 query에서 반환된 모든 선호 디스크도 두번째 query에서 반환되어야 하고 모든 디스크의 개수는 0이 아니어야 합니다. 그렇지 않으면 하나 이상의 선호 디스크가 손상됩니다.

  4. 선호 디스크가 손상된 경우 선호 디스크를 포함하는 그리드 디스크를 오프라인으로 설정합니다. 셀은 자동으로 잘못된 선호 디스크를 다른 그리드 디스크 및 온라인 선호 디스크로 이동합니다.

    1. 다음 명령은 이름이 DATAC01_CD_05_SCAQAE08CELADM13인 그리드 디스크를 오프라인으로 만듭니다.

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
     Diskgroup altered.

    2. 30초 동안 기다린 다음 3c 단계에서 두 개의 query를 재실행하여 Voting Disk가 새 Grid 디스크로 이전되었으며 정상 상태인지 확인합니다.

    3. 오프라인으로 설정한 그리드 디스크가 온라인 상태인지 확인합니다.

      SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';

      mode_status는 ONLINE이어야 하고 voting_file는 Y가 아니어야 합니다.

    손상된 선호 디스크가 포함된 나머지 각 그리드 디스크에 대해 4a - 4c 단계를 반복합니다.

    주:

    Voting Disk 손상으로 인해 CRS가 시작되지 않는 경우 4단계의 명령을 실행하기 전에 배타적 모드를 사용하여 시작하십시오.

    crsctl start crs -excl

  5. 번들 패치 없이 Oracle GI 버전 12.2.0.1을 사용 중인 경우 선호 디스크가 손상되었는지 여부에 관계없이 GI 버전을 최신 GI 번들로 업그레이드해야 합니다.

DB 시스템 스토리지 스케일링 실패

세부정보

단일 작업에서 10,240GB 미만의 값에서 10,240GB 이상의 값으로 스케일을 조정하려고 하면 스케일링 작업이 실패할 수 있습니다.

임시해결책

일반 데이터 스토리지 또는 RECO(복구 영역) 스토리지를 10,240GB(10TB) 미만의 값에서 10,240GB를 초과하는 값으로 스케일링하는 경우 두 가지 작업에서 스케일링을 수행합니다. 먼저 시스템을 10,240GB로 확장합니다. 이 첫번째 크기 조정 작업이 완료되고 시스템이 "사용 가능" 상태가 되면 대상 스토리지 값을 10,240GB 이상으로 지정하여 두번째 크기 조정 작업을 수행합니다.

DB 시스템 구성 스케일링 실패

세부정보

더 큰 시스템 구성을 사용하도록 DB 시스템을 스케일링할 때 DB_Cache_nX 매개변수가 0으로 설정되지 않은 경우 스케일링 작업이 실패합니다.

임시해결책

DB 시스템을 스케일링할 때는 모든 DB_Cache_nX 매개변수(예: DB_nK_CACHE_SIZE)가 0(영)으로 설정되어 있는지 확인합니다.