Lログのパーティションテーブルがきれいに簡単に、実行する時間でなければなりません
一般的なアプリケーションは、レコードユーザ操作ログデータ変更レコード、ログやその他の取引フロータイプライブラリのテーブルに使用されるいくつかのテーブルを持つことになります。これらのテーブルは、移行またはクリーンな歴史がプロパティをクリーンアップするには、Oracleのパーティションの切り替えで、より便利になるときに、効率が削除よりもはるかに高い、フィールドのパーティションを行うには最高の時間です。
sequece Lは、キャッシュが頻繁にアクセスが増加しなければなりません
Oracleは、このパラメータを開くとデータアプリケーションの各ブロックでsequeceの競合が得られる確率が取得sequece速度をスピードアップするために削減されますので、Oracleは、sequeceの事前の一部を生成することができ、シーケンスを作成するために、キャッシュ・パラメータを指定することができます。
Lチームリストには、パーティションの操作を行い、高い水問題を減らす必要があります
時々、私たちは、このようなメッセージキューとして、記録後の処理が削除され、処理されるべき情報を格納するデータベース・テーブルを使用しています。これは、我々はチームのリストを呼び出します。この表には、多くの場合、高い水の問題、終了した記録プロセス内のデータの多くの突然の流入、およびその他のシステム・テーブルをある時点で、テーブル全体のアクセス速度は、移動後に復元されないため、高水位の（非常に遅い削除）。ライブラリは、テーブルのパーティションを持っている場合はその後、この問題が発生する可能性はありません。
lは外部キーを軽減します
我々は、一般的に援助への外部キーを使用してデータベーステーブルの設計では、異なるデータベーステーブルのデータの関連付けを表しますが、実際の配備は外部キーを追加するのが最善ではありません。データの外部キーの挿入および削除が効率に影響を与えることで、より多くの重要な理由は、データベーステーブルのデータクレンジング中に外部キーを追加することである一つの理由は、修理に多くの問題をもたらすでしょう。
ストレージ手順を低減するL
いくつかのプログラマは、データ速度を処理するが、ビジネスロジックをカプセル化するが、圧力は、データベースサーバに任されているストアドプロシージャを使用することを好みます。データベース・サーバ・リソースは、多くの場合、より限定されたと拡大するのがより困難です。アプリケーション・サーバ・リソースは、拡張を破って、比較的豊かなになります。ストアドプロシージャの使用その使用を最小限にすることが提案されているとあまりにも多くのビジネスロジックを入れないでください。
バインド変数を使用してL
可能な限り、代わりに戦いのSQLバインド変数を使用し、これは、SQLインジェクションのリスクを軽減することであり、他のデータベースが、（同じテキストSQL可能多重化）の実行計画を再利用するデータベースが生成した実行計画の消費を減少させることができるようにすることです。
パラレルLを用い
オラクルは、速度データ処理を促進するように、分割SQLは異なるプロセスによって製造される部品の複数にデータセットに関連することができ、並列処理を提供します。OLAPシステムでは、SQLの速度を向上させるために、この技術を使用することを検討してください。
データ変更テーブルの過剰な量を使用して、L個のヒントを避けます
時々、私たちのアプリケーションは、データテーブル内のいくつかの比較的大きな変化、データの内部時々わずか数十テーブル、時には数万人、数十万人となります。そのようなAのテーブルへのアクセスは、好ましくは、力のヒントデータベースに使用される、バックSQLは変化しないため、データベース生成された実行計画は、ときに、データの変更、フルテーブルスキャンを使用して時間とすることができるデータの量は、いずれの場合にも実行計画へのアクセスを索引付けその後、全表スキャン効率が非常に低くなります使用し、変更されていません。
共有メモリなどを用いて、TTのL
セッションのニーズがデータのブロックにアクセスするには、このデータブロックが他のユーザーによってまたはディスクからデータブロックが別のセッションによって変更されているメモリに読み込まれている場合は、現在のセッションでは、それは忙しいバッファが生成されます、待機する必要があります待機は、待ってもラッチの競合を伴います。同じデータ・ブロックにアクセスするにはあまりにも多くのセッションが長いビジー待機をバッファリングの原因となる場合は通常、パフォーマンスのCPU使用率の形で、待って高いが、低いスループットです。熱は、データベースまたは同じ原因の一部SQL繰り返し実行頻繁にアクセスされるデータ・ブロックの急速な設定結果を引き起こす可能性があります。
二つの大きなテーブルに関連付けられているLは、クエリをハッシュ結合を歩いてみてください
Oracleは、テーブルの相関アルゴリズムの多様を提供するが、実験後、データ接続または接続の二つの大きなテーブルは、ハッシュ最高の効率を使用しているが。
lは主キーとして運用要素の使用を最小限に抑えます
システムの利便性の多くを提供することができ、主キーの操作要素として使用しないでください。まず、オリジナルを変更する必要性を避けます。第2
縦と横のテーブルデザインテーブルlの使用の合理化
いわゆるクロステーブルは、物理一列に格納された全てのレコードの特性、成形を指すデータベーステーブルの（ID、プロパティ1プロパティ2、...、N属性）。
縦軸は別々に、データベーステーブルとして（ID、属性名、属性値）を設計複数のレコードを、格納実体属性テーブルれています。
ここで、垂直および水平のテーブル表の一例です。
クロステーブルを使用する利点：
1、より直感的に、より便利にお問い合わせ
属性プロパティの値に応じて2含有量は、年齢とともに、番号のタイプが格納されている、例えば、VARCHAR2によってストレージ占有を設計することができます
垂直テーブルの利点を使用します。
1つのフィールドの回避単一伸展停止、Oracleデータベースがラインより記録フィールドに格納され、スキャンの記録に要する時間をよりIOなり
2より便利性を高めます
推奨：プロパティを頻繁に使用するためには、プロパティ（住所など）頻繁に使用されていない、またはレコードいくつかの属性（例えばブログ）耽溺テーブルのほんの一部のためのクロステーブルを置きます。
小さなテーブルL頻繁に使用されるキャッシュ・パラメータ・セットを考慮することができます
キャッシュを設定した後、Oracleは、この表のデータはメモリに保持されていることを確認し、アクセス速度を向上しようとします。私は、オペレータとメニュー情報テーブルに加えてキャッシュパラメータ、ログのスピードの場合の大幅な増加に会いました。
lはマテリアライズド・ビューを
ノーマルビューだけではない効率向上のための複雑なクエリを、簡素化するために使用されます。Oracleの特別なオブジェクトがマテリアライズド・ビューと呼ば提供し、クエリの結果セットがアップし、保存、およびサポートは、オートリフレッシュ時に基本となるデータの変更を表示することができます。しかし、より多くのバグよりも景色、使用注意をマテリアライズド。
RACクラスタ・データベースを使用して、Lは、好ましくは、異なる優先順位のサービス・ノードを使用して分割されています
要求されたデータブロックのOracle最初のアクセスデータがメモリにロードされているので、データブロックが頻繁に訪れたノードの異なるインスタンスである場合、クラスタは、他のノード装置への1つのノードからRAC頻繁なデータ転送をもたらす、それは非常に時間がかかるであろう。データ競争の確率を低減することができるように、それは、異なるRACノードに異なるビジネス優先的にアクセスすることをお勧めします。
機能インデックスフィールドクエリの解決状態のLテイク利点、より少ないビットマップインデックス
使用。ビットマップインデックスデータブロックは、原因の競合による可能性が高いあまり推奨されOLTPシステムです。
リットル悲観的ロックと楽観的ロック
ペシミスティック・ロックの思想は、データの同時変更の確率は、比較的大きい第一のデータのロックを変更する前に、データベースのロック機構の助けを必要と考えています。オプティミスティック・ロックの思想は、データは、一般的に競合が発生しないと考えています。だから、一般的にデータを最初にチェックアウトされていますが、データベースのチェックにデータバックを変更するときに、アップデートが失敗したと考えている場合ではない、変わっていない、ロックされました。ビジネスシナリオを再試行失敗を可能にする、データベースのロック上のリソース消費量を削減、悲観的ロックの使用を検討することをお勧めします。
lの読取り一貫性
Oracleは、データブロックがUNDO表領域になる前に、それはデータが検索結果に影響を与えずに変更する、SQLクエリ処理を保証することができ、データブロックにバックアップされている修正しました。しかし、また、指定した時点で「フラッシュバッククエリー」技術、データのクエリのデータベーステーブルを使用することができます。
リライトを有する複雑なクエリの使用に関連L
SQLの一つの利点は、このロジックを簡素化し、必要に応じて第二の、ヒントを使用することができる：反復クエリを低減する、第1のコンテンツエンティティとしてでマテリアライズします。
Lインデックスは合理的である（ベースが小さすぎるフィールドがインデックスを構築するには適していない場合）
一部のプログラマは、時間の保存、クエリの半数以上で、それは間違っていると、インデックス上記セックス列を構築しています。この選択性はあるため、クエリの高くないために、テーブルに戻り、インデックスを使用してクエリは、ランダム読み取りおよび書き込み速度がたくさん原因チェックが、早く全表スキャンを指示しないように。
データ移行方法の速度を加速するストレージのL大量。
NOWAITコミット
追記
ALTER TABLEのロギングなし
インデックスの削除
使用スワップ
Lは、好ましくは、SQLを含む出力ログするために、データベースAPIにカプセル化されています
複雑な操作を行うためのシステムの後、初心者は完全にシステム事業は非常に困難であることを理解したいと思います。あなたがアクセス出力の内部で使用されるデータベースへのSQLログを設定することができれば、我々は、システムの運用・保守のために、より便利にすることができます。
複数のデータベースの開発経験を参照してください。
https://www.cnblogs.com/kingstarer/p/9613626.html「Oracleデータベースアプリケーションのパフォーマンスの最適化の経験（研修配布資料）」
https://www.cnblogs.com/kingstarer/p/11968247.html「PROCは、Oracleのパフォーマンスの最適化の経験をプログラミング」