StarWindは、パフォーマンス、可用性、および迅速な復旧が重要な仮想化環境向けに共有ストレージを提供することで、構造化データワークロードをサポートします。これにより、一貫したストレージ動作を必要とするデータベース、ERPシステム、およびその他のビジネスクリティカルなアプリケーションに最適です。
構造化データと非構造化データの比較[ブログ]
文書、メール、チケット、チャット履歴などには貴重な知識が含まれているため、非構造化データはAIや検索強化生成（RAG）にとって極めて重要です。AIの回答の質は、こうしたコンテンツをどれだけ適切にインデックス化、チャンク化、埋め込み、保存できるかにかかっています。ソースデータの整理が不十分だと、検索精度が低下し、不正確な出力が生じることになります。
構造化データと非構造化データの比較[ブログ]：
構造化データは、すでに一貫性のあるフィールドに整理されているため、生の状態で最も分析しやすいです。半構造化データは、通常、分析の前に解析処理が必要です。非構造化データからは、インサイトを抽出する前に、インデックス作成、文書処理、全文検索、またはAIツールの活用が必要となります。
構造化データと非構造化データの比較[ブログ]
半構造化データは、構造化データと非構造化データの中間に位置します。リレーショナルテーブルにはきっちりと収まりませんが、タグ、キー、メタデータ、またはネストされた階層構造を含んでおり、機械が読み取れる形式となっています。代表的な例としては、JSON、XML、APIペイロード、イベントログ、テレメトリデータなどが挙げられます。
構造化データと非構造化データの比較[ブログ]
構造化データは固定されたスキーマに従い、行と列で保存されます。SQLを使用してクエリを実行したり、ダッシュボードで活用したりすることができます。非構造化データにはあらかじめ定義された形式がなく、文書、メール、画像、チャットログなどが含まれます。構造化データはレポート作成やトランザクション処理に最適です。非構造化データは、文脈の把握、検索、知識の抽出に適しています。
構造化データと非構造化データの比較[ブログ]
TempDBのデータファイルはいくつ使用すべきですか？
実用的な目安としては、論理CPUコア1つにつき1つのTempDBデータファイル（最大8つまで）を使用し、すべてのファイルを同じサイズに設定することです。それ以降は、競合状況や監視結果に基づいて変更を検討してください。
データベースに複数のトランザクションログファイルを使用すべきですか？
ほとんどの場合、必要ありません。適切なサイズで、増分が固定された単一のログファイルの方が管理が容易であり、通常はパフォーマンスも向上します。主な例外は、トランザクション・ログがディスク全体を埋め尽くしてしまう場合です。ログファイルを拡張する余地がなく、ログファイルが満杯になったためにそのデータベースへの書き込みが停止している場合、別のディスクに2つ目のログファイルを追加することは、短期的な対策として妥当な場合があります。それでも、データベースを単一のログファイルに戻すために、後でログを再構築するよう努めます。
パーセンテージベースの自動拡張は避けるべきですか？
必ずしもそうとは限りませんが、予測不可能性が生じます。固定サイズの自動拡張の方が理屈が分かりやすく、ファイルが大きくなるにつれてサイズが急激に跳ね上がるのを防げます。
ストレージが本当にボトルネックかどうかはどうやって判断すればよいですか？
待機統計とファイルレベルのI/Oメトリクスを長期的に確認してください。レイテンシや待機が特定のファイルや操作と一致している場合、調査すべき具体的な箇所が特定できます。
すでに過負荷状態にある場合、どこから手をつければよいでしょうか？
可視性とリスクが最も高い箇所から着手してください。具体的には、TempDB、トランザクションログのサイズ設定、および基本的なI/Oモニタリングです。これらの変更は、パフォーマンスや安定性の向上、そしてチームへの時間的還元という点で、多くの場合、すぐに成果をもたらします。
SQL ServerにおけるTempDBを一言で言うと、「SQL Serverが作業場として使う、共有のゴミ捨て場兼スクラップ帳」です。
サーバが起動するたびに新しく作成され、再起動すると中身はすべて消去されるという、非常に特殊なシステムデータベースです。
SQL Serverは、自分自身のメモリだけでは処理しきれない時や、一時的な保管場所が必要な時にTempDBを使います。
一時オブジェクトの保存: ユーザーが作成した一時テーブル（#temp）やテーブル変数などを置く場所です。
作業領域: 大きなデータのソート（並べ替え）、ハッシュ結合（JOIN処理）、重複削除（DISTINCT）などを行う際の作業スペースとして使われます。
行バージョン管理: 「スナップショット分離レベル」などを使っている場合、変更前の古いデータを一時的にここに避難させます。
再起動でリセットされる: SQL Serverサービスを再起動するたびに、TempDBは削除され、初期サイズで再作成されます。そのため、重要なデータをここに永続保存することはできません。
ログ記録が最小限: 通常のデータベースと違い、リカバリ（復旧）を想定していないため、書き込みパフォーマンスを上げるためにトランザクションログの記録が簡略化されています。
全ユーザーで共有: 一つのインスタンス内にあるすべてのデータベースが、この一つのTempDBを共有します。
設定がパフォーマンスに直結する: みんなが使う「作業場」なので、ここが渋滞するとシステム全体の速度が低下します。
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％近くを単に処理を高速化しようとすることに費やしていることに気づくかもしれません。それはかなりの時間です！
もし、システムを高速化するためにそれほど多くの時間を費やすのであれば、できるだけ効率的に作業を進めたいと思うはずです。それを実現するには、待機イベントを活用します。
考え方は単純です。クエリが何を待っているのかが分かれば、そのボトルネックを取り除き、クエリの実行速度を向上させることができるのです。
以下は、DPAに関して現在取り組んでいる、または検討中の事項の一覧です：
（注） 上記の機能の記載順は優先度を示すものではありません。また上記のリストは、現在開発中または検討中の項目を示していますが、これらの機能がいつ、あるいは実際に提供されるかを保証するものではありません。
Database Performance Analyzer (DPA) 2026.1が一般提供（GA：general availability）を開始したことをお知らせいたします。本リリースでは、アラートメールの認証に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 設定を更新してください。
DPA 2026.1 では、ネットワーク上のデータベースインスタンスを特定し、監視のためのオンボーディングプロセスを効率化する新しいデータベース検出機能が導入されました。
この機能により、DPAはユーザーが指定したIPアドレスとポートをスキャンし、DPAにまだ登録されていないデータベースインスタンスを検出します。検出結果は登録ワークフローに直接反映され、IPアドレスとポート情報が自動的に入力されるため、導入から価値創出までの時間を短縮し、データベース環境全体の可視化を加速します。
今後の検出機能の強化点には以下が含まれます：
DBA(データベース管理者)のバーンアウト（燃え尽き）は、単なる人材確保の課題にとどまらず、ビジネス上のリスクでもあります。「State of Database Report」調査によると、DBAの38%が職を辞することを検討したことがあるとのことです。
1人の離職がもたらす影響：
なぜDBAは退職を考えているのでしょうか？それは、彼らの1日が純粋に事後対応的な業務に費やされているからです。報告書によると、彼らは週に27時間（時間の68％近く）という驚くべき時間を、以下の業務に費やしています：
「消火活動」に費やされる1時間は、最適化、自動化、あるいはイノベーションに費やされるはずだった1時間です。この不均衡が仕事の満足度を蝕み、バーンアウトを加速させています。
この業務負荷の問題は、経営陣とDBAの間にある根本的な認識のズレによってさらに悪化しています。経営陣は、監視体制が包括的かつ統合されていると想定しがちです。一方、DBAはそれが
危険なほどサイロ化されていることを知っています：
この認識のギャップは、重大な死角を生み出し、アラート疲労を助長し、インシデントの見落としを招くことで、リスクの高い非効率性を招いています。この乖離は、すでに手一杯のチームに直接的なプレッシャーを加えています。
経営陣とDBAの認識が一致していないと、非効率性とリスクが倍増します。認識のズレは、単にフラストレーションを引き起こすだけでなく、対応時間の遅延、ダウンタイムの増加、そしてイノベーションの阻害につながります。その影響はビジネス全体に波及し、人事部門だけに留まりません：
DBAの燃え尽きがもたらす経済的コストを削減し、経営層とDBAの間の溝を埋める方法はDPA（Databese Performance Analyser）の導入です。
物理世界では、メールから猫動画、このブログ記事に至るまで、情報は絶えず生成され、管理され、消費されている。エラーメッセージやシステムログ、誰も読まないアラートメールは言うまでもない。そしてこのデジタルデータは決して消滅せず、ROT（冗長・陳腐・無意味な情報）の氾濫を招く。
データ中心の姿勢を強化すれば、ROTの過剰を削減し、適切なデータのみを収集して情報に基づいた意思決定が可能になる。複雑である必要はない。このサーバーは何度再起動されたか？再起動にはどれくらい時間がかかるか？データ収集は、こうした単純な質問に過剰なデータ加工なしで答えられるようにすべきです。データは何に使うのか？プレゼン資料や監視環境のダッシュボード用かもしれません。あるいは開発マネージャーに「チームが2週間データベースサーバーにログインしていない」と示すためのメトリクス収集かもしれません。最終目標を明確に把握することで、最も合理的な方法でデータを収集できます。質問はしばしば仮定に基づきますが、データから得られる情報は偏見を裏付けるのではなく、事実を明らかにする助けとなるべきです。例えば、サーバー再起動がパッチの頻繁な適用によって引き起こされているかどうかを判断したい場合、「パッチはどのくらいの頻度で適用されていますか？」と尋ねる代わりに、「再起動を必要とするパッチはいくつありますか？」と尋ねることができます。この数値をサーバー再起動の総数と比較することで、パッチ適用が再起動に与える影響頻度を結論付けられます。
データが容易に入手できる現代では、価値あるデータのみを収集することに集中するのが難しい場合があります。データ中心の考え方を強化し、データ駆動型のアプローチを採用することで、環境内のROT（Redundant, Obsolete, Trivial）を減らし、データの過剰蓄積を防ぐことができます。
Database Performance Analyzer（DPA）は、継続的な監視を提供し、応答時間分析と履歴動作ログを組み合わせることでパフォーマンスのベースライン確立を支援し、SQLパフォーマンスチューニングプロセスにおける推測作業を大幅に削減するように設計されています。DPAを使用すると、特にDPAのインテリジェントな機械学習機能と組み合わせることで、異常な動作を迅速に検出することも可能です。
DPAに統合されたテーブルチューニングアドバイザー機能は、クエリと実行計画を分析し、非効率なSQLクエリが実行されているテーブルを特定することで、Microsoft SQL Serverの最適化機会に対処し、情報に基づいたチューニング判断を下せるよう支援します。DPAの組み込みSQLパフォーマンス分析ツールでは、相対的なワークロード順にランク付けされた、テーブルにアクセスする非効率なSQLの詳細な分析も確認可能です。
DPAにはクエリパフォーマンスアナライザー機能も含まれており、クエリに関する最重要データを収集し、直感的で分かりやすいダッシュボードビューで表示します。クエリ詳細ページでは待機タイプやクエリ・チューニングアドバイザーを色分け表示し、チャートを組み立てることで、ユーザーは特定されたパフォーマンス問題を容易に検証・対処できます。カスタマイズ可能なレポートとアラートにより、ブロック階層やブロッキングがデータベース全体のパフォーマンスに与える影響に関する洞察も提供します。
多くの企業や組織（オンライン小売業者から政府機関まで）の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。
1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。
効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。
多くの企業や組織（オンライン小売業者から政府機関まで）の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。
1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。
効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。
SQL Serverデータベースのパフォーマンスチューニングの第一歩は、必要または望まれるほど効率的に実行されていない遅いSQLクエリを特定することです。
SQLチューニングには、将来予測可能な問題を未然に防ぐ「予防的」アプローチと、特定のユーザー問題が発生した際の「事後対応的」アプローチがあります。データベースクエリのチューニングにおいて、DBAが考慮すべき基本的なベストプラクティスを以下に示します：
待機時間と統計情報は、SQL Serverのパフォーマンスチューニングの重点領域を特定する有効な手段です。SQL Serverは「スレッド」を介してユーザー要求を管理し、各種スレッドのパフォーマンスを監視することで、管理者はどのクエリが低パフォーマンスであるかをより正確に判断できます。チューニングプロセスの目的は以下の通りです：
応答時間の短縮： ステートメント実行から応答までの時間
スループットの最適化： ステートメント処理に必要なリソース量
ただし、SQL Server パフォーマンス問題の根本原因を特定するには、データベース管理者はデータベースとサーバーの全レイヤーに関する洞察が必要となる場合があります。SQL Server チューニングツールは、上位 SQL ステートメント、待機タイプ、ブロックされたクエリ、およびインデックス不足がサーバーやデータベースのパフォーマンスに与える影響に関する理解を深めるプロセスを迅速化・効率化するのに役立ちます。
SQLパフォーマンスチューニングは、リレーショナルデータベースのクエリを可能な限り迅速かつ効率的に実行するために設計された一連の手順とプロセスです。SQLチューニングにはいくつかのステップが含まれます。まず、遅延が発生しているクエリを特定し、次にそれらのクエリを最適化して効率を最大化し、応答時間を短縮します。SQL Server、MySQLなど、多くのリレーショナルデータベースでSQLチューニングが必要となる場合があります。
管理者はシステムレベルでサーバーのパフォーマンス問題に対処しようと試みることができます（追加メモリやプロセッサの導入など）。しかし、これらの対策は実装コストが比較的高く、SQL Serverへの遅延クエリの根本原因に対処できない場合があります。SQLパフォーマンスチューニングは、不適切に記述されたSQLクエリや非効率的なインデックスを特定することでパフォーマンス向上を支援します。これはハードウェアや技術仕様の改善よりも、より的を絞った解決策となり得ます。
ただし、SQLのパフォーマンスチューニングは、特に手動で行う場合や大量のデータを管理する組織にとっては困難な作業となり得ます。こうした調整（たとえ小さな変更であっても）は、SQLサーバーやデータベースのパフォーマンスに広範な影響を及ぼす可能性があります。
分散環境では、データレプリケーションは、可用性、スケーラビリティ、回復性を確保するための確立されたプラクティスです。ただし、最大のリスクの 1 つは、デスティネーションにレプリケートされたデータがソースの現在の状態を反映していないことです。
データの不整合として知られるこの不整合は、ビジネス上の意思決定のエラーから自動化されたプロセスの誤動作まで、深刻な結果をもたらす可能性があり、システム全体の信頼性を直接損ないます。
複数のノード、データセンター、または分散サービスで運用されている組織では、テクノロジーガバナンスの原則に従って堅牢でスケーラブルで一貫性のあるアーキテクチャを構築するには、レプリケートされたデータの整合性を最優先事項にする必要があります。
📌 このずれの原因は何ですか?
➡️ レプリケーション・モデルの設計が不十分
➡️ ノード間のレイテンシーが高い
➡️ 書き込み競合の処理におけるエラー
➡️ 検証と整合性監査の欠如
📌 このリスクを軽減するにはどうすればよいでしょうか?
➡️ 効率的なトポロジーの設計
➡️ 整合性とリカバリの明確なポリシー
➡️ 運用の継続的な監視とトレーサビリティ
➡️ 技術アーキテクチャとビジネス目標の整合性
今日、企業のデータは戦略的資産です。
このため、複製されるものが原点に忠実であることを保証することは、事業継続性、制度的セキュリティ、デジタルの持続可能性のための構造的条件です。
●DynamoDB Streamsを活用して近リアルタイムのバックアップ強化を実現： 定期的なバックアップを補完し、部分的なデータ損失が発生した場合に最近の更新を再実行することで、最後のバックアップと現在の状態のギャップを最小限に抑えます。
●重要なデータにバージョン管理を実装（S3エクスポート）： エクスポートされたバックアップの履歴コピーを維持することで、追加の保護層を提供し、誤った上書きや削除からの復旧を容易にします。
●バックアップ前の検証を自動化： Lambda関数またはAWS Systems Manager Automationを使用して、バックアップ開始前にテーブルの状態を検証します。例えば、データの一貫性を確認したり、スループット制限がバックアッププロセスに影響を与えないことを確認します。
●オンデマンドバックアップとPITRを組み合わせる： 両方を組み合わせることで、長期的な履歴記録を維持しつつ、最近の変更に対する粒度の細かい復元を可能にします。
●AWS Backup Vault Lockをコンプライアンスに利用： この機能は、保持期間中にバックアップが変更または削除されないようにし、金融や医療業界などの厳格なコンプライアンス要件を満たします。
Database Performance Analyzer (DPA) 2024.4 ソフトウェアの提供のお知らせです。
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日稼働の業務では、パフォーマンスへの影響を最小限に抑えるため、最も業務が少ない時間帯にバックアップをスケジュールします。
●バックアップ・チェーニングの使用：増分バックアップを定期的にフル・バックアップにマージする「バックアップ・チェーニング」を導入します。これにより、リストアの複雑さが軽減され、増分バックアップ・プロセスの効率が向上します。
●クロス・データベースの整合性チェック：相互に作用する複数のデータベース（マイクロサービス・アーキテクチャなど）を扱う場合は、リストア時に依存関係にあるデータベース間の整合性を確保するために、システム全体のバックアップの整合性を定期的にチェックします。
●バックアップのメタデータ：特に複雑な環境では、データベースのスキーマと構成の詳細を常にバックアップします。バックアップに重要なメタデータが欠けていると、完全に機能する状態へのリストアに時間がかかったり、不完全な結果になることがあります。
