太陽光で「30分で海水を真水にする」技術。水不足解決のカギとなるか | Forbes JAPAN（フォーブス ジャパン）
太陽光で「30分で海水を真水にする」技術。水不足解決のカギとなるか | Forbes JAPAN（フォーブス ジャパン）
⇧「有機金属構造体（MOF：Metal Organic Framework）」が稀少なものであれば、いくら「太陽光」が半永久的なエネルギー源とみなせるとしても、水資源を得るためのコストが高騰して、水の価格が上昇するような事態になれば、結局のところ本当に水を必要としている人が手に入れることは難しいのではないか、と関係ないことを思ってしまった今日この頃、どうもボクです。
何にせよ、技術が発展することは喜ばしいことですね。
というわけで、「Oracle Database」についてです。
レッツトライ～。
Oracle Database 19cに接続できない、インスタンスが起動して無かったらしい...
久々に、「Oracle Database 19c」に接続を試みたところ（フリーソフトの「A5:SQL Mk-2 」を使ってます。バージョンは、2.15.4で、「ポータブル版」にしてます）、
⇧ 接続できません！
ただ、これは、「A5:SQL Mk-2 」が悪いわけではなく、なぜならば、「ORA-12514」っていうエラーメッセージを「Oracle Database 19c」側で提示してくれてるからですね。
試しに、sqlplusで接続を試みると、
⇧ また、別のエラーメッセージが表示されますと。「ORA-01034」ってエラーメッセージが表示されておりますと。
そもそも「アイドル・インスタンス」ってなってるんだけど（「アイドル・インスタンス」については後述）、「インスタンス」が起動していないってことらしい。
ただ、Windowsの「サービス」一覧を確認した限り、「Oracleリスナー」とかは動いてるんだわさ。
その前に「アイドル・インスタンス」とか「インスタンス」とか、いまいち何なのそれ？って感じな情弱な私ですと。
というわけで、そもそもの「Oracle Database」の仕組みについて整理してみようと。
Oracle Databaseのインスタンスって何？
Oracleさんが「Oracle Database」についてめっちゃイメージしやすい情報をまとめたブログを公開してくれてくださっているのを見つけることができました。
Oracleさんのブログの内容によりますと「Oracle Database」のインストールについては、
Oracle Databaseは単一サーバーで実行するシングル・インスタンスの構成と、複数のサーバーが共有ディスクとインターコネクト・ネットワークを介して協調動作するOracle Real Application Clusters（RAC）の構成があります。RAC構成の場合、Oracle Databaseのソフトウェアをインストールする前にOracle Grid Infrastructureのソフトウェアをインストールします。クラスタ構成のOracle Grid Infrastructureは、クラスタを構成するノードを確定させるノード・メンバシップの管理やOracle Automatic Storage Management（ASM）の構成、そしてOracleインスタンスやOracleリスナーの死活監視の役割を担います。
⇧ 大きく分けて、
の2パターンが存在するみたいですと。 （あたしは、「シングル・インスタンス構成」でインストールしておるということになりそうです）
で、「シングル・インスタンス」「Oracle Real Application Clusters（RAC）」のいずれについても、「Oracle Database」というもの自体の内容は変わらないと仮定して、「Oracle Database」の構成はというと、
データベース名とインスタンス名もデータベースを作成するときに指定する要素です。Oracle Databaseの文脈で「データベース」というのは、ストレージ上に構成されたオンラインREDOログ、制御ファイル、データファイルの集合のことを指します。これに対し「インスタンス」というのは共有メモリー領域（System Global Area）とバックグラウンド・プロセス群のことを指します。
⇧ とあるように、
という構成なんだと。
はい、出ました「インスタンス」。
つまり、「Oracle Database」って言った場合は、「インスタンス」「データベース」の両方のことを言ってるんだな、ってことになるんではないかと。
ちなみに、
RACの場合は1つのデータベースを複数のノードの複数のインスタンスがマウントします。RACのインスタンス名はクラスタ内で一意になっている必要があるため、インスタンス名はSID接頭辞に1、2、...というように数字が付加されます。
⇧ とあるように、「Oracle Real Application Clusters（RAC）」構成の場合は「インスタンス」が複数になるみたいね。
データベース接続の仕組み
で、「インスタンス」「データベース」によって構成されてるのが「Oracle Database」ということで、実際に「データベース」へ接続するには？
OracleリスナーとはTCP/IP経由の接続リクエストを処理するプロセスであり、Oracleインスタンスのプロセス群とは独立しています。SQL*PlusなどのOracleクライアントはこのOracleリスナーに対して接続リクエストを発行することになります。
基本からわかる！高性能×高可用性データベースシステムの作り方 第3回 ネットワーク経由で接続 | Oracle Technology Network Japan Blog
⇧ とあるように、「Oracleリスナー」ってものに対して「接続リクエスト」を発行することで「データベース」に接続できますと。
そして、「Oracleリスナー」と「Oracleインスタンス※」 はプロセスはそれぞれ独立していますと。
※以降、「Oracleインスタンス」と「インスタンス」は同義として考えます。（「Oracleインスタンス」と「インスタンス」が一緒かどうかをOracleさんは明示してくれてないので、あくまで、あたしがそう思っただけなので間違ってる可能性が大いにあり得ます。身近の有識者の方に確認しましょう）
つまり、「Oracleインスタンス」が止まっていようが、「Oracleリスナー」が動き続けることはあり得ますと。
話を「データベース」への「接続」に戻すと、
⇧ というように、「Oracle Database」ってのは「クライアント・サーバー」モデルでということのようですが、
⇧ というように「接続モード」というものがあるらしく、
- 専用サーバー・モード
- 共用サーバー・モード
- Database Resident Connection Pool（DRCP）
の3つがあるみたいですね。
で、「専用サーバー・モード」「共用サーバー・モード」については、
⇧ とあるように、イメージ図を見た感じでは「インスタンス（Oracleインスタンス）」経由でないと「データベース」に接続できないっぽいですね。
上図のオレンジ色の「Oracle」は「Oracle サーバー・プロセス」というものらしいです。（「サーバー・プロセス」については後述）
アイドル・インスタンスってどういうこと？
で、ようやく本題。
今回、「sqlplus」で「インスタンス」に「接続」を試みてるってことなんだと思うんだけど、『アイドル・インスタンスに接続しました。』ってなったわけなんですと。
で、「アイドル・インスタンス」って何？
Answer by Mark:
"Connected to an idle instance" usually means that you connected "AS SYSDBA" and the instance you connected to is not started.
⇧ というわけで、「インスタンス」が起動してないよ、ってことみたい。
ややこしいんだけど、「インスタンス」は起動してないけど「インスタンス」には「接続」できてる状態らしい。
「アイドル・インスタンスに接続しました」は、インスタンスが起動していない状態でインスタンスへ接続する（実際には「接続しよう」とする）と表示されるメッセージです。
なお、インスタンスが起動していない状態でインスタンスに接続できるのは、SYSDBA 権限またはSYSOPER 権限を指定した場合のみです。これらの権限を指定しなかった場合は ORA-01034 が発生してインスタンスに接続できません。
⇧ 上記サイト様によりますと、「SYSDBA権限」「SYSOPER権限」以外だと「アイドル・インスタンス」へは「接続」できずに「ORA-01034」が発生するみたい。
つまり、「インスタンス」から「データベース」への接続が断絶してる状態のようですと。
インスタンスを起動すれば良いんでしょ？からの「ORA-03113: 通信チャネルでend-of-fileが検出されました」
何のこっちゃない、「インスタンス」を起動すれば良いんでしょ？
で、「sqlplus」にて「SYSDBA権限」で「アイドル・インスタンス」に接続して「インスタンス」の起動を試みるも、
⇧ はい、出ました。
「ORA-03113: 通信チャネルでend-of-fileが検出されました」が出てきたよ...
Oracleさんの見解によりますと、
ORA-03113 "通信チャネルでend-of-fileが検出されました" エラーは通常 Oracle データベースに接続するクライアント・プロセスによって報告される一般的なエラーです。このエラーは基本的には 'Oracle シャドウ・プロセスと通信できません' という意味です。このような一般的なエラーは何が起きたのかを判断するために、より詳細な情報を収集する必要があります。- このエラー自体は問題の原因を示すものではありません。例えば、ORA-03113 は次のようなシナリオで発生します。:
- サーバー・マシンがクラッシュした
- サーバー・プロセスが O/S レベルで kill された
- ネットワークの問題
- Oracle の内部エラー (ORA-600 / ORA-7445) / サーバー上で異常終了
- クライアントが不適切に複数の接続を処理した
- など、多くの考えられる原因があります!!
⇧ う、う～ん...
『など、多くの考えられる原因があります!!』って力強く言われてもね...
結局、原因がよく分からんというやつですね、「エラーメッセージ」の意味ないな～...
そも「Oracle シャドウ・プロセス」って何ぞ？
専用サーバー・プロセスはクライアント・プロセスとは別のものであり、クライアント・プロセスのかわりとしてのみ動作します。
⇧ というように、「専用サーバー・プロセス」のことを「シャドウ・プロセス」と言うらしいですと。
「専用サーバー・プロセス」はというと、
⇧ 上図によりますと、「Oracle Database」の「インスタンス」内で生成される「プロセス」ってことらしいんだけで、「クライアント・プロセスのかわりとしてのみ動作します」ってのが、いまいちよく分からん...
そも、「Oracle Database」における「プロセス」とは？
プロセスは一連の処理を実行できるオペレーティング・システムのメカニズムです。
プロセス実行のアーキテクチャは、オペレーティング・システムによって決まります。たとえば、Windowsでは、Oracleバックグラウンド・プロセスはプロセス内の実行スレッドです。LinuxおよびUNIXにおけるOracleプロセスは、オペレーティング・システム・プロセスか、またはオペレーティング・システム・プロセス内部のスレッドです。
⇧「Oracle Database 12c」のドキュメントによると、「OS（Operation System）」によって変わってきますと。
⇧ ってことらしく、
「プロセス」としては、
- クライアント・プロセス
- Oracleプロセス
- バックグラウンド・プロセス
- サーバー・プロセス
- スレーブ・プロセス
という感じで、大きく分けて「クライアント・プロセス」「Oracleプロセス」の2つあり、「サーバー・プロセス」は「Oracleプロセス」の中の1つという位置づけらしい。
「サーバー・プロセス」は何なのかというと、
⇧ ってことみたいね。
「専用サーバー・プロセス」のことを「シャドウ・プロセス」というってことでしたが、「サーバー・プロセス」の特殊版ってことだとは思われます。（「サーバー・プロセス」と「シャドウ・プロセス」の違いについては、よく分からんです...）
脱線しましたが、「ORA-03113: 通信チャネルでend-of-fileが検出されました」でのOracleさんの見解は、
『このエラーは基本的には 'Oracle シャドウ・プロセスと通信できません' という意味です。』
ということなので、『「インスタンス」起動したって言ってるのに、「Oracle シャドウ・プロセス」と通信できない？何でやねん！』っていうツッコミを入れたくなるよね...
というか、そもそも「Oracle シャドウ・プロセス」が動いてるのかすら分からんというね...
ちなみに、「Oracle シャドウ・プロセス」は「シャドウ・プロセス」と同義ということで良いんだろうか？と思いましたが、Oracleさんのドキュメントを見る限り「Oracle シャドウ・プロセス」と「シャドウ・プロセス」が同じことを指していると特に明示してくれてるわけではないので、「Oracle シャドウ・プロセス」と「シャドウ・プロセス」は同じものを指してるんだよね、ってのは、あくまで、知見の無いあたしの推測です。（身近な有識者に確認しましょう。）
エラーログを見てみる
ちょっと、「sqlplus」で表示されるエラーを見ても全く役に立たないので、他に何か分かる情報がないか確認してみる。
Oracleのアラートログですが、11g以降(12c,18c,19c)は以下の場所に存在します。
$ORACLE_BASE/diag/rdbms/<SID>/<SID>/trace/alert_<SID>.log
※$ORACLE_HOME 配下ではないことに注意してください。
⇧ 上記サイト様を参考に、「アラートログ」の内容を確認してみる。
自分の環境では、「C:\app02\app\ts0818\diag\rdbms\orcldb\orcldb\trace\alert_orcldb.log」ってのが存在しておりました。
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: リカバリ・ファイルの制限を超えています」と「高速リカバリ領域（旧：フラッシュリカバリ領域）」
で、調べた感じでは、
どうやら「フラッシュリカバリ領域」が不足している事が原因でエラーが発生している様です。
ORA-03113 end-of-file on communication channelエラーの対処 – Rainbow Planet
⇧ 上記サイト様の現象と同じでありそうな感じでしたと。
「フラッシュリカバリ領域」とは？
手前味噌で恐縮ですが、
⇧ というか、自分が10ヵ月ぐらい前に同じ現象に遭遇してましたですね...いやはや、すっかり忘却の彼方でした、「未来の自分は他人」という言葉がありますが、備忘録は残すようにしておくことは大切ですね。
で、「フラッシュリカバリ領域」と「高速リカバリ領域」の関係が分からないんですが、おそらく、Oracle Database 12cとかで「フラッシュリカバリ領域」って呼ばれてものが「高速リカバリ領域」って呼ばれるようになったんじゃないかと推測してます。
で、「フラッシュリカバリ領域」もとい「高速リカバリ領域」とは？
（以降、「高速リカバリ領域（旧：フラッシュリカバリ領域）」と記載してますが、あくまで知見の無いあたしの推測です。）
CREATE DATABASEを実行すると、表領域を構成するデータファイルと制御ファイル、オンラインREDOログ・ファイルが作成されます。データファイルとオンラインREDOログ・ファイルの位置は制御ファイルに記録されています。そのため、これらのファイルを移動させたい場合、単純にOSのファイル移動コマンドで移動させただけではデータベースをオープンできなくなります。これらのファイルを移動させるには、物理的にファイルを移動させるだけでなく、ALTER DATABASE文で制御ファイルの内容も変更する必要があります。
データベースを構成するファイルを移動させるのは煩雑な手順が必要であるため、データベースを格納するストレージ領域についてはよく検討しておく必要があります。CREATE DATABASEを実行する前に、データベースを格納する領域と、高速リカバリ領域（Fast Recovery Area）となるファイルシステムやASMディスク・グループを構成しておきます。
⇧ という感じで、「データベース」を作成すると、上図のようなファイル群が作成されるようなのですが、「高速リカバリ領域（旧：フラッシュリカバリ領域）」は、
⇧ 「アーカイブREDOログ」「RMANバックアップ・ファイル」「フラッシュバック・ログ」が格納される領域ということで、デフォルトだと「DB_RECOVERY_FILE_DEST」に配置される部分ってことなんですかね？
高速リカバリ領域（DB_RECOVERY_FILE_DEST）はデータベースが破損した場合に備えるための領域であるため、データベースを構成する領域（DB_CREATE_FILE_DEST）とは物理的に別のストレージ・デバイスに格納すべきです。
⇧う、う～ん...
「物理的に別のストレージ・デバイス」っていうのがよく分からんのだけど、
Windows OSでハードディスクやSSDのようなストレージデバイスを利用する場合、通常はデバイス上にNTFSやFATなどの論理的な「ファイルシステム」を構築して、その中にデータを保存する。ディスクの物理的な構造やサイズ、形態などとは独立したファイルシステムを使うことにより、デバイスに依存せず、柔軟でポータビリティのある形でデータを保存したり、他のシステムとデータを交換したりできる。
ストレージデバイスにはさまざまな種類があるが、Windows OSでは全てランダムアクセス可能なブロック型のストレージ（一定サイズのブロックを単位としてデータの読み書きを行うタイプのストレージデバイス）として扱う。これにより、OSから見るとどれも同じ手段でアクセス、管理できるようになる。
⇧ ってことだとすると、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のドキュメントの内容だけど）、
RMANの保存方針によって高速リカバリ領域のディスク割当て制限より大きいバックアップのセットを保存する必要がある場合、またはこの保存方針がNONEに設定されている場合、高速リカバリ領域は再利用可能な領域がなくなるまで完全に一杯になることがあります。
再利用可能な領域が15%未満になると警告アラートが発行され、再利用可能な領域が3%未満になるとクリティカル・アラートが発行されます。この状況をDBAに警告するために、アラート・ログおよびDBA_OUTSTANDING_ALERTS表(Enterprise Managerで使用)にエントリが追加されます。ただし、高速リカバリ領域内の領域は、再利用可能な領域がなくなるまでデータベースによって継続して消費されます。
⇧ いやいやいや、有り得ない...
どう考えてもこの仕様はおかしいでしょ...
っていうか、「再利用可能な領域がなくなるまでデータベースによって継続して消費されます」って、正気ですか？
Oracleさんの闇を垣間見た気がするんですが...
恐ろし過ぎるんですけど...
何、この時限爆弾を抱えたかのような気持ちで使わないといけないって、データベースってこんな部分で精神をすり減らさなければいけないほど、精神衛生上宜しくないものなんでしたっけ？
で、Oracleさんが提示する対応アプローチとしては、
削除対象のファイルがない場合に高速リカバリ領域が一杯になった状態を解消する方法として、次のいくつかの方法があります。
-
使用可能なディスク領域を追加し、
DB_RECOVERY_FILE_DEST_SIZEを増加して、追加した領域を反映させます。 -
高速リカバリ領域からテープなどの3次ストレージ・デバイスにバックアップを移動します。
リカバリ領域のすべてのファイルを一度にテープにバックアップする簡単な方法の1つに、
BACKUPRECOVERYAREAコマンドがあります。バックアップをリカバリ領域からテープに転送した後、高速リカバリ領域からファイルを削除できます(「RMANバックアップおよびアーカイブREDOログの削除」を参照)。フラッシュバック・ログは、リカバリ領域外にはバックアップできないため、BACKUPRECOVERYAREAではバックアップされません。 -
オペレーティング・システム・ユーティリティを使用して削除されたファイルに対しては、
DELETEを実行します。ホスト・オペレーティング・システムのコマンドを使用してファイルを削除した場合、その結果できる空き領域はデータベースでは認識されません。RMANの
CROSSCHECKコマンドを実行して、高速リカバリ領域の内容を再確認し、期限切れのファイルを特定した後、DELETE EXPIREDコマンドを使用して、RMANリポジトリからすべての期限切れのバックアップを削除することができます。 -
保証付きリストア・ポイントが必要であることを確認します。必要ない場合は、「リストア・ポイントの削除」の説明に従って削除します。
保証付きリストア・ポイントで必要ないフラッシュバック・ログは、高速リカバリ領域内の他のファイルの領域を確保するために自動的に削除されます。保証付きリストア・ポイントを使用すると、リストア・ポイントSCNまでフラッシュバック・データベースを実行するために必要なフラッシュバック・ログを強制的に保存できます。
-
バックアップ保存方針を確認します。Data Guardを使用している場合は、アーカイブREDOログの削除方針も確認します。
⇧ 上記のような感じらしい。
まぁ、「不要ファイルを削除」を実施していく感じになるかと。
それにしても、なんだろう、「Oracle Database 19c」についても、この恐ろしい仕様（「再利用可能な領域がなくなるまでデータベースによって継続して消費されます」）を引き継いでいるんだろうか...
悲報...
RMANの保存方針によって高速リカバリ領域のディスク割当て制限より大きいバックアップのセットを保存する必要がある場合、またはこの保存方針がNONEに設定されている場合、高速リカバリ領域は再利用可能な領域がなくなるまで完全に一杯になることがあります。
再利用可能な領域が15%未満になると警告アラートが発行され、再利用可能な領域が3%未満になるとクリティカル・アラートが発行されます。この状況をDBAに警告するために、アラート・ログおよびDBA_OUTSTANDING_ALERTS表(Enterprise Managerで使用)にエントリが追加されます。ただし、高速リカバリ領域内の領域は、再利用可能な領域がなくなるまでデータベースによって継続して消費されます。
⇧ 「Oracle Database 19c」でもまったく変わっていないぃぃぃぃぃぃぃ～！
きっと、夢を見てるんだ...そうだ、起きなきゃ...
...って、現実なんですけど～！
わ、分からん...
データベース業界では、これが当たり前な仕様なんだろうか...
RMAN（Recovery Manager）の実行が失敗するんだけど...
とは言え、「RMAN（Recovery Manager）」で不要ファイルを一掃すれば、万事解決、こうして幸せに暮らしましたとさ、めでたしめでたし、で大円団を迎える展開が待ち受けてる、という優しい世界の話になってる、で良いんでしょう？
おりゃ～！
⇧ ...
駄目やんけ～！！！
前提条件
RMANがターゲット・データベースに接続していて、そのデータベースがマウントまたはオープン状態である必要があります。
https://docs.oracle.com/cd/F19136_01/rcmrf/DELETE.html#GUID-FB4EAC69-4978-42F7-8B09-77C6736188B3
⇧ しょ、衝撃なんですけど...
「データベース」が動いてないようだから動くようにするために、不要なファイルを削除しなきゃならんのにと思ったんですが、不要なファイルを削除するために使用する「RMAN（Recovery Manager）」コマンドの「前提条件」が、「データベースがマウントまたはオープン状態である必要があります」だと！
「インスタンス」は起動してるっぽいんだけど、「データベース」は動いてないってことだと思ったんだけど、
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
ってことなんですが、
⇧ 上記サイト様によりますと、「アーカイブログのモードを一旦リセット」すればいけるよ、とのこと。
ポイントは、startup mount
ここで、ポイントとなってくるのが、「startup mount」を実行することらしいです。
STARTUPコマンドでMOUNT句を指定すると、データベースをマウントし、オープンしない状態でインスタンスを起動できます。このモードで起動するのは、特定のメンテナンス操作を行う場合です。
⇧ とすることで、「データベース」は起動しないんだけど、「インスタンス」からの「接続」はできる状態にできるってことみたいです。
startup openと入力すると、異常のあるREDOログおよびアーカイブログが読み込まれ、マウントした直後に「ORA-03113:通信チャネルでend-of-fileが検出されました」というエラーが発生し、それ以降exitするまでうまくいかなくなるため、mount状態でいったんとめます。
Oracle DB起動時にエラーORA-01034・ORA-27101が出て起動しない際の対処法 | データベース アクセス ブログ
⇧ 上記サイト様にありますように、「ORA-03113: 通信チャネルでend-of-fileが検出されました」のエラーが起こることを回避できるようです。
では、改めまして、
「データベース」を起動！
⇧ 館長、「データベース」が起動しました！
別にコマンドプロンプトを起ち上げて、「rman」コマンドを実行していきます。
「RMAN（Recovery Manager）」で「データベース」に接続できたら、「アーカイブログ」を一掃します。
確認したころ、
⇧ すべて、跡形もなく消え去ったようです。
ですが、
⇧ ディレクトリが残ったままなんすけど...
RMANコマンドを使用してバックアップまたはアーカイブREDOログ・ファイルを削除する場合、RMANは次の処理を実行します。
-
オペレーティング・システムから物理ファイルを削除します(ファイルが存在する場合)。
-
制御ファイル内のファイル・レコードのステータスを
DELETEDに更新します。
制御ファイルのデータは内部構造に格納されているため、RMANは、制御ファイルからレコードを削除できず、レコードのステータスをDELETEDに更新するのみです。ただし、カタログ表は通常のデータベース表であるため、表から行が削除される場合と同様に、カタログ表から行が削除されます。
⇧ う、う～ん...
ドキュメントにも「アーカイブREDOログ」を格納してた「ディレクトリ」については一言も言及されてない...
何だろう、物理削除すれば良いんかな？
とりあえず、分からんけど、「RMAN（Recovery Manager）」でどうにかできそうにないっぽいので、「物理削除」するで。
きれいになりました。
「高速リカバリ領域」を設定し直す？
「Oracle Database」の「高速リカバリ領域」の仕様上、何度も同じ現象を迎えそうな感じなので、設定でどうにかできるもんなのか調べてみました。
「Oracle Database」のことは門外漢なので、何とも言えませんが、
⇧ おそらく、上記の2つのファイルで設定するしか無さそうな感じですかね。
- サーバー・パラメータ・ファイル（SPFILE：Server Parameter FILE）
バイナリファイル形式。データベースに接続して設定。 - 初期化パラメータ・ファイル（PFILE：Parameter FILE）
テキストファイル形式。データベースに接続して無くても設定可。インスタンスの再起動しないと設定変更は反映されない。
ってことだと思います。
で、その設定ファイルって、どこにあんのよ？
⇧ ってな感じで、「UNIX and Linux」と「Windows」で配置場所が変わるみたいなんだけど、「Windows」の場合のデフォルトの配置場所は、
- サーバー・パラメータ・ファイル（SPFILE：Server Parameter FILE）
- 初期化パラメータ・ファイル（PFILE：Parameter FILE）
Oracle_Home\database
ってことみたい。
⇧ っていうか、「初期化パラメータ・ファイル（PFILE：Parameter FILE）」が存在しないんだが...
注意:
初期化パラメータ用の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さんのドキュメントはカオスだな～。
話が脱線しましたが、
パラメータ・ファイルのパラメータ値は、いくつかの方法で変更できます。
-
初期化パラメータ・ファイルを編集する。
ほとんどの場合は、次にデータベースのインスタンスを起動したとき、新しいパラメータ値が使用されます。
-
ALTER SYSTEM SET ... SCOPE=SPFILE文を発行してサーバー・パラメータ・ファイルを更新する。 -
ALTER SYSTEM RESET文を発行して初期化パラメータの値をクリアする。
⇧ って感じなので、「サーバー・パラメータ・ファイル（SPFILE：Server Parameter FILE）」を変更していく方針で進めようかと。
⇧ ちゃんと「アラート・ログ」にも記録を残してくれるって言ってますし。
で、肝心の「変更可能なパラメーター」ってのはどんなものがあるんじゃろ？って思ったので、
⇧ 確認してみるも、
何か「高速リカバリ領域」に関する対処としては、
- DB_RECOVERY_FILE_DEST
高速リカバリ領域のデフォルトの位置を指定します。 - DB_RECOVERY_FILE_DEST_SIZE
高速リカバリ領域に作成されるターゲット・データベースのリカバリ・ファイルで使用される合計領域に対する厳密な制限(バイト)を指定します。
の2つぐらいしか無さ気なんですよね...
⇧ 上記サイト様でも、「DB_RECOVERY_FILE_DEST」「DB_RECOVERY_FILE_DEST_SIZE」の設定を行ってる感じですかね。
ちなみに、自分の設定を見てみたら、
⇧ 既に10GBに設定されていたという...
できることないやん...
いや、あれよ、パソコンのスペックがむっちゃ高くて、10GB以上割り振っても余裕よ、って人だったら、単純に「高速リカバリ領域」の容量を上げれば良い話かなとは思うんで、「DB_RECOVERY_FILE_DEST_SIZE」の値を100GBとかに増やしたりすれば良いと思うんよ。（私自身は「Oracle Database」に詳しくないので、どういうアプローチが良いのかは分かっておりません...）
自分が取りたいアプローチとしては、「高速リカバリ領域」がいっぱいになる前に、「アーカイブログ」が削除されれば良いな、って思ってたので、「アーカイブログ」とかの保存期間を調整するような感じにしたいかなと。
話が脱線しましたが、おまけに、
パラメータ・ファイルでは、これらのタイプのパラメータを指定しないでください。
⇧ 何か気になる記載が...
と思ったら、
CONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用すると、アーカイブREDOログが削除対象になる場合を指定できます。
この特定の場合、高速リカバリ領域は、ディスクまたはSBTに1回以上バックアップされているとき、またはバックアップ保存方針に従ってログが不要になったときに、リカバリ領域内のアーカイブREDOログ・ファイルを削除対象であるとみなします。
⇧ 何か「RMAN（Recovery Manager）」のほうで気になる情報が。
注意:
高速リカバリ領域を使用している場合は、保存方針が無効になっている状態でデータベースを実行しないでください。ファイルが不要とみなされないと、ファイルを高速リカバリ領域から削除できるのは、そのファイルが他のディスクの場所またはテープなどの3次ストレージ・デバイスにバックアップされた場合のみになります。このアクションによって、リカバリ領域内のすべての領域が使用され、データベースの通常の操作に影響を及ぼす可能性があります。「Oracleによる高速リカバリ領域でのディスク領域の管理方法」を参照してください。
⇧ 衝撃...
まさかの「RMAN（Recovery Manager）」側での設定があるらしい...
何これ、二重管理とかになってしまうことになるんでないの？
ボヤキが止まらないのですが、で、確認してみた。
以下が、自分の「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」ってなってたんだけど、
⇧ で「RMAN（Recovery Manager）」に設定できる値とかを見た感じでは、できることが無さ気な気がする...というか、設定できる値が見辛い...
とりあえず、一旦、「データベース」をシャットダウンして「マウント」し直します。
そしたらば、「アーカイブモード」に戻して、「データベース」を起動します。
一旦、「データベース」の接続を切断し、改めて接続し直して、「データベース」に対してコマンドを実行してみます。
⇧ 無事、「データベース」が復帰しました。
Windowsの「タスク スケジューラ」で削除するようにする
何と言うか、残念ながら「Oracle Database」側でできることは無さ気なので（パソコンのスペックが良ければ、単純に「DB_RECOVERY_FILE_DEST_SIZE」とかを大きくして「高速リカバリ領域」の容量を増やすとかできると思うけど...）、
⇧ 上記サイト様のように、Windows環境であれば、「削除バッチ」ファイルを作ってWindowsの「タスク スケジューラ」に追加して上げれば良いみたいですね。
いざいざ。
run{
# 1日以前を削除
delete noprompt archivelog until time 'sysdate-1';
# OSから削除された場合、oracle側も削除する
crosscheck archivelog all;
delete expired archivelog all;
}
で、このファイルを適当な場所に保存しますと。
自分は、「Oracle Database 19c」をインストールした時のディレクトリに配置してみました。
続きまして、コマンドを記述した上記のファイルを実施するバッチファイルを作成します。
REM アーカイブログを削除する "C:\app02\oracle\product\19.0.0\dbhome_1\bin\rman.exe" target / @del_arclog.rcv log=del_arclog.log append nocatalog
そしたらば、「タスク スケジューラ」で設定してきましょう。
⇧ 上記サイト様を参考にさせていただきました。
まずは、「タスク スケジューラ」を開きます。
「タスク スケジューラ ライブラリ」を選択した状態で右クリックし「新しいフォルダー(N)...」を選択。
「フォルダー名」を適当に付けて、「OK」で。
「タスク スケジューラ ライブラリ」内に「フォルダー」ができているので、作成された「フォルダー」を選択した状態で右クリックし、「タスクの作成(R)...」で。
「全般」タブの設定は以下のような感じにしました。続いて「トリガー」タブを選択します。
「トリガー」タブで「新規(N)...」を選択。
今回は「毎週(W)」で「土曜日(R)」「日曜日(U)」に実行するように設定してみました。時刻は「17:00:00」としました。「OK」を選択。
続きまして「操作」タブを選択し、「新規(N)...」を選択。
作成しておいた「バッチファイル」を選択。
「OK」で。
「条件」タブは何も変更してません。
「設定」タブは何も変更してません。「OK」を選択で。
普段、使用してるWindowsの「アカウント」と「パスワード」を設定しました。
「タスク」が設定されたようです。
これで、暫く様子を見てみますかね。
と思いきや、「RMAN（Recovery Manager）」でexitしたらエラーが発生...
作業を終了しようとしたら、エラー出たんだけど...
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さんが用意してくれてる「エラー・メッセージ」一覧を確認してみることに。
原因: ルーチンcreateRmanStatusRow()またはcreateRmanOutputRow()により、V$RMAN_STATUSまたはV$RMAN_OUTPUTに新規の行が追加された可能性があります。
処置: 関連するエラー・メッセージを確認してください。関連するエラー・メッセージに修正可能な状態が示されている場合は修正を実行し、そうでない場合はOracleサポート・サービスに連絡してください。
原因: これは情報メッセージです。
処置: 処置は必要ありません。
⇧ 処置が「必要なのか」「必要ないのか」、どっちやねん！
そして、「エラー・メッセージ」は、
原因: クライアント・プロセスとサーバー・プロセスの間の接続が切断されました。
措置: 通信エラーがありました。さらに調査する必要があります。最初に、ネットワークの問題の有無をチェックし、SQL*Netの設定を確認してください。また、 alert.log ファイルでもエラーの有無を調べてください。最後に、テストを実行して、サーバー・プロセスが停止しているかどうかと、障害時にトレース・ファイルが生成されたかどうかを確認してください。
⇧ はい、出ました！
ORA-03113 "通信チャネルでend-of-fileが検出されました" エラーは通常 Oracle データベースに接続するクライアント・プロセスによって報告される一般的なエラーです。このエラーは基本的には 'Oracle シャドウ・プロセスと通信できません' という意味です。このような一般的なエラーは何が起きたのかを判断するために、より詳細な情報を収集する必要があります。- このエラー自体は問題の原因を示すものではありません。例えば、ORA-03113 は次のようなシナリオで発生します。:
- サーバー・マシンがクラッシュした
- サーバー・プロセスが O/S レベルで kill された
- ネットワークの問題
- Oracle の内部エラー (ORA-600 / ORA-7445) / サーバー上で異常終了
- クライアントが不適切に複数の接続を処理した
- など、多くの考えられる原因があります!!
⇧『など、多くの考えられる原因があります!!』って力強く言ってくる、イラっとするやつですね。
というか「alert.log ファイルでもエラーの有無を調べてください。」って言ってるから「alert.log」確認してみたけど、「RMAN（Recovery Manager）」の手動実行を経由してるからなのか分からんけれど、「alert.log」に何の情報も残されてないしね！
（「alert.log」が「$ORACLE_BASE/diag/rdbms/[SID]/[SID]/trace/alert_[SID].log」のことを指してるとしての話だけど）
「RMAN（Recovery Manager）」のドキュメントを見た感じ、
⇧ 何となく、「RMAN（Recovery Manager）」コマンドの実行結果ってデフォルトだと、「ログファイル」に出力されない仕組みなんじゃないの？
だとしたら、「ORA-03113」に記載されてる「措置」が間違ってるのかね？
そもそもとして「RMAN（Recovery Manager）」は、「バックアップおよびリカバリ」のドキュメントとして紹介されてるのに、デフォルトでログファイルに出力するようになっていない仕様とかどうなのかね...
結局のところ、「RMAN-06900」「RMAN-06901」「ORA-03113」が同時に表示された場合は、「措置」としては何もしなくて良い、として良いのかが分からんな...
モヤモヤ感が半端ない...
いや～、何かいろいろ疲れますね...
今回はこのへんで。
