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

私はSQL Serverを使用しており、2つのファイルグループを持つ巨大なデータベースがあります。 プライマリ：大きなファイル（1MB +）を除くすべてのデータが含まれます FILESTREAM（読み取り/書き込み）：大きなファイルが含まれています 現在、バックアップシナリオは次のとおりです。 毎週金曜日に完全バックアップ（午前2時）を取得します 金曜日を除く毎日、差分バックアップ（午前2時）を取得します。 データベースが大きく、リモートサーバーで運用されているため、データベースをローカル環境に移動してテストデータベースを（毎週）作成する場合は常に、プライマリとファイルストリームの両方を使用する必要があります。 ファイルストリームを無視して、プライマリファイルグループを取得するだけで済むように、バックアップと復元の方法を変更できるようにしたいと考えています。このようにして、毎週、ファイルストリームを想定するすべての情報ではなく、プライマリファイルグループのみを取得します。 多くの問題があり、ファイルにアクセスするとすべてのファイルストリーム参照が失われる可能性があると思います。バックアップを実行するときにすべてのファイルストリーム列のコンテンツを変更できるか、またはテスト環境でホストされている別のファイルストリームを使用できるかどうか知りたいのですが。また、一部のファイルグループのみの段階的復元について聞いたことがありますが、その実行方法には多くの疑問があります。 質問1：このシナリオはありますか？ 質問2：完全バックアップを1つだけにし、差分バックアップ/トランザクションログをテスト環境に持ってくるのは良い考えですか？ 質問3：バックアップと復元のシナリオを改善できますか？ 私はすべての推奨事項に耳を傾けています。ケースの例がある場合は、T-SQLクエリを表示してください。

8 sql-server  backup  restore  filestream 

私は、pg_dumpPostgreSQL 8.3サーバーでホストしているJIRAデータベースで実行しました。データベース後のサイズvacuum fullだった217132652（約207メガバイト）。 次に、次のコマンドを使用して、JIRAデータベースをPostgreSQL 9.4サーバーに復元しました。 $ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql 私はを使用して以来、エラーが発生すると復元が終了すると思いON_ERROR_STOP=1ますが、SQLスクリプトは正常に終了しました（データの復元に関連しないいくつかの警告にもかかわらず）。 最終的に、サイズが158019348（約151 MB）のデータベースができました。 だから、ここの話は何ですか？データベースが正常に復元され、PostgreSQLがストレージ（バージョン8.3から9.4の間）を最適化し、スペースをより効率的に使用していると仮定できますか？

8 postgresql  restore  disk-space 

SQL Server 2012バックアップファイルがあり、これらをSQL Server 2016/2014に復元したい。うまくいきますか？ SQL Server 2012をアンインストールする前に、これを確認する必要があります。

8 sql-server-2012  backup  sql-server-2014  restore  migration 

私は現在、制御不能になったSQL Serverトランザクションログを処理する必要があります。免責事項：私はdbaではなく、これは私の専門分野ではないので、ご容赦ください。 現在、500 MBのデータベース用に115 GBのトランザクションログファイルがあり、この状態になるには（明らかに）しばらく管理が不十分でした。 最優先事項は、実行する前に、このファイルによって占有されているディスク上のスペースを再利用することです。ドライブのサイズを増やすことは一時的であってもオプションではないと言われています。過去の成長に基づいて、我々はすぐに行動する必要があります。 私が理解しているように、最良のアプローチは、dbを完全復旧モードに保ちながら、ログファイルの定期的なバックアップをとり、一定期間監視し、初期サイズと増分を適切に調整することです。大丈夫。 午前0時に定期的にフルデータベースバックアップを実行しているときに、データベースを一時的にシンプルリカバリモードにして（これらのバックアップの1つが実行された後）、ログファイルを圧縮して（事実上すべての）領域を解放し、次に、上記のバックアップ戦略でそれを完全復旧に戻しますか？ 私の考えでは、この時期に何かが起こった場合、ログを使用せずに完全なバックアップを復元することができます。 更新 いくつかの回答とコメントへの返信におけるいくつかの追加詳細： データベースを完全復旧モードのままにしておくために、ポイントインタイムリストアを実行する機能を保持したいと思います。 t-logファイルが非常に大きくなった理由は、バックアップされたことがないためです。log_reuse_wait_descが「LOG_BACKUP」を返すことを確認。

8 sql-server  sql-server-2012  backup  restore 

以前にこれと似たような質問をしましたが、以前はバックアップを共有の場所に移動することについて質問していました。今回は気になります。共有ドライブにデータベースを復元する場合、そのサーバーまたはSQL Serverを実行しているサーバーだけでIFIを有効にする必要がありますか？ 私が尋ねる理由は、かなり大きなデータベースを復元していて、過去2、3時間は100％で停止してしまったためです。の待機タイプsp_whoisactiveは次のとおりです。 (28472716ms) `PREEMPTIVE_OS_WRITEFILEGATHER. 私が見たのは、IFIがオンになっていないときだけですが、SQL Serverでは有効になっていますが、共有ドライブサーバーでは有効になっていません。

8 sql-server  performance  restore 

マイクロソフトは、SQL Server 2012データベースコピーウィザードがSQL Server 2000データベースをSQL Server 2012にコピーする最も最適な方法であると私に信じさせました。数時間苦労した後、いくつかの問題を乗り越えることができ、中規模のSQL Server 2000データベースからSQL Server 2012へ。 ただし、30GBデータベースの場合、ウィザードは次のエラーで常に失敗します。 メッセージ：データの転送中にエラーが発生しました。詳細については、内部の例外を参照してください。 StackTrace：Microsoft.SqlServer.Management.Smo.Transfer.TransferData（） at Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.TransferDatabasesUsingSMOTransfer（） InnerException->タイムアウト。操作が完了する前にタイムアウト期間が経過したか、サーバーが応答していません。 CREATE DATABASEが失敗しました。リストされている一部のファイル名を作成できませんでした。関連するエラーを確認してください。 StackTrace： System.Data.SqlClient.SqlConnection.OnError（SqlException exception、Boolean breakConnection） at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning（） System.Data.SqlClient.TdsParser.Run（RunBehavior runBehavior、SqlCommand cmdHandler、SqlDataReader dataStream、BulkCopySimpleResultSet bulkCopyHandler、TdsParserStateObject stateObj）で 私は再確認しましたが、ファイルパス、権限、またはディスク容量の問題ではありません。このCREATE DATABASEステップには2分ほどかかると思います。ウィザードは操作がタイムアウトしたと想定します。SQLを使用して同じファイルパスとファイルサイズで空のデータベースを手動で作成しましたが、うまくいきました。興味深いことに、1GBのデータベースコピーは同じエラーで失敗し、2回目の試行で成功しました。 助けてください。

8 sql-server  sql-server-2012  ssis  restore 

カスタムLinuxディストリビューションを実行している仮想マシンでPostgreSQL 8.2.1から9.2へのアップグレードをテストしています。アップグレード手順は次のとおりです。 pgサービスを開始する すべてのDBをバキュームします（これが必要かどうかは不明です） バックアップ pg_dumpall pgサービスを停止します データが格納されているディレクトリを移動します（/var/pg;これはシンプルな単一サーバーのセットアップです） PostgreSQL 9.2をインストールする initdb サーバーを起動する ダンプされたデータを復元する reindexdb すべてのDB referential_constraintsビューを再作成する すべてのDBをバキュームします（このアップグレード後にAFAIKが必要です） この手順は、1つのホストで問題なく動作し、問題なくバックアップおよび復元できます。データベースポイントが異なる1〜7の別のマシンでは正常に動作しますが、sleep 1after を追加しない限りサーバーは起動しません。initdbそれでも、「データベースシステムが起動中」であるため、ダンプされたデータを復元できません。これらのひどいハックを除いて、これに対処する標準的な方法は何ですか？ sleepどちらかの操作の前に、十分な時間をかけてください。 動作するまで、または十分なタイムアウトになるまでループするか、 簡単なクエリを受け入れるか、タイムアウトに達するまでループします。 編集：「ソリューション」は結局機能しませんでした。データベースが復元を実行する準備ができていることを確認するには何が必要ですか？

8 postgresql  restore  upgrade