ホームページ データベース mysql チュートリアル ORACLE 12C redo异常恢复测试—部分pdb未正常open

ORACLE 12C redo异常恢复测试—部分pdb未正常open

Jun 07, 2016 pm 04:36 PM
oracle redo 異常な 回復する テスト 一部

为了验证当前redo丢失的情况下ORACLE 12C CDB数据库恢复的情况,做了一个小实验,三个会话,分别操作为在root pdb中执行一个delete 不提交;另外一个会话在user pdb中delete记录不提交;最后一个会话中直接abort数据库,然后进行数据库恢复,验证数据库是否可

为了验证当前redo丢失的情况下ORACLE 12C CDB数据库恢复的情况,做了一个小实验,三个会话,分别操作为在root pdb中执行一个delete 不提交;另外一个会话在user pdb中delete记录不提交;最后一个会话中直接abort数据库,然后进行数据库恢复,验证数据库是否可以都正常open(所有pdb)
会话1(root pdb中操作)

CDB_CDB$ROOT@SYS> show pdbs;
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            READ WRITE NO
CDB_CDB$ROOT@SYS> show con_name
CON_NAME
------------------------------
CDB$ROOT
CDB_CDB$ROOT@SYS> create table t_xifenfei as select * from dba_objects;
表已创建。
CDB_CDB$ROOT@SYS> delete from t_xifenfei;
已删除 91032 行。
CDB_CDB$ROOT@SYS>
ログイン後にコピー

会话2(user pdb中操作)

CDB_CDB$ROOT@SYS> show con_name
CON_NAME
------------------------------
PDB
CDB_CDB$ROOT@SYS> drop table t_xifenfei purge;
表已删除。
CDB_CDB$ROOT@SYS> create table t_xifenfei as select * from dba_objects;
表已创建。
CDB_CDB$ROOT@SYS> delete from t_xifenfei;
已删除 91144 行。
ログイン後にコピー

会话3(直接abort数据库)

CDB_CDB$ROOT@SYS> shutdown abort;
ORACLE 例程已经关闭。
ログイン後にコピー

删除数据库联机日志

E:\app\XIFENFEI\oradata\cdb>dir redo*.log
 驱动器 E 中的卷是 本地磁盘
 卷的序列号是 000C-3B41
 E:\app\XIFENFEI\oradata\cdb 的目录
2013-08-07  01:41        52,429,312 REDO01.LOG
2013-08-07  01:40        52,429,312 REDO02.LOG
2013-08-07  01:40        52,429,312 REDO03.LOG
2014-03-20  22:47        52,432,896 REDO04.LOG
2014-03-20  22:47        52,432,896 REDO05.LOG
2014-03-20  22:47        52,432,896 REDO06.LOG
               6 个文件    314,586,624 字节
               0 个目录 21,359,374,336 可用字节
E:\app\XIFENFEI\oradata\cdb>del redo*.log
E:\app\XIFENFEI\oradata\cdb>dir redo*.log
 驱动器 E 中的卷是 本地磁盘
 卷的序列号是 000C-3B41
 E:\app\XIFENFEI\oradata\cdb 的目录
找不到文件
ログイン後にコピー

启动数据库报ORA-00313错误

idle> startup
ORACLE 例程已经启动。
Total System Global Area  521936896 bytes
Fixed Size                  2404552 bytes
Variable Size             205524792 bytes
Database Buffers          306184192 bytes
Redo Buffers                7823360 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 6 (用于线程 1) 的成员
ORA-00312: 联机日志 6 线程 1: 'E:\APP\XIFENFEI\ORADATA\CDB\REDO06.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ログイン後にコピー

使用_allow_resetlogs_corruption参数尝试open数据库

idle> shutdown abort
ORACLE 例程已经关闭。
idle> startup pfile='d:/pfile.txt' mount
ORACLE 例程已经启动。
Total System Global Area  521936896 bytes
Fixed Size                  2404552 bytes
Variable Size             205524792 bytes
Database Buffers          306184192 bytes
Redo Buffers                7823360 bytes
数据库装载完毕。
idle> show parameter resetlogs;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_allow_resetlogs_corruption          boolean     TRUE
idle> recover database until cancel;
ORA-00279: 更改 12696935641735 (在 03/20/2014 22:38:52 生成) 对于线程 1
是必需的
ORA-00289: 建议:
E:\APP\XIFENFEI\FAST_RECOVERY_AREA\CDB\ARCHIVELOG\2014_03_20\O1_MF_1_872_9LOZSK9
X_.ARC
ORA-00280: 更改 12696935641735 (用于线程 1) 在序列 #872 中
指定日志: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'E:\APP\XIFENFEI\ORADATA\CDB\SYSTEM01.DBF'
ORA-01112: 未启动介质恢复
idle> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [2956], [1012314778],
[2956], [1012314903], [268435600], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [2662], [2956], [1012314777],
[2956], [1012314903], [268435600], [], [], [], [], [], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [2956], [1012314768],
[2956], [1012314903], [268435600], [], [], [], [], [], []
进程 ID: 9268
会话 ID: 92 序列号: 3
ログイン後にコピー

ora-600[2662]很熟悉,文件头的scn小于文件中某个block的csn,通过bbed等工具修改文件scn,尝试启动数据库

CDB_CDB$ROOT@SYS> SHUTDOWN ABORT
ORACLE 例程已经关闭。
CDB_CDB$ROOT@SYS> STARTUP
ORACLE 例程已经启动。
Total System Global Area  521936896 bytes
Fixed Size                  2404552 bytes
Variable Size             205524792 bytes
Database Buffers          306184192 bytes
Redo Buffers                7823360 bytes
数据库装载完毕。
数据库已经打开。
ログイン後にコピー

尝试open user pdb

CDB_CDB$ROOT@SYS> alter session set container=pdb;
会话已更改。
CDB_CDB$ROOT@SYS> alter database open;
alter database open
*
第 1 行出现错误:
ORA-00600: 内部错误代码, 参数: [kcvfdb_pdb_set_clean_scn: cleanckpt], [3],
[2956], [1012312995], [2956], [1012334778], [2], [], [], [], [], []
ログイン後にコピー

查询mos得到结论:
Bug 16784143 ORA-600 [kcvfdb_pdb_set_clean_scn: cleanckpt] with PDBs
在12.2/12.1.0.2/12.1.0.1.1中修复,后续尝试打patch,来进一步恢复.
1


测试结果证明
1.root pdb的open过程和以前版本数据库无大差异,但是scn推进比较费劲,以前的event和隐含参数方法无效
2.user pdb再是看是因为bug无法open,后续继续验证
3.12.1的base 版本可能确实问题很多,生产使用慎重
  • ORACLE 12C redo异常恢复测试—打上patch恢复完全
  • ORACLE 12C 控制文件异常恢复
  • ORACLE 12C Windows-Linux 部署DATAGURAD
  • 通过修改控制文件scn推进数据库scn
  • 记录8.0.5数据库恢复过程
  • 异常断电导致current redo损坏处理
  • pdb正常运行丢失数据文件相关恢复
  • 当前联机日志损坏恢复
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

Oracle データベースのログはどのくらいの期間保存されますか? Oracle データベースのログはどのくらいの期間保存されますか? May 10, 2024 am 03:27 AM

Oracle データベース ログの保存期間は、次のようなログのタイプと構成によって異なります。 REDO ログ: 「LOG_ARCHIVE_DEST」パラメータで構成された最大サイズによって決定されます。アーカイブ REDO ログ: 「DB_RECOVERY_FILE_DEST_SIZE」パラメータで構成された最大サイズによって決まります。オンライン REDO ログ: アーカイブされず、データベースの再起動時に失われます。保持期間はインスタンスの実行時間と一致します。監査ログ: 「AUDIT_TRAIL」パラメータによって構成され、デフォルトで 30 日間保持されます。

MIT の最新傑作: GPT-3.5 を使用して時系列異常検出の問題を解決する MIT の最新傑作: GPT-3.5 を使用して時系列異常検出の問題を解決する Jun 08, 2024 pm 06:09 PM

今日は、MIT が先週公開した記事を紹介します。GPT-3.5-turbo を使用して時系列異常検出の問題を解決し、時系列異常検出における LLM の有効性を最初に検証しました。プロセス全体に微調整はなく、GPT-3.5-turbo は異常検出に直接使用されます。この記事の核心は、時系列を GPT-3.5-turbo が認識できる入力に変換する方法とその設計方法です。 LLM が異常検出タスクを解決できるようにするためのプロンプトまたはパイプライン。この作品について詳しく紹介していきます。画像用紙タイトル:Large languagemodelscanbeゼロショタノマリデテ

Oracle にはどれくらいのメモリが必要ですか? Oracle にはどれくらいのメモリが必要ですか? May 10, 2024 am 04:12 AM

Oracle が必要とするメモリーの量は、データベースのサイズ、アクティビティー・レベル、および必要なパフォーマンス・レベル (データ・バッファー、索引バッファーの保管、SQL ステートメントの実行、およびデータ・ディクショナリー・キャッシュの管理) によって異なります。正確な量は、データベースのサイズ、アクティビティ レベル、および必要なパフォーマンス レベルによって影響されます。ベスト プラクティスには、適切な SGA サイズの設定、SGA コンポーネントのサイズ設定、AMM の使用、メモリ使用量の監視などが含まれます。

Oracle データベース サーバーのハードウェア構成要件 Oracle データベース サーバーのハードウェア構成要件 May 10, 2024 am 04:00 AM

Oracle データベース サーバーのハードウェア構成要件: プロセッサ: マルチコア、少なくとも 2.5 GHz のメイン周波数 大規模なデータベースの場合は、32 コア以上が推奨されます。メモリ: 小規模データベースの場合は少なくとも 8 GB、中規模のデータベースの場合は 16 ~ 64 GB、大規模なデータベースまたは重いワークロードの場合は最大 512 GB 以上。ストレージ: SSD または NVMe ディスク、冗長性とパフォーマンスのための RAID アレイ。ネットワーク: 高速ネットワーク (10GbE 以上)、専用ネットワーク カード、低遅延ネットワーク。その他: 安定した電源、冗長コンポーネント、互換性のあるオペレーティング システムとソフトウェア、放熱と冷却システム。

Oracle データベースを使用するために必要なメモリの量 Oracle データベースを使用するために必要なメモリの量 May 10, 2024 am 03:42 AM

Oracle データベースに必要なメモリの量は、データベースのサイズ、ワークロードの種類、同時ユーザーの数によって異なります。一般的な推奨事項: 小規模データベース: 16 ~ 32 GB、中規模データベース: 32 ~ 64 GB、大規模データベース: 64 GB 以上。考慮すべきその他の要素には、データベースのバージョン、メモリ最適化オプション、仮想化、ベスト プラクティス (メモリ使用量の監視、割り当ての調整) などがあります。

C++ でネストされた例外処理を実装するにはどうすればよいですか? C++ でネストされた例外処理を実装するにはどうすればよいですか? Jun 05, 2024 pm 09:15 PM

ネストされた例外処理は、ネストされた try-catch ブロックを通じて C++ に実装され、例外ハンドラー内で新しい例外を発生させることができます。ネストされた try-catch ステップは次のとおりです。 1. 外側の try-catch ブロックは、内側の例外ハンドラーによってスローされた例外を含むすべての例外を処理します。 2. 内部の try-catch ブロックは特定のタイプの例外を処理し、スコープ外の例外が発生した場合、制御は外部例外ハンドラーに渡されます。

Oracleでリスニングプログラムを開始する方法 Oracleでリスニングプログラムを開始する方法 May 10, 2024 am 03:12 AM

Oracle リスナーは、クライアント接続リクエストを管理するために使用されます。起動手順は次のとおりです。 Oracle インスタンスにログインします。リスナー構成を見つけます。 lsnrctl start コマンドを使用してリスナーを開始します。 lsnrctl status コマンドを使用して起動を確認します。

Oracle データベースの起動段階は何ですか? Oracle データベースの起動段階は何ですか? May 10, 2024 am 03:15 AM

Oracle データベースの起動は 7 つの段階に分かれています: 1. 初期化、2. アーカイブ ログの回復、5. オブジェクトのオープン、7. サーバーの起動。このプロセスには、ライブラリ ファイルのロード、パラメータの構成、データベース インスタンスの復元、アーカイブ ログの適用、データ ファイルとオブジェクトの更新、そして最後にクエリを受け入れるためのデータベース サービスの開始が含まれます。

See all articles