次の項目が含まれます。
この項では、JVM診断エンジンのステータスを表示するエラーの一覧を表示します。階層間の機能エラーは、次のような原因で発生する可能性があります。
一致しないデータベース接続情報
ユーザー権限不足
「パフォーマンス診断」ページで、「上位SQL」グラフまたは「上位DBWaitイベント」グラフに「不明」エントリがあり、「上位データベース」グラフに未定義エントリがあり、かつ、「ライブ・スレッド分析」ページの「DB待機」リンクをクリックしたときに「データベース詳細」ポップアップ・ウィンドウが表示された場合は、多層間の相互関係を確立できません。
図21-1 ライブ・スレッド分析(クロス層)
注意:
多層間の相互関係が確立されている場合は、「ライブ・スレッド分析」ページの「DB待機」リンクをクリックすると、データベース・インスタンスのデータベース診断ページが表示されます。その場合、「JVMパフォーマンス診断」ページの「上位SQL」と「上位DBWaitイベント」、および「上位データベース」の各グラフにはそれぞれ「不明」および「未定義」エントリは含まれません。カスタム・データベースの場合、「DB待機」リンクは無効になっています。
解決策:
データベースの不一致のために多層間の相互関係を確立できない場合は、データベースが登録されているかどうか調べてください。「設定」メニューから、「ミドルウェア管理」、「アプリケーション・パフォーマンス管理」の順に選択します。「JVM診断エンジン」を選択して、「構成」をクリックします。「データベースの登録」タブをクリックして、データベースが登録されているかどうかを調べます。データベースが登録されていなかった場合は、「DB待機」リンクをクリックしてJDBC接続文字列を検査し、JVM診断に登録されているデータベースにそれが一致しているかどうか、確認します。たとえば、JDBC接続文字列にSIDが含まれている場合は、登録されているデータベースはSIDを持っている必要があります。同様に、JDBC接続文字列にあるサービス名とデータベースのホスト名も、登録されたデータベースのものと一致する必要があります。一致することが必要なそうした情報の別の例として、データベースのホスト名があります。
カスタム・データベースの場合は、ユーザーの権限が不足している場合があります。その場合は、v$active_services
、v$instance
、v$session
、v$sqltext
、v$process
およびv$session_wait
表に対する権限がユーザーにあるかどうかを調べます。
JVM診断エージェントから返されたJDBCのURLが、登録されたデータベースのうちのいずれかであるが、データベースの不一致やホスト名の誤りなどのために多層間の相互関係を確立できない場合は、そのJDBC URLを登録済データベースと関連付ける必要があります。次のページから、JDBC URLをデータベースと関連付けることができます。
「ライブ・スレッド分析」ページ: 「Java仮想マシン」メニューから、「ライブ・スレッド分析」を選択します。「JVMスレッド」表で、DB待機状態のスレッドを選択し、「DB URLの管理」をクリックします。「登録されたデータベースの関連付け/関連付け解除」で、JDBC URLを選択して「追加」をクリックし、関連付ける登録済データベースのURLを指定します。
図21-2 ライブ・スレッド分析: 登録済データベースの関連付け/関連付け解除
Java Workload Explorerでは、JVMまたはJVMプールに関連付けられたすべてのパフォーマンス統計の詳細なビューが提供されます。
「登録済データベース」ページ: 「設定」メニューから「ミドルウェア管理」、「アプリケーション・パフォーマンス管理」の順に選択します。「アプリケーション・パフォーマンス管理エンジン」表で「JVM診断エンジン」行を選択して、「構成」をクリックします。
「データベースの登録」タブをクリックします。「JVM診断登録済データベース」ページが表示されます。登録済データベースのリストが表示されます。データベースを選択し、「DB URLの管理」をクリックします。登録済データベースの関連付け/関連付け解除で、データベースURLを選択して「追加」をクリックし、関連付けるデータベースのURLを指定します。
図21-3 設定: 登録済データベースの関連付け/関連付け解除
JVM診断エージェントのホスト名と、データベースのV$ESSION
表に保管されているマシン名が不一致(マシンの論理名の付け方が一貫していないなど)のために多層間の相互関係が確立できない場合は、次の手順を実行します。
Enterprise Managerのjam_jvm
表にあるv$SESS_MACHINE
列を、データベースのV$SESSION
で指定された正しい値で更新します(例: update jam_jvm set V$SESS_MACHINE = 'JVMD Agent Machine name
' where jam_jvm_id ='jam_jvm_id
')。
データベースがJVM Diagnostics Managerにアクセスできないために多層間の相互関係が確立できない場合は、ログ・ファイルでデータベース名を調べ、そのデータベースが停止または非アクティブではないか、あるいはリスナーが停止していないか、確認します。そうである場合、JVM Diagnostics Managerはデータベースに接続して多層間の相互関係を確立することができません。
前述のすべての手順を実行しても、多層間の相互関係がまだ確立できない場合は、JVMDマネージャのログ・ファイルをパージする必要があります(*.out)。「設定」メニューで「ミドルウェア診断」を選択して、「エンジンおよびエージェント」を選択します。「JVM診断エンジン」を選択し、「構成」をクリックして、「JVMDエンジン・ログ・レベル」と「クロス層ログ・レベル」を一時的に「トレース」に設定します。
モニタリングを一時的にオフにして(可能な場合)、アプリケーションがDB呼出しを行うとき(「DB待機」に1つ以上のスレッドがある必要があります)に「ライブ・スレッド分析」に移動し、JVMDマネージャのログを送信して問題のレポートを作成します。元のログ・レベルに戻し、モニタリングを再度オンにします。
この項ではトレース中に発生するエラーの一覧を表示します。「ポーリング継続時間」の値が大きいためタイムアウトが生じた場合は、次のエラーが発生します。
エラー: weblogic.transaction.internal.TimedOutException: トランザクションは30秒後にタイムアウトしました。
解決策: このエラーはトレースの機能に影響しないため、無視できます。
この項では、デプロイメント・スクリプトの実行時に発生するエラーの一覧を表示します。
エラー: スクリプト例外: デプロイの実行中にエラーが発生しました: 実行したアクションは600,000ミリ秒後にタイムアウトしました。
解決策: この問題を解決するには、ターゲットのWebLogicドメイン管理コンソールのロックがすでに取得されているかどうか確認します。取得済の場合はそれを解放して、次の手順に従ってスクリプトを再度実行します。
WebLogic管理コンソール、http://<machine address>:<webogic port>/consoleにログインします。
保留中の変更が存在しないかどうかを確認します。保留中の変更が存在する場合、状況に応じて、それらの変更をアクティブ化するかまたは取り消して、スクリプトを再実行します。
エラー: WebLogic管理サーバーのユーザー名とパスワードが誤っている場合は、次のエラーが表示されます。
Caused by: java.lang.SecurityException: User: <username>, failed to be authenticated
.
このメッセージは一般に長いエラー・メッセージの末尾にあります。
次の例外が表示されることもあります。
javax.naming.AuthenticationException [Root exception is java.lang.SecurityException: User: weblogic, failed to be authenticated.] at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslat or.java:42) at weblogic.jndi.WLInitialContextFactoryDelegate.toNamingException(WLInitialContextFactoryDelegate.java:788) at weblogic.jndi.WLInitialContextFactoryDelegate.pushSubject(WLInitialContextFact oryDelegate.java:682) atweblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:469) at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialConte xtFactoryDelegate.java:376) at weblogic.jndi.Environment.getContext(Environment.java:315) at weblogic.jndi.Environment.getContext(Environment.java:285) at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactor y.java:117) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:235) at javax.naming.InitialContext.initializeDefaultInitCtx(InitialContext.java:318) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:348) at javax.naming.InitialContext.internalInit(InitialContext.java:286) at javax.naming.InitialContext.<init>(InitialContext.java:211)
解決策: WebLogic管理サーバーの正しいユーザー名とパスワードを入力して、スクリプトを再度実行します。
エラー: この例外は、weblogic.jar
へのパスが無効であるか、またはユーザーにweblogic.jar
ファイルの読取り権限がない場合に発生することがあります。
Exception in thread "main" java.lang.NoClassDefFoundError: javax/enterprise/deploy/spi/exceptions/TargetException Caused by: java.lang.ClassNotFoundException: javax.enterprise.deploy.spi.exceptions.TargetException at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
解決策: 正しいパスを指定するか、ユーザーにjarファイルへの読取り権限のある資格証明を付与します。
エラー: WebLogic管理コンソールがロックされていると、エージェントのデプロイメント・ジョブは予期したように動作しないことがあります。WebLogicドメインがロックされているためagent.log
ファイルがデプロイできない、というメッセージが表示されます。
解決策: JVM診断エージェントはt3/t3sプロトコルを使用してデプロイされます。t3/t3sポートが開いていることを確認します。
エラー: SSLを有効にしたWebLogicドメインに、デモ用証明書を使用してデプロイするとき、WebLogicサーバーのデモ用証明書がキーストアにインポートされていない場合にエラーが表示されることがあります。
解決策: WebLogic Serverターゲットをモニタリングしている管理エージェントのキーストアに、WebLogic Serverのデモ資格証明をインポートします。
エラー: deployer.zip
またはjavadiagnosticagent.ear
ファイルのコピー中にBroken pipeエラー(接続が失われた)のようなエラーが表示されます。
解決策: Oracle Management Serviceおよび管理エージェントは、同じグループに属する同じユーザーによりインストールされる必要があります。
エラー: JVMD AGENT DEPLOYMENT FAILED FOR WEBLOGIC 9.2 TARGET
.
次の例外が発生します。
EM Agent home : /scratch/aime/agsh_0819/core/12.1.0.2.0 MIDDLEWARE_HOME : /scratch/aime/mw923 IS_WEBLOGIC9 : true em agent state dir : /scratch/aime/agsh_0819/agent_inst acsera home : /tmp/ad4j_1345730608009/4910760210525348050 wls admin url : t3://emHost.example.com:7001 wls username : weblogic target : AdminServer? weblogic jar path : /scratch/aime/mw923/weblogic92/server/lib/weblogic.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wljmxclient.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wlcipher.jar application name : HttpDeployer? agent keystore location : /scratch/aime/agsh_0819/agent_inst/sysman/config/montrust/AgentTrust.jks Command used for deployment: /scratch/aime/agsh_0819/core/12.1.0.2.0/jdk/bin/java -cp /tmp/ad4j_1345730608009/4910760210525348050/ADPAgent/lib/mips.jar:/scratch/aim e/mw923/weblogic92/server/lib/weblogic.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wljmxclient.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wlcipher.jar -Dweblogic.security.SSL.ignoreHostnameVerify=true -Djava.security.egd=file:/dev/./urandom -Dweblogic.security.SSL.trustedCAKeyStore=/scratch/aime/agsh_0819/agent_inst/ sysman/config/montrust/AgentTrust.jks-Dsun.lang.ClassLoader.allowArraySyntax= true -Dbea.home=/scratch/aime/mw923 com.acsera.ejb.Deployer.RemoteHttpDeployerShell -deploy -adminurl t3://emHost.example.com:7001 -upload -source /tmp/ad4j_1345730608009/4910760210525348050/ADPAgent/deploy/HttpDeployer.ear -targets AdminServer? -username weblogic -name HttpDeployer? -usenonexclusivelock
まず、アプリケーションはターゲット・サーバーでアンデプロイされます
使用法: java [-options] class [args...]
(クラスを実行する場合)
またはjava [-options] -jar jarfile
(jarファイルを実行する場合)
次のオプションがあります。
可能な場合、d32は32ビット・データ・モデルを使用します
-d64 use a 64-bit data model if available -client to select the "client" VM -server to select the "server" VM -hotspot is a synonym for the "client" VM [deprecated] The default VM is server, because you are running on a server-class machine. -cp <class search path of directories and zip/jar files> -classpath <class search path of directories and zip/jar files> A : separated list of directories, JAR archives, and ZIP archives to search for class files. -D<name>=<value> set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:<value> require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -X print help on non-standard options -ea[:<packagename>...|:<classname>] -enableassertions[:<packagename>...|:<classname>] enable assertions -da[:<packagename>...|:<classname>] -disableassertions[:<packagename>...|:<classname>] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions -agentlib:<libname>[=<options>] load native agent library <libname>, e.g. -agentlib:hprof see also, -agentlib:jdwp=help and -agentlib:hprof=help -agentpath:<pathname>[=<options>] load native agent library by full pathname -javaagent:<jarpath>[=<options>] load Java programming language agent, see java.lang.instrument -splash:<imagepath> show splash screen with specified image /scratch/aime/mw923/weblogic92/server/lib/wljmxclient.jar ls: invalid line width: eblogic.security.SSL.ignoreHostnameVerify=true Status returned from the java process is 512
この項ではloadheapエラーの一覧を表示します。
エラー: ヒープダンプ操作中に次のエラーが発生します。
glibc detected * free(): invalid next size (fast): 0x0965d090" ./loadheap.sh: line 237: 32357 Aborted ./bin/${bindir}/processlog in=$infile hdr=${sumdata} obj=${objdata} rel=${reldata} root=${rootdata} osum=${objsumdata} rrel=${rootrel} heap=${heap_id} skip=$skipgarbage db=$dbtype $* Error processing file /tmp/heapdump6.txt
解決策: ヒープダンプ操作が正常に完了しているかどうか確認します。heapdump6.txt
ファイルを開いて、ファイルの最後にheapdump finishedの文字列があるかどうか確認します。この文字列がある場合は、終了したダンプ・ファイルをロードします。
エラー: ヒープダンプはすでに進行中で、別のヒープダンプは実行できません。
解決策: ヒープダンプ操作が正常に完了しているかどうか確認します。heapdump6.txt
ファイルを開いて、ファイルの最後にheapdump finishedの文字列があるかどうか確認します。
エラー: loadheap.sh
により、使用できない一意の索引が作成されました。
解決策: loadheap.zip
に付属しているloadheap/sql/cleanup.sql
を実行して、一意の索引を修正します。
IBM JDK 1.6でJVM診断エージェントをデプロイしようとすると、次のエラーが発生します。
エラー: JVM診断エージェントがJDK 1.6にデプロイされると、次のメッセージが表示される場合があります。
Jam Agent : can_tag_objects capability is not set. Copy /tmp/libjamcapability.so to another directory and restart Java with argument -agentpath: <Absolute path of libjamcapability.so>
解決策: 最新のjamagent.warをデプロイし、-agentpath:<Absolute path of libjamcapability.so after copying to another directory>
をjava引数に追加します。
このメッセージはJVM診断エージェントがJVM診断エンジンに接続してからのみ、表示されます。2番目に、この引数はJVM引数である必要があります(プログラム引数ではありません)
WebLogic管理コンソールを使用して(ノードマネージャを介して)サーバーが起動される場合、これらの引数は管理コンソールの「サーバーの起動」の下で指定できます。サーバーがコマンドラインから起動される場合(startWeblogic.sh
またはstartManagedServer.sh
)、これらの引数はstartWeblogic.sh
で指定する必要があります。サーバーが複数台ある場合は、サーバー名の確認がstartWeblogic.sh
にあり、libjamcapability.so
のパスがサーバーごとに異なっていることを確認してください。
startWeblogic.sh
での入力例を次に示します。
if [ "${SERVER_NAME}" = "AdminServer" ] ; then echo "********************************************* MODIFIED ADMIN SERVER" JAVA_OPTIONS="${JAVA_OPTIONS} -agentpath:<Absolute path of libjamcapability.so.X after copying to another directory> export JAVA_OPTIONS fi
サーバー起動時(jamagentログが表示される前)のメッセージ「Capabilities Added by libjamcapability.so」は、libjamcapability.so
が正常にロードされたことを確認しています。
この項ではユーザー・インタフェース・エラーの一覧を表示します。
エラー: これはエージェントのタイムアウト・エラーです。
JAM Console:Socket timed out after recv -- client emHost.example.com:7001 is not Active [0] secs JAM Console jamlooptimeout=[3] JAM CONSOLE: JVM 1 is not active JAM Cons ErrProcessing Request:128 JVM 1 is not active jamDAL: jamreq returned 128 return status < 0 from jamDalInst.processRequest
解決策: このエラーを解決するには、「エージェント・リクエスト・タイムアウト」および「エージェント・ループ・リクエスト・タイムアウト」の値を増やします。
エラー: JVM診断エージェントは起動され、稼働しているが、リアルタイム・ページに表示されません。
解決策: ログ・ファイルにJAMMANAGER: OLD AGENT
またはNULL POOL
と表示されていたり、最適化レベルが誤っている場合、これは、古いJVM診断エージェントまたはDBエージェントが使用されていることを示しています。この問題を解決するには、次の手順を実行します。
「設定」メニューから、「アプリケーション・パフォーマンス管理」を選択します。
「アプリケーション・パフォーマンス管理エンジン」のリストが表示されます。
「JVM診断エンジン」行をクリックし、「構成」、「データベースの登録」タブの順にクリックします。
「登録されているDBエージェント」リージョンの「ダウンロード」ボタンをクリックして、JVMDコンポーネント・リストから「JVMDエージェント」を選択します。JVM診断エージェントWeb xml
パラメータを指定し、「ダウンロード」、「OK」の順にクリックして、jamagent.war
ファイルをダウンロードします。
エラー: このページを表示するために必要な権限がありません。
解決策: JVM診断データを表示するために必要なJVM診断管理者権限またはユーザー権限があることを確認してください。
この項では、JVM診断の使用中に生じる可能性のある質問の一覧を表示します。次が含まれています。
JVM診断ログは次の場所にあります。
JVM診断エンジンのログ・ファイルは次の場所にあります
<gc_instへのパス>/em/EMGC_OMS1/sysman/log/jvmdlogs/jvmdengine.log.0
UI関連エラーのログの場所は次のとおりです。
$T_WORK/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.out
$T_WORK/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.log
JVM診断エンジンとコンソール間の通信エラーのログ・ファイルは、$T_WORK/gc_inst/em/EMGC_OMS1/sysman/log/emoms.log
にあります。
JVM診断エンジンのステータスを確認するには、次の手順を実行します。
「設定」メニューで「ミドルウェア診断」を選択して、「エンジンおよびエージェント」をクリックします。
JVM診断エージェントのログ・ファイルを確認して、エージェントとマネージャ間の通信を検証します。JAM Agent ERROR: Cannot connect to Console:Connection refused
というエラーが表示されている場合、これはJVM診断エンジンが稼働していないことを示しています。
JAM Console: Agent connection from:[Hostname]
というメッセージが、JVM診断エンジンのログ・ファイル内にあるかどうか確認します。このメッセージが表示されている場合、これはJVM診断エンジンが稼働中でエージェントに接続されていることを示しています。
JVM診断エージェントのステータスを確認する手順:
「ターゲット」メニューから「ミドルウェア」を選択し、Java仮想マシン・ターゲットをクリックします。「Java仮想マシン」メニューから「ライブ・スレッド分析」オプションを選択します。「接続されているJVM」表でJVMのステータスを確認します。
ステータスが「非アクティブ」の場合、これはエージェントがマネージャに接続されていないことを示しています。エージェント・ログを確認して、エージェントが稼働中でマネージャのIPアドレスおよびポート番号が正しいかどうか検証します。
ステータスが「JVMDエージェントがデプロイされていません」の場合、JVM DiagnosticsエージェントをそのJVMにデプロイする必要があります。
JVM Diagnosticsエージェントが稼働している場合、アクティブ・スレッド・データが表示されます。JVM Diagnosticsエージェントが稼働していない場合、JVM is inactive, Please try again after some time
というメッセージが表示されます。
JVM診断エンジンがデータをモニタリング中かどうか検証するには、次の手順を実行します。
JVM診断エンジンは次の理由で停止することがあります。
SLBが正しく構成されていない。
OMSポートがファイアウォールによってブロックされた。
JVMDエンジンにアクセスできるようにするには、OMSポートのブロックを解除し、SLBがアクセスできるようにする必要があります。
次の図は、Enterprise ManagerコンソールのJVMD SLB構成を示しています。
図21-4 JVMD SLB構成
SLB上の仮想サーバー
SLB仮想サーバー・ポート: 4901 aixcs2.us.oracle.com
SLBの仮想サーバーで構成されているIPアドレス: 10.242.182.114
次の図は、SLB上の仮想サーバー構成の詳細を示しています。
図21-5 SLB上の仮想サーバー
「リソース」タブに移動し、デフォルト・プールをメモします。ここで、ローカル・トラフィック・パネルの「プール」メニューを開き、「メンバー」タブに移動します。アクティブな各メンバーは、EMで構成されたOMSを示します。
たとえば、次の図では、OMSは1つのみです。したがって、アクティブなメンバーは1つのみです。メンバー・ホストのOMSホストおよびOMS SSLポートのプロパティが正しいことを確認してください。
EMおよびJVMDのF5 SLBの構成の詳細は、F5 BIG-IPローカル・トラフィック・マネージャによるOMS高可用性の構成を参照してください。
loadHeap
スクリプトを使用してヒープのみをロードできる権限の低いユーザーを作成する場合、create_jvm_diagnostic_db_user.sh
スクリプトを実行できます。
JVM診断エージェントは3つの最適化レベルをサポートしています。
レベル0は、JVM診断エージェントがJVMTIベース・エンジンを使用していることを示します。このレベルは、サポートされているほとんどすべてのプラットフォームでJDK 6シリーズに対してサポートされています。
レベル1はレベル0とレベル2の混合です。選択したプラットフォーム上のごくわずかなJDKに対してのみサポートされています。
レベル2は実行時が効率的なので、ランタイム・オブジェクト分析手法を使用してモニタリングします。
カスタム・プロビジョニング・スクリプトを実行すれば、本番環境でのJVMDエージェントのデプロイメントをカスタマイズできます。
OMSがインストールされていれば、ミドルウェアのインストール・ディレクトリのplugins/oracle.sysman.emas.oms.plugin_12.1.0.0.0
ディレクトリにjvmd.zip
ファイルが見つかります。zipファイルのcustomprov
ディレクトリに、一連のスクリプトが含まれています。これらのスクリプトの使用方法は、同じディレクトリにあるREADME.TXT
に詳しく説明されています。カスタム・プロビジョニング・スクリプトを使用するには、次の手順を実行します。
jamagent.war
ファイルをダウンロードします。jamagent.war
の場所、ドメインおよびサーバーの詳細が記載されたデプロイメント・プロファイルのコピーを作成します。Perl script
を実行すると、指定したすべてのサーバーにJVMDエージェントがデプロイされます。デフォルトのログ・マネージャ・レベルは3です。なんらかの問題が発生した場合は、このレベルを一時的に上げることができます。次の1から5のログ・レベルがサポートされています。
1 - エラー
2 - 警告
3 - 情報
4 - デバッグ
5 - トレース
モニタリング・データには、JVMごとに1日当たり50MB、パージ間隔はデフォルトで24時間に設定することをお薦めします。この容量は、使用する環境の実行時要因(コール・スタックの深さなど)によって変わる可能性があります。そのため、表領域の増加を定期的にチェックし、必要に応じて領域要件を変更する必要があります。こうすれば、急激なスパイクが発生することなく、通常のモニタリングによるデータベースの増加にスムーズに対応することができます。表領域のサイズ変更は、次の要因によって影響を受ける場合があります。
ヒープ・ダンプ: ヒープの分析には大量の表領域が必要です。標準的な対処方法として、ロードされるヒープ・ダンプ・ファイルのサイズの5倍の空き領域を表領域に確保しておくことをお薦めします。ダンプ・ファイルのサイズはわかるため、データベースにロードされる前に、ダンプ・ファイルを収容するのに十分な領域があることを確認します。
スレッド・トレース: これらはヒープより小さくなっています。ユーザーがコンソールでトレースを開始すると、これらがデータベースに自動的にロードされます。これらのスレッドのサイズは、トレース時のアクティブ・スレッドの数、トレースの期間およびトレースのサンプル間隔に応じて大きく異なります。通常は100MB未満ですが、複数のスレッド・トレースが開始されていると、データベースがすぐに一杯になる可能性があります。トレースを開始する前に、データベースに十分な領域があることを必ず確認してください。