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

7
PostgreSQLでデータベーススナップショットをすばやく作成/復元することは可能ですか?
まず、私はDBAやシステム管理者ではなく、開発者です。優しくしてください:) 私は、単一のユーザーアクションがデータベースの複雑な変更をトリガーするアプリケーションワークフローに取り組んでいます。いくつかのテーブルで数百のレコードを作成し、他のテーブルで数百のレコードを更新します。 )このアクションに触れます。複雑なため、別のテストを実行する前にすべての変更を手動で元に戻すのは非常に困難です。ほとんどの開発期間中、ワークフローの終わり近くに「ROLLBACK」ステートメントを挿入するだけで済みますが、変更のコミットが近づいたら、本物をテストする必要があります。 運用する運用データベースのローカルコピーがあります。私の場合、テスト間のダ​​ンプと復元は、すべての変更を取り消すスクリプトを書くよりも高速です。それは高速ですが、それでも私はかなり遅くなります(私のラップトップでの復元には約20分かかります)。データベースの現在の状態のスナップショットを保存して、すぐに復元する方法はありますか? システム上の唯一のユーザーであることが保証されており、ルートアクセス権があります。データベースダンプは、tarおよびgzipで圧縮された場合、約100 MBです。PostgreSQLバージョンは8.3です。 役立つアイデアを事前に感謝します。

5
10-20のSQL Serverデータベースを〜同期状態にバックアップおよび復元しますか?
10〜50 GBのサイズの10〜20個のSQL Server 2008 R2データベースをオンラインでバックアップし、単一のエンタープライズアプリで同時に使用する必要があります。また、すべてのデータベースでほぼ同期された状態にそれらを復元する必要があります(データベース間で最大数秒の非同期が可能です)。目的は、QA / DEV環境の実稼働データをキャプチャすることです。 データベースを完全復旧で実行することを要求せず、QA環境のデータをキャプチャするための専用のバックアップ方法を考え、私の制御下にないメインのバックアッププロセスに依存しないことを強く望みます。 私の顧客の場合、それぞれ最大30 GBで20の完全バックアップをキャプチャするのに1〜2時間かかります。これにより、単純なリカバリで実行する場合にデータベースの同期がとれすぎるため、フルバックアップを連続して取得することは受け入れられなくなります。 私はこれらよりも良いアイデアを探しています: アイデア1:VMディスクのSANレベルのスナップショット。スナップショットからMDF / LDFをxcopyします。 コピーされたファイルが別のサーバーインスタンスにアタッチされると、その回復プロセスにより、ほぼ同時にスナップショットである一貫性のあるデータベースが作成されます。 少なくとも私がmaster / msdb / etcに対してdesyncを取得する可能性があるため、グーグルでこれが悪い考えだと確信しました。 アイデア2:複雑なバックアップを調整し、すべてのデータベースで同期復元 これには、データベースを完全復旧で実行する必要がありますが、これは望ましくありません。期限(T0)のかなり前に、すべてのデータベースの並列バックアップを開始します。T0に達したら、すべてのログをバックアップします(最大で数分かかります)。結果として得られる無数のバックアップを取り、それらを復元し、ログをロールバック/ロールバックして、T0に対してデータベース全体である程度一貫した状態を取得します。 これを確実に使用するには多くの計画とスクリプトが必要なので、それを避けるためにかなりの時間を費やします。 他の解決策がありませんか? PS1:db snapshotsを使用できるようになりたいと思っていました。アイデアは、各データベースでスナップショットを開始し(数秒で終了する必要があります)、その後、次の分/時間にわたって順番に完全にバックアップします。次に、それらすべてを別のサーバーに復元し、それぞれをスナップショットに戻します。スナップショットはデータベースと一緒にバックアップできないため、このシナリオは不可能です。それらは、作成されたサーバー上の所定の場所にのみロールバックできます。さらに、これらにはEnterprise Editionが必要ですが、これは私がすべての顧客に提供しているわけではありません。 PS2:クロスデータベース同期バックアップを作成できるサードパーティのソリューションをご存知の場合は、そのことをお知らせください。

2
統合テスト用のSQL Serverデータベーススナップショット
統合テストのために(SQL Serverの)テストデータベースを操作する方法を定義しようとしています。 私のアイデアは、統合テストアセンブリの起動時に次の手順を実行することでした。 完全に空のデータベースを作成する 「データベースオブジェクトの作成」スクリプトを実行して、関連するすべてのデータベースオブジェクト(テーブル、ビュー、シーケンスなど)を作成します。 「ベースデータ」を入力します(ルックアップ値など) (db)_Basis将来の統合テストのために「ベースライン」と呼ばれるデータベースのスナップショットを撮る すべてのテストクラス(1-nテストを含む)の前に、「スナップショットからの復元」を実行して、データベースの定義済みの多かれ少なかれ「空の」状態に戻すことを計画していました。これまでのところ魅力のように動作します。 ただし、大規模なテストデータベースで動作する必要がある統合テストのセットがあります。そのため、これらの各テストフィクスチャ(n個の個別テストを持つクラス)の前にこれを実行したいと考えていました。 (db)_Basisスナップショットからデータベースを復元する これらの50'000 +行のデータをデータベースに挿入します 別のスナップ(db)_With_Testdataショットスナップショットを作成する その後、テストごとに、データベースを適切に定義された(db)_With_Testdataスナップショットバージョンにリセットし、テストを実行して、結果を検証します。 問題は、2つの dbスナップショットを同時に持つことができないように思われることです。一度行うと、データベースをどちらにも復元できません。このエラーが引き続き発生します。 メッセージ3137、レベル16、状態4、行9 データベースを元に戻すことはできません。プライマリ名またはスナップショット名が不適切に指定されているか、他のすべてのスナップショットが削除されていないか、ファイルが欠落しています。 メッセージ3013、レベル16、状態1、行9 RESTORE DATABASEが異常終了しています。 SQL Serverデータベースのスナップショットは実際にどのように機能しますか?? ひどく制限しているようです.....おそらく元の「(db)_Basis」スナップショットに直接戻れないかどうかはわかりますが、2つのスナップショットを持っているという理由だけで、最新のスナップショットに戻ることさえできません。 ?!?!?

1
SQL Serverで既存のデータベーススナップショットを照会するにはどうすればよいですか?
特定のデータベースに、そこから作成されたデータベーススナップショットがあるかどうかを判断できるt-sqlクエリを作成しようとしています。 たとえば、次のようなスナップショットを作成するとします。 CREATE DATABASE [DatabaseA_Snapshot] ON (NAME=DatabaseA, FileName='<whatever>') AS SNAPSHOT OF [DatabaseA] そのスナップショットの存在を後でもう一度クエリできる方法はありますか?sys.databasesに表示されることがわかりますが、DatabaseAから作成されたデータベーススナップショットであると判断するのに役立つ情報が見つかりませんでした。 SQL Server Management Studioのオブジェクトエクスプローラーは、 'データベーススナップショット'フォルダーの下に配置するため、これらを通常のデータベースと区別するいくつかの方法があります。

1
SQL Serverスナップショットレプリケーションは毎回完全にデータをコピーしますか、それともデルタを発行しますか?
2つのサーバー間のスナップショットレプリケーションを見ています。これが私が持っているものです: 500GBデータベース 〜500MBの毎晩のbcpロード 〜50MBの毎日のトランザクション 使用するレプリケーションの種類について、社内の他のDBAに尋ねていました。スナップショットレプリケーションを使用するように言われました。ただし、私が理解して読んでいることから、ロード後の毎晩、スナップショットはデータベースをディストリビューターに完全にコピーし、他のサーバーを完全に上書きします。 スナップショットはデルタで機能しますか、それとも毎回完全なコピーですか?

1
EC2-PostgreSQLデータを正しくバックアップする方法
これがセットアップです。3つの追加ボリュームを持つ1つの小さなAmazon Linux(EBS-backed)EC2インスタンス。これは、Webサーバーとデータベースサーバーの両方です。コード用の1つのボリューム、PostgreSQL(8.4)データディレクトリ用の1つのボリューム、およびPostgreSQLからのWALファイルを格納するための1つのボリューム。 (1)WALファイルを含むボリュームには、pg_start_backup()を実行した後にコピーされるデータディレクトリのベースバックアップもあります。次に、PostgreSQLからの継続的なアーカイブ出力(WALファイル)を保存します。このボリュームのスナップショットを作成するには、同期を発行してファイルシステムをフリーズする(XFSの場合はxfs_freezeを使用するか、EXT4の場合はdmsetupを使用する)意味がありますか?または、ライブスナップショットを撮ることができますか?WALファイルは、毎分1つの速度で出荷されます。単一のWALファイルがコピーされている間にスナップショットが開始され、データが破損する可能性はありますか? (2)ライブPostgreSQLデータディレクトリを含むボリュームも、適切な方法で(毎日)バックアップされます。このボリュームのスナップショットを作成する前に、pg_dumpを実行すると、結果のSQLファイルがデータディレクトリに保持されます。実際のデータベースデータの整合性を確保するための予防策を講じることに意味はありますか?ライブスナップショットを作成すると、(a)構成ファイル(postgresql.conf、pg_hba.conf、pg_ident.conf)が適切にバックアップされ、(b)SQLダンプファイルがバックアップされると想定して間違いありませんか。SQLダンプファイルと構成ファイルの2つをバックアップすることが、このボリュームのスナップショットの主なポイントになります。DBはそれほど大きくないので、データファイルがこのスナップショットを膨らませることは気にしません。その場合、ライブスナップショットを作成できます-正しいですか? (2a)ルートボリュームにデータディレクトリを保持し、SQLダンプファイルと構成ファイルを別のボリュームにコピーするバックアップスクリプトを用意し、コピーが完了したらそのボリュームのスナップショットを作成するほうがよいでしょうか? (3)コードが含まれているボリュームについて、ファイルシステムを同期してフリーズするポイントはありますか?または、ライブスナップショットのみを取得できますか?このデータはかなり「静的」である必要があります。 (4)これは確かなバックアップスキームですか?ルートボリュームは定期的にバックアップされません。これは、セットアップして構成した後のマシンイメージを保持するだけだからです。 ありがとう

2
スナップショットアイソレーションを使用すると、SQL Serverデータベースの書き込みが遅くなりますか?
システムで多くのデッドロックが発生しています。 それらを修正するためにスナップショットアイソレーションを使用したいのですが、私のDBAはそれについて予約しています。 彼の懸念の1つは、スナップショット分離が書き込み速度を低下させることです。これは、キャッシュに書き込んでからTempDb(行バージョン)に書き込む必要があり、呼び出し元に戻ることができるためです。 「通常の」書き込みは、キャッシュに書き込むだけで実行できます。 これは行のバージョン管理のしくみですか?それともそれよりも複雑ですか?それはどういうわけかこれらを並行して行いますか? それともスナップショットアイソレーションでは書き込みが遅くなりますか?

2
レポート目的でデータベーススナップショットを使用する利点
レポート目的でデータベースのスナップショットを使用することのパフォーマンス上の利点は何ですか? 私の見たところ、元のデータベースへの書き込みごとに、スナップショット自体に別の書き込みを行う必要があるため、おそらくパフォーマンスが低下します。 その時点までのデータのレポートを作成したいときはいつでもスナップショットを使用することがわかりますが、それはパフォーマンスのカテゴリに分類されません。 繰り返しますが、パフォーマンス上の利点はありますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.