データベース(データ)

  • カテゴリーなし

Amazon RDS データベースのバックアップについて

Amazon RDS データベースをバックアップするにはどうすればよいですか？

RDS では、ポイント・イン・タイム復旧機能を備えた自動の日次バックアップと、オンデマンドの手動スナップショットが提供されます。リージョン間、アカウント間、またはより高頻度の保護が必要な場合は、ポリシーに基づいてスナップショットや DR コピーを管理する AWS Backup や N2WS などのツールを追加します。

AWS BackupはRDSの特定時点復旧（PITR）をサポートしていますか？

PITRはRDSの自動バックアップによって実現され、ソースリージョン内の保持期間（最大35日間）内の任意の秒単位の時点まで復旧できます。AWS Backupはその上にスナップショットレベルのバックアップを管理しますが、PITR自体は保持期間とリージョンに制限されます。

RDSのバックアップはどのくらいの頻度で実行できますか？

RDSの自動バックアップは1日1回実行されます。N2WSのポリシースケジューリングを使用すれば、ワークロードにより厳格なRPOが必要な場合、RDSスナップショットバックアップを60秒ごとに実行することも可能です。

RDSのバックアップをリージョンやアカウント間でコピーすることはできますか？

はい。RDSの自動バックアップ自体はアカウントをまたいでコピーされませんが、N2WS（DRが有効な場合）はポリシーに基づいて、RDSスナップショットを他のリージョンにコピーし、適切なライセンスがあれば他のアカウントにもコピーします。

RDSのバックアップを不変化し、ランサムウェアに耐性を持たせるにはどうすればよいですか？

S3 Object Lockを有効にした、ご自身が所有するストレージに、別のアカウントまたはリージョンにコピーを保管してください。N2WSはこのコピーとロックの処理を自動化するため、本番用アカウントの外側に、隔離され改ざん防止されたバックアップが存在することになります。

N2WSはAuroraおよびRDS Customのバックアップに対応していますか？

はい、両方とも対応しています。Auroraはサポートされており（AWSがスナップショットにリソースタグをコピーする機能を含む）、RDS Customの復元については、いくつかの追加のIAM権限が必要ですがサポートされています。

MySQLのバックアップのためのヒント

バイナリログを用いた特定時点への復旧（PITR）の実装：特定時点への復旧（PITR）を可能にするため、バイナリログを定期的にアーカイブし、安全に保管してください。これをフルバックアップ戦略と組み合わせることで、データベースを特定の時点に復元できます。

データベースのパーティショニングを活用してバックアップを高速化：mysqldump のような論理バックアップや MySQL Workbench などのツールは、大規模な単一テーブルよりも、小さなパーティションをより効率的に処理します。

サーバーレベルで圧縮を有効にする：ページ圧縮機能を備えた InnoDB テーブルなどの圧縮ストレージエンジンを使用するように MySQL を設定します。これにより、バックアッププロセス中に追加の手順を必要とせずに、バックアップのサイズを縮小し、ストレージコストを削減できます。

負荷管理のために専用のバックアップサーバーを使用する：スレーブサーバーへのMySQLレプリケーションを設定します。レプリカ上でバックアップを実行することで、リソースの競合を最小限に抑え、本番環境のプライマリデータベースへの影響をゼロにすることができます。

スケーラビリティのためにクラウドネイティブなバックアップソリューションを採用する：AWSやAzureなどのクラウドサービスと緊密に統合された、クラウドベースのバックアップサービスを利用します。これらのサービスは、速度とコスト効率に最適化されており、強化された災害復旧オプションを提供します。

Workload Identity Federation (OIDC) とは

Workload Identity Federation (OIDC) とは、GitHubやAWSなどの外部サービス（ワークロード）が、静的な認証キーを使うことなく、OpenID Connect（OIDC）を利用してGoogle Cloudなどのクラウドプラットフォームへ安全にアクセスする仕組み

そのメリット

従来の方式では、外部環境からクラウドにアクセスするために長期的に有効なサービスアカウントキーなどを発行・管理する必要がありました。OIDCを用いた連携では以下のメリットがあります。

  • シークレットレス（鍵の管理不要）: 長期的な認証キーをコードに埋め込んだり管理したりする必要がなくなります。
  • 短時間有効なトークン: 外部のIDプロバイダー（IdP）から発行されたIDトークンをクラウド側に渡し、一時的で有効期間の短いアクセス権と交換します。
  • セキュリティの向上: 鍵の漏洩リスクが大幅に減り、権限も最小限に絞り込めます。

主なその仕組み

  1. 外部環境（例: GitHub Actions）で実行中の処理が、そのプラットフォームのIdPから「OIDCトークン」を取得します。
  2. クラウド側（例: Google Cloud）で事前に設定した「Workload Identityプール」と「プロバイダ」へそのトークンを提示します。
  3. トークン内の情報（リポジトリ名やブランチ名など）を検証し、許可された条件に一致した場合にのみ一時的なアクセストークンが付与されます。

具体的な活用例

  • GitHub Actions から直接Google Cloudのリソースへアクセスし、デプロイやデータ操作を行う
  • AWS や Azure の仮想マシン、コンテナなどから、他クラウドのAPIを呼び出す
  • Terraform などによるマルチクラウド・インフラストラクチャの自動化

StarWindは構造化データワークロードをどのようにサポートしますか？

StarWindは、パフォーマンス、可用性、および迅速な復旧が重要な仮想化環境向けに共有ストレージを提供することで、構造化データワークロードをサポートします。これにより、一貫したストレージ動作を必要とするデータベース、ERPシステム、およびその他のビジネスクリティカルなアプリケーションに最適です。

 

構造化データと非構造化データの比較[ブログ]

構造化データと非構造化データの比較

AIやRAGにとって、非構造化データはなぜ重要なのでしょうか？

文書、メール、チケット、チャット履歴などには貴重な知識が含まれているため、非構造化データはAIや検索強化生成（RAG）にとって極めて重要です。AIの回答の質は、こうしたコンテンツをどれだけ適切にインデックス化、チャンク化、埋め込み、保存できるかにかかっています。ソースデータの整理が不十分だと、検索精度が低下し、不正確な出力が生じることになります。

 

構造化データと非構造化データの比較[ブログ]：

構造化データと非構造化データの比較

どの種類のデータが最も分析しやすいでしょうか？

構造化データは、すでに一貫性のあるフィールドに整理されているため、生の状態で最も分析しやすいです。半構造化データは、通常、分析の前に解析処理が必要です。非構造化データからは、インサイトを抽出する前に、インデックス作成、文書処理、全文検索、またはAIツールの活用が必要となります。

 

構造化データと非構造化データの比較[ブログ]

構造化データと非構造化データの比較

半構造化データとは何ですか？

半構造化データは、構造化データと非構造化データの中間に位置します。リレーショナルテーブルにはきっちりと収まりませんが、タグ、キー、メタデータ、またはネストされた階層構造を含んでおり、機械が読み取れる形式となっています。代表的な例としては、JSON、XML、APIペイロード、イベントログ、テレメトリデータなどが挙げられます。

 

構造化データと非構造化データの比較[ブログ]

構造化データと非構造化データの比較

構造化データと非構造化データの違いは何ですか？

構造化データは固定されたスキーマに従い、行と列で保存されます。SQLを使用してクエリを実行したり、ダッシュボードで活用したりすることができます。非構造化データにはあらかじめ定義された形式がなく、文書、メール、画像、チャットログなどが含まれます。構造化データはレポート作成やトランザクション処理に最適です。非構造化データは、文脈の把握、検索、知識の抽出に適しています。

 

構造化データと非構造化データの比較[ブログ]

構造化データと非構造化データの比較

データベースのストレージ最適化に関するFAQ

TempDBのデータファイルはいくつ使用すべきですか？

実用的な目安としては、論理CPUコア1つにつき1つのTempDBデータファイル（最大8つまで）を使用し、すべてのファイルを同じサイズに設定することです。それ以降は、競合状況や監視結果に基づいて変更を検討してください。

 

データベースに複数のトランザクションログファイルを使用すべきですか？

ほとんどの場合、必要ありません。適切なサイズで、増分が固定された単一のログファイルの方が管理が容易であり、通常はパフォーマンスも向上します。主な例外は、トランザクション・ログがディスク全体を埋め尽くしてしまう場合です。ログファイルを拡張する余地がなく、ログファイルが満杯になったためにそのデータベースへの書き込みが停止している場合、別のディスクに2つ目のログファイルを追加することは、短期的な対策として妥当な場合があります。それでも、データベースを単一のログファイルに戻すために、後でログを再構築するよう努めます。

 

パーセンテージベースの自動拡張は避けるべきですか？

必ずしもそうとは限りませんが、予測不可能性が生じます。固定サイズの自動拡張の方が理屈が分かりやすく、ファイルが大きくなるにつれてサイズが急激に跳ね上がるのを防げます。

 

ストレージが本当にボトルネックかどうかはどうやって判断すればよいですか？

待機統計とファイルレベルのI/Oメトリクスを長期的に確認してください。レイテンシや待機が特定のファイルや操作と一致している場合、調査すべき具体的な箇所が特定できます。

すでに過負荷状態にある場合、どこから手をつければよいでしょうか？

可視性とリスクが最も高い箇所から着手してください。具体的には、TempDB、トランザクションログのサイズ設定、および基本的なI/Oモニタリングです。これらの変更は、パフォーマンスや安定性の向上、そしてチームへの時間的還元という点で、多くの場合、すぐに成果をもたらします。

 

 

TempDBとは：

SQL ServerにおけるTempDBを一言で言うと、「SQL Serverが作業場として使う、共有のゴミ捨て場兼スクラップ帳」です。

サーバが起動するたびに新しく作成され、再起動すると中身はすべて消去されるという、非常に特殊なシステムデータベースです。

主な役割

SQL Serverは、自分自身のメモリだけでは処理しきれない時や、一時的な保管場所が必要な時にTempDBを使います。

  • 一時オブジェクトの保存: ユーザーが作成した一時テーブル（#temp）やテーブル変数などを置く場所です。

  • 作業領域: 大きなデータのソート（並べ替え）、ハッシュ結合（JOIN処理）、重複削除（DISTINCT）などを行う際の作業スペースとして使われます。

  • 行バージョン管理: 「スナップショット分離レベル」などを使っている場合、変更前の古いデータを一時的にここに避難させます。

TempDBの4つの大きな特徴

  1. 再起動でリセットされる: SQL Serverサービスを再起動するたびに、TempDBは削除され、初期サイズで再作成されます。そのため、重要なデータをここに永続保存することはできません。

  2. ログ記録が最小限: 通常のデータベースと違い、リカバリ（復旧）を想定していないため、書き込みパフォーマンスを上げるためにトランザクションログの記録が簡略化されています。

  3. 全ユーザーで共有: 一つのインスタンス内にあるすべてのデータベースが、この一つのTempDBを共有します。

  4. 設定がパフォーマンスに直結する: みんなが使う「作業場」なので、ここが渋滞するとシステム全体の速度が低下します。

AI Query Assist

1. AI Query Assistとは？

AI Query Assistは、生成AIと実行プランのコンテキストを活用して、パフォーマンス重視のSQL書き換えを提案するSolarWindsの機能です。

2. なぜ一般的なAIツールを使わないのですか？

一般的なAIツールには実行コンテキストが欠けていたり、機密性の高いクエリの詳細が漏洩する恐れがあります。AI Query AssistはSolarWindsのワークフローに組み込まれており、データベースのチューニングを目的に設計されています。

3. AI Query Assistはどのように機能しますか？

パフォーマンスの低いクエリを選択し、分析に送信すると、最適化されたバージョンと元のクエリを並べて確認でき、提案された変更点についての明確な説明も表示されます。

4. AI Query Assist はどこで利用できますか？

AI Query Assist は、SQL Sentry、Database Performance Analyzer (DPA)、および SolarWinds Observability SaaS で利用可能です。

5. 手動によるクエリチューニングの代わりになりますか？

いいえ。書き換えの段階を迅速化しますが、提案された SQL を展開するかどうかは、引き続きユーザー自身が確認、テスト、判断する必要があります。

データベースのパフォーマンス・チューニングと所要時間

パフォーマンスチューニングのようなことに関しては、「無駄な時間」という言葉にはあまり共感できません。確かに、誰もがそう感じることはあるでしょう。特に、何時間も費やした挙句、最初から間違った方向に進んでいたと気づいた時はなおさらです。

 

その代わり、それを「投資した時間」、つまり何かを学ぶために費やした時間だと捉えるようにすべきです。次にこう尋ねるべきです。「週に何時間、何かを学ぶために費やしていますか？」。これによって大抵、研修についての議論が始まり、そこから「実務を通じた」研修へと話題が移り、気がつけばまさに目指していた場所、つまりSQL文のパフォーマンスチューニングに費やす時間について話し合っているのです。

 

では、その時間はどれくらいになると見積もりますか？まだ答えないでください。開発、デプロイ、保守、本番サポート、管理など、あらゆる分野について考えてみてください。気づけば、時間の75％近くを単に処理を高速化しようとすることに費やしていることに気づくかもしれません。それはかなりの時間です！

 

もし、システムを高速化するためにそれほど多くの時間を費やすのであれば、できるだけ効率的に作業を進めたいと思うはずです。それを実現するには、待機イベントを活用します。

 

考え方は単純です。クエリが何を待っているのかが分かれば、そのボトルネックを取り除き、クエリの実行速度を向上させることができるのです。

Database Performance Analyzer (DPA)の開発状況 (updated March 2026)

DPAの最新リリース状況

  • データベース検出機能により、ネットワーク上のデータベースを検索できるため、データベース環境を簡単に特定して登録し、可観測性の実現までの時間を短縮できます。
  • DPA Centralの機能が拡張され、環境全体のビューが表示されるようになりました。カスタムプロパティでフィルタリングしたり、カスタムプロパティを列として表示したりできます。その他の改善点として、ページネーション、グループ化ビュー、SAMLのサポートが追加されています。
  • 「AI Query Assist」機能で SolarWinds AI を活用し、SQL Server および Oracle ターゲットのクエリパフォーマンスを最適化するためのクエリ書き換えの提案を提供します。
  • 多数の Azure SQL DB メトリクスが追加され、tempDB の使用状況を含め、データベースの動作のさまざまな側面とクエリパフォーマンスを関連付けることが可能になりました。
  • PostgreSQLおよびMySQLデータベースワークロード向けのテーブルチューニングおよびインデックスアドバイザー。
  • DPAのPlatform Connectを通じて、ServiceNowおよびPagerDutyとのアラート通知連携が簡素化されました。
  • IPv6専用またはハイブリッド環境向けのIPv6サポート。
  • 認証サポートの強化（MySQL向けのgMSAおよびSHA2パスワード）。

現在取り組んでいること

以下は、DPAに関して現在取り組んでいる、または検討中の事項の一覧です：

 

  • データベース検出機能について、検出結果をDPAの各インストール間で共有し、異なるDPAインストールに登録されている検出結果を無視するようにします。また、検出対象をクラウドアカウントにも拡張します。
  • DPAをDockerコンテナで提供し、ポータブルかつ効率的なデプロイ環境を実現します。
  • DPAの統合の柔軟性を高めるため、汎用的なWebhookを統合用に導入します。
  • SAP Hanaを監視対象としてサポートします。これにはオンプレミスおよびHana Cloudのデプロイメントが含まれ、シングルコンテナおよびマルチコンテナアーキテクチャに対応します。
  • Oracle Autonomous Databaseを監視対象としてサポートします。
  • DB2の最新バージョン向けに、セッションブロッキング情報を提供します。
  • 既存のインデックス、テーブルサイズ、カラムのカーディナリティなどの追加プロンプト入力により、AIクエリアシストの出力品質を継続的に向上させます。また、将来のリリースでは他のDBMSタイプにも対応を拡大します。
  • ホームページにアラームアイコンが表示されないよう、チューニングアドバイザーをミュートする機能を追加します。これは、監視対象への変更を行う能力が限られている場合に役立ちます。これらのアドバイザーをミュートすることで、対処不可能な問題に気を取られることがなくなります。
  • チューニングの意思決定を支援するため、SQL ServerのtempDBのアクティビティおよび構成情報の可視化を拡充します。DPAは、懸念されるtempDBの動作や状態について通知するアラートを提供します。
  • ユーザー権限管理用のエンドポイントを含むDPAのAPI。
  • SolarWinds製品（SquadCastおよびService Desk）へのアラート通知（Platform Connect経由）。
  • 複数のDPAサーバー間で一貫性を維持できるようにする、大規模なDPA環境向けの管理機能。
  • DPAのセキュリティが、米国連邦政府および共通基準相互承認協定（CCRA）参加国での利用に必要な厳格な保護プロファイルを満たすことを保証するための、共通基準（Common Criteria）認証。

 

（注） 上記の機能の記載順は優先度を示すものではありません。また上記のリストは、現在開発中または検討中の項目を示していますが、これらの機能がいつ、あるいは実際に提供されるかを保証するものではありません。

 

Database Performance Analyzer (DPA) 2026.1 のGA

DPA 2026.1 リリース

Database Performance Analyzer (DPA) 2026.1が一般提供（GA：general availability）を開始したことをお知らせいたします。本リリースでは、アラートメールの認証にOAuth 2.0に対応したほか、ネットワーク上のデータベースを特定し、監視対象として検討できるようにする新しい検出機能を導入しています。

Microsoft Exchange Online 向け OAuth 2.0

セキュリティ強化のため、Microsoft は Exchange Online における基本 SMTP 認証を段階的に廃止し、OAuth 2.0 への移行を進めており、2026年3月からこの変更が適用されます。この変更は、アラートメールの配信に Exchange Online を使用するように DPA が設定されている環境に影響します。

サービスの中断を防ぐため、DPA 2026.1 にアップグレードし、Microsoft Exchange Online との通信に OAuth 2.0 を使用するように SMTP 設定を更新してください。

image.png

新機能：データベース検出 ！

DPA 2026.1 では、ネットワーク上のデータベースインスタンスを特定し、監視のためのオンボーディングプロセスを効率化する新しいデータベース検出機能が導入されました。

この機能により、DPAはユーザーが指定したIPアドレスとポートをスキャンし、DPAにまだ登録されていないデータベースインスタンスを検出します。検出結果は登録ワークフローに直接反映され、IPアドレスとポート情報が自動的に入力されるため、導入から価値創出までの時間を短縮し、データベース環境全体の可視化を加速します。

今後の検出機能の強化点には以下が含まれます：

  • クラウドアカウントベースのデータベース検出
  • 複数のDPAデプロイメント間での検出結果の共有
  • インテリジェンスと自動化の拡張

image.png

 

迫りくる脅威：DBAの大量離職

DBA(データベース管理者)のバーンアウト（燃え尽き）は、単なる人材確保の課題にとどまらず、ビジネス上のリスクでもあります。「State of Database Report」調査によると、DBAの38%が職を辞することを検討したことがあるとのことです。

 

1人の離職がもたらす影響：

  • 財務的損失：DBA1人を補充するのに6～9ヶ月分の給与が必要
  • 知識の喪失：組織のノウハウが失われる
  • 運用リスク：ダウンタイムの増加、システムの不安定化、およびインシデントの深刻化

 

バーンアウトの原因とは？その「消火活動」の過負荷

なぜDBAは退職を考えているのでしょうか？それは、彼らの1日が純粋に事後対応的な業務に費やされているからです。報告書によると、彼らは週に27時間（時間の68％近く）という驚くべき時間を、以下の業務に費やしています：

  • アラートやチケットへの対応
  • バックアップと復旧
  • パフォーマンス問題の修正

「消火活動」に費やされる1時間は、最適化、自動化、あるいはイノベーションに費やされるはずだった1時間です。この不均衡が仕事の満足度を蝕み、バーンアウトを加速させています。

 

監視における重大な認識のギャップ


この業務負荷の問題は、経営陣とDBAの間にある根本的な認識のズレによってさらに悪化しています。経営陣は、監視体制が包括的かつ統合されていると想定しがちです。一方、DBAはそれが
危険なほどサイロ化されていることを知っています：

  • 経営陣の認識：IT経営幹部の50％近くが、自社の環境は統合されていると考えている
  • DBAの現実：これに同意するDBAはわずか40％

この認識のギャップは、重大な死角を生み出し、アラート疲労を助長し、インシデントの見落としを招くことで、リスクの高い非効率性を招いています。この乖離は、すでに手一杯のチームに直接的なプレッシャーを加えています。

 

事態を悪化させる認識のズレ

経営陣とDBAの認識が一致していないと、非効率性とリスクが倍増します。認識のズレは、単にフラストレーションを引き起こすだけでなく、対応時間の遅延、ダウンタイムの増加、そしてイノベーションの阻害につながります。その影響はビジネス全体に波及し、人事部門だけに留まりません：

  • 離職コストの増加：DBAの大量離職という悪循環を招く
  • 対応時間の遅延：事業継続性に直接的な影響を与える
  • イノベーション能力の低下：デジタルトランスフォーメーションの取り組みを阻害する

DBAの燃え尽きがもたらす経済的コストを削減し、経営層とDBAの間の溝を埋める方法はDPA（Databese Performance Analyser）の導入です。

 

データ中心型企業になる方法

物理世界では、メールから猫動画、このブログ記事に至るまで、情報は絶えず生成され、管理され、消費されている。エラーメッセージやシステムログ、誰も読まないアラートメールは言うまでもない。そしてこのデジタルデータは決して消滅せず、ROT（冗長・陳腐・無意味な情報）の氾濫を招く。

データ中心の姿勢を強化すれば、ROTの過剰を削減し、適切なデータのみを収集して情報に基づいた意思決定が可能になる。複雑である必要はない。このサーバーは何度再起動されたか？再起動にはどれくらい時間がかかるか？データ収集は、こうした単純な質問に過剰なデータ加工なしで答えられるようにすべきです。データは何に使うのか？プレゼン資料や監視環境のダッシュボード用かもしれません。あるいは開発マネージャーに「チームが2週間データベースサーバーにログインしていない」と示すためのメトリクス収集かもしれません。最終目標を明確に把握することで、最も合理的な方法でデータを収集できます。質問はしばしば仮定に基づきますが、データから得られる情報は偏見を裏付けるのではなく、事実を明らかにする助けとなるべきです。例えば、サーバー再起動がパッチの頻繁な適用によって引き起こされているかどうかを判断したい場合、「パッチはどのくらいの頻度で適用されていますか？」と尋ねる代わりに、「再起動を必要とするパッチはいくつありますか？」と尋ねることができます。この数値をサーバー再起動の総数と比較することで、パッチ適用が再起動に与える影響頻度を結論付けられます。

  1. 適切な質問から始める
  2. 最終目標を設定する
  3. 良い質問を投げかける

データが容易に入手できる現代では、価値あるデータのみを収集することに集中するのが難しい場合があります。データ中心の考え方を強化し、データ駆動型のアプローチを採用することで、環境内のROT（Redundant, Obsolete, Trivial）を減らし、データの過剰蓄積を防ぐことができます。

Database Performance AnalyzerはSQLパフォーマンスに何ができるのか

Database Performance Analyzer（DPA）は、継続的な監視を提供し、応答時間分析と履歴動作ログを組み合わせることでパフォーマンスのベースライン確立を支援し、SQLパフォーマンスチューニングプロセスにおける推測作業を大幅に削減するように設計されています。DPAを使用すると、特にDPAのインテリジェントな機械学習機能と組み合わせることで、異常な動作を迅速に検出することも可能です。

DPAに統合されたテーブルチューニングアドバイザー機能は、クエリと実行計画を分析し、非効率なSQLクエリが実行されているテーブルを特定することで、Microsoft SQL Serverの最適化機会に対処し、情報に基づいたチューニング判断を下せるよう支援します。DPAの組み込みSQLパフォーマンス分析ツールでは、相対的なワークロード順にランク付けされた、テーブルにアクセスする非効率なSQLの詳細な分析も確認可能です。

DPAにはクエリパフォーマンスアナライザー機能も含まれており、クエリに関する最重要データを収集し、直感的で分かりやすいダッシュボードビューで表示します。クエリ詳細ページでは待機タイプやクエリ・チューニングアドバイザーを色分け表示し、チャートを組み立てることで、ユーザーは特定されたパフォーマンス問題を容易に検証・対処できます。カスタマイズ可能なレポートとアラートにより、ブロック階層やブロッキングがデータベース全体のパフォーマンスに与える影響に関する洞察も提供します。

SQLパフォーマンス・チューニング・ツールどう役立つのか

多くの企業や組織（オンライン小売業者から政府機関まで）の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。

1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。

効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。

なぜSQLパフォーマンス・チューニングは重要なのか

多くの企業や組織（オンライン小売業者から政府機関まで）の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。

1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。

効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。

SQLパフォーマンス・チューニングはどのように始動するのか

SQL Serverデータベースのパフォーマンスチューニングの第一歩は、必要または望まれるほど効率的に実行されていない遅いSQLクエリを特定することです。

SQLチューニングには、将来予測可能な問題を未然に防ぐ「予防的」アプローチと、特定のユーザー問題が発生した際の「事後対応的」アプローチがあります。データベースクエリのチューニングにおいて、DBAが考慮すべき基本的なベストプラクティスを以下に示します：

  • インデックスは慎重に作成する。 インデックスはデータ取得用のデータ構造であり、行の選択を高速化しますが、ボトルネックを避けるため慎重に作成する必要があります。
  • ループ処理を避ける。 クエリ実行時の繰り返し処理や過剰負荷を回避すべきです。
  • SQLサブクエリの相関を避ける。 サブクエリは親クエリを参照し、行単位で処理されるため、処理速度が低下します。

待機時間と統計情報は、SQL Serverのパフォーマンスチューニングの重点領域を特定する有効な手段です。SQL Serverは「スレッド」を介してユーザー要求を管理し、各種スレッドのパフォーマンスを監視することで、管理者はどのクエリが低パフォーマンスであるかをより正確に判断できます。チューニングプロセスの目的は以下の通りです：

応答時間の短縮： ステートメント実行から応答までの時間

スループットの最適化： ステートメント処理に必要なリソース量

ただし、SQL Server パフォーマンス問題の根本原因を特定するには、データベース管理者はデータベースとサーバーの全レイヤーに関する洞察が必要となる場合があります。SQL Server チューニングツールは、上位 SQL ステートメント、待機タイプ、ブロックされたクエリ、およびインデックス不足がサーバーやデータベースのパフォーマンスに与える影響に関する理解を深めるプロセスを迅速化・効率化するのに役立ちます。

SQLパフォーマンス・チューニングとは

SQLパフォーマンスチューニングは、リレーショナルデータベースのクエリを可能な限り迅速かつ効率的に実行するために設計された一連の手順とプロセスです。SQLチューニングにはいくつかのステップが含まれます。まず、遅延が発生しているクエリを特定し、次にそれらのクエリを最適化して効率を最大化し、応答時間を短縮します。SQL Server、MySQLなど、多くのリレーショナルデータベースでSQLチューニングが必要となる場合があります。

管理者はシステムレベルでサーバーのパフォーマンス問題に対処しようと試みることができます（追加メモリやプロセッサの導入など）。しかし、これらの対策は実装コストが比較的高く、SQL Serverへの遅延クエリの根本原因に対処できない場合があります。SQLパフォーマンスチューニングは、不適切に記述されたSQLクエリや非効率的なインデックスを特定することでパフォーマンス向上を支援します。これはハードウェアや技術仕様の改善よりも、より的を絞った解決策となり得ます。

ただし、SQLのパフォーマンスチューニングは、特に手動で行う場合や大量のデータを管理する組織にとっては困難な作業となり得ます。こうした調整（たとえ小さな変更であっても）は、SQLサーバーやデータベースのパフォーマンスに広範な影響を及ぼす可能性があります。

データレプリケーションシステムにおける最大のリスクは、宛先のデータがソースの実際の状態を反映していないことです

分散環境では、データレプリケーションは、可用性、スケーラビリティ、回復性を確保するための確立されたプラクティスです。ただし、最大のリスクの 1 つは、デスティネーションにレプリケートされたデータがソースの現在の状態を反映していないことです。

データの不整合として知られるこの不整合は、ビジネス上の意思決定のエラーから自動化されたプロセスの誤動作まで、深刻な結果をもたらす可能性があり、システム全体の信頼性を直接損ないます。

複数のノード、データセンター、または分散サービスで運用されている組織では、テクノロジーガバナンスの原則に従って堅牢でスケーラブルで一貫性のあるアーキテクチャを構築するには、レプリケートされたデータの整合性を最優先事項にする必要があります。

 

📌 このずれの原因は何ですか?

 

➡️ レプリケーション・モデルの設計が不十分

➡️ ノード間のレイテンシーが高い

➡️ 書き込み競合の処理におけるエラー

➡️ 検証と整合性監査の欠如

📌 このリスクを軽減するにはどうすればよいでしょうか?

➡️ 効率的なトポロジーの設計

➡️ 整合性とリカバリの明確なポリシー

➡️ 運用の継続的な監視とトレーサビリティ

➡️ 技術アーキテクチャとビジネス目標の整合性

 

今日、企業のデータは戦略的資産です。

このため、複製されるものが原点に忠実であることを保証することは、事業継続性、制度的セキュリティ、デジタルの持続可能性のための構造的条件です。

DynamoDBバックアップについて

●DynamoDB Streamsを活用して近リアルタイムのバックアップ強化を実現： 定期的なバックアップを補完し、部分的なデータ損失が発生した場合に最近の更新を再実行することで、最後のバックアップと現在の状態のギャップを最小限に抑えます。

 

●重要なデータにバージョン管理を実装（S3エクスポート）： エクスポートされたバックアップの履歴コピーを維持することで、追加の保護層を提供し、誤った上書きや削除からの復旧を容易にします。

 

●バックアップ前の検証を自動化： Lambda関数またはAWS Systems Manager Automationを使用して、バックアップ開始前にテーブルの状態を検証します。例えば、データの一貫性を確認したり、スループット制限がバックアッププロセスに影響を与えないことを確認します。

 

●オンデマンドバックアップとPITRを組み合わせる： 両方を組み合わせることで、長期的な履歴記録を維持しつつ、最近の変更に対する粒度の細かい復元を可能にします。

 

●AWS Backup Vault Lockをコンプライアンスに利用： この機能は、保持期間中にバックアップが変更または削除されないようにし、金融や医療業界などの厳格なコンプライアンス要件を満たします。

 

Database Performance Analyzer (DPA)： 2024.4

Database Performance Analyzer (DPA) 2024.4 ソフトウェアの提供のお知らせです。

  • 柔軟なデータベースライセンス： セルフホスト型データベース製品に対するライセンスの付与方法を変更しました。 セルフホスト型ライセンスを1つ取得するだけで、ニーズに合わせてDPAを使用できます。 Azure SQL Databaseを監視している場合は、DBaaS環境専用の分割コストライセンスも導入しました。これにより、クラウドデータベースを簡単にコスト効率よく組み込むことができます。詳細については、担当のアカウントマネージャーまでお問い合わせください。
  • MySQL/Percona MySQLワークロード分析は、SQL Server、Oracle、PostgreSQL（実行計画収集）用の強力なDPA機能、インデックスアドバイザ、テーブルチューニングアドバイザなど、人気の高い機能が含まれています。
  • また、MySQL に関するセキュリティ対策も改善し、caching_sha2_password 認証をサポートするようになりました。チューニングアドバイザと併用することで、MySQL ユーザーの大幅な増加が見込まれます。
  • セキュリティを念頭に置き、お客様からご要望のあった Windows のグループ管理サービスアカウント（gMSA）認証もサポートするようになりました。
  • Oracle 関連では、Oracle のマルチテナント・アーキテクチャ上のターゲットとしてCDB をサポートするようになりました。これにより、より広範なアラート機能と可視性機能を備えた PDB を活用するインスタンスの全体像が完成しました。

 

Database Performance Analyzer (DPA):2024.3

Database Performance Analyzer (DPA)と の最新統合機能として、ServiceNow®とPagerDuty®を発表できることを嬉しく思います。この機能強化は、多くの要望に応えるもので、アラート通知を拡張し、IT運用をこれまで以上に効率的かつ迅速に行うことを可能にします。
DPAは、ServiceNow®とPagerDuty®に直接アラートを送信できるようになり、より効率的なワークフローが可能になりました。これにより、インシデントとイベントをより効果的に管理できるようになり、ITイベントの適切な通知、追跡、論理的なワークフローを確保できます。

動作方法
この統合により、SolarWinds Platform Connect 経由で SQL Sentry と DPA が貴社の ServiceNow® および PagerDuty® アカウントに接続されます。 設定が完了すると、DPA によって生成されたアラートは自動的にこれらのチャネルに送信され、IT チームはリアルタイム通知を受け取ることができ、問題が発生するとすぐに適切な優先順位付けと対処が行われるようになります。

統合のメリット
対応の迅速化：ServiceNow®とPagerDuty®にリアルタイムのアラートが送信されるため、チームはインシデントに迅速に対応でき、ダウンタイムを削減し、システムの信頼性を向上させることができます。

●インシデント管理の一元化：この統合により、すべてのITイベントを一元的に管理できるようになります。一元化によりワークフローが簡素化され、問題の追跡と解決が容易になります。
●業務の合理化：新しい統合により、適切なタイミングで適切な担当者にアラートが送信されることが保証されます。これにより、ITイベントやインシデントの優先順位付けと管理がより効果的に行われ、リソースが最適に利用されることが保証されます。
●すべてのサブスクリプション顧客が利用可能
この機能は、追加費用なしで、すべてのサブスクリプション顧客が利用可能です。これは、お客様のITインフラストラクチャを効率的に管理するための最高のツールと統合を提供するという、当社の継続的な取り組みの一環です。

データベース・バックアップへのヒント

●階層型ストレージのアプローチ：迅速な復元のために、最近のバックアップは高速ストレージ（SSDなど）に保存し、古いバックアップは安価で低速のストレージ（クラウドコールドストレージなど）に保存します。これにより、パフォーマンスとコストのバランスを取ることができます。

●きめ細かなバックアップウィンドウのスケジュール：高度な監視ツールを使用して、システム負荷とユーザーのトラフィックパターンを分析します。特に24時間365日稼働の業務では、パフォーマンスへの影響を最小限に抑えるため、最も業務が少ない時間帯にバックアップをスケジュールします。

●バックアップ・チェーニングの使用：増分バックアップを定期的にフル・バックアップにマージする「バックアップ・チェーニング」を導入します。これにより、リストアの複雑さが軽減され、増分バックアップ・プロセスの効率が向上します。

●クロス・データベースの整合性チェック：相互に作用する複数のデータベース（マイクロサービス・アーキテクチャなど）を扱う場合は、リストア時に依存関係にあるデータベース間の整合性を確保するために、システム全体のバックアップの整合性を定期的にチェックします。

●バックアップのメタデータ：特に複雑な環境では、データベースのスキーマと構成の詳細を常にバックアップします。バックアップに重要なメタデータが欠けていると、完全に機能する状態へのリストアに時間がかかったり、不完全な結果になることがあります。