何を更新するかなどについて、実際には多くの詳細を提供していません。
更新文を作成するための基礎として、SQLで実行したいことを達成できない場合を除いて、PL / SQLを使用しないでください。コンテキストの切り替えだけでは、レコードの処理に取り掛かる前にパフォーマンスが低下します。
更新専用のインデックスを作成できる場合は、更新ステートメントのWHERE句に表示される列にインデックスを付けて、更新される前にレコードをすばやく見つけられるようにします。
挿入に関しては、レコードを挿入するためのヒントの利点を調べて、/*+ append */特定のケースに役立つかどうかを確認してください。
最後に、使用するテーブル構造は、提供した詳細に触れ始めていない可能性のある要因によって異なります。DB構造について調査するか、DBAに101クラスを依頼することをお勧めします。それ。
幸運を祈ります...
編集：
に応答して：
Play ID - ID ( here id would be song name like abc.wav something..so may be VARCHAR2, yet not decided..whats your openion...is that fine if primary key is of type VARCHAR2....any suggesstions are most welcome...... ) Type - Song or Message ( varchar2) Count - Summation of total play ( Integer) Retries - Summation of total play, if failed. ( Integer) Duration - Total Duration ( Integer) Last Updated - Late Updated Date Time ( DateTime )
VARCHAR2データ型としてPRIMARYKEYを使用することに問題はありません（ただし、非特定のPK、つまりシーケンスを使用することの価値については、多くの場合議論があります）。ただし、PKが一意であることを確認する必要があります。これを保証できない場合は、一意性を維持するために別の列を導入するよりも、PKとしてシーケンスを使用する価値があります。
テーブル列をINTEGERとして宣言することに関しては、いずれにせよ最終的にNUMBERに解決されるので、テーブル列を数値として作成します（INTEGERとして作成する特別な理由がない限り）。
最後に、DATETIME列では、時間部分に実際の精度が必要な場合を除いて、DATEデータ型としてデケアする必要があります。必要な場合は、TIMESTAMPデータ型として宣言します。
テーブル自体の構造（つまり、必要な列など）を支援することに関しては、レポート要件、アプリケーション要件または監査要件、会社のベストプラクティス、命名について何も知らないため、それは私が支援できるものではありません。コンベンションなど。それはあなたが自分で決めることだと思います。
ただし、パフォーマンスのために、インデックスを最小に保ち（つまり、UPDATE WHERE句の検索に役立つインデックス列のみ）、可能な限り最小のデータのみを更新し、前に提案したように、挿入のAPPENDヒントを調べてください。自分でテストする必要があります。