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

データベースのコンテキストでは、メンテナンスとは、モニタリング、チューニング、バックアップ手順など、データベースシステムに関連する日常的な運用タスクを指します。

4
他の人が接続されている間、強制的にデータベースを削除
PostgreSQL DBクラスターからデータベースを削除する必要があります。アクティブな接続がある場合でもどうすればよいですか?-forceフラグのようなものが必要です。これはすべての接続をドロップし、次にDBをドロップします。 どうすれば実装できますか? dropdb現在使用していますが、他のツールも使用できます。

5
データベースを縮小しても大丈夫ですか?
シュリンクは悪魔です。ページの順序を逆にし、皮膚がん、データの断片化、地球温暖化の原因となります。リストは続きます...つまり、100 GBのデータベースがあり、50 GBのデータを削除するとします。1つのテーブルではなく、データベース全体のレベルで古いデータを削除し、90%をカバーします。テーブル-これはデータベースを縮小するための適切なユースケースを構成しますか? そうでない場合、データベースからこのような高い割合のデータを削除した後に家をきれいにするために取る適切な手順は何ですか?インデックスの再構築と統計の更新の2つを考えることができます。ほかに何か?

5
SQL Serverメンテナンスプラン-タスクとスケジューリングのベストプラクティス
私は、SQL Server 2005データベースのメンテナンスプランを考案する必要があります。バックアップについては、毎日15分ごとにデータベースの完全バックアップとトランザクションログバックアップを行いたいと考えています。私が抱えている問題は、他にどのようなタスクをやりたいのか、どのくらいの頻度でそれらを行うべきなのかを把握することです。 それで、これまでのところ私はこれを念頭に置いています。私の考えに欠陥がある場合、またはこれを行うためのより良い方法がある場合は、私を修正してください。 バックアップ-すべてのテーブル、フルバックアップ(毎日) バックアップ-選択したテーブル、フルバックアップ(1時間ごと) バックアップ-トランザクションログ(15分ごと) データベースの整合性を確認する(毎日) インデックスの再編成(毎日) 統計の更新(毎日) データベースの縮小(毎週) インデックスの再構築(毎週) メンテナンスクリーンアップ(毎日) これらのタスクの一部は毎日実行する必要がないか、毎日実行するべきではないことを少し前に(別のジョブで同様の計画を設定したとき)読んだことを思い出しました。どのものに関しては、それは私を免れます。災害時のデータ損失を削減するより良いメンテナンスプランを作成するための少しのガイダンスを使用できますが、ピーク時の実行時にシステムに負担をかけません(そしてパフォーマンスも向上します)。

2
統計を更新するタイミング
以下を行うメンテナンスプランを継承しました。 古いデータをクリーンアップする DBの整合性をチェックします データベースとトランザクションログのバックアップを実行します インデックスを再編成します 統計の更新 古いバックアップとメンテナンスプランファイルを削除する 23分間のメンテナンスプランのうち、統計の更新には13分間という驚異的な時間がかかります。この13分間、データベースへのアクセスはブロックされます(または、少なくとも、このDBから他のデータベースへのレプリケーションは一時停止されます)。 私の質問は: 統計をいつ更新する必要がありますか? これは、毎日よりも頻繁に行うべきではないように思えます。私は、不必要なメンテナンスを行うという「理由」の考え方から抜け出そうとしています。

1
BACKUPコマンドのBUFFERCOUNT、BLOCKSIZE、およびMAXTRANSFERSIZEの設定
私を探しています実用的に値を設定するためのガイダンスBUFFERCOUNT、BLOCKSIZEおよび、MAXTRANSFERSIZEのBACKUPコマンド。私は少し調査を行い(以下を参照)、少しテストを行いました。本当に価値のある答えは「まあ、それは...」で始まることを十分に認識しています。私が行ったテストと私が見つけたリソースのいずれかに示されているテスト(以下の方法を参照)に対する私の懸念は、テストが真空で行われることです。ほとんどの場合、他の負荷のないシステムで行われます。 長期的な経験に基づいたこれらの3つのオプションに関する適切なガイダンス/ベストプラクティスに興味があります:数週間または数か月にわたる多くのデータポイント。そして、特定の値を探しているわけではありません。それはほとんどが利用可能なハードウェアの機能だからです さまざまなハードウェア/負荷要因が、実行すべき内容にどのように影響するか。 これらの値がどれもオーバーライドされるべきではない状況はありますか? すぐに明らかではないこれらのいずれかをオーバーライドするための落とし穴はありますか?メモリーやディスクI / Oを使いすぎていますか?復元操作を複雑にしますか? SQL Serverの複数のインスタンス(既定のインスタンスと2つの名前付きインスタンス)を実行しているサーバーがあり、3つのインスタンスすべてのバックアップを同時に実行すると、集合(BUFFERCOUNT* MAXTRANSFERSIZE)使用可能なRAMを超えていませんか?可能なI / O競合? 1つのサーバーで3つのインスタンスを使用し、3つすべてのバックアップを同時に同時に実行する同じシナリオで、各インスタンス内で複数のデータベースのバックアップを同時に実行すると、これらの値の設定にどのように影響しますか?つまり、3つのインスタンスのそれぞれに100個のデータベースがあり、各インスタンスごとに2つまたは3つのバックアップを同時に実行し、6から9のバックアップが同時に実行される場合。(この状況では、いくつかの大きなデータベースではなく、多くの中小規模のデータベースがあります。) これまでに収集したもの: BLOCKSIZE: サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および65536(64 KB)バイトです。[1] デフォルトは、テープデバイスの場合は65536、それ以外の場合は512です[1] CD-ROMへのコピーおよびCD-ROMからの復元を計画しているバックアップを作成する場合は、BLOCKSIZE = 2048 [1]を指定します 単一のディスクに書き込む場合、デフォルトの512で十分です。RAIDアレイまたはSANを使用する場合は、デフォルトまたは65536のどちらが優れているかをテストする必要があります。[13(18ページ)] 手動で設定する場合、値はデータファイルの作成に使用されるブロックサイズ以上でなければなりません。そうでない場合、次のエラーが表示されます。 メッセージ3272、レベル16、状態0、行3 'C:\ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak'デバイスのハードウェアセクターサイズは4096ですが、ブロックサイズパラメーターは互換性のない512のオーバーライド値。互換性のあるブロックサイズを使用してステートメントを再発行します。 BUFFERCOUNT: デフォルト[2]、[8]: SQL Server 2005以降のバージョン: (NumberofBackupDevices * [mystery_multiplier])+ NumberofBackupDevices +(2 …

3
メンテナンスプランでバックアップデータベースタスクを作成する際の「バックアップセットの有効期限:」オプションの使用方法
データベースのバックアップ中に、「バックアップセットの有効期限:」オプションを使用して、古いデータベースのバックアップを削除/上書きします。このオプションは使用できません。 メンテナンスプランの作成中に「バックアップセットの有効期限が切れる」オプションの使用方法に関するアドバイスを歓迎します。

5
SQL Serverを再起動すると速度が上がりますか?
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 一部のDBAがSQL Serverを非常に頻繁に、時には夜間でも再起動することに気付きました。メモリを解放するために、またはクエリを高速化するために、彼らがそれを行うと信じています。再起動後にクエリプランを再コンパイルする必要があることは知っていますが、それを含めて、このプラクティスに最終的なメリットがあるのではないかと考えています。 SQL Serverを毎日再起動すると、実行速度が向上するのは本当ですか?

1
ディスクスペースをオペレーティングシステムに戻すVACUUM
VACUUM通常、特別な場合を除いて、オペレーティングシステムにディスク領域を返しません。 ドキュメントから: 標準形式でVACUUMは、テーブルとインデックス内の無効な行バージョンを削除し、将来の再利用に使用可能なスペースをマークします。ただし、テーブルの最後の1つ以上のページが完全に空になり、排他的なテーブルロックを簡単に取得できる特別な場合を除いて、オペレーティングシステムに領域を返しません。対照的に、VACUUM FULLデッドスペースのない完全に新しいバージョンのテーブルファイルを書き込むことにより、アクティブにテーブルを圧縮します。これにより、テーブルのサイズが最小になりますが、時間がかかる場合があります。また、操作が完了するまで、テーブルの新しいコピー用に追加のディスク領域が必要です。 問題は、このデータベースの状態をどのone or more pages at the end of a table become entirely freeように達成できるかということです。これはを介して行うことができますがVACUUM FULL、実装するのに十分なスペースがありません。他の可能性はありますか?


4
SQL Server Expressのタスクスケジューラ
SQL Server 2008 R2 Expressエディションのデータベースで動作するASP.NET MVCアプリがあります。データベース内の一部のレコードを更新するには、定期的なタスクを実行する必要があります。 残念ながら、Express EditionにはSQLエージェントがありません。 どのアプローチをお勧めしますか?

2
DELETE + REORGがディスクスペース(DB2)を解放しないのはなぜですか?
DB2には、大きなバイナリデータを含むテーブルがあります。今、テーブル全体をパージし、runstats、reorg、runstatsを実行しましたが、使用されたディスク容量は変わりません。ここで何が間違っているのでしょうか? テーブルは、次のように作成した独自のテーブルスペースにあります。 CREATE BUFFERPOOL "MY_BP" SIZE 250 AUTOMATIC PAGESIZE 4096; CREATE LARGE TABLESPACE MY_TBS IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL MY_BP OVERHEAD 10.500000 TRANSFERRATE 0.140000 FILE SYSTEM CACHING; 私は次のように削除/再編成しました: DELETE FROM MY_TBL RUNSTATS ON TABLE MY_TBL WITH DISTRIBUTION AND DETAILED …

1
ページ数が1000未満のインデックスを再構築しませんか?
Ola Hallengrensスクリプトを使用して、インデックスをメンテナンスします。その前に、次のクエリを使用して、どのインデックスが最も断片化されているかを確認しました。 SELECT dbschemas.[name] as 'Schema', dbtables.[name] as 'Table', dbindexes.[name] as 'Index', indexstats.avg_fragmentation_in_percent, indexstats.page_count FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id] INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id] INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id] AND indexstats.index_id …

2
呼び出し側データベースコンテキストで実行する中央ストアドプロシージャ
sys.dm_db_index_physical_statsビューを使用して、カスタマイズされたメンテナンスソリューションに取り組んでいます。現在、ストアドプロシージャから参照されています。これで、そのストアドプロシージャがデータベースの1つで実行されると、必要な処理が実行され、データベースに関するすべてのレコードのリストがプルダウンされます。別のデータベースに配置すると、そのDBのみに関連するすべてのレコードのリストがプルダウンされます。 例(下部のコード): データベース6に対して実行されたクエリは、データベース1〜10の[要求された]情報を示します。 データベース3に対して実行されたクエリは、データベース3のみの[要求された]情報を表示します。 特にデータベース3でこの手順が必要な理由は、同じデータベース内にすべてのメンテナンスオブジェクトを保持したいからです。このジョブをメンテナンスデータベースに配置し、あたかもそのアプリケーションデータベースにあるかのように動作させたいと思います。 コード: ALTER PROCEDURE [dbo].[GetFragStats] @databaseName NVARCHAR(64) = NULL ,@tableName NVARCHAR(64) = NULL ,@indexID INT = NULL ,@partNumber INT = NULL ,@Mode NVARCHAR(64) = 'DETAILED' AS BEGIN SET NOCOUNT ON; DECLARE @databaseID INT, @tableID INT IF @databaseName IS NOT NULL AND @databaseName NOT IN ('tempdb','ReportServerTempDB') BEGIN …

4
メンテナンスプランジョブでローカルサーバー接続を変更または更新する方法
2日前に、クライアントが開発サーバー名の1つを変更しました サーバーの名前が変更された後、サーバー名が一致しないため、すべてのメンテナンスジョブおよびその他のジョブが失敗します。 私たちは、使用しているSQL Server 2012のバージョンとサーバー2008 OSを だから今日の朝、私はSQL Server 2012の名前を名前を更新して名前を変更し、テーブル、手順を更新しました メンテナンスジョブでローカルサーバー接続を更新しようとしましたが、編集できません。次に、新しいサーバー接続を追加しましたが、ジョブを実行中にエラーが発生することはありません。 ジョブプロパティオプションのターゲットページで試した後、ターゲットサーバーのみが選択され、複数のターゲットサーバーが無効になっています。 以下のエラー ユーザーとして実行:NT Service \ SQLSERVERAGENT。64ビット版Microsoft(R)SQL Server Execute Package Utilityバージョン11.0.2100.60 Copyright(C)Microsoft Corporation。全著作権所有。 開始:12:01:28 AMエラー:2013-12-16 00:01:43.98コード:0xC00291ECソース:{410F7661-F71A-4B68-9584-BA422AB00F02} SQLタスクの実行の 説明:接続「ローカルサーバー接続」の取得に失敗しました。接続が正しく構成されていないか、この接続に対する適切な権限がない可能性があります。終了エラー エラー:2013-12-16 00:02:00.00 コード:0xC0024104 ソース:Territory_Update 説明:タスクのExecuteメソッドがエラーコード0x80131904を返しました(SQL Serverへの接続の確立中にネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできませんでした。インスタンス名が正しいことと、 SQL Serverは、リモート接続を許可するように構成されています(プロバイダー:名前付きパイププロバイダー、エラー:40-SQL Serverへの接続を開けませんでした)。Executeメソッドは成功し、「out」パラメーターを使用して結果を示す必要があります。終了エラー エラー:2013-12-16 00:02:15.00 コード:0xC0024104 ソース:{4E2AF328-0B8D-4905-83BE-839FDDEFC09C} 説明:タスクのExecuteメソッドがエラーコード0x80131904を返しました(SQL Serverへの接続の確立中にネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないかアクセスできませんでした。インスタンス名が正しいことと、 SQL Serverは、リモート接続を許可するように構成されています(プロバイダー:名前付きパイププロバイダー、エラー:40-SQL Serverへの接続を開けませんでした)。Executeメソッドは成功し、「out」パラメーターを使用して結果を示す必要があります。 終了エラーDTExec:パッケージ実行はDTSER_FAILURE(1)を返しました。 開始:12:01:28 AM 終了:12:02:15 AM …

4
autovacuumがオンになっている場合、PostgreSQLデータベースを手動でVACUUMする必要がありますか?
私は大きなPostgreSQLデータベース(その中に百万行を持つテーブルがある)と、開発者は、私がすべきと言うするソフトウェアを使用VACUUMしてANALYZE定期的に。ただし、PostgreSQLデータベースのデフォルトはautovacuumオンになっています。 まったく掃除機をかける/分析する必要がありますか?利点は何ですか?自動真空と手動真空の違いは何ですか たとえば、Pgadmin3では、これがあります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.