プロアクティブな最適化について最初に話すのは、何を最適化する必要があるかわからないということです。 「それをしてください、私は何を知りません。」

• 古典的なアルゴリズムはありません。
• 問題はまだ発生しておらず（不明）、どこにあるかを推測することしかできません。
• システム内の潜在的な弱点を見つける必要があります。
• これらの場所でクエリのパフォーマンスを最適化してください。

プロアクティブな最適化の主な目標

プロアクティブな最適化の主なタスクは、リアクティブな最適化のタスクとは異なり、次のとおりです。

• データベースのボトルネックを取り除く。
• データベースのリソース消費の減少。

最後の瞬間が最も基本的です。 リアクティブ最適化の場合、リソース消費全体を削減するタスクはありませんが、機能の応答時間を許容範囲内にするタスクのみがあります。



バトルサーバーを使用している場合、パフォーマンスインシデントの意味を理解できます。 すべてを終了し、問題を迅速に解決する必要があります。 RNKO Payment Center LLCは多くのエージェントと連携しており、できるだけ少ない問題を抱えることが非常に重要です。 HighLoad ++ SiberiaのAlexander Makarovは、パフォーマンスインシデントの数を大幅に減らすために何が行われたかを語りました。 プロアクティブな最適化が助けになりました。 そして、戦闘サーバーで作成される理由と方法については、以下をお読みください。



講演者について：アレクサンダーマカロフ（ AL_IG_Makarov ）、Oracleデータベースの主任管理者、RNCO Payment Center LLC。 位置にもかかわらず、そのような管理はほとんどありません。主なタスクは、特にパフォーマンスの問題を解決するために、複合体のメンテナンスとその開発に関連しています。

戦闘データベースの最適化はプロアクティブですか？

まず、このレポートで「プロアクティブなパフォーマンスの最適化」と呼ばれる用語を扱います。 プロアクティブな最適化とは、アプリケーションを起動する前であっても問題領域の分析を実行することであるという観点を満たせる場合があります。 たとえば、十分なインデックスがないか、クエリが非効率的なアルゴリズムを使用しており、この作業はテストサーバーで実行されるため、一部のクエリは最適に機能しないことがわかります。

それにもかかわらず、RNCOの私たちは戦闘サーバーでこのプロジェクトを行いました。 私は何度も聞いた：「どうして？ 戦闘サーバーでそれを行います。つまり、プロアクティブなパフォーマンスの最適化ではありません！」ここでは、ITILで培われたアプローチを思い出す必要があります。 ITILの観点から、次のものがあります。

• パフォーマンスインシデントは既に発生しているものです。
• パフォーマンスインシデントが発生しないようにするための対策。

この意味で、私たちの行動は積極的です。 バトルサーバーで問題を解決しているという事実にもかかわらず、問題自体はまだ発生していません。インシデントは発生せず、実行せず、短時間でこの問題を解決しようとしませんでした。

したがって、このレポートでは、プロアクティブはITILの意味でのプロアクティブと理解されており 、パフォーマンスインシデントが発生する前に問題を解決します。

基準点

RNKO「Payment Center」は、2つの大規模システムに対応しています。

• RBS-Retail Bank;
• CFT銀行。

これらのシステムの負荷の性質は混在しています（DSS + OLTP）：非常に迅速に機能するものがあり、レポートがあり、中程度の負荷があります。

あまり頻繁ではなく、一定の頻度でパフォーマンスの問題が発生するという事実に直面しました。 バトルサーバーで作業する人は、それが何であるかを想像します。 これは、この時点でクライアントがサービスを受信できないか、何かがまったく機能しないか、動作が非常に遅いため、すべてを終了して問題を迅速に解決する必要があることを意味します。

非常に多くのエージェントとクライアントが組織に結びついているため、これは私たちにとって非常に重要です。 パフォーマンスの問題を迅速に解決できない場合、お客様は何らかの形で苦しむことになります。 たとえば、カードを補充したり、送金したりすることはできません。 したがって、これらのまれなパフォーマンスインシデントでさえ取り除くために何ができるのか疑問に思いました。 すべてをドロップして問題を解決する必要があるときにモードで作業する-これは完全に正しいわけではありません。 スプリントを使用して、スプリント作業計画を作成します。 パフォーマンスインシデントの存在は、作業計画からの逸脱でもあります。

あなたはそれについて何かをしなければなりません！

最適化アプローチ

プロアクティブな最適化のテクノロジーを考え、理解するようになりました。 ただし、プロアクティブな最適化について説明する前に、古典的なリアクティブな最適化についていくつか説明する必要があります。

リアクティブ最適化

シナリオは単純です。何かが起こったバトルサーバーがあります。彼らはレポートを立ち上げ、クライアントはステートメントを受け取り、この時点でデータベース上で進行中のアクティビティがあり、突然誰かが何らかの種類のディレクトリを更新することを決めました。 システムの速度が低下し始めます。 この時点で、クライアントが来て、「私はこれまたはそれをすることができません」と言います-私たちは彼がこれをできない理由を見つける必要があります。

従来のアクションアルゴリズム：

1. 問題を再現します。
2. 問題箇所を見つけます。
3. 問題箇所を最適化します。

リアクティブアプローチのフレームワーク内での主なタスクは、根本原因自体を見つけてそれを排除することではなく、システムを正常に機能させる方法です。 根本原因の除去は後で対処できます。 主なことは、クライアントがサービスを受信できるように、サーバーをすばやく復元することです。

リアクティブ最適化の主な目標

リアクティブ最適化では、2つの主要な目標を区別できます。

1. 応答時間を短縮します。

レポート、ステートメント、トランザクションの受信などのアクションは、スケジュールされた時間に実行する必要があります。 サービスの受信時間がクライアントに受け入れられる境界に戻ることを確認する必要があります。 サービスは通常より少し遅くなるかもしれませんが、クライアントにとってはこれは許容範囲です。 その後、パフォーマンスインシデントは解消されたと考え、根本原因の調査を開始します。

2. バッチ処理中の単位時間あたりの処理済みオブジェクトの数の増加 。

トランザクションのバッチ処理が進行中の場合、パッケージの1つのオブジェクトの処理時間を短縮する必要があります。

リアクティブアプローチの長所：

● さまざまなツールとテクニックが、リアクティブアプローチの主な利点です。

監視ツールを使用して、問題が何であるかを直接理解できます。CPU、スレッド、メモリが不足しているか、ディスクシステムがスリップしているか、ログの処理が遅いです。 Oracleデータベースの現在のパフォーマンスの問題を調査するための多くのツールとテクニックがあります。

● 望ましい応答時間はもう1つのプラスです。

そのような作業の過程で、状況を許容可能な応答時間にします。つまり、状況を最小値にまで低下させようとしませんが、特定の値に到達し、このアクションの後、許容限度に到達したと考えられるため、終了します。

リアクティブアプローチの短所：

• パフォーマンスインシデントは残ります。これは、根本的な原因に常に到達できるとは限らないため、事後対応型アプローチの最大のマイナスです。 私たちが許容できるパフォーマンスに到達したという事実にもかかわらず、彼女はどこか離れたところにとどまり、どこかに深く横たわっていたかもしれません。

パフォーマンスインシデントがまだ発生していない場合の対処方法は？ そのような状況を防ぐために、どのようにプロアクティブな最適化を実行できるかを定式化してみましょう。

プロアクティブな最適化

最初に遭遇することは、何を最適化する必要があるかがわからないということです。 「それをしてください、私は何を知りません。」

• 古典的なアルゴリズムはありません。
• 問題はまだ発生しておらず（不明）、どこにあるかを推測することしかできません。
• システム内の潜在的な弱点を見つける必要があります。
• これらの場所でクエリのパフォーマンスを最適化してください。

プロアクティブな最適化の主な目標

プロアクティブな最適化の主なタスクは、リアクティブな最適化のタスクとは異なり、次のとおりです。

• データベースのボトルネックを取り除く。
• データベースのリソース消費の減少。

最後の瞬間が最も基本的です。 リアクティブ最適化の場合、リソース消費全体を削減するタスクはありませんが、機能の応答時間を許容範囲内にするタスクのみがあります。

データベースでボトルネックを見つける方法

この問題について考え始めると、すぐに多くのサブタスクが発生します。 以下を実行する必要があります。

• CPUテスト
• 読み取り/レコードの負荷テスト。
• アクティブなセッションの数によるストレステスト。
• 負荷テスト...など

テスト複合体でこれらの問題をシミュレートしようとすると、テストサーバーで発生した問題は戦闘のものとは関係がないという事実に遭遇する可能性があります。 これには多くの理由があります。テストサーバーは通常弱いという事実から始まります。 テストサーバーを戦闘サーバーの正確なコピーにすることができれば良いのですが、ユーザーアクティビティや最終的な負荷に影響するさまざまな要素を正確に再現する必要があるため、負荷が同じ方法で再現されることは保証されません。 この状況をシミュレートしようとすると、概して、バトルサーバーでまったく同じことが起こることを誰も保証しません。

あるケースで新しいレジストリが到着したために問題が発生した場合、別のケースでは、ユーザーが大規模なソートを行う巨大なレポートを起動したために発生する可能性があります。その結果、システムの速度が低下し始めました。 つまり、理由は異なる可能性があり、常に予測できるとは限りません。 したがって、ほとんど最初からテストサーバーでボトルネックを検索する試みを放棄しました 。 私たちは戦闘サーバーとそれに何が起こっているかに依存していました。

この場合の対処方法 そもそも不足している可能性が最も高いリソースを理解してみましょう。

データベースのリソース消費の削減

私たちが自由に使える工業団地に基づいて、 リソースの最も頻繁な不足はディスク読み取りとCPUで観察されます 。 したがって、そもそもこれらの領域の弱点を正確に探します。

2番目の重要な質問：何かを探す方法は？
質問は非常に重要です。 Oracle Enterprise EditionではDiagnostic Packオプションを使用しますが、 AWRレポート （Oracleの他のエディションではSTATSPACKレポートを使用できます ）というツールが見つかりました。 PostgreSQLにはアナログがあります-pgstatspack、 Andrey Zubkovのpg_profileです 。 私が理解しているように、最後の製品が登場し、昨年だけ開発を開始しました。 MySQLの場合、同様のツールは見つかりませんでしたが、MySQLの専門家ではありません。

アプローチ自体は、特定の種類のデータベースに関連付けられていません。 レポートからシステム負荷に関する情報を取得できる場合は、これから説明する手法を使用して、 任意のベースでプロアクティブな最適化の作業を実行できます 。

上位5つの操作の最適化

ペイメントセンターRSCOで開発および使用しているプロアクティブな最適化テクノロジーは、4つの段階で構成されています。

ステージ1。AWRレポートを可能な限り最大期間受け取ります。

週のさまざまな曜日の負荷を平均化するには、可能な限り最大の時間が必要です。 たとえば、先週のレジストリは火曜日にRBS-Retail Bankに到着し、処理が開始され、終日平均約2〜3回の負荷がかかります。 他の日には、負荷はより少なくなります。

システムにいくつかの仕様があることがわかっている場合-ある日には負荷が大きく、ある日には-少ない場合、これらの期間のレポートを個別に受信し、特定の時間間隔を最適化する場合は個別に作業する必要があります。 サーバーの全体的な状況を最適化する必要がある場合は、その月の大きなレポートを取得して、サーバーのリソースが実際に消費しているものを確認できます。

時には非常に予期しない状況が発生します。 たとえば、CFT Bankの場合、レポートサーバーキューをチェックする要求は上位10にある可能性があります。 さらに、このリクエストは公式であり、ビジネスロジックを実行しませんが、実行に関するレポートがあるかどうかのみをチェックします。

ステージ2.セクションを見ます：

• 経過時間で並べ替えられたSQL-実行時間で並べ替えられたSQLクエリ。
• CPU時間順に並べられたSQL-CPU使用率。
• Getsで順序付けられたSQL-論理読み取り値。
• 読み取り順に並べられたSQL-物理的な読み取り用。

SQLの残りのセクションは、必要に応じて調査されます。

ステージ3.親操作とそれに依存する要求を決定します。

AWRレポートには個別のセクションがあり、Oracleのバージョンに応じて、これらの各セクションに15以上の上位クエリが表示されます。 しかし、AWRレポートのこれらのクエリOracleは混乱を示しています。
たとえば、親操作があり、その中に3つの上位クエリがある場合があります。 AWRレポートのOracleは、親操作とこれら3つのクエリの両方を表示します。 したがって、このリストを分析し、特定の要求が参照する操作を確認して、グループ化する必要があります。

ステージ4。上位5つのオペレーションを最適化します。

このようなグループ化の後、出力は最も難しい操作を選択できる操作のリストになります。 5つの操作に制限されています（要求、つまり操作ではありません）。 システムがより複雑な場合は、さらに多くを取ることができます。

一般的なクエリ設計エラー

この手法の適用中に、典型的な設計エラーの小さなリストをまとめました。 いくつかのエラーは非常に単純であるため、そうではないようです。

● インデックスの欠如→フルスキャン
たとえば、戦闘スキームに関するインデックスがないなど、非常に偶発的なケースがあります。 インデックスなしで長時間のクエリが迅速に機能する特定の例がありました。 しかし、フルスキャンが行われ、テーブルサイズが徐々に大きくなるにつれて、クエリの動作が遅くなり、四半期ごとに少し時間がかかりました。 結局、私たちは彼に注意を払いましたが、インデックスがそこにないことがわかりました。

● 大規模な選択→フルスキャン
2番目のよくある間違いは、大量のデータサンプル-フルスキャンの典型的なケースです。 フルスキャンは、正当な理由がある場合にのみ使用する必要があることを誰もが知っています。 たとえば、フィルタリング条件をpl / sqlコードからクエリに転送する場合など、フルスキャンが実行できない場合があります。

● 無効なインデックス→ロングインデックスレンジスキャン
たぶんこれは最も一般的な間違いです。何らかの理由で、彼らは非常に少ないと言っています-いわゆる非効率的なインデックス（長いインデックススキャン、長いインデックス範囲スキャン）。 たとえば、レジ​​ストリ用のテーブルがあります。 要求では、このエージェントのすべてのレジストリを検索し、最終的に、たとえば特定の期間、特定の番号、特定のクライアントなどのフィルター条件を追加しようとします。 このような状況では、インデックスは通常、使用の普遍性の理由から「エージェント」フィールドにのみ構築されます。 結果は次の図になります。たとえば、作業の最初の年には、エージェントはこのテーブルに100個のエントリを持ち、来年はすでに1,000個、別の年には10,000個のエントリがあります。 時間が経つと、これらのレコードは100,000になります。リクエストでは、エージェント識別子だけでなく、この場合は日付による追加のフィルターも追加する必要があるため、リクエストの動作が遅くなることは明らかです。 そうしないと、このエージェントのレジストリの数が増えているため、サンプルサイズが年々増加することがわかります。 この問題はインデックスレベルで対処する必要があります。 データが多すぎる場合は、パーティション分割の方向をすでに考えておく必要があります。

● 不要な配布コードブランチ
これも好奇心is盛なケースですが、それにもかかわらず、起こります。 上位のクエリを見ると、奇妙なクエリがいくつかあります。 私たちは開発者のところに来て、「私たちはいくつかのリクエストを見つけました。それを理解し、それについて何ができるか見てみましょう。」 開発者は考え、しばらくしてから次のように言います。「このコードのブランチはシステム上にあるべきではありません。 この機能は使用しません。」 次に、開発者は、コードのこのセクションを回避するために、特別な設定をオンにすることをお勧めします。

ケーススタディ

ここで、実際の実践から2つの例を検討します。 上位のクエリを処理する場合、もちろん、まず最初に、複雑で操作が非常に大きく、自明ではない何かがあるはずであるという事実について考えます。 実際、これは常にそうではありません。 非常に単純なクエリが上位の操作に該当する場合があります。

例1

select * from (select o.* from rnko_dep_reestr_in_oper o where o.type_oper = 'proc' and o.ean_rnko in (select l.ean_rnko from rnko_dep_link l where l.s_rnko = :1) order by o.date_oper_bnk desc, o.date_reg desc) where ROWNUM = 1 

この例では、クエリは2つのテーブルのみで構成されており、これらは重いテーブルではなく、わずか数百万のレコードです。 それは簡単に思えますか？ ただし、リクエストはトップにヒットします。

彼の何が悪いのかを考えてみましょう。

以下は、Enterprise Manager Cloud Controlの写真です。このリクエストの統計に関するデータです（Oracleにはそのようなツールがあります）。 このリクエストには通常の負荷があることがわかります（上のグラフ）。 横の数字1は、平均して1つのセッションのみが実行されていることを示します。 緑の図は、 リクエストがCPUのみを使用していることを示しています。



ここで何が起こっているのかを理解してみましょうか？



上の表は、リクエストに関する統計を含む表です。 ほぼ70万回の打ち上げ-これは誰も驚かないでしょう。 ただし、12月15日の最初の読み込み時間から12月22日の最後の読み込み時間までの時間間隔（前の図を参照）は1週間です。 1秒あたりの開始回数を数えると、 クエリは1秒ごとに平均して実行されることがわかります 。

さらに調べます。 クエリの実行時間は0.93秒です。 1秒未満、それは素晴らしいことです。 私たちは喜ぶことができます-要求は重いものではありません。 それにもかかわらず、彼はトップを叩きました。つまり、彼は多くのリソースを消費します。 どこで多くのリソースを消費しますか？

テーブルには、論理読み取り用の行があります。 1回の起動には約8,000ブロックが必要であることがわかります（通常、1ブロックは8 KBです）。 1秒に1回動作するリクエストは、メモリから約64 MBのデータをロードすることがわかりました。 ここで何かが間違っています。理解する必要があります。

計画を見てみましょう：フルスキャンがあります。 それでは先に進みましょう。

  Plan hash value: 634977963 ------------------------------------------------------------------- | Id | Operation | Name | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | |* 3 | SORT ORDER BY STOPKEY | | | 4 | NESTED LOOPS | | | 5 | TABLE ACCESS BY INDEX ROWID| RNKO_DEP_LINK | |* 6 | INDEX UNIQUE SCAN | UK_RNKODEPLINK$S_RNKO | |* 7 | TABLE ACCESS FULL | RNKO_DEP_REESTR_IN_OPER | ------------------------------------------------------------------- Predicate Information (identified by operation id): 1 - filter(ROWNUM=1) 3 - filter(ROWNUM=1) 6 - access("L"."S_RNKO"=:1) 7 - filter(("O"."TYPE_OPER"='proc' AND "O"."EAN_RNKO"="L"."EAN_RNKO")) 

rnko_dep_reestr_in_operテーブルには500万行しかなく、行の平均の長さは150バイトです。 しかし、接続しているフィールドに十分なインデックスがないことが判明しました。サブクエリは、ean_rnkoフィールドを介してリクエストに接続されています。

さらに、たとえ彼が現れても、実際には状況はあまり良くありません。 その長いインデックススキャン（長いINDEX RANGE SCAN）が発生します。 ean_rnkoは、エージェントの内部識別子です。 エージェントのレジストリは蓄積され、このリクエストが選択するデータの量は毎年増加し、リクエストは遅くなります。

解決策： ean_rnkoおよびdate_regフィールドのインデックスを作成し、このリクエストで日付ごとにスキャンの深さを制限するように開発者に依頼します。 その後、少なくともある程度、クエリのパフォーマンスがほぼ同じ境界にとどまることを保証できます。これは、サンプルサイズが一定の時間間隔に制限され、テーブル全体を読み取る必要がないためです。 これは非常に重要なポイントです、何が起こったのか見てください。


最適化後、動作時間は100分の1秒未満（0.93でした）になり、ブロック数は平均で8.5になりました-それは以前の1000分の1になりました。

例2

 select count(1) from loy$barcodes t where t.id_processing = :b1 and t.id_rec_out is null and not t.barcode is null and t.status = 'u' and not t.id_card is null 

通常、クエリトップには複雑なものが予想されるという話から話を始めました。 上記は、1つのテーブルに移動する「複雑な」クエリの例です（！）。また、上位のクエリにも入りました:) ID_PROCESSINGフィールドにインデックスがあります。
このクエリにはIS NULL条件が3つあり、ご存じのとおり、このような条件にはインデックスが付けられていません（この場合はインデックスを使用できません）。 さらに、（ID_PROCESSINGおよびSTATUSによる）等価タイプの条件は2つしかありません。

おそらく、このクエリを見る開発者は、まずID_PROCESSINGとSTATUSにインデックスを作成することをお勧めします。 しかし、選択されるデータの量（多くのデータがある）を考えると、このソリューションは機能しません。

ただし、リクエストは多くのリソースを消費します。つまり、動作を速くするには何かをする必要があります。 理由を理解してみましょう。


上記の統計は1日間のものであり、5分ごとにリクエストが開始されることがわかります。 主なリソース消費は、CPUとディスクの読み取りです。 クエリの開始数の統計を示すグラフの下では、すべてが順調であることがわかります-開始数は時間とともにほとんど変化しません-かなり安定した状況です。


さらに詳しく見ると、クエリの実行時間が非常に大きく変化することがあります-数回、これはすでに重要です。


次に考えてみましょう。

Oracle Enterprise ManagerにはSQL監視ユーティリティがあります。 このユーティリティを使用すると、リクエストによるリソースの消費をリアルタイムで確認できます。


上記は問題のあるリクエストのレポートです。 まず、[実際の行]列のINDEX RANGE SCAN（下の行）が1700万行を示していることに注目してください。 おそらく検討する価値があります。

実装計画をさらに見ると、計画の次の項目の後、これらの1700万行のうち、1705だけが残っていることがわかります。 最終サンプルでは、​​約0.01％が残っています。つまり、明らかに非効率的で、不要な作業が行われました 。 さらに、この作業は5分ごとに行われます。 ここに問題があります！ したがって、このリクエストは上位クエリにヒットします。

この重要な問題を解決してみましょう。 そもそもそれ自体を請うインデックスは非効率的であるため、トリッキーな何かを考え出し、IS NULLの条件を破る必要があります。

新しいインデックス

開発者と相談し、考えて、この決定に至りました。ID_PROCESSING列が含まれる機能インデックスを作成しました。これは、リクエストに同等の条件があり、他のすべてのフィールドをこの関数の引数として含めました。

 create index gc.loy$barcod_unload_i on gc.loy$barcodes (gc.loy_barcodes_ic_unload(id_rec_out, barcode, id_card, status), id_processing);  function loy_barcodes_ic_unload( pIdRecOut in loy$barcodes.id_rec_out%type, pBarcode in loy$barcodes.barcode%type, pIdCard in loy$barcodes.id_card%type, pStatus in loy$barcodes.status%type) return varchar2 deterministic is vRes varchar2(1) := ''; begin if pIdRecOut is null and pBarcode is not null and pIdCard is not null and pStatus = 'U' then vRes := pStatus; end if; return vRes; end loy_barcodes_ic_unload; 

この関数のタイプは決定論的です。つまり、同じパラメーターセットに対して常に同じ答えを返します。 この関数は常に1つの値、この場合は「U」を常に返すようにしました。 これらのすべての条件が満たされると、満たされない場合は「U」が発行されます-NULL。 このような機能インデックスにより、データを効果的にフィルタリングできます。

このインデックスを適用すると、次の結果が得られました。



ここでは、1つの列が1つのスナップショットであり、データベースの30分ごとに行われます。 私たちは目標を達成し、この指標は本当に効果的です。 定量的な特性を見てみましょう。

平均リクエスト統計
	前に	後
経過時間、秒	143.21	60.7
CPU時間、秒	33.23	45.38
バッファ取得ブロック	6`288`237.67	1`589`836
ディスク読み取りブロック	266`600.33	2`680

動作時間は2.5倍減少し、リソースの消費（バッファ取得）-約4減少しました。ディスクから読み取られたデータブロックの数は非常に大幅に減少しました。

積極的な最適化の結果

私達は受け取った：

• データベースの負荷を軽減します。
• データベースの安定性を向上させます。
• ソフトウェアパフォーマンスインシデントの数の大幅な削減。

パフォーマンスインシデントは10倍減少しました 。 これは主観的な量であり、以前は、RBS-Retail Bankの複合施設で月に1〜2回発生していましたが、今では事実上忘れていました。

これにより問題が発生します。ソフトウェアパフォーマンスの問題はどうでしょうか。 私たちはそれらに直接対処しませんでしたか？

最後のスケジュールに戻ります。 覚えていれば、フルスキャンが行われ、メモリに多数のブロックを保存する必要がありました。 要求は定期的に実行されたため、これらのブロックはすべてOracleキャッシュに格納されていました。 現時点でデータベースで高負荷が発生した場合、たとえば誰かが積極的にメモリを使用し始めた場合、データブロックを保存するためにキャッシュが必要になることがわかります。 したがって、リクエストのデータの一部は混み合ってしまいます。つまり、物理的な読み取りを行う必要があります。 物理的な読み取りを行うと、クエリの実行時間はすぐに大幅に増加します。

論理読み取りはメモリを使用して動作しているため、高速で発生し、ディスクへのアクセスは遅くなります（時間、ミリ秒を見ると）。 運がよく、オペレーティングシステムのキャッシュまたはアレイキャッシュにこのデータがある場合、それはまだ数十マイクロ秒になります。 Oracleのキャッシュからの読み取りははるかに高速です。

フルスキャンを削除すると、このような多数のブロックをキャッシュ（バッファーキャッシュ）に保存する必要がなくなりました。 これらのリソースが不足している場合、リクエストは多少安定しています。 古いインデックスのような大きなサージはもうありません。

プロアクティブな最適化の概要：

• クエリとそのビジネスロジックがどのように機能するかを確認するために、テストサーバーで最初のクエリ最適化を実行し、余分な操作を行わないようにします。 これらの作品は残っています。
• ただし、定期的に、数か月に1回、サーバーから全負荷に関するレポートを削除し、データベース内の上位のクエリと操作を検索して最適化することは理にかなっています。

Oracleデータベースで統計を取得するための多くのツールがあります。

• AWRレポート（DBMS_WORKLOAD_REPOSITORY.awr_report_html）;
• Enterprise Manager Cloud Control 12c（SQLの詳細）;
• SQL詳細アクティブレポート（DBMS_PERF.report_sql）;
• SQL監視（EMCCのタブ）;
• SQL監視レポート（DBMS_SQLTUNE.report_sql_monitor *）。

これらのツールの一部はコンソールで機能します。つまり、Enterprise Managerに関連付けられていません。


ボーナス： RNCO「ペイメントセンター」およびCFT の専門家は、ノボシビルスクでの会議の準備が整っており、いくつかの有用なレポートを作成し、実際の出口ラジオを編成しました。 2日間、専門家、講演者、主催者がCFTラジオを訪れました。 エントリを含めることで、シベリアの夏に戻ることができます。ブロックへのリンクは次のとおりです。Kubernetes：長所と短所 。 データサイエンスと機械学習 DevOps

既に11月8日と9日であるモスクワのHighLoad ++では、さらに興味深いことがあります。 このプログラムには、専門家のアドバイスを共有し、驚きの何かを見つけるパートナーからの、負荷の高いプロジェクト、マスタークラス、会議、イベントに関する作業のあらゆる側面に関するレポートが含まれています。 最も興味深いものについて書き、 ニュースレターであなたに通知します、接続してください！