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

その瞬間、やや不本意なDBAになり、何かの助けが本当に必要です。 フルリカバリモードで40GBのデータベースがあり、ログバックアップが構成されておらず、84GBの巨大なログファイルがあります。これまでのところ、この状況を回避するための私の計画は、データベースで完全なログバックアップを実行し、ログファイルを圧縮し、データベースバックアップを使用してログバックアップを毎晩実行し、制御を維持できるように保守計画を推進することです。 私の問題は、ログファイルを何も縮小しないで、月曜日の最初の朝を絶えず成長させておくことです。ファイルがどうあるべきか（データベースの約20％）については大まかな見積もりがあり、できる限り多くの連続したスペースを確保するために、最初から設定します。これは、データベースのプロパティ->ファイルで「初期サイズ」を変更した場合に過ぎませんか？これを実行するには、データベースをオフラインにする必要があると思いますか？ 前もって感謝します

10 sql-server-2008  transaction-log 

今朝、私はデータベースの1つでトランザクションログが一杯になったという警告に目覚めました。このサーバーは、常時接続のクラスターであり、トランザクションレプリケーションサブスクライバーでもあります。log_reuse_wait_descを確認したところ、logbackupが表示されました。4日前に誰かが誤ってlogbackupジョブを無効にしていたため、ログバックアップジョブを再度有効にしたところ、ログがクリアされました。午前4時だったので、その朝遅くにオフィスに行って、ログが400GBに達したときにログを鳴らそうと思いました。 午前10時-オフィスにいて、縮小する前にログの使用状況を確認したところ、約16％でした。私は驚いて、複製を示したlog_reuse_wait_descを確認しました。これがレプリケーションサブスクライバーだったため、混乱しました。次に、dbがCDCに対して有効になっていることがわかり、それが原因である可能性があるため、CDCを無効にすると、log_reuse_wait_descにAVAILABILITY_REPLICAが表示されます。 一方、ログの使用量は着実に増加しており、現在は17％です。alwaysonダッシュボードを確認し、送信済みキューとやり直しキューを確認しましたが、どちらもほぼゼロです。ログの再利用がAVAILABILITY_REPLICAと表示され、ログをクリアできない理由がわかりません。 なぜこれが起こっているのでしょうか？

9 sql-server  sql-server-2014  availability-groups  transaction-log  transactional-replication 

私はDBAではありませんが、DBAの帽子をかぶってSQL Serverインスタンスのメンテナンスプランをセットアップする必要があります。 だから、わたしは自分のSSISの一晩のプロセスが実行されたされてきた一方でSQLタスクを実行してバックアップを実行するために-基本的に実行されているmaster.dbo.xp_create_subdirフォルダが、その後存在し、先を確保するためにBACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT。 そのタスクが失敗すると、残りのプロセスは中止され、通知が届き、翌朝、トランザクションログのドライブがいっぱいになり、手動で切り捨てて先に進みます。 ..ストーリーが繰り返され、トランザクションログが再び使用可能なディスク領域を超えてしまうまで。 「手動切り捨て」スクリプトは次のようになります。 use Staging; alter database Staging set recovery simple alter database Staging set recovery full dbcc shrinkfile ('Staging_log', 0, truncateonly); go だから私はこれに飽きてきており、代わりに適切にやってみることを決心し、ここの手順に従って実際のメンテナンス計画を作成しました： ことは、私はこれを以前に行ったことがないので、いくつか質問があります。 このようなトランザクションログをバックアップすると、自動的に切り捨てられますか、それとも他に何かする必要がありますか？ データとトランザクションログのバックアップを同時に実行しても大丈夫ですか？そうでない場合、これを行う適切な方法は何ですか？ バックアップファイルは、サーバー上のすべてのファイルを取得して別の場所に保存する別のプロセスによって夜間に取得されます。2日後にバックアップセットを期限切れにするのは良い考えでしょうか。それらを完全に期限切れにする必要がありますか？ クリーンアップタスクは、のサブフォルダの下にある「古い」.bakファイルと.trnファイルをそれぞれ削除しますG:\Backups。それは理にかなっていますか？ バックアップが失敗した場合や失敗した場合にETLを失敗させることができるように、SSISでこれを行う方が良いでしょうか？それとも私のETLプロセスは気にすべきですか？ これが1つの投稿に対して多すぎる質問の場合は申し訳ありません。必要に応じて、編集して複数の質問をします。それらはすべて密接に関連していると思います。

9 sql-server  backup  sql-server-2014  transaction-log  maintenance-plans 

通常、運用サーバーから非運用サーバーへのDBの復元を実行するときは、WITH REPLACEオプションを使用します。 MSDNによれば、復元する前に実際にテールログをバックアップする必要があります。 データベースがオンラインであり、データベースで復元操作を実行する予定の場合は、まずログの末尾をバックアップします。オンラインデータベースのエラーを回避するには、BACKUP Transact-SQLステートメントの…WITH NORECOVERYオプションを使用する必要があります。 私がそれをしている方法のいくつかの危険または不利な点は何ですか？なぜ、最初にテールログをバックアップするのが有利なのですか？ 私はSQL Server 2008R2を使用していますが、このクエリはほとんどの新しいバージョンのSQL Serverにも関連していると考えられるため、最初はそのようにタグ付けしていません。

9 sql-server  restore  transaction-log 

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

9 sql-server  backup  transaction-log  recovery 

これは、プリンシパルデータベースのログファイルを圧縮できなかった理由に関する前の質問のフォローアップ質問です。 簡単に言うと、データベースミラーリングをセットアップしましたが、トランザクションログをバックアップしたジョブが再び実行されていることを忘れて、トランザクションログがほぼ60GBに増えました。 ミラーリングがセットアップされたため、このサイズの増加はミラーリングされたサーバーに複製され、最終的にすべてのディスク領域を占有し、ミラーデータベースを使用できなくなりました。 パーこの質問ミラーデータベースのトランザクションログのメンテナンスについて、あなたは鏡にログをバックアップすることはできませんが、ときに特異的に尋ねたコメントは、ミラーデータベース上の生い茂ったログファイルを縮小する方法について、コメントをすることを残っていました これを行う1つの方法は、ミラー化されたデータベースにフェールオーバーし、そこで縮小することです。これを非本番環境で徹底的にテストして、期待どおりの動作が期待できることを確認してください。 これは、ミラー上のログファイルを圧縮する他の方法が存在する可能性があることを示唆しているようであり、この方法は、必ずしも運用サーバーで安全に実行できるとは限りません。 データベースミラー上のトランザクションログファイルを安全に縮小する方法はありますか？

9 sql-server  transaction-log  mirroring 

SQL Server 2005を使用しています。集計情報を含む2つのテーブルがあります。情報は常に更新されており、1日にほぼ5GBのログデータが生成されます。（データベース全体よりも大きい！）ロールバックは本当に必要ないので、これらのテーブルのロギングを無効にしたいと思います。ただし、データベース内の他のテーブルにログオンし続けたいと思います。 データベース内の特定のテーブルのロギングを無効にすることは可能ですか？そうでない場合、2つのテーブルを同じスキーマに配置して、スキーマへのロギングを無効にできますか？2つのテーブルを別のデータベースに移動し、そこでログを無効にする唯一のオプションはありますか？ 更新： これらのテーブルのアクティビティをログに記録する必要がない理由を説明します。 2つのテーブルにはGPSデータが含まれているため、かなり大きくなります。最初のテーブルは、フィールド内の6つのAndroidテーブルから生の場所をキャプチャしています。各タブレットからの新しいデータは5〜10秒ごとに送信されます。その情報は、locationA、locationB、travelTimeとして集約されます。最終的には、実際の運転データに基づいて、すべての場所間の移動時間を最短にすることが目標です。データは小都市のみのものであり、小数点第4位までしか正確ではないため、管理可能です。ただし、新しい生データが入力されると、更新が必要な移動時間が遅くなり、新しい移動データが挿入される必要があります。 生データが集約されると、パージされます。長い移動時間に戻ることはないので、これらのテーブルではロールバックはそれほど重要ではありません。

9 sql-server  sql-server-2005  transaction-log 

SQL Server 2008 R2を使用しており、継続的な展開を通じてデータベースを作成しています。 私たちのシステムでは、SQL Serverのデフォルトの1Mb / 10％自動拡張設定は、データを適切に処理しません。特に、スキーマをあまり変更できないレガシーアプリケーションがあるためです。データベースの設定をインスタンスレベルで構成して、段階的な展開で変更できるようにします。 新しいデータベースのデフォルト設定が「モデル」の設定に基づいていることをいくつか読んだことがありますが、これはSQL Management Studio UIで新しいデータベースをクリックすることによってのみ機能し、スクリプト、たとえばCREATE DATABASE [MyDb]からは機能しないようです。 msdn.microsoft.com/en-us/library/ms186388(v=sql.105).aspx sqlservercentral.com/Forums/Topic1065073-391-1.aspx /programming/8828557/possible-to-configure-database-autogrowth-settings-at-the-instance-level/8828604#comment15586568_8828604 実際にこれを作成スクリプトで機能させる人はいますか？サーバーインスタンスごとに自動拡張を設定できる別の方法はありますか？

9 sql-server  transaction-log 

SQL Serverデータファイルを1つのハードドライブに配置し、トランザクションログを別のハードドライブに配置することのメリットを称賛する多くのブログ投稿とベストプラクティスの記事があります。理由は、トランザクションログにはシーケンシャルな書き込みしかありませんが、データベースファイルではランダムな読み取りと書き込みが発生するためです。 しかし、何百ものデータベースがある場合はどうでしょうか？数百のトランザクションログファイルを別のディスクに配置することには、本当にパフォーマンス上のメリットがありますか 複数のトランザクションログが書き込まれている場合、トランザクションログの書き込みはデータベースの書き込みと同じくらいランダムになると思います。

9 sql-server  transaction-log  hardware 

SQL Serverショップから来て、今はMySQLを使用しています。 MySQLのバイナリログとMSSQLのトランザクションログの違いは何ですか？ これまでの見通しでは、MSSQLのようにデータベースごとのトランザクションログとは対照的に、MySQLインスタンスごとに1つのバイナリログしかないようです。

9 sql-server  mysql  transaction-log 

私はトランザクションの初心者ですが、トランザクションログに関する質問です。トランザクションをコミットすると、変更はトランザクションログに書き込まれますが、トランザクションログはRAMまたは物理ファイルにありますか？RAM内にあり、システム障害が発生した場合、明らかにRAMが再消去されるため、トランザクション情報が失われるので、コミットを回復するにはどうすればよいでしょうか。

9 sql-server  transaction-log  transaction 

次のスニペットがあるとします。 -- error checking omitted for brevity begin tran exec database1..my_stored_procedure exec database2..my_other_stored_procedure if (@@error <> 0) rollback commit トランザクション情報はどのデータベースのトランザクションログに挿入されますか？ database1トランザクションログを再生しようとしても、そのDBだけに影響を与えるのでは意味がないので、両方のログがすべてのデータを取得すると思います。また、存在しないdatabase1サーバーでdatabase2はのトランザクションログを再生できず、その逆も同様です。 ..しかし、私は修正にオープンです！

9 sql-server  sql-server-2008-r2  transaction-log 

SQLデータベースに関する知識を集めようとしていますが、トランザクションログファイル（LDF）について質問があります。 まず、データベースを作成するときに、データベースとログファイルの両方の初期ファイルサイズを定義する必要があります。私が見ることができることから、ディスク上にファイルが作成されると、データベースに実際のデータがあるかどうか、またはトランザクション（ログ）があるかどうかに関係なく、指定されたサイズになります。 私の理解は、データベースをバックアップすることでした： トランザクションログを切り捨てます。 サイズを縮小します 内部のログを「空にする」ことによる、ディスク上のLDFファイルの削除。 ログファイルのサイズが固定されているように見えるため、これを正しく理解していないようです。私の実際の質問は次のようになります： ログの切り捨ては実際にログファイル（LDF）に対して何をしますか？このプロセスは、ディスクがいっぱいになるのを防ぐためのものです。 一部の概念を正しく理解していない場合は、修正してください。 ありがとうございました！

8 sql-server  transaction-log 

正しい方向に向けていただければ幸いです。私はT-SQLを頻繁に使用するわけではありませんが、グーグル操作をして、以下のスクリプトを見つけました。スクリプトを少し修正しました。 スクリプトで次のことを行います。 システムDBを除くすべてのデータベースを選択します。 リカバリをシンプルに設定します。 システムデータベースを除くすべてのdb（.ldf）のログファイルを圧縮するには スクリプト： USE MASTER declare @isql varchar(2000), @dbname varchar(64) declare c1 cursor for select name from master..sysdatabases where name not in ('master','model','msdb','tempdb','ReportServer','ReportServerTempDB') open c1 fetch next from c1 into @dbname While @@fetch_status <> -1 begin select @isql = 'ALTER DATABASE @dbname SET RECOVERY SIMPLE' select @isql …

8 sql-server  sql-server-2012  transaction-log  shrink  recovery-model 

週末にデータベースミラーリングをセットアップしましたが、トランザクションログをバックアップするジョブを再度有効にするのを忘れていました。私が今朝来たとき、トランザクションログは58GBに膨れ上がっており、ドライブ容量のほとんどを占めていました。 トランザクションログをディスクに手動でバックアップして、データベースを再度実行しましたが、DBCC SHRINKFILEを実行しても、トランザクションログファイルの物理的なサイズは小さくなっていません。 DBCC SHRINKFILE (N'MyDatabaseName_Log', 1000) を使用してログの使用状況を確認した場合 DBCC SQLPERF(LOGSPACE) 現在のログの22％だけが使用されていることがわかります データベース名ログサイズ（MB）ログ使用領域（％）ステータス MyDatabaseName 55440.87 22.38189 0 log_reuse_wait_descsys.databsesでチェックアウトした場合、表示される唯一のレコードはDATABASE_MIRRORINGなので、ログファイルの物理サイズが縮小されないのは、ミラーが役割を果たしていると思いますか？ SELECT log_reuse_wait_desc FROM sys.databases WHERE name = N'MyDatabaseName'; また、プリンシパルデータベースミラーリングの状態がSuspendedであることにも気付きました。再開することは、次のエラーですぐに失敗します。 データベース 'MyDatabaseName'のリモートミラーリングパートナーでエラー5149、ステータス1、重大度25が発生しました。データベースミラーリングが一時停止されました。リモートサーバーのエラーを解決してミラーリングを再開するか、ミラーリングを削除してミラーサーバーインスタンスを再確立します。 ミラーサーバーのエラーログにはこのエラーも含まれますが、ログファイルドライブがいっぱいであることに関するエラーも含まれます 物理ファイルを拡張しようとしたときに、MODIFY FILEでオペレーティングシステムエラー112（ディスクに十分なスペースがありません。）が発生しました。 そして F：\ Databaselogs \ MyDatabaseName_1.ldf：オペレーティングシステムエラー112（ディスクに十分なスペースがありません。）が発生しました。 プリンシパルサーバーのログファイルドライブには60 GBがあり（他のデータベースはここでホストされています）、ミラーサーバーには45 GBしかありません。 ログファイルをバックアップするとデータベースが再び使用できるようになりましたが、ディスク上の物理ログファイルのサイズを減らし、ミラーリングを再開したいと考えています。 ミラーリングやバックアップチェーンを犠牲にすることなく、物理トランザクションログファイルのサイズを縮小するにはどうすればよいですか？ SQL Server 2005を実行しています

8 sql-server  sql-server-2005  backup  transaction-log  mirroring