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

これは、ほとんどのフォーラムやWeb全体でよくある質問のようです。ここでは、一般的に次のような多くの形式で質問します。 SQL Serverで- トランザクションログが非常に大きくなる理由は何ですか？ ログファイルが非常に大きいのはなぜですか？ この問題の発生を防ぐ方法は何ですか？ 根本的な原因を追跡し、トランザクションログファイルを正常なサイズにしたい場合はどうすればよいですか？

264 sql-server  transaction-log  shrink  auto-growth  recovery-model 

TEMPDBデータベースのトランザクションログを実際に埋めている正確なクエリまたはストアドプロシージャを識別する方法を知りたいです。

65 sql-server  sql-server-2008  sql-server-2005  transaction-log  tempdb 

データ用にディスク上に4.3 GBを使用する64m行のテーブルがあります。 各行は約30バイトの整数列に加えて、NVARCHAR(255)テキスト用の可変列です。 data-typeのNULLABLE列を追加しましたDatetimeoffset(0)。 次に、すべての行でこの列を更新し、すべての新しい挿入でこの列に値が配置されるようにしました。 NULLエントリがなくなったら、このコマンドを実行して新しいフィールドを必須にしました。 ALTER TABLE tblCheckResult ALTER COLUMN [dtoDateTime] [datetimeoffset](0) NOT NULL その結果、トランザクションログサイズが大幅に増加しました。スペースがなくなるまで、6GBから36GBを超えました。 SQL Server 2008 R2がこの単純なコマンドでこのような大きな成長をもたらすために一体何をしているのか、誰にもわかりませんか？

56 sql-server  sql-server-2008-r2  transaction-log  alter-table  null 

について質問がありXTP_CHECKPOINTます。 SQL Server 2014を使用しています。シンプルリカバリモデルモードのデータベースがあります。また、複製されています。 開いているトランザクションはありません。私は実行しDBCC OPENTRAN、それが返されます： 「アクティブなオープントランザクションはありません。」 しかし、テーブルを作成または削除、またはデータを削除しようとするたびに、このメッセージが表示され続けます （実際のデータベース名をに置き換えましたdatabase_name）。 「データベース「database_name」のトランザクションログは、「XTP_CHECKPOINT」が原因でいっぱいです」 なぜこれが起こっているのか誰も知っていますか、そしてもっと重要なことは、どうすればそれを止めることができますか？ そして、はい、データベースは本当に単純復旧モデルモードです。つまり、トランザクションログは自動的に切り捨てられます。 ちなみに、完全復旧モードで使用している別のデータベースは同じことを行い、同じエラーを返し始めました。 データベース 'database_name'のトランザクションログは、 'XTP_CHECKPOINT'が原因でいっぱいです。 ログの増加設定を無制限の増加に変更しようとしましたが、同じエラーが返されてしまいました。 ファイルグループのみを除いて、XTPを一切使用せずに問題を再現できます。方法は次のとおりです。http：//pastebin.com/jWSiEU9U

26 sql-server  sql-server-2014  transaction-log  memory-optimized-tables 

すぐに重複としてマークする前に、Mike Walshの「なぜトランザクションログが増え続けるか、スペースが足りないのですか？」を読みました。、しかし、それが私の状況に答えを与えたとは思わない。私は十数個の同様の質問に目を通しましたが、関連する質問のほとんどは「重複」と言って、マイクの質問を指しています。 詳細：SQL Server 2008 R2には約500MBのデータベースがあり、すべてSIMPLEリカバリモード（選択ではありません）、夜間フルバックアップ、最大200MBのデータファイル、および約300MBのログファイルがあります。ログはすぐに300MBに拡大するのではなく、数か月かけてゆっくりと拡大します。少なくともsp_who2とアクティビティモニターによれば、それらのいずれにもオープントランザクションはありません。データベースを右クリックしてプロパティを選択すると、最大50MBの空きがあることがわかります。特にバックアップ直後は、ログ全体を解放すべきではありませんか？SIMPLEモードでは、開いているトランザクションがない限り、ログは解放されませんか？ log_reuse_wait_descfrom sys.databasesは「NOTHING」と言っており、上記の質問と回答に基づいて、スペースを再利用するために何も待つべきではないことを示しています。 「DBCC SHRINKFILE」を実行すると、ログファイルが1MBに縮小されるため、スペースを再利用できます。毎週ログを圧縮し、制御不能にならないように設定することはできますが、SQL Serverがそれを行う理由について混乱しています。 ログに300MBを必要とするクレイジーなトランザクションがあったかどうかはわかりますが、極端なことはしていません。基本的なOLTPだけです。マイクの質問/回答から： 単純復旧モデル-したがって、上記の概要では、最初に単純復旧モデルについて説明するのが最も簡単です。このモデルでは、SQL Serverに通知しています-クラッシュと回復の再開にトランザクションログファイルを使用しても問題ありません（実際には選択の余地はありません。ACIDプロパティを検索し、すぐに意味をなすはずです）。クラッシュ/リスタートリカバリの目的でこれが必要になったら、ログファイルを再利用してください。 SQL Serverは、シンプルリカバリでこのリクエストをリッスンし、クラッシュ/リカバリの再開に必要な情報のみを保持します。データがデータファイルに（多少なりとも）強化されているためにSQL Serverが回復できることが確認されると、強化されたデータはログに不要になり、切り捨てのマークが付けられます。つまり、再利用されます。 ログスペースを再利用する必要があると言われ続けていますが、数か月にわたるこの緩やかな成長により、そうではないようです。 私は何が欠けていますか？SQL Serverがデータを「強化された」ものとして認識し、ログを解放できないようにしているのでしょうか？ （編集） アフターアクションレポート-ちょっとした知識は危険です これが「一般的な質問」であることがわかった後、7か月前に何が起こったのか、他の人々に悲しみを救うために学んだことを説明する義務があると感じました。 まず、データベースのプロパティを表示したときにSSMSに表示される使用可能な領域は、データファイルで使用可能な領域です。これを表示するには、データベースで次のコマンドを実行します。SSMSによって報告される使用可能な領域は、FileSizeMBとUsedSpaceMBの違いです。 SELECT DB.name, MF.physical_name, MF.type_desc AS FileType, MF.size * 8 / 1024 AS FileSizeMB, fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB, mf.name LogicalName FROM sys.master_files MF JOIN …

24 sql-server  sql-server-2008-r2  transaction-log 

350 MBのデータファイル（.mdf）と4.9 GBのログファイル（.ldf）を持つデータベースがあります。復旧モデルはに設定されFULLます。 ログファイルを圧縮しようとしても、圧縮されません。 データベースの縮小は良くないことを知っています。しかし、私はまだログファイルを縮小するためにそれをやろうとしています。 走ったとき DBCC SQLPerf(logspace) ログサイズは4932 MBで、使用されるログ領域は98.76％であることがわかりました。 それから私はこのコマンドを試しました USE <databasename>; DBCC loginfo; 現在、ほとんどすべてのVLFは「ステータス2」であり、すべてが使用中であることを意味します。 ログのバックアップを取り、ログファイルを圧縮しようとしました。縮小してもサイズは小さくなりませんでした。 復旧モデルをに変更し、SIMPLE再度縮小しようとしましたが、これも役に立ちませんでした。 未処理のトランザクションを確認しました DBCC opentran (database); 現在開いているトランザクションがないことがわかりました。 ログファイルの縮小を妨げているのは何ですか？どうすれば解決できますか？

23 sql-server  transaction-log  dbcc  database-size  shrink 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 トランザクションログのサイズを50 GBに事前に割り当てた複数のマシンがあります。再編成しようとしているテーブルのサイズは55〜60 GBですが、継続的に増加します。私が再編成したい主な理由は、スペースを再利用することであり、それによるパフォーマンス上の利点は追加のボーナスです。 テーブルの断片化レベルは30〜35％です。これらのマシンの一部では、「トランザクションログがいっぱいです」エラーが発生し、再編成が失敗します。トランザクションログのサイズは最大48GBに達します。これに対抗する良い方法は何ですか？自動インクリメントをオンにしていません。これを行うのは嫌です。 ログサイズをより大きな値に増やすことはできますが、将来テーブルサイズが大きくなると、値が十分ではなくなる可能性があります。また、ログサイズを均等に増やしようとすると、スペースを再利用するために再編成を行う目的が無効になります。これに効果的に対処する方法についてのアイデアはありますか？データ損失は許容されないため、バルクモードの使用はオプションではありません。

19 sql-server  sql-server-2008  transaction-log  index-maintenance 

というSQL Server 2005テーブルBRITTNEY_SPEARS_MARRIAGESがあり、次の列があります。 MarrigeId tinyint, HusbandName varchar(500), MarrigeLength int 今、私は別のテーブルを持っています BRITTNEY_SPEARS_MARRIAGE_STORIES StoryId int, MarriageId tinyint, StoryText nvarchar(max) 問題は、私たちが更新したいですMarrigeIdに列をintからtinyint。私たちは、ブリトニーがすべてのことを言って成し遂げる前にたくさんの結婚をするだろうと感じています。 現在、BRITTNEY_SPEARS_MARRIAGE_STORIESテーブルには1800万行があり（女の子に問題があるので）、更新を行うとトランザクションログがいっぱいになり、SQL Serverボックスが停止します。 どうすればこれを回避できますか？ とにかく「SQL Serverをこの列を更新して大きくします。このSQL Serverで信頼してください。すべての検証を試みている間、トランザクションログをいっぱいにしないでください」と言うことはできますか？

18 sql-server  sql-server-2005  transaction-log 

私たちは、使用しているAlwaysOn Availability Group2012年の正規完全データベースバックアップとトランザクションログのバックアップがセカンダリデータベース上で毎日行われているSQL Serverの機能を。 私は読んだことが、ここでのプライマリレプリカまたはセカンダリレプリカのいずれかにトランザクションログのバックアップを行うことは、再利用可能なよう両方のレプリカトランザクション・ログをマークします。とにかく、トランザクションログのバックアップサイズは大きく、縮小ファイルを使用して縮小できます。 データベースをローカルに復元し、縮小操作を実行しました。ログファイルのサイズは160 MBに縮小されました。 私の質問は、どのデータベースでトランザクションログファイル（プライマリ、セカンダリ、またはその両方）の縮小操作を実行する必要があるかということです。 過去数年間、ログファイルのバックアップは作成されていなかったため、非常に大きくなりました。実行するDBCC SQLPERF (LOGSPACE)と0.06%、ファイルのみが使用されていることがわかります。このような巨大なサイズのログファイルを保持する意味はありません。で[sys].[database_files]、私はそのことを確認してくださいがmax_sizeに設定されている-1とgrowthする65536ことは、それが得るより多くのスペースを必要とするとき、私は推測するようにします。とにかく、将来の成長を防ぐために、たとえば5％に縮小できます。私はそうすることは悪い考えではないという確認を見つけようとしています。 実際、（データベースとログファイルの）バックアップはセカンダリデータベースでのみ実行されるため、それらのデータベースでシュリンクファイルを実行する方が簡単ですが、プライマリログファイルのサイズも小さくなりますか？

17 sql-server  sql-server-2012  transaction-log  shrink 

SQL Server Centralスレッドで見た完全バックアップはログを切り捨てますか？その完全バックアップはログを切り捨てません： いいえ。完全バックアップでも差分バックアップでも、トランザクションログは切り捨てられません。- リン・ペティス はありません-フルバックアップは、ログを切り捨てません。- チャド・クロフォード それでは、完全バックアップとコピーのみの完全バックアップの違いは何ですか？ ログバックアップには、ログを切り捨てずにログチェーンが壊れないようにするコピーのみのバックアップがあります。では、コピーのみの完全バックアップとは何ですか？

17 sql-server  sql-server-2008-r2  backup  transaction-log 

tl; dr：CHECKDBがメモリ最適化テーブルを持つユーザーデータベースのトランザクションログを読み取るのはなぜですか？ CHECKDBは、データベースの1つ（特に、インメモリOLTPテーブルを使用するデータベース）をチェックするときに、ユーザーデータベースのトランザクションログファイルを読み取っているようです。 このデータベースのCHECKDBはまだ妥当な時間内に終了するため、ほとんどの場合、動作に興味があります。ただし、このインスタンス上のすべてのデータベースのCHECKDBの期間は間違いなく最長です。 Paul Randalの叙事詩「あらゆる角度からのCHECKDB：すべてのCHECKDBステージの完全な説明」を見ると、データベースの一貫性のあるビューを取得するために、SQL 2005より前のCHECKDB がログを読み取っていたことがわかります。ただし、これは2016年なので、内部データベーススナップショットを使用します。 ただし、スナップショットの前提条件の 1つは次のとおりです。 ソースデータベースにMEMORY_OPTIMIZED_DATAファイルグループを含めることはできません ユーザーデータベースにはこれらのファイルグループのいずれかがあるため、スナップショットがテーブルから外れているように見えます。 CHECKDBドキュメントによると： スナップショットを作成できない場合、またはTABLOCKが指定されている場合、DBCC CHECKDBはロックを取得して必要な整合性を取得します。この場合、割り当てチェックを実行するには排他的なデータベースロックが必要であり、テーブルチェックを実行するには共有テーブルロックが必要です。 さて、スナップショットの代わりにデータベースとテーブルのロックを行っています。しかし、それでもトランザクションログを読み取る必要がある理由は説明されていません。それで何が得られますか？ シナリオを再現するために、以下のスクリプトを提供しました。それは使用していますsys.dm_io_virtual_file_statsログファイルの読み取りを識別するためします。 ほとんどの場合、ログの小さな部分（480 KB）を読み取りますが、それよりもはるかに多く（48.2 MB）を読み取ります。私の実稼働シナリオでは、CHECKDBを実行する深夜に、毎晩ほとんどのログファイル（2 GBファイルのうち約1.3 GB）を読み取ります。 スクリプトでこれまでに得た出力の例を次に示します。 collection_time num_of_reads num_of_bytes_read 2018-04-04 15:12:29.203 106 50545664 またはこれ： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:25:14.227 1 491520 メモリ最適化オブジェクトを通常のテーブルに置き換えると、出力は次のようになります。 collection_time num_of_reads num_of_bytes_read 2018-04-04 15:21:03.207 0 0 CHECKDBがログファイルを読み取るのはなぜですか？そして特に、なぜログファイルのはるかに大きな部分を時々読むのですか？ 実際のスクリプトは次のとおりです。 -- let's …

16 sql-server  sql-server-2016  transaction-log  dbcc-checkdb 

私は、SQL Server 2008 r2のデータコレクターを介して2週間、ファイルの増加を監視しています。データベースは、約35（MB）/日で一貫して成長しています。DBは初期サイズの2 GBにまだ達していません。 DBファイルの自動拡張は5MBに設定されています。別のアプローチを試してみたいので、提案やコメントを探しています。 毎週日曜日の夜1:30 AMに実行されるチューニングタスクがあります。タスクは： データベースの整合性を確認する ログファイルを圧縮する-（ログモードがシンプルなので、これは問題ありません） データベースの縮小 インデックスの再編成 インデックスを再構築 統計を更新する 履歴をクリーンアップする 毎週の調整計画にさらに2つのステップを追加したいと思います。 使用領域が特定のしきい値または合計サイズに達した場合、データベースファイルを500 MB増やします。 使用されているスペースが合計サイズの特定のしきい値に達すると、ログファイルを250 MB（縮小後）増やします。 オフラインの時間に成長の負担をかけることにより、高負荷時の自動成長イベントの数を減らしてパフォーマンスを向上させたいと考えています。 自動拡張ファイルに関する質問が2つあります。 ファイルの成長ステップを配置する最適な場所は、現在のステップの前か後ですか？ を使用しALTER DATABASE|MODIFY FILEてファイルを拡大すると、どうすれば判断できSpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)ますか？

16 sql-server  sql-server-2008  sql-server-2008-r2  transaction-log  best-practices 

PCのローカルSQL Server Developer Edition 12.0.2000.8に開発目的でデータベースを設定しようとしています。データベース全体のバックアップと、ネットワーク経由で送られてきたトランザクションログ専用のバックアップファイルが用意されています。 完全バックアップから復元しようとすると、しばらくして（おそらく1時間以内に、データベースのサイズが〜270 GBになります）、エラーが発生します： System.Data.SqlClient.SqlError：データベース 'database name'のログの処理中にエラーが発生しました。可能であれば、バックアップから復元します。バックアップが利用できない場合、ログを再構築する必要があるかもしれません。（Microsoft.SqlServer.SmoExtended） この後、データベースは「復元中」状態になります。 私は次のようなものを実行したかった（この質問からそれを得た） ALTER DATABASE recovery_test_2 SET EMERGENCY; ALTER DATABASE recovery_test_2 SET SINGLE_USER; DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS; それに対して、データベースが「復元中..」状態にあるため、当然のことながらできません。復元プロセスを再起動しても同じエラーメッセージが表示され、ドロップと復元は再び役に立ちませんでした。 データベースを起動して動作させるにはどうすればよいですか？トランザクションの一貫性は私には関係ありません。 SSMS自動生成復元スクリプト： USE [master] RESTORE DATABASE [database_name] FROM DISK = N'D:\database_name.bak' WITH FILE = 1, MOVE N'database_name' TO N'D:\MSSQL\MSSQL12.MSSQLSERVER\MSSQL\DATA\database_name.mdf', MOVE …

14 sql-server  restore  sql-server-2014  transaction-log 

MySQLについて読んだことがあります。私の意見では、2つのログタイプは非常に似ていると思います。MySQLは、データがログで変更される方法とタイミングを保存します。情報はMySQLの回復に使用されます。2つのログタイプの機能を混同しています。

14 mysql  transaction-log 

私はさまざまなシナリオで最小限のロギング挿入をテストしており、TABLOCKを使用して非クラスター化インデックスを持つヒープにINSERT INTO SELECTを読んだことから、SQL Server 2016+は最小限に記録する必要がありますが、これを行うときは完全なロギング。私のデータベースは単純な復旧モデルであり、インデックスとTABLOCKを使用せずに、ヒープ上に最小限のログが挿入されます。 Stack Overflowデータベースの古いバックアップを使用してテストし、次のスキーマでPostsテーブルの複製を作成しました... CREATE TABLE [dbo].[PostsDestination]( [Id] [int] NOT NULL, [AcceptedAnswerId] [int] NULL, [AnswerCount] [int] NULL, [Body] [nvarchar](max) NOT NULL, [ClosedDate] [datetime] NULL, [CommentCount] [int] NULL, [CommunityOwnedDate] [datetime] NULL, [CreationDate] [datetime] NOT NULL, [FavoriteCount] [int] NULL, [LastActivityDate] [datetime] NOT NULL, [LastEditDate] [datetime] NULL, [LastEditorDisplayName] [nvarchar](40) NULL, …

14 sql-server  transaction-log