1

(長い説明が嫌いな場合は、以下の私の質問を読んでください)

非協力的なベンダーによって販売されている一部のソフトウェアで問題が発生しています(残念ながら、この製品の唯一の顧客です)。ソフトウェアのプラットフォームはOracleです。夜間、アプリは一連の夜間プロセスを実行します。場合によっては、夜間のプロセスの一部がクラッシュし、スクランブルしてデータベースを復元し、次の夜まで作業を引き継ぐことがあります。もちろん、これはユーザーの心痛を引き起こし、ITに至るまで管理に細流になります。私たちはベンダーを非難し、彼らは私たちを非難しています。少なくとも、問題を特定するのに役立つログを追加しておくと便利です。

考えられる問題をいくつか絞り込みました。奇妙なことに、失敗の直前からバックアップを復元し、テストボックスで夜間のプロセスを再実行すると、失敗することはありません。したがって、これにより、次のいずれかを信じることになります。

  • まだ検出されていないテストボックスと本番ボックスの違い
  • ソフトウェアで何か奇妙なこと
  • エクスポート前の本番データと復元されたデータとの違い
  • ??

それは私の待望の質問(上記の「C」に関する)に私を導きます:

本番データがバックアップデータ(「exp」を使用してコマンドラインから取得)と異なる原因となるものはありますか?

私は疑わしいと思いますが、上記のオプションの1つを削除したかっただけです。

4

1 に答える 1

0

これは、imp/exp の動作が原因であるとは考えられません (ただし、imp/exp はデータを適切に適切にロードし、新しいインデックスを作成するため、テスト データベースのパフォーマンスが向上し、アプリケーション メモリ リークの蓄積が回避される可能性があります)。 . テスト データベースとアプリケーションの初期状態はクリーンで競合がない可能性が高いですが、本番システムは終日実行されているため、別の状態 (メモリにさまざまなものがロードされている) になる可能性があります。一部のプロセスをブロックし、アプリケーションが失敗する原因となる他のプロセスを実行している。

プロセスを実行する前に、データベースとアプリケーションを閉じて再起動しようとする場合があります。これにより、テストと同じ開始点が得られます。ここでの問題を解消するために、運用環境でインデックスや統計などを再構築することをお勧めします。また、アプリケーションを介して、または同じデータベースで実行されている他のものから、プロセスと競合する可能性のある他の作業を排除する必要があります。

Oracle がクラッシュせず、アラート ログに問題がない場合は、アプリケーションに問題があり、調査が必要です。メモリまたはプロセスの問題についてアプリケーション サーバーを監視し、ベンダーに何が起こっているかのログを取得してもらいます (ベンダーが Oracle エラーについて心配している場合は、これが必要であることを伝えます)。

于 2012-09-12T07:56:36.593 に答える