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

データベースの再構築。

1
データベースの単純または完全復旧モデル？
いつ完全復旧モデルを使用する必要があり、いつデータベースの単純復旧モデルを使用すればよいですか？ デフォルトであるため、常に完全復旧モデルを使用しましたが、今日このエラーが発生しました： SQL Server用Microsoft OLE DBプロバイダー（0x80040E14）データベース 'DATABASE NAME'のトランザクションログがいっぱいです。ログ内のスペースを再利用できない理由を確認するには、sys.databasesのlog_reuse_wait_desc列を参照してください。 特定のデータベースは、実際にはサーバー上で最小かつ最も非アクティブなデータベースの1つであるため、他のデータベースではなく、このデータベースでログがいっぱいになる方法がわかりません。 ログを圧縮してデータベースに再度アクセスできるようにするには、次のコマンドを使用して、復旧モデルをFULLからSIMPLEに変更し、論理ファイルログを圧縮しました alter database myDbName SET recovery simple go dbcc shrinkfile('LOG FILE LOGICAL NAME', 100) go それは助けたが、今私が理解する必要がなぜ、それが助けHOWこの状況が開始され、どのように将来的にはこれを防ぐには？ 編集： 毎晩1時に、サーバー上のすべてのデータベースのスクリプト化されたバックアップを行っています。これは、31行のスクリプトで行われています。最も重要な部分は set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak' set @Description = 'Full backup of database …
1
PostgreSQL DELETE FROMが「エラー：不可視のタプルを削除しようとしました」で失敗します
この質問は、データベース管理者のStack Exchangeで回答できるため、Server Faultから移行されました。 2年前に移行され ました。 エラー 無効なタイムスタンプを含むタプルを削除しようとしています DELETE FROM comments WHERE date > '1 Jan 9999' OR date < '1 Jan 2000' OR date_found > '1 Jan 9999' OR date_found < '1 Jan 2000'; で終わる ERROR: attempted to delete invisible tuple 2009年には、OPで修正されたまったく同じエラーメッセージについて議論するメーリングリストがありますが、彼がそれをどのようにしたのか、またはこのエラーにつながったのかについての説明はありません。 Googleでヒットがなく、PostgreSQLの知識が限られているため、私は無力です。 腐敗の原因 OSカーネルがパニックになったときに、おそらくスワップが配置されている/ dev / md1を再構築しているときに、Debian 8で実行しているPostgreSQL 9.5.5サーバー（メモリ制限の上限を除くすべてのデフォルト設定）を実行しました。それ以前は、PostgreSQLは400GBのログファイルでほとんどすべてのディスク領域を使い果たしました。OSは二度と起動しなかったので、ディスクチェックは問題ありませんでした。念のため、LiveCDから起動し、各ブロックデバイスをイメージにバックアップしました。/ …
3
SQL Serverは回復中のデータベースを表示します
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 今日、停電後、1つのデータベース（リカバリ：フル）がSSMSで「リカバリ中」と表示されます。そう： myDatabase（リカバリ中）（データベースステータス：リカバリ、シャットダウン） 終了後、データベースの「回復プロセス」には、「（回復中）」のないmyDatabaseという名前が表示されます。問題は解決したと思ったが、そうではなかった。 そのデータベースを使用するアプリケーションを起動すると、データベース名の横に「（回復中）」という余分なテキストが再び表示されます。 「回復プロセス」が終了するまで待ってから、データベースをオフラインにし、オンラインに戻しました。 サーバーを再起動し、コンピューターを再起動し、アプリケーションが実行されていたときに余分なテキストが再び表示されます。SQL Serverログに、「データベース 'myDatabase'を起動しています」というメッセージが数回表示されます。データを挿入できるのでデータベースは機能しているようですが、状態は何かが起こっていることを示しています。 サーバーログには興味深いものは何も表示されません。唯一の異常なことは、「データベース 'myDatabase'を起動しています」というエントリが30個あることです。 サーバーが起動すると、すべてのデータベースが使用可能な状態になる前に回復することを知っています。しかし、私の場合、データベースはオンラインになり、「myDatabase（In recovery）」と表示されます。アプリケーションを閉じると、データベースはStatus：Normalになります。これは私を夢中にさせます。 SQL Serverの新しいインスタンスをインストールし、その上に古いデータベース「myDatabase」を配置しました。問題は引き続き発生します。 このクエリを実行すると： SELECT databasepropertyex('nyDatabase', 'STATUS') 回復中、オンライン、疑わしい、オンラインに戻った後、回復などが表示されます。
2
トランザクションログの再構築
トランザクションログファイルが（SQL Serverがシャットダウンされている間に）削除された非常に大きなデータベース（〜6TB）があります。 データベースの切り離しと再接続。そして トランザクションログファイルの削除の取り消し ...しかし、これまでのところ何も機能していません。 現在実行中です： ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>') ...しかし、データベースのサイズを考えると、これを完了するにはおそらく数日かかります。 ご質問 上記のコマンドと次のコマンドに違いはありますか？ DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) REPAIR_ALLOW_DATA_LOSS代わりに実行する必要がありますか？ データベースを再構築できるようにデータが他のソースから派生していることは注目に値しますが、すべてのデータを再挿入するよりもデータベースを修復する方がはるかに迅速になると思われます。 更新 スコアを保持している場合：ALTER DATABASE/REBUILD LOGコマンドは約36時間後に完了し、報告しました： 警告：データベース 'dbname'のログが再構築されました。トランザクションの一貫性が失われました。RESTOREチェーンが破損し、サーバーは以前のログファイルのコンテキストを失ったため、それらが何であるかを知る必要があります。 DBCC CHECKDBを実行して、物理的な一貫性を検証する必要があります。データベースはdbo専用モードになっています。データベースを使用可能にする準備ができたら、データベースオプションをリセットし、余分なログファイルを削除する必要があります。 その後、DBCC CHECKDB成功しました（約13時間かかりました）。データベースバックアップの重要性（そしてプロジェクトマネージャーにサーバーへのアクセスを許可すること...）をすべて知ったとしましょう。
1
ibdファイルからibdata1なしでデータフォルダからMySQLデータベースを回復します
WAMPディレクトリが誤って別のユーザーによって削除されます。MySQLのデータフォルダのみが使用可能です。また、データベースフォルダー（ "\ bin \ mysql \ mysql5.6.12 \ data \"内のフォルダーとデータベース名）のみが使用可能です。「\ bin \ mysql \ mysql5.6.12 \ data \」のルートにある「ibdata1」を含むすべてのファイルも削除されます。 データベースフォルダーには、以下の拡張子を持つファイルのみが含まれます。 * .frm、*。ibd および「db.opt」ファイル。 データベースをどのように回復できますか？ 私はすでにbdata1を回復しようとしました。しかし、それを取り戻すことができません。また、一部のデータベースにはMYISAMも含まれています。
2
1000ページの制限に達するオンラインページの復元
（I / O障害により修正された）破損に苦しんでいるデータベースを回復しようとする仕事をしました。私は、データベースまたはデータベースに含まれる内容に詳しくありません。 古い（最大3週間）フルバックアップと一連のトランザクションログが与えられました...しかし、トランザクションログが欠落しているため、特定の日付までしか回復できません。2.5週間分のデータが失われています（このデータベースには常に多くのデータが追加されています）。 また、破損したデータベースのコピー（アクセス可能ですが、多くのページが破損/欠落しています）のコピーも提供されています。 私は典型的なDBCC CHECKDBコマンドを試してみました（まだありrepair_allow_data_lossません。他に何も機能しない場合、それは私の最後の手段になります）。 多くの人がデータベースに出入りした後（dbは1.5テラバイトの小さな怪物で、私がすることはすべて遅くて時間がかかります）、破損したページの最後の正常なバックアップからオンラインページの復元を試みました。 それを行うためにRESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'、DBCC CHECKDB出力から多くのコマンドを作成するスクリプトを作成しました（基本的には正規表現と異なる）...これまでのところ、これは1000ページの制限に達したと言った時点まで機能しました復元コマンドごとにファイルごと（このデータベースには8つのファイルがあります）。 そのため、「オンライン復元を完了する」ように求められますが、それを行う方法に途方に暮れています...私はテールログまたは最初の完全バックアップよりも完全なものを持っていないので、基本的に、残りのページで試行を続けるために復元を完了する方法がわかりません。 私は試してみましたRESTORE DATABASE <foo> WITH RECOVERYが、それでもうまくいきませんでした、私は持っていないログを要求します。 誰かがここから何かを回復しようとする方法についてのヒントを持っていますか？または、オンライン復元を「完了」して、さらに多くのページを復元しようとする方法はありますか？オフライン復元を試しても同じ問題が発生しますか（基本的WITH NORECOVERYにすべてを追加してから、最後に復元しようとしますか？） データベースを手作業で処理することは基本的に元に戻せません...数百万の行を持つ数百のテーブルがあり、それが何であるかについて明確な意味はありません。SELECT数百万行を超えると、破損したDBはクエリで失敗しますが、どこで解決できるかはわかりません。すべての非クラスター化インデックスを再構築しようとしましたが、行データを含む破損したページがあるため、どちらも機能しませんでした。 ある程度のデータ損失は許容されますが、DBでの一貫性の達成は少なくとも試みられるべきです。 破損したデータベースはまだオンラインであり、クライアントが作業しているため（新しいデータを取得し続けます）、ラボベンチで行うすべてのプロセスは、後で運用データベースで再現可能です（ダウンタイムは困難です）。 これはSQL Server 2014 Enterpriseです PS：私はDBAではありません...私はプログラマーですが、クライアントはいくつかの「エキスパート」SQLディザスタリカバリサービスを試してみましたが、彼らはあきらめました。何でもする。 更新：多くのテストの後、ページごとの復元は不要でしたので、アイデアを捨てました。手動リカバリ（破損したテーブルから不足しているレコードを手動で選択し、最後の既知の正常なバックアップに挿入する）を行い、自動化ツールを使用します（再び、何百ものテーブルがあります）。
4
なぜMongoはSTARTUP2で動かなくなるのですか？
Mongoいくつかのセカンダリを含むレプリカセットがあります。セカンダリインスタンスをホストするボックスがクラッシュし、データベースが失われました。 セカンダリMongoインスタンスを再び起動しましたが、現在は12時間以上STARTUP2で停止しています。それは理にかなっていますか？ドキュメントはMongo、RECOVERING状態に入る前に、短時間STARTUP2にあるべきだと言っています STARTUP2とはどういう意味ですか？プライマリからデータベースをコピーしていますか？どうすれば検証できますか（MongoがLinuxで実行されていると仮定）？
12 mongodb  recovery 
3
可用性グループデータベースが同期なし/回復保留モードでスタックしている
SQL Server 2014 SP1（12.0.4422.0）インスタンスのストレージをアップグレードしているときに、SQL Serverの再起動後に2つのデータベースがセカンダリで起動しないという問題が発生しました。新しい（大きい）SSDを取り付け、データファイルを新しいボリュームにコピーしている間、サーバーは数時間オフラインでした。SQL Serverを再起動すると、2つを除くすべてのデータベースが再び同期を開始しました。他の2つは、SSMS で同期なし/回復保留中と表示されました。 以前に同様の同期しない/回復中の問題があったため、可用性グループ->可用性データベースセクションでステータスを確認しましたが、赤いXが表示されていました。 データ移動を一時停止しようとすると、エラーメッセージが生成されました。 可用性グループ「SENetwork_AG」の可用性レプリカ「ny-sql03」にあるデータベース「StackExchange.Bycycles.Meta」でのデータ移動の一時停止に失敗しました。（Microsoft.SqlServer.Smo） 追加情報：Transact-SQLステートメントまたはバッチの実行中に例外が発生しました。（Microsoft.SqlServer.ConnectionInfo） ファイル「StackExchange.Bycycles.Meta」にアクセスできません。ファイルにアクセスできないか、メモリまたはディスク領域が不足しています。詳細については、SQL Serverエラーログを参照してください。（Microsoft SQL Server、エラー：945） チェックしたところ、ファイルは存在し、権限の問題はありませんでした。また、管理下のSSMSでSQL Serverログを確認しましたが、保留中の回復や2つのデータベースの問題については何も表示されませんでした。 ヘルプを検索したところ、データベースを復元する必要があると述べた2つの異なる記事が見つかりました。 データベースがリカバリ保留状態でスタックしているときに、セカンダリでデータレプリケーションを再開する方法はありますか？
2
トランザクションログファイルの内容の詳細
トランザクションログ（略してLDFと呼ぶ）の内容について質問があります。完全復旧モデルのデータベースを想定しています。 私は、LDFファイルに（ログ）データベースへのすべての操作（つまり、完全復旧モード）が含まれていることを読みました。ロギング中とどう違うのBEGIN TRAN; COMMAND(s); COMMITですか？どうやらトランザクションはロールバックできますが、標準コマンド（完全復旧モード）はロールバックできないので、私は尋ねています。 トランザクション中にLDFファイルに記録される内容は、通常の完全復旧ロギングの場合とは異なると思います。そうですか？どう違うの？各アクションに「元に戻す」操作が含まれているだけですか？ 関連するメモとして、完全復旧LDFファイルを使用して標準クエリを「ロールバック/元に戻す」ための商用ツールがあると聞きました。どうやってやっているの？彼らはLDFの内容を分析し、逆/元に戻す操作を考え出そうとしますか？
2
bakファイルをより小さいmdfおよびldfデータベースファイルに復元する
私はレガシーデータベースの設計に悪夢のような欠如があるので、ここでは触れませんが、サーバー上のファイルは（比較的）巨大です。私が持っています： MyDatabase.mdf：24.8GB MyDatabase.ldf：114.6GB このデータベースは毎晩.bakファイルにバックアップされ、レポートサーバーに送られ、そこで復元されます。.bakファイルは、わずか1.8 GBと非常に小さくなります。 ただし、レポートサーバーで復元しようとすると、スペース不足のため失敗します。サーバーには約100GBの空き容量があり、元のサーバーでファイルが消費した139.​​4GB全体を消費しようとしています。圧縮に関する私の知識がひどく間違っているのでない限り、1.8 GBのファイルが実際に7400％拡大されていないことにはかなりの自信があります。 私の質問：そのスペースを事前に予約せずにこのバックアップファイルを復元するようにSQL Serverに指示する方法はありますか？ログは気にしません。そこにデータが必要です。開発とスキーマの観点からデータベースを理解していますが、私は決してDBAの一種ではありません。 これはSQL Server 2008 R2にあります。助けや提案をありがとう。
3
.ibd、.frm、およびmysqllogbinファイルからのMySQLテーブルの復元
何らかの理由で、（MySQLまたはphpmyadminに関係なく）.frmと.ibdファイルに保存されている自分のテーブルを開こうとすると、構文エラーが表示されるか、存在しないと表示されます。 これと同様の問題があった他の投稿を読みましたが、innodb_file_per_table有効になっているかどうかを確認する方法がわからず、全体的に本当に混乱しています。また、mysql-bin.000002ファイルのコピーをtxtファイルに変換したので、データベースのデータが完全に失われていないことがわかります。 データベースは昨年作成されました。これらのmysql-bin.00000ファイルは6つありますが、なんらかの理由で.000002最大です。現在、すべてのデータベースの.ibdおよび.frmファイルがありますが、MySQLに、または少なくとも読み取り可能なものに復元する方法について、私は途方に暮れています。 Windows 2003 ServerでWampServer 2.4とMySQL 5.6.12を使用しています。また、InnoDBでプラグインをダウンロードする必要がありますか？
2
孤児の化身とは何ですか？
インカネーションはで説明されている答えに別の質問このサイトに。答えは「孤立した」化身について言及しています： …ORPHANEDインカネーションとOBSOLETEバックアップにつながる他の要因があります… Oracleドキュメントから、関連する必要がある、またはの値を持つことができる列がV$DATABASE_INCARNATION含まれてSTATUSいることがわかります。ORPHANCURRENTPARENT 「孤立した」化身とは何ですか。また、STATUS= ORPHANinの行がどのステップで生成されるのでしょうV$DATABASE_INCARNATIONか。
1
復元できません（エラー3456）
簡単に理解できない状況があり、このフォーラムで他の人に提案があるかどうか尋ねたいと思いました。 Windows Server 2008R2 EnterpriseでSQL Server 2008 R2 Standard SP3を実行しています。 データベースにはいくつかのメンテナンスが必要でしたが、その後、別のサーバーに復元する必要がありました。COPY_ONLYで実行される完全なdbバックアップと、4つのtlogバックアップのセットがあります。 開始する前に、tlogbackup1を作成します 以下からの変更FULLへのBULK_LOGGED復旧モデル 新しいファイルグループを追加する newfilegroupにファイルを追加する newfilegroupをデフォルトに設定 テーブルに選択（newfilegroup） 元のテーブルをドロップ 元のファイルを削除 元のファイルグループを削除する 新しいテーブルの名前を元のテーブルと一致するように変更する 元のファイルグループと一致するようにnewfilegroupのファイル名を変更する 元のファイル名と一致するようにカタログのファイル名を変更する OSレベルでファイル名を変更して元のファイル名と一致させる 既定のファイルグループを元のファイルグループに設定する dbをオンラインにする 以下からの変更BULK_LOGGEDへのFULL復旧モデル すべての手順が完了したら、tlogbackup2を作成します 復元サーバーでのドライブ文字の変更により、すべてのバックアップの復元にはWITH MOVEを使用する必要があります。 回復手順： RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak' WITH MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf' ,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf' ,MOVE 'SystemData_log' TO …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.