Oracle Database 19cでの「高速リカバリ領域」も闇を抱えている?

f:id:ts0818:20210314134732j:plain

forbesjapan.com

この技術が実用化されれば、水不足という人類の不安も時代遅れなものになるかもしれない。各国の研究者によるグループが導入したばかりのこの技術は、有機金属構造体(MOF)と太陽光によって、そのままでは飲めない海水を30分未満で安全かつ清潔な飲料水に変えることができるのだ。

太陽光で「30分で海水を真水にする」技術。水不足解決のカギとなるか | Forbes JAPAN(フォーブス ジャパン)

今回研究チームが開発した「PSP-MIL-53」はまったく新しいMOFであり、海水中の汚染物質と塩分を吸着することができる。MOFが、海水からイオンを抜き出して自身の表面に吸いつける。その結果、水が精製されるのだ。

太陽光で「30分で海水を真水にする」技術。水不足解決のカギとなるか | Forbes JAPAN(フォーブス ジャパン)

⇧「有機金属構造体(MOF:Metal Organic Framework)」が稀少なものであれば、いくら「太陽光」が半永久的なエネルギー源とみなせるとしても、水資源を得るためのコストが高騰して、水の価格が上昇するような事態になれば、結局のところ本当に水を必要としている人が手に入れることは難しいのではないか、と関係ないことを思ってしまった今日この頃、どうもボクです。

何にせよ、技術が発展することは喜ばしいことですね。

というわけで、「Oracle Database」についてです。

レッツトライ~。

 

Oracle Database 19cに接続できない、インスタンスが起動して無かったらしい...

久々に、「Oracle Database 19c」に接続を試みたところ(フリーソフトの「A5:SQL Mk-2 」を使ってます。バージョンは、2.15.4で、「ポータブル版」にしてます)、 

f:id:ts0818:20210302160920p:plain

⇧ 接続できません!

ただ、これは、「A5:SQL Mk-2 」が悪いわけではなく、なぜならば、「ORA-12514」っていうエラーメッセージを「Oracle Database 19c」側で提示してくれてるからですね。

試しに、sqlplusで接続を試みると、

f:id:ts0818:20210302161407p:plain

⇧ また、別のエラーメッセージが表示されますと。「ORA-01034」ってエラーメッセージが表示されておりますと。

そもそも「アイドル・インスタンス」ってなってるんだけど(「アイドル・インスタンス」については後述)、「インスタンス」が起動していないってことらしい。

ただ、Windowsの「サービス」一覧を確認した限り、「Oracleリスナー」とかは動いてるんだわさ。

f:id:ts0818:20210302164106p:plain

その前に「アイドル・インスタンス」とか「インスタンス」とか、いまいち何なのそれ?って感じな情弱な私ですと。

というわけで、そもそもの「Oracle Database」の仕組みについて整理してみようと。

 

Oracle Databaseのインスタンスって何?

Oracleさんが「Oracle Database」についてめっちゃイメージしやすい情報をまとめたブログを公開してくれてくださっているのを見つけることができました。

Oracleさんのブログの内容によりますと「Oracle Database」のインストールについては、 

blogs.oracle.com

f:id:ts0818:20210302163106p:plain

Oracle Databaseは単一サーバーで実行するシングル・インスタンスの構成と、複数のサーバーが共有ディスクとインターコネクト・ネットワークを介して協調動作するOracle Real Application Clusters(RAC)の構成があります。RAC構成の場合、Oracle Databaseのソフトウェアをインストールする前にOracle Grid Infrastructureのソフトウェアをインストールします。クラスタ構成のOracle Grid Infrastructureは、クラスタを構成するノードを確定させるノード・メンバシップの管理やOracle Automatic Storage Management(ASM)の構成、そしてOracleインスタンスOracleリスナーの死活監視の役割を担います

基本からわかる!高性能×高可用性データベースシステムの作り方 第1回 オンプレミス環境でのOracle Grid InfrastructureとOracle Databaseのインストール | Oracle Technology Network Japan Blog

⇧ 大きく分けて、

の2パターンが存在するみたいですと。 (あたしは、「シングル・インスタンス構成」でインストールしておるということになりそうです)

で、「シングル・インスタンス」「Oracle Real Application Clusters(RAC)」のいずれについても、「Oracle Database」というもの自体の内容は変わらないと仮定して、「Oracle Database」の構成はというと、

blogs.oracle.com

f:id:ts0818:20210302162656p:plain

データベース名とインスタンス名もデータベースを作成するときに指定する要素です。Oracle Databaseの文脈で「データベース」というのは、ストレージ上に構成されたオンラインREDOログ、制御ファイル、データファイルの集合のことを指します。これに対し「インスタンス」というのは共有メモリー領域(System Global Area)とバックグラウンド・プロセス群のことを指します。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

⇧ とあるように、

という構成なんだと。

はい、出ました「インスタンス」。

つまり、「Oracle Database」って言った場合は、「インスタンス」「データベース」の両方のことを言ってるんだな、ってことになるんではないかと。

ちなみに、 

f:id:ts0818:20210302164718p:plain

RACの場合は1つのデータベースを複数のノードの複数のインスタンスがマウントします。RACインスタンス名はクラスタ内で一意になっている必要があるため、インスタンス名はSID接頭辞に1、2、...というように数字が付加されます。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

⇧ とあるように、「Oracle Real Application Clusters(RAC)」構成の場合は「インスタンス」が複数になるみたいね。

 

データベース接続の仕組み

で、「インスタンス」「データベース」によって構成されてるのが「Oracle Database」ということで、実際に「データベース」へ接続するには? 

blogs.oracle.com

f:id:ts0818:20210302162355p:plain

OracleリスナーとはTCP/IP経由の接続リクエストを処理するプロセスであり、Oracleインスタンスのプロセス群とは独立しています。SQL*PlusなどのOracleクライアントはこのOracleリスナーに対して接続リクエストを発行することになります。

基本からわかる!高性能×高可用性データベースシステムの作り方 第3回 ネットワーク経由で接続 | Oracle Technology Network Japan Blog

⇧ とあるように、「Oracleリスナー」ってものに対して「接続リクエスト」を発行することで「データベース」に接続できますと。

そして、「Oracleリスナー」と「Oracleインスタンス」 はプロセスはそれぞれ独立していますと。

※以降、「Oracleインスタンス」と「インスタンス」は同義として考えます。(「Oracleインスタンス」と「インスタンス」が一緒かどうかをOracleさんは明示してくれてないので、あくまで、あたしがそう思っただけなので間違ってる可能性が大いにあり得ます。身近の有識者の方に確認しましょう)

つまり、「Oracleインスタンス」が止まっていようが、「Oracleリスナー」が動き続けることはあり得ますと。

話を「データベース」への「接続」に戻すと、

アプリケーション・サーバーなどのOracleクライアントからOracleサーバーに接続しSQLを発行すると、Oracleサーバー・プロセスによってSQLが実行されます。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

⇧ というように、「Oracle Database」ってのは「クライアント・サーバー」モデルでということのようですが、

接続モードとは、OracleクライアントからのコネクションとOracleサーバー・プロセスの関係を決める設定です。接続モードには専用サーバーと共有サーバー、そしてDatabase Resident Connection Pool(DRCP)があります。dbcaで設定できるのは専用サーバーと共有サーバーです。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

⇧ というように「接続モード」というものがあるらしく、

  • 専用サーバー・モード
  • 共用サーバー・モード
  • Database Resident Connection Pool(DRCP)

 の3つがあるみたいですね。

で、「専用サーバー・モード」「共用サーバー・モード」については、 

専用サーバー・モードは、OracleクライアントからのコネクションとOracleサーバー・プロセスが1対1の関係になるモードです。Oracleクライアントからの接続リクエストがOracleリスナー・プロセスに届くと、Oracleリスナー・プロセスはOracleサーバー・プロセスを生成し、コネクションはOracleサーバー・プロセスに接続されます。専用サーバー・モードは最も基本的な接続モードです。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

共有サーバー・モードは、OracleクライアントからのコネクションとOracleサーバー・プロセスがm対nの関係になるモードです。あらかじめ生成されたOracleサーバー・プロセスがOracleインスタンスに接続しており、共有サーバー・プロセスと呼ばれます。共有サーバー・プロセスはキューを経由してディスパッチャ・プロセスと接続しています。Oracleクライアントからの接続リクエストがOracleリスナー・プロセスに届くと、コネクションはディスパッチャ・プロセスに接続されます。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

⇧ とあるように、イメージ図を見た感じでは「インスタンスOracleインスタンス)」経由でないと「データベース」に接続できないっぽいですね。

上図のオレンジ色の「Oracle」は「Oracle サーバー・プロセス」というものらしいです。(「サーバー・プロセス」については後述)

 

アイドル・インスタンスってどういうこと?

で、ようやく本題。

今回、「sqlplus」で「インスタンス」に「接続」を試みてるってことなんだと思うんだけど、『アイドル・インスタンスに接続しました。』ってなったわけなんですと。

で、「アイドル・インスタンス」って何?

www.dba-oracle.com

 

Answer by Mark:

"Connected to an idle instance" usually means that you connected "AS SYSDBA" and the instance you connected to is not started.

http://www.dba-oracle.com/t_connect_to_idle_instance.htm

⇧ というわけで、「インスタンス」が起動してないよ、ってことみたい。

ややこしいんだけど、「インスタンス」は起動してないけど「インスタンス」には「接続」できてる状態らしい。

 

cosol.jp

「アイドル・インスタンスに接続しました」は、インスタンスが起動していない状態でインスタンスへ接続する(実際には「接続しよう」とする)と表示されるメッセージです。
なお、インスタンスが起動していない状態でインスタンスに接続できるのは、SYSDBA 権限またはSYSOPER 権限を指定した場合のみです。これらの権限を指定しなかった場合は ORA-01034 が発生してインスタンスに接続できません。

アイドル・インスタンスに接続しました | 技術情報 | 株式会社コーソル

⇧ 上記サイト様によりますと、「SYSDBA権限」「SYSOPER権限」以外だと「アイドル・インスタンス」へは「接続」できずに「ORA-01034」が発生するみたい。

つまり、「インスタンス」から「データベース」への接続が断絶してる状態のようですと。

 

インスタンスを起動すれば良いんでしょ?からの「ORA-03113: 通信チャネルでend-of-fileが検出されました」

何のこっちゃない、「インスタンス」を起動すれば良いんでしょ?

で、「sqlplus」にて「SYSDBA権限」で「アイドル・インスタンス」に接続して「インスタンス」の起動を試みるも、

f:id:ts0818:20210302181250p:plain

⇧ はい、出ました。

「ORA-03113: 通信チャネルでend-of-fileが検出されました」が出てきたよ...

Oracleさんの見解によりますと、

support.oracle.com

ORA-03113 "通信チャネルでend-of-fileが検出されました" エラーは通常 Oracle データベースに接続するクライアント・プロセスによって報告される一般的なエラーです。このエラーは基本的には 'Oracle シャドウ・プロセスと通信できません' という意味です。このような一般的なエラーは何が起きたのかを判断するために、より詳細な情報を収集する必要があります。- このエラー自体は問題の原因を示すものではありません。例えば、ORA-03113 は次のようなシナリオで発生します。:

  • サーバー・マシンがクラッシュした
  • サーバー・プロセスが O/S レベルで kill された
  • ネットワークの問題
  • Oracle の内部エラー (ORA-600 / ORA-7445) / サーバー上で異常終了
  • クライアントが不適切に複数の接続を処理した
  • など、多くの考えられる原因があります!!

マスターノート: ORA-03113 のトラブルシューティング

⇧ う、う~ん...

など、多くの考えられる原因があります!!』って力強く言われてもね...

結局、原因がよく分からんというやつですね、「エラーメッセージ」の意味ないな~...

そも「Oracle シャドウ・プロセス」って何ぞ?

docs.oracle.com

専用サーバー・アーキテクチャ

専用サーバー・アーキテクチャでは、各クライアント・プロセスのかわりとして作成されたサーバー・プロセスは専用サーバー・プロセス(またはシャドウ・プロセス)と呼ばれます。

アプリケーションとOracle Net Servicesのアーキテクチャ

専用サーバー・プロセスはクライアント・プロセスとは別のものであり、クライアント・プロセスのかわりとしてのみ動作します。

アプリケーションとOracle Net Servicesのアーキテクチャ

⇧ というように、「専用サーバー・プロセス」のことを「シャドウ・プロセス」と言うらしいですと。

「専用サーバー・プロセス」はというと、

⇧ 上図によりますと、「Oracle Database」の「インスタンス」内で生成される「プロセス」ってことらしいんだけで、「クライアント・プロセスのかわりとしてのみ動作します」ってのが、いまいちよく分からん...

そも、「Oracle Database」における「プロセス」とは?

docs.oracle.com

プロセスは一連の処理を実行できるオペレーティング・システムのメカニズムです。

プロセス・アーキテクチャ

プロセス実行のアーキテクチャは、オペレーティング・システムによって決まります。たとえば、Windowsでは、Oracleバックグラウンド・プロセスはプロセス内の実行スレッドです。LinuxおよびUNIXにおけるOracleプロセスは、オペレーティング・システム・プロセスか、またはオペレーティング・システム・プロセス内部のスレッドです。

プロセス・アーキテクチャ

⇧「Oracle Database 12c」のドキュメントによると、「OS(Operation System)」によって変わってきますと。

データベース・インスタンスには複数のプロセスが含まれ、またデータベース・インスタンスは複数のプロセスと相互作用します。

プロセス・アーキテクチャ

⇧ ってことらしく、

「プロセス」としては、

という感じで、大きく分けて「クライアント・プロセス」「Oracleプロセス」の2つあり、「サーバー・プロセス」は「Oracleプロセス」の中の1つという位置づけらしい。

「サーバー・プロセス」は何なのかというと、 

プロセス・アーキテクチャ

⇧ ってことみたいね。

「専用サーバー・プロセス」のことを「シャドウ・プロセス」というってことでしたが、「サーバー・プロセス」の特殊版ってことだとは思われます。(「サーバー・プロセス」と「シャドウ・プロセス」の違いについては、よく分からんです...)

 

脱線しましたが、「ORA-03113: 通信チャネルでend-of-fileが検出されました」でのOracleさんの見解は、

このエラーは基本的には 'Oracle シャドウ・プロセスと通信できません' という意味です。

ということなので、『「インスタンス」起動したって言ってるのに、「Oracle シャドウ・プロセス」と通信できない?何でやねん!』っていうツッコミを入れたくなるよね...

というか、そもそも「Oracle シャドウ・プロセス」が動いてるのかすら分からんというね...

ちなみに、「Oracle シャドウ・プロセス」は「シャドウ・プロセス」と同義ということで良いんだろうか?と思いましたが、Oracleさんのドキュメントを見る限り「Oracle シャドウ・プロセス」と「シャドウ・プロセス」が同じことを指していると特に明示してくれてるわけではないので、「Oracle シャドウ・プロセス」と「シャドウ・プロセス」は同じものを指してるんだよね、ってのは、あくまで、知見の無いあたしの推測です。(身近な有識者に確認しましょう。)

 

エラーログを見てみる

ちょっと、「sqlplus」で表示されるエラーを見ても全く役に立たないので、他に何か分かる情報がないか確認してみる。

dekiruengineer.com

Oracleのアラートログですが、11g以降(12c,18c,19c)は以下の場所に存在します。

$ORACLE_BASE/diag/rdbms/<SID>/<SID>/trace/alert_<SID>.log

※$ORACLE_HOME 配下ではないことに注意してください。

Oracle Database アラートログの場所(11g,12c,18c,19c)

⇧ 上記サイト様を参考に、「アラートログ」の内容を確認してみる。

自分の環境では、「C:\app02\app\ts0818\diag\rdbms\orcldb\orcldb\trace\alert_orcldb.log」ってのが存在しておりました。

f:id:ts0818:20210302204936p:plain

 

2021-03-02T15:37:28.785228+09:00
Errors in file C:\APP02\APP\TS0818\diag\rdbms\orcldb\orcldb\trace\orcldb_ora_11808.trc:
ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 191339520バイトのディスク領域を10737418240バイト制限から再利用できません
NET  (PID:11808): Error 19809 Creating archive log file to 'C:\APP02\APP\TS0818\FAST_RECOVERY_AREA\ORCLDB\ARCHIVELOG\2021_03_02\O1_MF_1_229_%U_.ARC'
2021-03-02T15:37:28.820400+09:00
Errors in file C:\APP02\APP\TS0818\diag\rdbms\orcldb\orcldb\trace\orcldb_ora_11808.trc:
ORA-16038: ログ1、順序番号229をアーカイブできません。
ORA-19809: リカバリ・ファイルの制限を超えています
ORA-00312: オンライン・ログ1 スレッド1: 'C:\APP02\APP\TS0818\ORADATA\ORCLDB\REDO01.LOG'
USER (ospid: ): terminating the instance due to ORA error 
2021-03-02T15:37:29.007403+09:00
System state dump requested by (instance=1, osid=11808), summary=[abnormal instance termination].
System State dumped to trace file C:\APP02\APP\TS0818\diag\rdbms\orcldb\orcldb\trace\orcldb_diag_26944.trc
2021-03-02T15:37:32.921114+09:00
Instance terminated by USER, pid = 11808

⇧「アラートログ」の内容を見てみると、

  • ORA-19809: リカバリ・ファイルの制限を超えています
  • ORA-19804: 191339520バイトのディスク領域を10737418240バイト制限から再利用できません
  • ORA-16038: ログ1、順序番号229をアーカイブできません。
  • ORA-00312: オンライン・ログ1 スレッド1: 'C:\APP02\APP\TS0818\ORADATA\ORCLDB\REDO01.LOG'

という感じで、「ORA-19809」「ORA-19804」「ORA-16038」「ORA-00312」の4つのエラーが「アラートログ」には記録されてましたと。

 

「ORA-19809: リカバリ・ファイルの制限を超えています」と「高速リカバリ領域(旧:フラッシュリカバリ領域)」

で、調べた感じでは、

rainbow-engine.com

どうやら「フラッシュリカバリ領域」が不足している事が原因でエラーが発生している様です。

ORA-03113 end-of-file on communication channelエラーの対処 – Rainbow Planet

⇧ 上記サイト様の現象と同じでありそうな感じでしたと。

「フラッシュリカバリ領域」とは?

手前味噌で恐縮ですが、

ts0818.hatenablog.com

名前が変わったらしい。(11g とかまでは、「フラッシュ・リカバリ領域」と呼ばれていたのではないかと。12c からしOracle Database 使ったことないから分からんけど。)

Oracle Databaseの高速リカバリ領域(旧:フラッシュ・リカバリ領域)って何ぞ? - ts0818のブログ

⇧ というか、自分が10ヵ月ぐらい前に同じ現象に遭遇してましたですね...いやはや、すっかり忘却の彼方でした、「未来の自分は他人」という言葉がありますが、備忘録は残すようにしておくことは大切ですね。

で、「フラッシュリカバリ領域」と「高速リカバリ領域」の関係が分からないんですが、おそらく、Oracle Database 12cとかで「フラッシュリカバリ領域」って呼ばれてものが「高速リカバリ領域」って呼ばれるようになったんじゃないかと推測してます。

で、「フラッシュリカバリ領域」もとい「高速リカバリ領域」とは?

(以降、「高速リカバリ領域(旧:フラッシュリカバリ領域)」と記載してますが、あくまで知見の無いあたしの推測です。)

blogs.oracle.com

CREATE DATABASEを実行すると、表領域を構成するデータファイルと制御ファイル、オンラインREDOログ・ファイルが作成されます。データファイルとオンラインREDOログ・ファイルの位置は制御ファイルに記録されています。そのため、これらのファイルを移動させたい場合、単純にOSのファイル移動コマンドで移動させただけではデータベースをオープンできなくなります。これらのファイルを移動させるには、物理的にファイルを移動させるだけでなく、ALTER DATABASE文で制御ファイルの内容も変更する必要があります。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

データベースを構成するファイルを移動させるのは煩雑な手順が必要であるため、データベースを格納するストレージ領域についてはよく検討しておく必要があります。CREATE DATABASEを実行する前に、データベースを格納する領域と、高速リカバリ領域(Fast Recovery Area)となるファイルシステムやASMディスク・グループを構成しておきます。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

⇧ という感じで、「データベース」を作成すると、上図のようなファイル群が作成されるようなのですが、「高速リカバリ領域(旧:フラッシュリカバリ領域)」は、

⇧ 「アーカイブREDOログ」「RMANバックアップ・ファイル」「フラッシュバック・ログ」が格納される領域ということで、デフォルトだと「DB_RECOVERY_FILE_DEST」に配置される部分ってことなんですかね?

高速リカバリ領域(DB_RECOVERY_FILE_DEST)はデータベースが破損した場合に備えるための領域であるため、データベースを構成する領域(DB_CREATE_FILE_DEST)とは物理的に別のストレージ・デバイスに格納すべきです。

基本からわかる!高性能×高可用性データベースシステムの作り方 第2回 データベースを作成(CREATE DATABASE)するときに考慮しておくこと | Oracle Technology Network Japan Blog

⇧う、う~ん...

「物理的に別のストレージ・デバイス」っていうのがよく分からんのだけど、

www.atmarkit.co.jp

 Windows OSでハードディスクやSSDのようなストレージデバイスを利用する場合、通常はデバイス上にNTFSやFATなどの論理的な「ファイルシステム」を構築して、その中にデータを保存する。ディスクの物理的な構造やサイズ、形態などとは独立したファイルシステムを使うことにより、デバイスに依存せず、柔軟でポータビリティのある形でデータを保存したり、他のシステムとデータを交換したりできる。

第8回 Windowsのストレージアーキテクチャ:Windows OS入門 - @IT

 ストレージデバイスにはさまざまな種類があるが、Windows OSでは全てランダムアクセス可能なブロック型のストレージ(一定サイズのブロックを単位としてデータの読み書きを行うタイプのストレージデバイス)として扱う。これにより、OSから見るとどれも同じ手段でアクセス、管理できるようになる。

第8回 Windowsのストレージアーキテクチャ:Windows OS入門 - @IT

⇧ ってことだとすると、Windows で「Oracle Database」を使う場合は、「SSD」に「データベースを構成する領域(DB_CREATE_FILE_DEST)」を「HDD」に「高速リカバリ領域(DB_RECOVERY_FILE_DEST)」を格納するような感じにしないといけなかったってことですかね?

 

「高速リカバリ領域(旧:フラッシュリカバリ領域)」をどうする?

「ORA-19809: リカバリ・ファイルの制限を超えています」っていうエラーが「高速リカバリ領域(旧:フラッシュリカバリ領域)」 の制限による問題ということで、対処する方法としては、

  • 高速リカバリ領域(旧:フラッシュリカバリ領域)のサイズを増やす
    「DB_RECOVERY_FILE_DEST_SIZE」の値を変える
  • 高速リカバリ領域(旧:フラッシュリカバリ領域)で不要ファイルを削除
    RMAN(Recovery Manager)で削除する必要あり

のどちらかのアプローチを取ることになる感じでしょうか。

Oracleのドキュメントを見た限りだと(Oracle Database 12cのドキュメントの内容だけど)、

docs.oracle.com

RMANの保存方針によって高速リカバリ領域のディスク割当て制限より大きいバックアップのセットを保存する必要がある場合、またはこの保存方針がNONEに設定されている場合、高速リカバリ領域は再利用可能な領域がなくなるまで完全に一杯になることがあります。

RMANバックアップおよびリポジトリ・レコードのメンテナンス

再利用可能な領域が15%未満になると警告アラートが発行され、再利用可能な領域が3%未満になるとクリティカル・アラートが発行されます。この状況をDBAに警告するために、アラート・ログおよびDBA_OUTSTANDING_ALERTS表(Enterprise Managerで使用)にエントリが追加されます。ただし、高速リカバリ領域内の領域は、再利用可能な領域がなくなるまでデータベースによって継続して消費されます。

RMANバックアップおよびリポジトリ・レコードのメンテナンス

⇧ いやいやいや、有り得ない...

どう考えてもこの仕様はおかしいでしょ...

っていうか、「再利用可能な領域がなくなるまでデータベースによって継続して消費されます」って、正気ですか?

Oracleさんの闇を垣間見た気がするんですが...

恐ろし過ぎるんですけど... 

何、この時限爆弾を抱えたかのような気持ちで使わないといけないって、データベースってこんな部分で精神をすり減らさなければいけないほど、精神衛生上宜しくないものなんでしたっけ?

で、Oracleさんが提示する対応アプローチとしては、

削除対象のファイルがない場合に高速リカバリ領域が一杯になった状態を解消する方法として、次のいくつかの方法があります。

  • 使用可能なディスク領域を追加し、DB_RECOVERY_FILE_DEST_SIZEを増加して、追加した領域を反映させます。

  • 高速リカバリ領域からテープなどの3次ストレージ・デバイスにバックアップを移動します。

    リカバリ領域のすべてのファイルを一度にテープにバックアップする簡単な方法の1つに、BACKUP RECOVERY AREAコマンドがあります。バックアップをリカバリ領域からテープに転送した後、高速リカバリ領域からファイルを削除できます(「RMANバックアップおよびアーカイブREDOログの削除」を参照)。フラッシュバック・ログは、リカバリ領域外にはバックアップできないため、BACKUP RECOVERY AREAではバックアップされません。

  • オペレーティング・システム・ユーティリティを使用して削除されたファイルに対しては、DELETEを実行します。

    ホスト・オペレーティング・システムのコマンドを使用してファイルを削除した場合、その結果できる空き領域はデータベースでは認識されません。RMANのCROSSCHECKコマンドを実行して、高速リカバリ領域の内容を再確認し、期限切れのファイルを特定した後、DELETE EXPIREDコマンドを使用して、RMANリポジトリからすべての期限切れのバックアップを削除することができます。

  • 保証付きリストア・ポイントが必要であることを確認します。必要ない場合は、「リストア・ポイントの削除」の説明に従って削除します。

    保証付きリストア・ポイントで必要ないフラッシュバック・ログは、高速リカバリ領域内の他のファイルの領域を確保するために自動的に削除されます。保証付きリストア・ポイントを使用すると、リストア・ポイントSCNまでフラッシュバック・データベースを実行するために必要なフラッシュバック・ログを強制的に保存できます。

  • バックアップ保存方針を確認します。Data Guardを使用している場合は、アーカイブREDOログの削除方針も確認します。

RMANバックアップおよびリポジトリ・レコードのメンテナンス

⇧ 上記のような感じらしい。

まぁ、「不要ファイルを削除」を実施していく感じになるかと。 

それにしても、なんだろう、「Oracle Database 19c」についても、この恐ろしい仕様(「再利用可能な領域がなくなるまでデータベースによって継続して消費されます」)を引き継いでいるんだろうか...

悲報...

docs.oracle.com

RMANの保存方針によって高速リカバリ領域のディスク割当て制限より大きいバックアップのセットを保存する必要がある場合、またはこの保存方針がNONEに設定されている場合、高速リカバリ領域は再利用可能な領域がなくなるまで完全に一杯になることがあります。

RMANバックアップおよびリポジトリ・レコードのメンテナンス

再利用可能な領域が15%未満になると警告アラートが発行され、再利用可能な領域が3%未満になるとクリティカル・アラートが発行されます。この状況をDBAに警告するために、アラート・ログおよびDBA_OUTSTANDING_ALERTS表(Enterprise Managerで使用)にエントリが追加されます。ただし、高速リカバリ領域内の領域は、再利用可能な領域がなくなるまでデータベースによって継続して消費されます。

RMANバックアップおよびリポジトリ・レコードのメンテナンス

⇧ 「Oracle Database 19c」でもまったく変わっていないぃぃぃぃぃぃぃ~!

きっと、夢を見てるんだ...そうだ、起きなきゃ...

...って、現実なんですけど~!

わ、分からん...

データベース業界では、これが当たり前な仕様なんだろうか...

 

RMAN(Recovery Manager)の実行が失敗するんだけど...

とは言え、「RMAN(Recovery Manager)」で不要ファイルを一掃すれば、万事解決、こうして幸せに暮らしましたとさ、めでたしめでたし、で大円団を迎える展開が待ち受けてる、という優しい世界の話になってる、で良いんでしょう?

おりゃ~!

f:id:ts0818:20210313165452j:plain
⇧ ...

駄目やんけ~!!!

docs.oracle.com

前提条件

RMANがターゲット・データベースに接続していて、そのデータベースがマウントまたはオープン状態である必要があります。

https://docs.oracle.com/cd/F19136_01/rcmrf/DELETE.html#GUID-FB4EAC69-4978-42F7-8B09-77C6736188B3

⇧ しょ、衝撃なんですけど...

「データベース」が動いてないようだから動くようにするために、不要なファイルを削除しなきゃならんのにと思ったんですが、不要なファイルを削除するために使用する「RMAN(Recovery Manager)」コマンドの「前提条件」が、「データベースがマウントまたはオープン状態である必要があります」だと!

インスタンス」は起動してるっぽいんだけど、「データベース」は動いてないってことだと思ったんだけど、

blogs.oracle.com

RMANはOracle8で導入された物理バックアップ・ツールです。RMANでバックアップ/リストアを行うには、rmanコマンドでOracleインスタンスに接続します。rmanコマンドはアプリケーションからの接続と同様に、Oracleサーバー・プロセスを介してOracleインスタンスに接続します。Oracleサーバー・プロセスがOracleデータベースのファイルにアクセスする仕組みを使って、バックアップ/リストア/リカバリの操作を行います。

基本からわかる!高性能×高可用性データベースシステムの作り方 第7回 バックアップ/リカバリ(2)RMANの基本 | Oracle Technology Network Japan Blog

⇧ 上図のイメージ図だと、「oracle(「サーバー・プロセス」のことと思われ)」に対して「RMAN(Recovery Manager)」で接続しにいってるように見えるのと、説明では「rmanコマンドでOracleインスタンスに接続します。」と仰ってるので、「oracle(「サーバー・プロセス」)」が起動してないってことなのかしら?

とは言え、「データベース」が起動してる必要があり、「RMAN(Recovery Manager)」実行時のメッセージには「ターゲット・データベースに接続しました(起動していません)。」って言われたから「データベース」を起動せにゃならんってことよね?

で、「RMAN(Recovery Manager)」によるエラーが、

  • ORA-01034: ORACLE not available
  • ORA-27101: shared memory realm does not exist

ってことなんですが、

www.climb.co.jp

⇧ 上記サイト様によりますと、「アーカイブログのモードを一旦リセット」すればいけるよ、とのこと。

 

ポイントは、startup mount

ここで、ポイントとなってくるのが、「startup mount」を実行することらしいです。

www.atmarkit.co.jp

STARTUPコマンドでMOUNT句を指定すると、データベースをマウントし、オープンしない状態でインスタンスを起動できます。このモードで起動するのは、特定のメンテナンス操作を行う場合です。

データベースの起動(SQL*Plus版) − @IT

⇧ とすることで、「データベース」は起動しないんだけど、「インスタンス」からの「接続」はできる状態にできるってことみたいです。

www.climb.co.jp

startup openと入力すると、異常のあるREDOログおよびアーカイブログが読み込まれ、マウントした直後に「ORA-03113:通信チャネルでend-of-fileが検出されました」というエラーが発生し、それ以降exitするまでうまくいかなくなるため、mount状態でいったんとめます。

Oracle DB起動時にエラーORA-01034・ORA-27101が出て起動しない際の対処法 | データベース アクセス ブログ

⇧ 上記サイト様にありますように、「ORA-03113: 通信チャネルでend-of-fileが検出されました」のエラーが起こることを回避できるようです。

では、改めまして、 

f:id:ts0818:20210313164322p:plain

「データベース」を起動!

f:id:ts0818:20210313164534p:plain

⇧ 館長、「データベース」が起動しました!

別にコマンドプロンプトを起ち上げて、「rman」コマンドを実行していきます。

「RMAN(Recovery Manager)」で「データベース」に接続できたら、「アーカイブログ」を一掃します。

f:id:ts0818:20210313165522j:plain

f:id:ts0818:20210313165535j:plain

f:id:ts0818:20210313165546j:plain

確認したころ、

f:id:ts0818:20210313165933p:plain

⇧ すべて、跡形もなく消え去ったようです。

ですが、

f:id:ts0818:20210313170423p:plain

ディレクトリが残ったままなんすけど...

RMANコマンドを使用してバックアップまたはアーカイブREDOログ・ファイルを削除する場合、RMANは次の処理を実行します。

  • オペレーティング・システムから物理ファイルを削除します(ファイルが存在する場合)。

  • 制御ファイル内のファイル・レコードのステータスをDELETEDに更新します。

  • リカバリ・カタログ表からファイル・レコードを削除します(RMANがリカバリ・カタログに接続されている場合)。

RMANバックアップおよびリポジトリ・レコードのメンテナンス

制御ファイルのデータは内部構造に格納されているため、RMANは、制御ファイルからレコードを削除できず、レコードのステータスをDELETEDに更新するのみです。ただし、カタログ表は通常のデータベース表であるため、表から行が削除される場合と同様に、カタログ表から行が削除されます。

RMANバックアップおよびリポジトリ・レコードのメンテナンス

⇧ う、う~ん...

ドキュメントにも「アーカイブREDOログ」を格納してた「ディレクトリ」については一言も言及されてない...

何だろう、物理削除すれば良いんかな?

とりあえず、分からんけど、「RMAN(Recovery Manager)」でどうにかできそうにないっぽいので、「物理削除」するで。

f:id:ts0818:20210313172018p:plain

f:id:ts0818:20210313172136p:plain

f:id:ts0818:20210313172158p:plain

きれいになりました。

f:id:ts0818:20210313172256p:plain

 

「高速リカバリ領域」を設定し直す?

Oracle Database」の「高速リカバリ領域」の仕様上、何度も同じ現象を迎えそうな感じなので、設定でどうにかできるもんなのか調べてみました。

Oracle Database」のことは門外漢なので、何とも言えませんが、

docs.oracle.com

Oracleは、次の2種類のパラメータ・ファイルをサポートしています。

パラメータ・ファイル

⇧ おそらく、上記の2つのファイルで設定するしか無さそうな感じですかね。

  • サーバー・パラメータ・ファイル(SPFILE:Server Parameter FILE)
    バイナリファイル形式。データベースに接続して設定。
  • 初期化パラメータ・ファイル(PFILE:Parameter FILE)
    テキストファイル形式。データベースに接続して無くても設定可。インスタンスの再起動しないと設定変更は反映されない。

ってことだと思います。 

で、その設定ファイルって、どこにあんのよ?

docs.oracle.com

⇧ ってな感じで、「UNIX and Linux」と「Windows」で配置場所が変わるみたいなんだけど、「Windows」の場合のデフォルトの配置場所は、

  • サーバー・パラメータ・ファイル(SPFILE:Server Parameter FILE)
    • Without Oracle ASM:
      OH\database
    • When Oracle ASM is present:
      In the same disk group as the data files (assuming the database was created with DBCA)
  • 初期化パラメータ・ファイル(PFILE:Parameter FILE)
    Oracle_Home\database

ってことみたい。

f:id:ts0818:20210313181919p:plain

⇧ っていうか、「初期化パラメータ・ファイル(PFILE:Parameter FILE)」が存在しないんだが... 

docs.oracle.com

注意:

初期化パラメータ用のinit.oraファイルは、Oracle Universal Installerによりデータベース・インストール中に設定されます。これらのパラメータ設定は、ハードウェア構成の違いに応じて、異なる可能性があります。

初期化パラメータ・ファイルの概要

⇧ え~っと...

で、自分の場合、「Oracle Universal Installer」使って「Oracle Database 19c」インストールしたんじゃなかったんだっけ?って思って確認したところ、バッチリ「Oracle Universal Installer」を使ってインストールしてました。

そして、

注意:

SQLスクリプトを使用して手動でデータベースを作成する場合は、初期化パラメータ・ファイルを作成するか、または既存の初期化パラメータ・ファイルをコピーしてその内容を変更する必要があります。Database Configuration Assistantを使用してデータベースを作成する場合は、初期化パラメータ・ファイルが自動的に作成されます。


初期化パラメータ・ファイルの場所について

⇧「Database Configuration Assistant」についても使ってましたけど...。

なのに、何故「初期化パラメータ・ファイル(PFILE:Parameter FILE)」存在しない?

う~ん、自分が使ってるのが「Oracle Database 19c(Version 19.3.0.0.0)」なんだけど「Version 19.3.0.0.0」限定のバグなのかな?

相変わらず、Oracleさんのドキュメントはカオスだな~。

話が脱線しましたが、

docs.oracle.com

パラメータ・ファイルのパラメータ値は、いくつかの方法で変更できます。

  • 初期化パラメータ・ファイルを編集する。

    ほとんどの場合は、次にデータベースのインスタンスを起動したとき、新しいパラメータ値が使用されます。

  • ALTER SYSTEM SET ... SCOPE=SPFILE文を発行してサーバー・パラメータ・ファイルを更新する。

  • ALTER SYSTEM RESET文を発行して初期化パラメータの値をクリアする。

パラメータ・ファイルのパラメータ値の変更

⇧ って感じなので、「サーバー・パラメータ・ファイル(SPFILE:Server Parameter FILE)」を変更していく方針で進めようかと。

パラメータをALTER SYSTEM文を使用して変更すると、変更に使用した文がOracle Databaseによってアラート・ログに記録されます。

パラメータ・ファイルのパラメータ値の変更

⇧ ちゃんと「アラート・ログ」にも記録を残してくれるって言ってますし。

で、肝心の「変更可能なパラメーター」ってのはどんなものがあるんじゃろ?って思ったので、

この項では、初期化パラメータを機能カテゴリ別にリストします。

パラメータ・ファイルのパラメータ値の変更

⇧ 確認してみるも、

何か「高速リカバリ領域」に関する対処としては、

  • DB_RECOVERY_FILE_DEST
    高速リカバリ領域のデフォルトの位置を指定します。
  • DB_RECOVERY_FILE_DEST_SIZE
    高速リカバリ領域に作成されるターゲット・データベースのリカバリ・ファイルで使用される合計領域に対する厳密な制限(バイト)を指定します。

の2つぐらいしか無さ気なんですよね...

souiunogaii.hatenablog.com

⇧ 上記サイト様でも、「DB_RECOVERY_FILE_DEST」「DB_RECOVERY_FILE_DEST_SIZE」の設定を行ってる感じですかね。

ちなみに、自分の設定を見てみたら、

f:id:ts0818:20210313190459p:plain

⇧ 既に10GBに設定されていたという...

できることないやん... 

いや、あれよ、パソコンのスペックがむっちゃ高くて、10GB以上割り振っても余裕よ、って人だったら、単純に「高速リカバリ領域」の容量を上げれば良い話かなとは思うんで、「DB_RECOVERY_FILE_DEST_SIZE」の値を100GBとかに増やしたりすれば良いと思うんよ。(私自身は「Oracle Database」に詳しくないので、どういうアプローチが良いのかは分かっておりません...)

自分が取りたいアプローチとしては、「高速リカバリ領域」がいっぱいになる前に、「アーカイブログ」が削除されれば良いな、って思ってたので、「アーカイブログ」とかの保存期間を調整するような感じにしたいかなと。

話が脱線しましたが、おまけに、

パラメータ・ファイルでは、これらのタイプのパラメータを指定しないでください。

  • 問題を解決するために、オラクル社から指示があった場合にのみ変更するパラメータ

  • 値がOracle Databaseサーバーによって自動的に算出されるため、通常、変更する必要のない導出パラメータ

パラメータ・ファイルのパラメータ値の変更

⇧ 何か気になる記載が...

と思ったら、

docs.oracle.com

5.7.1 アーカイブREDOログの削除方針

CONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用すると、アーカイブREDOログが削除対象になる場合を指定できます。

この削除方針は、高速リカバリ領域を含むすべてのアーカイブ先に適用されます。

RMAN環境の構成

デフォルトでは、アーカイブREDOログの削除方針はありません。そのためアーカイブREDOログの方針はNONE句に設定されています。

RMAN環境の構成

この特定の場合、高速リカバリ領域は、ディスクまたはSBTに1回以上バックアップされているとき、またはバックアップ保存方針に従ってログが不要になったときに、リカバリ領域内のアーカイブREDOログ・ファイルを削除対象であるとみなします。

RMAN環境の構成

⇧ 何か「RMAN(Recovery Manager)」のほうで気になる情報が。

5.5 バックアップの保存方針の構成

バックアップの保存方針では、データ・リカバリの要件を満たすために保存する必要のあるバックアップを指定します。

RMAN環境の構成

この保存方針は、リカバリ期間または冗長性のいずれに基づいていてもかまいません。保存方針を指定するには、CONFIGURE RETENTION POLICYコマンドを使用します。

RMAN環境の構成

注意:

高速リカバリ領域を使用している場合は、保存方針が無効になっている状態でデータベースを実行しないでください。ファイルが不要とみなされないと、ファイルを高速リカバリ領域から削除できるのは、そのファイルが他のディスクの場所またはテープなどの3次ストレージ・デバイスにバックアップされた場合のみになります。このアクションによって、リカバリ領域内のすべての領域が使用され、データベースの通常の操作に影響を及ぼす可能性があります。「Oracleによる高速リカバリ領域でのディスク領域の管理方法」を参照してください。

RMAN環境の構成

⇧ 衝撃...

まさかの「RMAN(Recovery Manager)」側での設定があるらしい...

何これ、二重管理とかになってしまうことになるんでないの?

ボヤキが止まらないのですが、で、確認してみた。

f:id:ts0818:20210313195949p:plain

以下が、自分の「Oracle Database」に同梱されてる「RMAN(Recovery Manager)」によって設定されてるらしい「CONFUGIURE」の一覧ってことらしい。

db_unique_name ORCLDBのデータベースにおけるRMAN構成パラメータ:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\APP02\ORACLE\PRODUCT\19.0.0\DBHOME_1\DATABASE\SNCFORCLDB.ORA'; # default

⇧ 見た感じ、「CONFIGURE ARCHIVELOG DELETION POLICY TO NONE」「CONFIGURE RETENTION POLICY TO REDUNDANCY 1」ってなってたんだけど、

docs.oracle.com

⇧ で「RMAN(Recovery Manager)」に設定できる値とかを見た感じでは、できることが無さ気な気がする...というか、設定できる値が見辛い...

とりあえず、一旦、「データベース」をシャットダウンして「マウント」し直します。

f:id:ts0818:20210313215430p:plain

そしたらば、「アーカイブモード」に戻して、「データベース」を起動します。

f:id:ts0818:20210313215541p:plain

一旦、「データベース」の接続を切断し、改めて接続し直して、「データベース」に対してコマンドを実行してみます。

f:id:ts0818:20210313215759p:plain

⇧ 無事、「データベース」が復帰しました。

 

Windowsの「タスク スケジューラ」で削除するようにする

何と言うか、残念ながら「Oracle Database」側でできることは無さ気なので(パソコンのスペックが良ければ、単純に「DB_RECOVERY_FILE_DEST_SIZE」とかを大きくして「高速リカバリ領域」の容量を増やすとかできると思うけど...)、 

sql-oracle.com

ここでは、この増え続けるアーカイブログを自動で削除するバッチを作成してみます。

アーカイブログを自動で削除する方法(RMAN) | Oracle初心者でもスッキリわかる

⇧ 上記サイト様のように、Windows環境であれば、「削除バッチ」ファイルを作ってWindowsの「タスク スケジューラ」に追加して上げれば良いみたいですね。

いざいざ。

run{
 # 1日以前を削除
 delete noprompt archivelog until time 'sysdate-1';
 # OSから削除された場合、oracle側も削除する
 crosscheck archivelog all;
 delete expired archivelog all;
}    

で、このファイルを適当な場所に保存しますと。

自分は、「Oracle Database 19c」をインストールした時のディレクトリに配置してみました。

f:id:ts0818:20210313210552p:plain

続きまして、コマンドを記述した上記のファイルを実施するバッチファイルを作成します。

REM アーカイブログを削除する
"C:\app02\oracle\product\19.0.0\dbhome_1\bin\rman.exe" target / @del_arclog.rcv log=del_arclog.log append nocatalog 

 

f:id:ts0818:20210313211202p:plain

そしたらば、「タスク スケジューラ」で設定してきましょう。

qiita.com

⇧ 上記サイト様を参考にさせていただきました。

まずは、「タスク スケジューラ」を開きます。

f:id:ts0818:20210313211248p:plain

「タスク スケジューラ ライブラリ」を選択した状態で右クリックし「新しいフォルダー(N)...」を選択。

f:id:ts0818:20210313211528p:plain

「フォルダー名」を適当に付けて、「OK」で。

f:id:ts0818:20210313211840p:plain

「タスク スケジューラ ライブラリ」内に「フォルダー」ができているので、作成された「フォルダー」を選択した状態で右クリックし、「タスクの作成(R)...」で。

f:id:ts0818:20210313211947p:plain

「全般」タブの設定は以下のような感じにしました。続いて「トリガー」タブを選択します。

f:id:ts0818:20210313212542p:plain

「トリガー」タブで「新規(N)...」を選択。

f:id:ts0818:20210313212751p:plain

今回は「毎週(W)」で「土曜日(R)」「日曜日(U)」に実行するように設定してみました。時刻は「17:00:00」としました。「OK」を選択。

f:id:ts0818:20210314120724p:plain

続きまして「操作」タブを選択し、「新規(N)...」を選択。

f:id:ts0818:20210313213353p:plain

f:id:ts0818:20210313213553p:plain

作成しておいた「バッチファイル」を選択。

f:id:ts0818:20210313213739p:plain

「OK」で。

f:id:ts0818:20210313213818p:plain

f:id:ts0818:20210313213922p:plain

「条件」タブは何も変更してません。

f:id:ts0818:20210313214052p:plain

「設定」タブは何も変更してません。「OK」を選択で。

f:id:ts0818:20210313214157p:plain

普段、使用してるWindowsの「アカウント」と「パスワード」を設定しました。

f:id:ts0818:20210313214901j:plain

「タスク」が設定されたようです。

f:id:ts0818:20210313214613p:plain

これで、暫く様子を見てみますかね。

 

と思いきや、「RMAN(Recovery Manager)」でexitしたらエラーが発生...

 作業を終了しようとしたら、エラー出たんだけど...

f:id:ts0818:20210313220654p:plain

RMAN-06900: 警告: V$RMAN_STATUS行またはV$RMAN_OUTPUT行 を生成できません
RMAN-06901: 警告: V$RMAN_STATUS行およびV$RMAN_OUTPUT行 の更新を禁止しています
ターゲット・データベースのOracleエラー:
ORA-03113: 通信チャネルでend-of-fileが検出されました
プロセスID: 20076
セッションID: 626、シリアル番号: 20681


Recovery Managerが完了しました。

⇧ 何なのかね...

とりあえず、Oracleさんが用意してくれてる「エラー・メッセージ」一覧を確認してみることに。

docs.oracle.com

RMAN-06900: 警告: V$RMAN_STATUS行またはV$RMAN_OUTPUT行を生成できません

原因: ルーチンcreateRmanStatusRow()またはcreateRmanOutputRow()により、V$RMAN_STATUSまたはV$RMAN_OUTPUTに新規の行が追加された可能性があります。

処置: 関連するエラー・メッセージを確認してください。関連するエラー・メッセージに修正可能な状態が示されている場合は修正を実行し、そうでない場合はOracleサポート・サービスに連絡してください。

RMAN-00201からRMAN-20517

RMAN-06901: 警告: V$RMAN_STATUS行およびV$RMAN_OUTPUT行の更新を禁止しています

原因: これは情報メッセージです。

処置: 処置は必要ありません。

RMAN-00201からRMAN-20517

⇧ 処置が「必要なのか」「必要ないのか」、どっちやねん!

そして、「エラー・メッセージ」は、

ORA-03113: 通信チャネルでファイルの終わりが検出されました

原因: クライアント・プロセスとサーバー・プロセスの間の接続が切断されました。

措置: 通信エラーがありました。さらに調査する必要があります。最初に、ネットワークの問題の有無をチェックし、SQL*Netの設定を確認してください。また、 alert.log ファイルでもエラーの有無を調べてください。最後に、テストを実行して、サーバー・プロセスが停止しているかどうかと、障害時にトレース・ファイルが生成されたかどうかを確認してください。

ORA-02100からORA-04099

⇧ はい、出ました!

ORA-03113 "通信チャネルでend-of-fileが検出されました" エラーは通常 Oracle データベースに接続するクライアント・プロセスによって報告される一般的なエラーです。このエラーは基本的には 'Oracle シャドウ・プロセスと通信できません' という意味です。このような一般的なエラーは何が起きたのかを判断するために、より詳細な情報を収集する必要があります。- このエラー自体は問題の原因を示すものではありません。例えば、ORA-03113 は次のようなシナリオで発生します。:

  • サーバー・マシンがクラッシュした
  • サーバー・プロセスが O/S レベルで kill された
  • ネットワークの問題
  • Oracle の内部エラー (ORA-600 / ORA-7445) / サーバー上で異常終了
  • クライアントが不適切に複数の接続を処理した
  • など、多くの考えられる原因があります!!

マスターノート: ORA-03113 のトラブルシューティング

⇧『など、多くの考えられる原因があります!!』って力強く言ってくる、イラっとするやつですね。

というか「alert.log ファイルでもエラーの有無を調べてください。」って言ってるから「alert.log」確認してみたけど、「RMAN(Recovery Manager)」の手動実行を経由してるからなのか分からんけれど、「alert.log」に何の情報も残されてないしね!

(「alert.log」が「$ORACLE_BASE/diag/rdbms/[SID]/[SID]/trace/alert_[SID].log」のことを指してるとしての話だけど)

「RMAN(Recovery Manager)」のドキュメントを見た感じ、

docs.oracle.com

⇧ 何となく、「RMAN(Recovery Manager)」コマンドの実行結果ってデフォルトだと、「ログファイル」に出力されない仕組みなんじゃないの?

だとしたら、「ORA-03113」に記載されてる「措置」が間違ってるのかね?

そもそもとして「RMAN(Recovery Manager)」は、「バックアップおよびリカバリ」のドキュメントとして紹介されてるのに、デフォルトでログファイルに出力するようになっていない仕様とかどうなのかね...

結局のところ、「RMAN-06900」「RMAN-06901」「ORA-03113」が同時に表示された場合は、「措置」としては何もしなくて良い、として良いのかが分からんな...

モヤモヤ感が半端ない...

いや~、何かいろいろ疲れますね...

今回はこのへんで。