タグ付けされた質問 「log-shipping」

2
ネットワーク上でダウンタイムの少ない巨大なSQL Serverデータベースを移行する最良の方法
問題定義 データベースサーバーを他のデータセンターに転送する必要があります。Microsoft SQL Server 2012 Enterprise(64ビット)で実行され、約2TBと1TBの2つのデータベースが含まれています。 ダウンタイムがほとんどないか、まったくないことが理想的です。 仕事量 これらのデータベースは.NET Webサイトに使用され、常に更新されています。 ただし、週末に利用できなくても問題ありません。現在使用中のDBは、新しいDBに切り替えるまで使用中の唯一のDBのままです。 この切り替えは、理想的には、DBが更新されていないことを確認しながら、新しいDBサーバーを指すようにDNSエントリを変更するだけで行われます。 また、1つのサーバーから別のサーバーへの切り替え(ダウンタイム)が低く抑えられている限り、この操作にかかる時間は実際には重要ではありません。 考慮されるアプローチ バックアップと復元 これは過去に行われたことがありますが、内部ネットワークを介して行われたにもかかわらず、インターネットよりも効率的にダウンタイムが長くなりました ログ配布 私の知る限り、このアプローチは、マスター/スレーブを構成し、マスターDBの正確なコピーを読み取り専用のスレーブに転送することにより、ダウンタイムを最小限に抑えます。上記のように、スレーブへのアクセスは不要であり、データ破損なしでマスターDBのレプリカを保持する方法が必要です。 また、リソース使用率の面でも非常に効率的であるようで、マスターのパフォーマンスにはほとんど影響しません。 私はこのアプローチについて間違っているかもしれませんので、私を修正してください。 データベースミラーリング 私はそのアプローチをあまり認識していませんが、有効なオプションのようです。リアルタイムで同期する必要はなく、マスターのパフォーマンスは非常に重要であるため、このアプローチを選択する場合は非同期が最適です。 別のオプション? このサーバーはベアメタルハードウェア上で直接実行されるため、残念ながら低レベルのソリューションはオプションではありません。たぶんこれを達成するためのより良い方法がありますか? 制約 説明したように、これらのデータベースは維持するのが難しいほど大きなものですが、それは別の問題です。 SQL Serverのバージョンは同じです(Microsoft SQL Server 2012 Enterprise 64ビット)。 2つのデータセンター間のネットワーク経由で転送する必要があるため、おそらくインターネット経由で転送する必要があります。最初の同期のために、あるサイトから別のサイトにディスクを送信することは、残念ながらオプションではありません。転送に何らかのセキュリティを持たせることが理想的ですが、この状況を最大限に活用します。 これにより、このタスクに対する私たちのニーズの非常に良い概要が得られるはずです。

2
データベースの復元を削除する方法
SQL Server 2008 R2でログ配布を実行しています。 セカンダリデータベースドライブの領域が不足し、ログ配布トランザクションログを適用していなかった状況があります。 これを修正する方法は、セカンダリでデータベースを削除し、ログ配布をゼロから構成することです。 現在の問題は、セカンダリデータベースが復元状態にあり、削除できないことです。どうすれば続行できますか? たとえば、オフラインにしようとすると、エラーが発生します。 ALTER DATABASE is not permitted while the database is in the Restoring state.

2
ログ配布-スタンバイを使用した復元-SQL Server 2012で壊れ続ける
RESTORE WITH STANDBYレポート目的でデータベースを読み取り専用モードで復元するために、ログ配布とSQL Server 2012を使用しています。ただし、ログ配布の設定は、1つまたは2つのログバックアップの復元が完了した後も壊れ続けます。ログ配布は、それがとして実行されている場合にのみ機能しRESTORE WITH STANDBYます。RESTORE WITH NORECOVERY問題はありません。 これに関する私の唯一の直感は、プライマリデータベースはそれほど動的ではないということです。したがって、トランザクションがない場合、これはRESTOREプロセスに問題を引き起こす可能性がありますか? アイデア、既知の修正? 2つのテーブルを頻繁に更新する定期的なジョブを実行することで、数日間は機能していました。ジョブがログ配布セットアップの実行を停止するとすぐに失敗し、.trnファイルを処理できませんでした。私はログ配布をリセットし、小さな更新を行って実行が継続するかどうかを確認しようとしました。テーブルの1つのレコードの1つの列の値を、失敗した場合でも変更しました。 ご回答いただきありがとうございます。 PS:ログからの抜粋 2013年2月25日13:00:00、LSRestore_DBDB01-A_BulldogDB、In Progress、1、DBREPORTS、LSRestore_DBDB01-A_BulldogDB、Log shipping restore log job step。,, 2013-02-25 13:00:12.31 ***エラー:ログバックアップファイル '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn'をセカンダリデータベース 'BulldogDB'に適用できませんでした。(Microsoft.SqlServer.Management.LogShipping)*** 2013-02-25 13:00:12.31 ***エラー:データベース 'BulldogDB'のログの処理中にエラーが発生しました。可能であれば、バックアップから復元します。バックアップが利用できない場合は、ログを再構築する必要があるかもしれません。 リカバリ中にエラーが発生し、データベース 'BulldogDB'(8:0)を再起動できませんでした。回復エラーを診断して修正するか、既知の正常なバックアップから復元します。エラーが修正されない、または予期されない場合は、テクニカルサポートに連絡してください。 RESTORE LOGが異常終了しています。 ファイル1のデータベース「BulldogDB」ファイル「BulldogDB」の0ページを処理しました ファイル1でデータベース「BulldogDB」ファイル「BulldogDB_log」の1ページを処理しました(.Net SqlClientデータプロバイダー)*** 2013-02-25 13:00:12.32 ***エラー:履歴/エラーメッセージをログに記録できませんでした(Microsoft.SqlServer.Management.LogShipping)*** 2013-02-25 13:00:12.32 ***エラー:ExecuteNonQueryには、開いて利用可能な接続が必要です。接続の現在の状態は閉じています。(System.Data)*** …

1
ログ配布SQL Server 2012
私はDBAがいない小さなショップの開発者で、SQL Server 2012を使用してログ配布を取得しようとしています。トランザクションシステムから新しいデータウェアハウスにレポートの負荷を軽減しようとしています。このデータベースをステージング領域として使用します。 ログ配布ウィザードを実行したところ、主要なバックアップジョブとファイルコピージョブが毎回機能しました。セカンダリリストアジョブがランダムに失敗するようです。 プライマリサーバーには、1つのトランザクションログジョブしかありません。差分バックアップは無効になっています(問題かどうかは不明です)が、完全バックアップがあります。 セカンダリサーバーは、メンテナンスプラン、バックアップ、またはアクティブユーザーのいないフレッシュインストールです。 バックアップを強制的に同期させる方法はありますか、または常に同期を維持することを保証しますか? とても壊れやすいようです。お知らせ下さい。 以下の編集ログ: *Starting transaction log copy. Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7' Retrieving copy settings. Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7' Retrieved copy settings. Primary Server: '', Primary Database: 'db', Backup Source Directory: '\\server\folder', Backup Destination Directory: '\\server\folder', Last Copied File: '\\server\folder\db_20160105070002.trn' Starting transaction log restore. Secondary ID: 'b58d7ce8-2fd7-4cec-b5bd-f3c5e5d3c0f7' …

1
大きなDBのログ配布-ログはどうですか?
現在、大容量のDB(約1.5 TB)のログ配布を設定しており、ログファイルに対して何ができるか疑問に思っています。 現状では、次の手順を実行したいと思います。 DBを完全復旧に変更する プライマリで完全バックアップ(5〜6時間)を取る フルバックアップをセカンダリに復元(NORECOVERYのまま) プライマリでDIFFバックアップを作成 DIFFバックアップをセカンダリに復元(まだNORECOVERYのまま) 「データベースはすでに初期化されています」を使用してログ配布を初期化します 問題は、フルバックアップを実行しているときに、ログファイルがバックアップの完了よりも早くいっぱいになることです。 ログファイルがいっぱいにならないようにするには、どのようなオプションが必要ですか?DIFFリストアはその期間中に行われたトランザクションをすべてカバーするため、フルバックアップ中に通常どおりにログバックアップを実行できますか?これまでにこのサイズのDBでこれを行ったことがありますか?それを簡単にするためのヒント/トリック?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.