タグ付けされた質問 「recovery」

バックグラウンド： 最近、50以上のSQL Serverと450以上のデータベースを継承しました。毎晩のバックアップは約8 TBであり、言うまでもなく、必要以上のディスク領域を使用しています。すべてのデータベースが完全復旧に設定されており、トランザクションログがバックアップされたことがない。私はすべてのSQL Serverを調べ、夜間のバックアップのみが必要で、1日のデータ損失が許容される優先度の低いサーバーを特定しました。 質問： 多くの優先度の低いデータベースをからSIMPLEリカバリモードに切り替えていFULLます。既存のトランザクションログは切り捨てられますか（チェックポイントが作成されるとき）？既存のトランザクションログの一部は50〜100 GBです。前進するためにそれらを縮小する必要があるものを決定する上で最良のアプローチは何ですか？そんなに大きくしたくないのは明らかです。または、時間の経過とともに自然に縮小しますか（そうなるとは思いません）？

9 sql-server  backup  transaction-log  recovery 

CentOS 5.8 32ビットOSで実行されているPostgreSQL 9.1サーバーを使用していて、WALアーカイブを有効にしています。このサーバーには、databaseA、databaseB、およびdatabaseCの3つのデータベースがあります。誰かがdatabaseBの午後12時にテーブルを削除し、テーブルが削除された時刻の直前にdatabaseBを復元したいと考えています。時間は今午後3時です。 他の2つのデータベースの3時間分のデータを失うことなく、データベースBを午後12時まで復元するにはどうすればよいですか？ postgresql.conf wal_level = archive archive_mode = on archive_command = 'test ! -f /opt/pgsql/logs/%f && cp %p /opt/pgsql/logs/%f' max_wal_senders = 100 recovery.conf restore_command = 'cp /opt/pgsql/logs/%f %p' recovery_target_time = '2012-06-29 11:59:59 CEST' 午前9時にベースバックアップを実行しました pg_basebackup -h 127.0.0.1 -D /opt/pgsql/backup PostgreSQLサービスは午後3時にシャットダウンされました。

9 postgresql  backup  recovery 

SQL 2005 Express Editionを使用しています。一部の削除されたレコードを復元するために、LDFファイルからデータを読み取ります。 ApexSQLの試用版を使用してみました。サードパーティのソフトウェアを使用する代わりに、ログファイルを自分で読み取る方法を見つけようとしています。 LDFファイルからデータを読み取って回復するにはどうすればよいですか？

9 sql-server  sql-server-2005  backup  restore  recovery 

「スタンバイファイル」がない場合、SQLデータベースをスタンバイ/読み取り専用モードから回復する方法はありますか？ （ログ配布シナリオでこれをTUFファイルと呼ぶ参照がいくつかありますが、私の場合、それは手動の復元であり、スタンバイファイルにはBAK拡張子が付いていました。） 「RESTORE DATABASE foo WITH RECOVERY」を実行すると、致命的なエラーが発生します。 During startup of warm standby database 'foo', its standby file ('path\filename.bak') was inaccessible to the RESTORE statement. The operating system error was '5(Access is denied.)'. Diagnose the operating system error, correct the problem, and retry startup. 復元は少し前に行われましたが、残念ながらスタンバイファイルはバックアップフォルダーにあり、フォルダーのクリーンアップルーチンによって削除されました。他のメディアにはファイルのコピーはありません。この時点まで復元するために使用された元のバックアップもなくなりました。 幸い、これは私たちにとって大した問題ではありませんが（一時的な復元でした）、「このファイルを削除しないでください」以外に、この質問に関して他の有用な参照を見つけることができませんでした。 それが原因である場合は、データベース全体をスクリプト化するか、SSISを使用してすべてのオブジェクトを新しいデータベースコンテナーにコピーできると思います。目の前にデータベースの読み取り専用コピーがあるからです。 この問題を修正する方法はありますか？「復元」に戻して、その後の復元などを続行できるとは思いませんが、現在の状態で通常のオンラインモードに強制的に切り替えて、アクセス許可の変更、回復モードの変更、新しい完全バックアップなどを実行します。

8 sql-server  sql-server-2008  recovery  standby 

mysqlのデータディレクトリをバックアップから抽出し、古いテーブルからスキーマを取得する必要がありますが、それは別のマシンからのバックアップです。 今日、これを行う方法についてのチュートリアルを多数読んでいますが、失敗するように見えるたび、またはmysqlがハングまたはクラッシュするためにmysqlを再インストールする必要があります。私は以下を試しました： 別のデータベースを作成する そのデータベースに同じ名前のテーブルを作成する ファイルを置き換える エンジンの停止/開始 .frmファイルから回復する いろいろな順番や組み合わせで試してみました。 .frmファイルからスキーマを抽出できる外部ツールはありますか？ファイルを開くと、列名が表示されます。私は一見したが、これを可能にする何かを見つけることができないようです。 前もって感謝します。

8 mysql  innodb  schema  recovery