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

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

3
ベストプラクティスのSQL Serverメンテナンスプランはどのようなものですか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私はアイントホーフェンのフォンティス大学の学生です。現在、SQL Serverツールの開発を支援するために一連のインタビューを実施しています。この分野の専門家からフィードバックをもらいたいと思います。 私の質問の1つは次のとおりです。 ベストプラクティスのSQL Serverメンテナンスプランはどのようなものですか？これにはSQL Serverメンテナンスプランを使用しますか、それともカスタムスクリプトを使用しますか？
5
sys.dm_db_index_physical_statsのパフォーマンスを改善する
メンテナンスジョブ中に、断片化されたインデックスのリストを取得しようとしています。しかし、クエリは非常に遅く、実行に30分以上かかります。これはsys.dm_db_index_physical_statsのリモートスキャンによるものだと思います。 次のクエリを高速化する方法はありますか？ SELECT OBJECT_NAME(i.OBJECT_ID) AS TableName, i.name AS TableIndexName FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat INNER JOIN sys.indexes i ON i.OBJECT_ID = phystat.OBJECT_ID AND i.index_id = phystat.index_id WHERE phystat.avg_fragmentation_in_percent > 20 AND OBJECT_NAME(i.OBJECT_ID) IS NOT NULL ORDER BY phystat.avg_fragmentation_in_percent DESC 私はDBAではないので、上記のクエリで明らかな間違いを犯している可能性があります。または、役立つインデックスまたは統計があるかもしれません。たぶん、それはデータベースのサイズだけです（約140のテーブルで約20Gb）。 私が尋ねる理由は、夜中にメンテナンスのための非常に小さなウィンドウしかなく、これがほとんどの時間を占めているからです。
6
SQL Serverチェックリスト
私の他の質問に続いて、アラートの観点から、毎日/毎週/毎月のベースで何を検討すべきかについて考え始めたいと思います。私は問題が起こる前に来ることを見ることができることを望んでいます（それは計画です）... これまでのところ、次のスクリプトを収集し始めました（順序なし）： 毎日 システムの稼働時間を確認します（DBAとして何かを確認する必要がある場合に備えて） 最後のバックアップを確認する トランザクションログのバックアップを確認する SQLジョブのステータスを確認する 過去24時間（または1140分）の平均CPU使用率を確認します 毎週 MSDBバックアップ履歴を確認する CheckDBが最後に実行された時刻を確認する インデックスの断片化を確認する インデックスの統計を確認します（読み取りと書き込みなど） IOのボトルネックを確認する 毎月 不足しているインデックスを確認する 使用されなくなったインデックスを確認する 他の提案はありますか？（私はDBAが初めてなので、どんなヘルプ/アドバイスもいつでも歓迎します）
1
PostgreSQLで（AUTO）VACUUMプロセスをキャンセルすると、すべての作業が無駄になりますか？
場合によっては、大量のを作成した後update、insertまたはdeleteテーブルからVACUUM FULL ANALYZE、DBが肥大化していないことを確認するためにを開始しました。本番データベースでこれを行うと、長期間テーブルをブロックすることができたため、これは良いアイデアではなかったことがわかりました。それで、私はプロセスをキャンセルしました、多分ちょうどVACUUM（完全ではない）試みたか、AUTOVACUUMそれができることは何でも後でやらせ​​ます。 問題は、VACUUMまたはAUTOVACUUMを「途中」で停止すると、すでに実行されたすべての処理が失われるのですか？ たとえば、VACUUMすでに100万のデッド行が見つかって停止した場合、この情報はすべて失われますか？VACUUMは完全にトランザクション的な方法で動作しますか（非常に多くのPostgreSQLプロセスのように、「すべてまたは何もない」）？ すべての作業を失うことなくVACUUMを安全に中断できる場合、vacuum作業を段階的に行う方法はありますか？[100 ms動作し、停止し、10 ms待機して、残りの世界をブロックしないようにします...]。autovacuumパラメータを調整することでこれの一部を実行できることはわかっていますが、これをプログラムで制御できること、特定の時間/特定の条件下でそれを実行できるようにすることについて考えています。 注：プロセスを停止/キャンセル/強制終了するとは、次のことを意味します。 pgAdminを使用している場合は、[クエリのキャンセル]ボタンを押します。 プログラムで作業する場合は、pg_cancel_backend（）を呼び出します。 どちらも同等だと思います。シェル/システムレベルのkillコマンドは使用していません。
1
SQL Server 2008 R2インデックスの再構築が重大度17で失敗する
インデックスのメンテナンス中に、SEV 17エラーでジョブが失敗し、再構築中のオブジェクトに十分なスペースを割り当てられないことがあります。データベースは次のようにレイアウトされます。 Data_file1 PRIMARY 0 growth 0% free Max Size UNLIMITED Data_file2 PRIMARY 0 growth 0% free Max Size UNLIMITED Data_file3 PRIMARY 0 growth Less than 1% free Max Size UNLIMITED Data_file4 PRIMARY 250 MB growth Less than 1% free Max Size UNLIMITED 基本的に、4つのデータファイルのうち3つがいっぱいで成長が許可されず、4つ目がいっぱいで成長が許可されています。ファイルはさまざまなLUNに分散しています（そして、その理由は面倒です）。そのため、オンラインインデックスの再構築が開始されると、追加のスペースが必要な場合、Data_file4に成長して問題ないことを理解していますが、成長が許可されておらず失敗する別のファイルに成長しようとしているようです。このエラーを再現することはできませんが、なぜこれが発生するのかについての洞察を誰かが持っているかどうか疑問に思っていました。 SQL Serverの完全バージョンは2008 R2 Enterprise、SP2 CU 4（10.50.4270）です。Ola …
1
PostgreSQLデータベースデータファイルの整合性チェック
PostgreSQLデータベースシステムを実行している場合、データベース全体の整合性が100％であることをどのように知ることができますか？基本的に、破損していないデータファイルとページがすべて100％良好であるかどうかを知るにはどうすればよいですか？ Microsoft SQL Serverの世界には、問題があるかどうかを通知するDBCC CHECKDBを実行できるコマンドがあります。コマンドの詳細を知りたい場合は、次のリンクをご覧ください。DBCC CHECKDB（Transact-SQL） 私は妄想的なデータベース整合性を重視している人であり（DBAタイプの役割でデータベースを操作する人なら誰でもそうするべきです）、この種のことは夜によく眠れないようにします。このようなユーティリティは必須です！グーグルでの検索では、このようなツールでいくつかの試みが見つかりましたが、PostgreSQLプロジェクトで公式に承認されたツールでない限り、私はこの重要なものを信用しません。 ここに、私が本当の決定的な答えとは思わないもので、同様の質問をする人々へのいくつかのリンクがあります。そして私の意見では、PostgreSQLはOracleとMicrosoft SQL Serverが持っているように見えるいくつかのツールを用意する必要があることを示しています。 最初のリンクは、このテーマで見つけた最も興味深いものです。おそらくそれを要約する記事へのコメントは、「Postgresはデータベースの破損を特定して修復するのはかなり不自由です。それを検出する唯一の方法は、データベースをダンプするか、データベース内のすべてのテーブルから*を選択することです」 」 PostgreSQLが部分的なページ書き込みとデータ破損から保護する方法 データとインデックスファイルの破損の確認-Dev Shed ヘルプ：テーブルが壊れています！ PostgreSQL：破損した主キー、一貫性のないテーブル 9.3にはいくつかの破損チェック機能がある可能性があると思います。必要に応じて、ページファイルのチェックを合計することを希望する可能性があります。そのため、ZFSやPostgresの将来のバージョンでページチェックサミングを使用することを検討している場合、状況は明るいように見えます。 https://commitfest.postgresql.org/action/patch_view?id=759 更新：2012年1月14日-ZFSに基づくファイルシステムを使用すると、データの各ブロックを合計してチェックすることで破損を検出できるようです。私はこれをさらに調べ、これがデータベースデータが静かに破損していないことを知って夜寝るのを可能にする回避策であるかどうかを確認する必要があります。 更新：2012年1月17日-ZFSで破損しているファイルを見つける方法。http://docs.oracle.com/cd/E18752_01/html/819-5461/gbbwl.html#gbcuz 更新：2014年4月14日9.3でデータチェックサムが取得されました。https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.3
5
SQL Serverバックアップ-いくつかの質問
金曜日の午後9時に毎週のバックアップジョブを実行しますが、ディスクスペース（時々非常に低くなります）とパフォーマンスに関するいくつかの問題が発生しています。何が起こるかを合理化/最適化することを検討しており、コメントをお待ちしています。 具体的には： バックアッププロセスは、バックアップ中に統計を更新するのに約4時間かかります。このプロセスを安全に無効にして時間を節約できますか？ ディスクスペースが非常に頻繁に不足しているため、プロセスを再調整する必要があるかと考えています。現在、バックアップを作成してから以前のバックアップを削除しますが、これがディスク容量を圧迫しています。最初に以前のものを安全に削除してからバックアップを実行できますか？ その他のコメントや意見は大歓迎です編集：サーバー上のSQLファイルの合計サイズは約35GBです。1つのデータベースのサイズは約25GBで、他の6つの共有は他の10GB程度を占めています。
2
行レベルとページレベルのロックの違いと結果
メンテナンスプランを実行しようとすると、次のエラーが表示されます。 クエリ ""の実行が次のエラーで失敗しました： "ページレベルロックが無効になっているため、テーブル" "のインデックス" "（パーティション1）を再編成できません。" 現在、このインデックスで行レベルのロックが有効になっています。ページレベルのロックを有効にすることはできますが、どのような影響があるのか​​わかりません。 私の質問は次のとおりです。2つのロックスキームの違いは何ですか、そして実際の（運用中の）結果は何ですか？
3
データベースを安全に完全に削除するためのベストプラクティスは何ですか？
私たちは「有機的な」環境を持っています。つまり、人々は最小限の監視またはドキュメント化でコードにコードを10年間積み上げてきました。私が使用しているサーバーには、もう使用されていないと思われるいくつかのデータベースがあります。それらを削除して、実際に使用している3つだけを残したいです。 無謀な極端では、これらのデータベースを無効にして、誰かが悲鳴を上げるのを待つことができました。もう一方では、「念のため」、それらを永久に実行したままにすることができます。サーバーが使用されているかどうか、およびその方法を特定する上で、どのような手順が重要であると思いましたか？ また、システムを無効にすることで前進するときに、一定期間便利に元に戻せるようにするためにどのような手順を推奨しますか（オブジェクトを完全に削除するのではなく、名前を変更するなど）？ ありがとう！
2
SQL 2005：インデックスの再構築ジョブがデータベースログファイルをどれだけ拡張できるかを判断できますか？
SQL Server 2005で、すべてのデータベースがフルモード（1時間ごとのトランザクションログバックアップを使用）である場合、データベースのすべてのインデックスを再構築してデータベースのログファイルを拡張できるかどうかを判断できますか？そして、それはどれくらい成長することができますか？ 正解がない場合は、どのような指示もいただければ幸いです。 前もって感謝します。
2
Cassandra：メンテナンス
私はCassandraに不慣れですが、SQLベースのリレーショナルデータベースにはある程度の経験があります。 展開後のCassandraのメンテナンス方法に関するベストプラクティス情報を見つけることができませんでした。データベースをVACUUMする必要がありますか？読み取り/書き込みの負荷はストレージの断片化を引き起こすと考えるべきです。 またはより一般的には、Cassandra実稼働デプロイメントを維持するためのベストプラクティスは何ですか？システムの状態を維持するために、定期的に何をしなければなりませんか？運用マニュアルでは、この点については触れていません。 ありがとう。
1
ミラーの解除と復元
ミラーのセカンダリノードでメンテナンスを行う必要があります。これは、ネットワークが短時間停止した後にミラーが再確立されている間にサイトが遅くなった結果です。安全のためにミラーを無効にし、問題のサーバーで突っ込んだ後で再度有効にします。 私が今持っている計画は： ミラーを無効にする 潜在的に危険なトラブルシューティングを行う 失われたトランザクションログをすべて復元する ミラーを再確立します これは、ミラーを解除/再確立するための最も安全な方法ですか？気を付けるべき落とし穴はありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.