Memecahkan masalah basis data untuk Amazon RDS Custom for Oracle - Layanan Basis Data Relasional Amazon
Melihat peristiwa RDS CustomBerlangganan acara RDS CustomMemecahkan masalah pembuatan CEVMemperbaiki konfigurasi yang tidak didukung di RDS Custom for OracleMemecahkan masalah pemutakhiran RDS Custom for OracleMemecahkan masalah promosi replika RDS Custom for Oracle

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah basis data untuk Amazon RDS Custom for Oracle

Model tanggung jawab bersama RDS Custom menyediakan akses tingkat shell OS dan akses administrator basis data. RDS Custom menjalankan sumber daya di akun Anda, tidak seperti Amazon RDS, yang menjalankan sumber daya di akun sistem. Bersama akses yang lebih besar datang tanggung jawab yang lebih besar. Pada bagian-bagian berikut, Anda dapat mempelajari cara memecahkan masalah pada instans basis data Amazon RDS Custom.

catatan

Bagian ini menjelaskan cara memecahkan masalah RDS Custom for Oracle. Lihat pemecahan masalah RDS Custom for SQL Server di Memecahkan masalah basis data untuk Amazon RDS Custom for SQL Server.

Melihat peristiwa RDS Custom

Prosedur untuk melihat peristiwa adalah sama untuk instans basis data RDS Custom dan Amazon RDS. Untuk informasi selengkapnya, lihat Melihat peristiwa Amazon RDS.

Untuk melihat pemberitahuan acara khusus RDS menggunakan AWS CLI, gunakan describe-events perintah. RDS Custom memperkenalkan beberapa peristiwa baru. Kategori-kategori peristiwa sama dengan untuk Amazon RDS. Lihat daftar peristiwa di Kategori acara Amazon RDS dan pesan acara Aurora.

Contoh berikut mengambil perincian peristiwa-peristiwa yang telah terjadi untuk instans basis data RDS Custom yang ditentukan.

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

Berlangganan acara RDS Custom

Prosedur untuk berlangganan peristiwa sama untuk instans basis data RDS Custom dan Amazon RDS. Untuk informasi selengkapnya, lihat Berlangganan pemberitahuan peristiwa Amazon RDS.

Untuk berlangganan notifikasi peristiwa RDS Custom dengan menggunakan CLI, gunakan perintah create-event-subscription. Sertakan parameter-parameter wajib berikut:

  • --subscription-name

  • --sns-topic-arn

Contoh berikut membuat pelangganan untuk peristiwa-peristiwa pencadangan dan pemulihan untuk sebuah instans basis data RDS Custom di akun AWS saat ini. Notifikasi dikirim ke topik Amazon Simple Notiļ¬cation Service (Amazon SNS), yang ditentukan oleh --sns-topic-arn.

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

Memecahkan masalah pembuatan versi mesin kustom untuk RDS Custom for Oracle

Jika pembuatan CEV gagal, RDS Custom menerbitkan RDS-EVENT-0198 dengan pesan Creation failed for custom engine version major-engine-version.cev_name dan menyertakan detail kegagalan itu. Misalnya, peristiwa mencetak file yang hilang.

Pembuatan CEV mungkin gagal karena masalah berikut:

  • Bucket Amazon S3 yang berisi file instalasi Anda tidak berada di AWS Wilayah yang sama dengan CEV Anda.

  • Saat Anda meminta pembuatan CEV Wilayah AWS untuk pertama kalinya, RDS Custom membuat bucket S3 untuk menyimpan sumber daya Kustom RDS (seperti artefak CEV, AWS CloudTrail log, dan log transaksi).

    Pembuatan CEV gagal jika RDS Custom tidak dapat membuat bucket S3. Entah pemanggil tidak memiliki izin-izin S3 seperti dijelaskan di Langkah 5: Berikan izin yang diperlukan ke pengguna atau peran IAM Anda, atau jumlah bucket S3 telah mencapai batas.

  • Pemanggil tidak memiliki izin-izin untuk mendapatkan file dari bucket S3 yang berisi file-file media instalasi. Izin-izin ini dijelaskan di Langkah 7: Tambahkan izin IAM yang diperlukan.

  • Kebijakan IAM Anda memiliki syarat aws:SourceIp. Pastikan untuk mengikuti rekomendasi di AWS Menolak akses ke AWS berdasarkan IP sumber dalam Panduan Pengguna AWS Identity and Access Management . Pastikan juga bahwa pemanggil memiliki izin S3 yang dijelaskan di Langkah 5: Berikan izin yang diperlukan ke pengguna atau peran IAM Anda.

  • File-file media instalasi yang tercantum dalam manifes CEV tidak ada di bucket S3 Anda.

  • Checksum SHA-256 file-file instalasi tidak dikenal bagi RDS Custom.

    Pastikan bahwa checksum SHA-256 file-file yang disediakan cocok dengan checksum SHA-256 di situs web Oracle. Jika checksum cocok, hubungi Dukungan AWS dan berikan nama CEV, nama file, dan checksum yang gagal.

  • Versi OPatch tidak kompatibel dengan file-file tambalan Anda. Anda mungkin mendapatkan pesan berikut: OPatch is lower than minimum required version. Check that the version meets the requirements for all patches, and try again. Untuk menerapkan tambalan Oracle, Anda harus menggunakan versi utilitas OPatch yang kompatibel. Anda dapat menemukan versi utilitas OPatch yang disyaratkan di file readme tambalan. Unduh utilitas OPatch terbaru dari My Oracle Support, dan coba buat CEV lagi.

  • Tambalan yang ditentukan dalam manifes CEV berurutan salah.

Anda dapat melihat peristiwa RDS baik di konsol RDS (di panel navigasi, pilih Acara) atau dengan menggunakan perintah. describe-events AWS CLI Durasi default adalah 60 menit. Jika tidak ada peristiwa yang ditampilkan, tentukan durasi yang lebih lama, seperti ditunjukkan pada contoh berikut.

aws rds describe-events --duration 360

Saat ini, MediaImport layanan yang mengimpor file dari Amazon S3 untuk membuat CEV tidak terintegrasi dengannya. AWS CloudTrail Oleh karena itu, jika Anda mengaktifkan pencatatan data untuk Amazon RDS CloudTrail, panggilan ke MediaImport layanan seperti CreateCustomDbEngineVersion peristiwa tidak dicatat.

Namun, Anda mungkin melihat panggilan dari gateway API yang mengakses bucket Amazon S3 Anda. Panggilan ini berasal dari MediaImport layanan untuk CreateCustomDbEngineVersion acara tersebut.

Memperbaiki konfigurasi yang tidak didukung di RDS Custom for Oracle

Dalam model tanggung jawab bersama, Anda bertanggung jawab untuk memperbaiki masalah konfigurasi yang menempatkan instans basis data RDS Custom for Oracle Anda ke dalam keadaan unsupported-configuration. Jika masalahnya ada pada AWS infrastruktur, Anda dapat menggunakan konsol atau AWS CLI untuk memperbaikinya. Jika masalahnya ada pada sistem operasi atau konfigurasi basis data, Anda dapat masuk ke host untuk memperbaikinya.

catatan

Bagian ini menjelaskan cara memperbaiki konfigurasi yang tidak didukung di RDS Custom for Oracle. Lihat informasi tentang RDS Custom for SQL Server di Memperbaiki konfigurasi yang tidak didukung di RDS Custom for SQL Server.

Pada tabel berikut, Anda dapat menemukan deskripsi notifikasi dan peristiwa yang dikirim oleh perimeter dukungan dan cara memperbaikinya. Semua notifikasi ini dan perimeter dukungan dapat berubah sewaktu-waktu. Lihat latar belakang perimeter dukungan di Perimeter dukungan RDS Custom. Lihat deskripsi peristiwa di Kategori acara Amazon RDS dan pesan acara Aurora.

ID peristiwa Konfigurasi Pesan peristiwa RDS Tindakan

SP-O0000

Konfigurasi manual yang tidak didukung

Status instans RDS Custom DB disetel ke [Konfigurasi tidak didukung] karena: alasan.

Untuk mengatasi masalah ini, buat AWS Support kasus.
AWS sumber daya (infrastruktur)

SP-O1001

Volume Amazon Elastic Block Store (Amazon EBS)

Volume EBS berikut ditambahkan ke instans EC2 ec2_id: volume_id. Untuk mengatasi masalah ini, lepaskan volume yang ditentukan dari instance.

RDS Custom membuat dua jenis volume EBS, selain volume root yang dibuat dari Amazon Machine Image (AMI), dan mengaitkannya dengan instans EC2:

  • Volume biner tempat biner perangkat lunak basis data berada

  • Volume data tempat file database berada

Saat Anda membuat instans DB, konfigurasi penyimpanan yang Anda tentukan mengonfigurasi volume data.

Perimeter dukungan memantau hal-hal berikut:

  • Volume EBS awal yang dibuat dengan instans DB masih terkait dengan instance.

  • Volume EBS awal masih memiliki konfigurasi yang sama dengan yang awalnya ditetapkan: jenis penyimpanan, ukuran, IOPS yang Tersedia, dan throughput penyimpanan.

  • Tidak ada volume EBS tambahan yang dilampirkan pada instans basis data.

Gunakan perintah CLI berikut untuk membandingkan jenis volume detail volume EBS dan detail instans RDS Custom for Oracle DB: 

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

SP-O1002

Volume Amazon Elastic Block Store (Amazon EBS)

Volume EBS volume_id telah terlepas dari instance EC2 [ec2_id]. Anda tidak dapat melepaskan volume asli dari instance ini. Untuk mengatasi masalah ini, pasang kembali volume_id ke ec2_id.

RDS Custom membuat dua jenis volume EBS, selain volume root yang dibuat dari Amazon Machine Image (AMI), dan mengaitkannya dengan instans EC2:

  • Volume biner tempat biner perangkat lunak basis data berada

  • Volume data tempat file database berada

Saat Anda membuat instans DB, konfigurasi penyimpanan yang Anda tentukan mengonfigurasi volume data.

Perimeter dukungan memantau hal-hal berikut:

  • Volume EBS awal yang dibuat dengan instans DB masih terkait dengan instance.

  • Volume EBS awal masih memiliki konfigurasi yang sama dengan yang awalnya ditetapkan: jenis penyimpanan, ukuran, IOPS yang Tersedia, dan throughput penyimpanan.

  • Tidak ada volume EBS tambahan yang dilampirkan pada instans basis data.

Gunakan perintah CLI berikut untuk membandingkan jenis volume detail volume EBS dan detail instans RDS Custom for Oracle DB: 

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

SP-O1003

Volume Amazon Elastic Block Store (Amazon EBS)

Volume volume EBS asli yang dilampirkan ke EC2 instance ec2_id telah dimodifikasi sebagai berikut: size [X] to [Y], type [N] to [M], atau IOPS [J] to [K]. Untuk mengatasi masalah, kembalikan modifikasi.

RDS Custom membuat dua jenis volume EBS, selain volume root yang dibuat dari Amazon Machine Image (AMI), dan mengaitkannya dengan instans EC2:

  • Volume biner tempat biner perangkat lunak basis data berada

  • Volume data tempat file database berada

Saat Anda membuat instans DB, konfigurasi penyimpanan yang Anda tentukan mengonfigurasi volume data.

Perimeter dukungan memantau hal-hal berikut:

  • Volume EBS awal yang dibuat dengan instans DB masih terkait dengan instance.

  • Volume EBS awal masih memiliki konfigurasi yang sama dengan yang awalnya ditetapkan: jenis penyimpanan, ukuran, IOPS yang Tersedia, dan throughput penyimpanan.

  • Tidak ada volume EBS tambahan yang dilampirkan pada instans basis data.

Gunakan perintah CLI berikut untuk membandingkan jenis volume detail volume EBS dan detail instans RDS Custom for Oracle DB: 

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

SP-O1004

Keadaan instans Amazon EC2

Pemulihan otomatis meninggalkan instans EC2 [ec2_id] dalam keadaan terganggu. Untuk mengatasi masalah ini, lihat Memecahkan masalah kegagalan pemulihan instans.

Untuk memeriksa status instans DB, gunakan konsol atau jalankan AWS CLI perintah berikut:

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

SP-O1005

Atribut-atribut instans Amazon EC2

Instance EC2 [ec2_id] dimodifikasi sebagai berikut: atribut [att1] berubah dari [val-old] menjadi [val-new], atribut [att2] diubah dari [val-old] menjadi [val-new]. Untuk mengatasi masalah ini, kembalikan ke nilai aslinya.

SP-O1006

Keadaan instans Amazon EC2

Instans EC2 [ec2_id] dihentikan atau tidak dapat ditemukan. Untuk mengatasi masalah ini, hapus instans RDS Custom DB.

Perimeter dukungan memantau notifikasi perubahan keadaan instans EC2. Instans EC2 harus selalu berjalan.

Untuk menghapus instans DB Anda

  1. Untuk memeriksa status instans DB, gunakan konsol atau jalankan AWS CLI perintah berikut: 

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

  2. Hapus RDS Custom Anda untuk instans Oracle DB.

SP-O1007

Keadaan instans Amazon EC2

Instans EC2 [ec2_id] dihentikan. Untuk mengatasi masalah ini, mulailah instance.

Perimeter dukungan memantau notifikasi perubahan keadaan instans EC2. Instans EC2 harus selalu berjalan.

Untuk memulai ulang instans DB Anda

  1. Untuk memeriksa status instans DB, gunakan konsol atau jalankan AWS CLI perintah berikut: 

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

  2. Mulai instans DB Anda.

  3. Tumpangkan ulang volume-volume biner dan data.
Sistem operasi

SP-O2001

Status agen RDS Custom

Agen Kustom RDS tidak berjalan pada instans EC2 [ec2_id]. Pastikan agen berjalan di [ec2_id].

Pada RDS Custom for Oracle, instans basis data berada di luar perimeter dukungan jika agen RDS Custom berhenti. Agen menerbitkan IamAlive metrik ke Amazon CloudWatch setiap 30 detik. Alarm terpicu jika metrik tidak diterbitkan selama 30 detik. Perimeter dukungan juga memantau status proses agen RDS Custom pada host setiap 30 menit.

Untuk memulai ulang agen Kustom RDS

  1. Masuk ke host Anda dan pastikan bahwa agen RDS Custom berjalan.

  2. Jalankan perintah berikut untuk menemukan status agen.

    service rdscustomagent status

  3. Gunakan perintah berikut untuk memulai agen.

    service rdscustomagent start

Saat agen Kustom RDS berjalan lagi, IamAlive metrik dipublikasikan ke Amazon CloudWatch, dan alarm beralih ke OK status. Peralihan ini memberi tahu perimeter dukungan bahwa agen sedang berjalan.

SP-O2002

AWS Systems Manager status agen (agen SSM)

Agen Systems Manager pada instans EC2 [ec2_id] tidak dapat dijangkau. Pastikan Anda telah mengonfigurasi izin jaringan, agen, dan IAM dengan benar.

Agen SSM harus selalu berjalan. Agen RDS Custom bertanggung jawab untuk memastikan bahwa agen Systems Manager berjalan. Jika Agen SSM dihentikan dan kemudian dimulai ulang, agen Kustom RDS menerbitkan metrik ke. CloudWatch Agen RDS Custom mengatur alarm set metrik agar terpicu ketika telah ada pemulaian ulang dalam setiap menit dari dari tiga menit ke belakang. Perimeter dukungan juga memantau status proses Agen SSM di host setiap 30 menit.

Lihat informasi yang lebih lengkap di Memecahkan masalah Agen SSM.

SP-O2003

AWS Systems Manager status agen (agen SSM)

Agen Systems Manager pada instans EC2 [ec2_id] crash beberapa kali. Untuk informasi selengkapnya, lihat dokumentasi pemecahan masalah Agen SSM.

Lihat informasi yang lebih lengkap di Memecahkan masalah Agen SSM.

SP-O2004

Zona waktu OS

Zona waktu pada instans EC2 [ec2_id] diubah. Untuk mengatasi masalah ini, kembalikan zona waktu ke pengaturan sebelumnya [] previous-time-zone. Kemudian gunakan grup opsi RDS untuk mengubah zona waktu.

Automasi RDS mendeteksi bahwa zona waktu pada host diubah tanpa menggunakan grup opsi. Perubahan tingkat host ini dapat menyebabkan kegagalan automasi RDS, sehingga instans EC2 ditempatkan dalam keadaan unsupported-configuration.

Untuk memperbaiki pengaturan zona waktu

  1. Masuk ke host EC2 Anda dan periksa zona waktu OS sebagai berikut:

    timedatectl

  2. Jeda otomatisasi RDS Custom. Untuk informasi selengkapnya, lihat Menjeda dan melanjutkan instans RDS Custom DB.

  3. Hentikan instans basis data.

  4. Kembalikan perubahan zona waktu pada sistem operasi.

  5. Mulai instans basis data.

  6. Lanjutkan automasi RDS Custom.

Instans basis data Anda menjadi tersedia dalam 30 menit. Untuk mencegah keluar dari perimeter di masa depan, ubah zona waktu Anda melalui grup opsi. Untuk informasi selengkapnya, lihat Zona waktu Oracle.

SP-O2005

Konfigurasi-konfigurasi sudo

Konfigurasi sudo pada instans EC2 [ec2_id] tidak memiliki izin yang diperlukan. Untuk mengatasi masalah ini, kembalikan perubahan terbaru ke konfigurasi sudo.

Perimeter dukungan memantau bahwa pengguna OS tertentu diizinkan untuk menjalankan perintah tertentu pada kotak. Perimeter memantau konfigurasi-konfigurasi sudo terhadap keadaan yang didukung.

Ketika konfigurasi-konfigurasi sudo tidak didukung, RDS Custom mencoba menindas agar kembali ke keadaan terdukung sebelumnya. Jika berhasil, notifikasi berikut dikirim:

RDS Custom berhasil menindas konfigurasi Anda.

Untuk menyelidiki perubahan pada konfigurasi sudo

  1. Masuk ke host Anda.

  2. Jalankan perintah berikut.

    visudo -c -f /etc/sudoers.d/individual_sudo_files

  3. Ubah sudo konfigurasi seperlunya.

Setelah perimeter dukungan menentukan bahwa sudo konfigurasi didukung, instans RDS Custom for Oracle DB Anda akan tersedia dalam waktu 30 menit.

SP-O2006

Aksesibilitas bucket S3

Otomatisasi khusus RDS tidak dapat mengunduh file dari bucket S3 pada instans EC2 [ec2_id]. Periksa konfigurasi jaringan Anda dan pastikan instance memungkinkan koneksi ke dan dari S3.
Basis Data

SP-O3001

Target kelambatan arsip basis data

Parameter ARCHIVE_LAG_TARGET pada instance EC2 [ec2_id] berada di luar rentang value_range yang direkomendasikan. Untuk mengatasi masalah, setel parameter ke nilai dalam value_range.

Perimeter dukungan memantau parameter ARCHIVE_LAG_TARGET database untuk memverifikasi bahwa waktu restorable terbaru dari instans DB berada dalam batas yang wajar.

Untuk mengubah target lag untuk log pengulangan yang diarsipkan

  1. Masuk ke host EC2 Anda

  2. Connect ke instans RDS Custom for Oracle DB

  3. Ubah ARCHIVE_LAG_TARGET parameter menjadi nilai dari 60-7200. Misalnya, gunakan pernyataan SQL berikut.

    ALTER SYSTEM SET ARCHIVE_LAG_TARGET=300 SCOPE=BOTH;

Instans basis data Anda menjadi tersedia dalam 30 menit.

SP-O3002

Peran Oracle Data Guard

Peran database [role_name] tidak didukung untuk Oracle Data Guard pada instans EC2 [ec2_id]. Untuk mengatasi masalah, setel parameter DATABASE_ROLE ke PRIMARY atau PHYSICAL STANDBY.

Perimeter dukungan memantau peran database saat ini setiap 15 detik dan mengirimkan CloudWatch pemberitahuan jika peran database telah berubah. Parameter DATABASE_ROLE Oracle Data Guard harus PRIMARY atau PHYSICAL STANDBY.

Untuk mengembalikan peran database Oracle Data Guard Anda ke nilai yang didukung

  1. Periksa peran Oracle Data Guard dengan menjalankan pernyataan berikut:

    SELECT DATABASE_ROLE FROM V$DATABASE;

  2. Jika instans DB Anda berdiri sendiri, gunakan salah satu pernyataan berikut untuk mengubahnya kembali ke PRIMARY peran:

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

    Jika instans DB Anda adalah replika, gunakan pernyataan berikut untuk mengubahnya kembali ke PHYSICAL STANDBY peran:

    ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Setelah perimeter dukungan menentukan bahwa peran basis data didukung, instans basis data RDS Custom for Oracle Anda akan tersedia dalam waktu 15 detik.

SP-O3003

Kondisi basis data

Proses SMON dari database Oracle berada dalam keadaan zombie. Untuk mengatasi masalah ini, pulihkan database secara manual pada instans EC2 [ec2_id], buka database, lalu segera buat cadangan. Untuk bantuan lebih lanjut, hubungi AWS Support.

Perimeter dukungan memantau keadaan instans basis data. Perimeter juga memantau jumlah pemulaian ulang yang terjadi selama jam dan hari sebelumnya. Anda diberi tahu saat instans berada dalam keadaan dengan instans masih ada, tetapi Anda tidak dapat berinteraksi dengannya.

Untuk membuat perimeter dukungan mengevaluasi status instans Anda

  1. Masuk ke host Anda dan tentukan status database.

    ps -eo pid,state,command | grep smon

  2. Jika perlu, restart instans DB Anda. Jika restart gagal, lanjutkan ke langkah berikutnya.

  3. Jika perlu, restart host EC2 Anda.

Setelah instans DB Anda restart, agen RDS Custom mendeteksi bahwa instans DB Anda tidak lagi dalam keadaan tidak responsif. Agen itu lalu memberi tahu perimeter dukungan untuk mengevaluasi ulang keadaan instans basis data Anda.

SP-O3004

Mode log basis data

Mode log database pada instans EC2 [ec2_id] diubah menjadi [value_b]. Untuk mengatasi masalah ini, setel mode log ke [value_a].
Untuk mengubah mode log instans DB Anda menjadi ARCHIVELOG

  1. Masuk ke host EC2 Anda.

  2. Connect ke database Anda dan jalankan pernyataan berikut:

    SELECT LOG_MODE FROM V$DATABASE;

    Atau Anda dapat menjalankan perintah ikuti di SQL* Plus:

    ARCHIVE LOG LIST

  3. Jalankan perintah SQL* Plus berikut untuk memulai shutdown yang konsisten.

    SHUTDOWN IMMEDIATE

Agen Kustom RDS secara otomatis me-restart instans DB Anda dan menyetel mode log ke. ARCHIVELOG Instans basis data Anda menjadi tersedia dalam 30 menit.

SP-O3005

Jalur rumah Oracle

Beranda Oracle pada instans EC2 [ec2_id] diubah menjadi new_path. Untuk mengatasi masalah ini, kembalikan pengaturan ke old_path.

SP-O3006

Nama unik database

Nama unik database pada instans EC2 [ec2_id] diubah menjadi new_value. Untuk mengatasi masalah ini, kembalikan nama ke old_value.
Untuk mengubah nama unik database untuk instans DB Anda

  1. Masuk ke host EC2 Anda.

  2. Connect ke database dan jalankan pernyataan berikut:

    SELECT DB_UNIQUE_NAME FROM V$DATABASE;

  3. Tentukan nama unik database asli menggunakan perintahALTER SYSTEM SET DB_UNIQUE_NAME.

  4. Jalankan pernyataan SQL berikut untuk memulai shutdown yang konsisten.

    SHUTDOWN IMMEDIATE;

Agen Kustom RDS secara otomatis me-restart instans DB Anda dan menyetel mode log ke. ARCHIVELOG Instans basis data Anda menjadi tersedia dalam 30 menit.

Memecahkan masalah pemutakhiran untuk RDS Custom for Oracle

Pemutakhiran instans RDS Custom for Oracle Anda mungkin gagal. Di bawah, Anda dapat menemukan teknik-teknik yang dapat Anda gunakan selama pemutakhiran basis data RDS Custom untuk instans basis data Oracle:

  • Periksa file log output pemutakhiran di direktori /tmp pada instans basis data Anda. Nama-nama log bergantung pada versi mesin basis data Anda. Misalnya, Anda mungkin melihat log yang berisi string catupgrd ataucatup.

  • Periksa file alert.log yang terletak di direktori /rdsdbdata/log/trace.

  • Jalankan perintah grep berikut di direktori root untuk melacak proses pemutakhiran OS. Perintah ini menunjukkan letak file log sedang ditulis dan menentukan keadaan proses pemutakhiran.

    ps -aux | grep upg

    Berikut menampilkan contoh output.

    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

  • Jalankan kueri SQL berikut untuk memeriksa keadaan komponen-komponen saat ini untuk menemukan versi basis data dan opsi-opsi yang diinstal pada instans basis data.

    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;

    Output-nya menyerupai berikut.

    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.

  • Jalankan kueri SQL berikut untuk memeriksa objek-objek yang tidak valid yang mungkin mengganggu proses pemutakhiran.

    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');

Memecahkan masalah promosi replika untuk RDS Custom for Oracle

Anda dapat mempromosikan replika Oracle terkelola di RDS Custom for Oracle menggunakan konsol, promote-read-replica AWS CLI perintah, atau API. PromoteReadReplica Jika Anda menghapus instans basis data utama Anda, dan semua replikanya berkondisi baik, RDS Custom for Oracle mempromosikan secara otomatis replika terkelola Anda ke instans mandiri. Jika replika telah menjeda automasi atau berada di luar perimeter dukungan, Anda harus memperbaiki replika sebelum RDS Custom dapat mempromosikannya secara otomatis. Untuk informasi selengkapnya, lihat Batasan promosi replika untuk RDS Custom for Oracle.

Alur kerja promosi replika mungkin macet dalam situasi berikut:

  • Instans basis data utama berada dalam keadaan STORAGE_FULL.

  • Basis data utama tidak dapat mengarsipkan semua log pengulangan online-nya.

  • Ada celah antara file log redo yang diarsipkan di replika Oracle Anda dan basis data utama.

Untuk menanggapi alur kerja yang macet

  1. Sinkronkan celah log redo pada instans basis data replika Oracle Anda.

  2. Paksa promosi replika baca ke log redo terbaru yang diterapkan. Jalankan perintah SQL*Plus berikut:

    ALTER DATABASE ACTIVATE STANDBY DATABASE;
SHUTDOWN IMMEDIATE
STARTUP

  3. Hubungi AWS Support dan minta mereka untuk memindahkan instans DB Anda ke available status.