ダメンDBが遭遇したいくつかの障害
- パイプライン接続のタイムアウト
「パイプライン接続のタイムアウト」の問題は、プロンプトが非常に少ないために不可解です。特にオンラインの方法では解決できない場合は、さらにわかりにくいです。この問題は、次の2つの側面からも調査できます
。1）DMAPServiceが閉じている場合は、ケース1を参照してください
。2）DM7がrootとともにインストールされている場合は、ケース2を参照してください。
1.1。ケース1、エラーメッセージに「DM_PIPE_DMAP_RD」または「DM_PIPE_DMAP_WR」が含まれています。
これは主に、DmAPServiceの「データベースプラグインサービス」が
オフになっているためです。DmAPServiceサービスを閉じると、「/ dm7 / bin / DM_PIPE_DMAP_WR」と「 / dm7 / bin / DM_PIPE_DMAP_RD "これら2つのファイル。ただし、バックアップを実行する場合、dmrmanはこれら2つのファイルが正しく機能する必要があります。ファイルが存在しない場合、前述のエラーが報告されます。したがって、バックアップのためにdmrmanを呼び出すときは、DmAPServiceサービスを閉じないでください。閉じている場合は問題ありません。DmAPServiceを開始すると、これら2つのファイルが自動的に作成されます。次に、dmrmanバックアップの実行を再試行すると、正常に実行できます。
1.2。ケース2の場合、エラー「パイプ接続タイムアウト」のみ
が報告されます。DmAPServiceサービスが閉じられていない場合、エラーメッセージは次のように非常に単純になります。
解決策：su-dmdbaを実行してから、dmrmanを実行します。
理由分析：この状況は、インストールプロセス中にroot権限が混在して使用されていることが原因である可能性があります。
さらに観察すると、DM7がrootの下にインストールされると、インストールプログラムが自動的にdmdbaアカウントを作成することがわかります（何度も試した後、パスワードが空であることがわかりました）。ルートを介してdmdbaパスワードを強制的に変更した後にdmrmanを実行すると、おめでとうございます。3番目のピット（後述）に陥ろうとしています。
この時点で、su-dmdbaコマンドを実行する必要があります。その結果、異常な状況が発生しました。以前の[dmdba @ xxx] $は、もはや馴染みのないものでしたが、
これはよりブラフですが、ほとんど効果がありません。-sh-4.1 $が表示されるのは、主に、インストール中に空のディレクトリ/ home / dmdbaのみが作成され、その下に構成ファイルがないためです。成功したバックアップの完了に大胆dmrmanのコマンドを実行します
。1.3をdmdbaパスワード変更の結果
、問題を解決する過程で、私はまたのsu -dmdba方法を試してみましたが、不思議な初めに困惑した
そうで、ログアウト、スイッチユーザーは、操作するためにdmdbaアカウントを入力したいと考えています。しかし、複数のパスワードを試したところ、ログインできませんでした。次に、root-> passwd dmdbaに切り替えて、パスワードを変更しました-> su again-dmdba、パスワードを入力させなかったことがわかりました。！奇妙な始まりが再び現れました。さて、ログアウトして、dmdbaと入力し、dmrmanを実行します。驚いたことに、「パイプタイムアウト」は消えましたが、新しいエラーが発生しました。dmdbaのパスワードを変更すると、su-dmdbaがルート化されていても、dmrmanを再度実行しても効果がなく、次のエラーが報告されます。
したがって、パスワードを変更すると、解決策を見つけるのは簡単ではありません。
1.4。
「DM_PIPE_DMAP_RD」と「DM_PIPE_DMAP_WR」の役割2つのファイル「DM_PIPE_DMAP_RD」と「DM_PIPE_DMAP_WR」には、DmAPServiceにとって興味深い現象があります。
オペレーティングシステムが予期せずシャットダウンした場合、これら2つのファイルは残ります。次に、DmAPServiceの開始に失敗します。「パイプラインファイルはすでに存在します」というエラーメッセージが表示されます。この場合、「/ dm7 / bin / DM_PIPE_DMAP_WR」と「/ dm7 / bin / DM_PIPE_DMAP_RD」を手動で削除するだけで、DmAPServiceを正常に起動できます。起動後、これら2つのファイルが自動的に作成されます。
dmrmanは、実行中にこれら2つのファイルを読み取る必要があります。以前にDmAPServiceを閉じると、「DM_PIPE_DMAP_RD」と「DM_PIPE_DMAP_WR」が自動的に削除されます。その結果、dmrmanは正常に実行できず、「状況1」に示すようなエラーが報告されます。DmAPServiceを開始すると、これら2つのファイルが自動的に作成されます。dmrmanを再度実行しても、エラーは報告されません。
1.5。原因「DM_PIPE_DMAP_RD」と「DM_PIPE_DMAP_WR」が残ります。
サービスマネージャを介してDmAPServiceを閉じると、2つのファイル「DM_PIPE_DMAP_RD」と「DM_PIPE_DMAP_WR」が自動的に削除されます。ただし、仮想マシンの電源が突然オフになったり、DmAPServiceを停止せずに手動でシャットダウンしたりすると、これら2つのファイルも取り残されます。したがって、正しいシャットダウン姿勢は次のとおりです。DmAPServiceサービスを停止し、仮想マシンをシャットダウンします。
1.6。「DM_PIPE_DMAP_RD」と「DM_PIPE_DMAP_WR」が残って
いますが、インターフェイスのバックアップ時にパイプラインのタイムアウトが発生する問題は何ですか。この場合、2つの解決策があります：
1）この記事の前述の方法
2）それが機能しない場合は、バックアップインターフェイスの「UseDMAP」方法を削除してください。
- データベースの復元後にインスタンスを起動できない
2.1。解決策
インスタンスを起動できない理由は、データベースの復元後に次のファイルアクセス許可がrootに設定され、dmdbaにアクセスできなくなるためです。chown dmdba：dinstall / xxxを使用して、次のディレクトリをdmdbaの開始権限として設定します（データベースディレクトリは「/ dm7 / data / DM01 /」）：
chown dmdba：dinstall /dm7/data/DM01/DM0101.log
chown dmdba：dinstall /dm7/data/DM01/DM0102.log
chown dmdba：dinstall /dm7/data/DM01/dm_service.prikey
chown -R dmdba：dinstall / dm7 / data / DM01 / HMAIN
chown dmdba：dinstall / dm7 / data / DM01 / MAIN .DBF
のchown dmdba：dinstall /dm7/data/DM01/ROLL.DBF
のchown dmdba：dinstall /dm7/data/DM01/SYSTEM.DBF
。2.2理由分析
次のように復元する前にディレクトリ権限がある：
ディレクトリのアクセス許可を復元した後、以下の通りである：
比較して、前述の7つのファイルとディレクトリのアクセス許可がrootに設定されていたため、DBサービスがキーファイルにアクセスできず、起動できなかったことがわかりました。 - 復元後に増分バックアップできない
場合の解決策は、2.1と同じです。