You notice that the performance of your production 24/7 Oracle 12c database has
significantly degraded. Sometimes you are not able to connect to the instance because it
hangs. You do not want to restart the database instance.
How can you detect the cause of the degraded performance?
A.
Enable Memory Access Mode, which reads performance data from SGA.
B.
Use emergency monitoring to fetch data directly from SGA for analysis.
C.
Run Automatic Database Diagnostic Monitor (ADDM) to fetch information from the latest
Automatic Workload Repository (AWR) snapshots.
D.
Use Active Session History (ASH) data and hang analysis in regular performance
monitoring,
E.
Run ADDM in diagnostic mode.
Explanation:
* In most cases, ADDM output should be the first place that a DBA looks when notified of a
performance problem.
* Performance degradation of the database occurs when your database was performing
optimally in the past, such as 6 months ago, but has gradually degraded to a point where it
becomes noticeable to the users. The Automatic Workload Repository (AWR) Compare
Periods report enables you to compare database performance between two periods of time.
While an AWR report shows AWR data between two snapshots (or two points in time), the
AWR Compare Periods report shows the difference between two periods (or two AWR
reports with a total of four snapshots). Using the AWR Compare Periods report helps you to
identify detailed performance attributes and configuration settings that differ between two
time periods.Reference:
Resolving Performance Degradation Over Time
It’s B
See here : https://oracle-base.com/articles/12c/emergency-monitoring-em12c
Or mayve D ?
Why not C? Has enterprise manager express a emergency monitor tab? Oracle Cloud Control has It but this is exam for 12 database not 12 cloud control
See here : https://oracle-base.com/articles/12c/emergency-monitoring-em12c
Command Line
You don’t need Cloud Control to perform emergency monitoring. Once connected to the database, you can query views such as V$SESS_TIME_MODEL, V$SESSTAT, V$SQLSTATS, V$ACTIVE_SESSION_HISTORY, DBA_BLOCKERS, DBA_WAITERS etc.
Hang analysis can be performed using oradebug hanganalyze, as described here.
$ sqlplus / as sysdba
SQL> oradebug hanganalyze 3
On versions prior to 11g, you can run hanganalyze from a preliminary connection, which may help if you are trying to connect to a hung database, so a normal connection is not possible.
$ sqlplus -prelim / as sysdba
SQL> oradebug hanganalyze 3
From 11g onward, this method of hanganalyze will still appear to work, but the resulting trace file will include an error message, as documented here.
Tanel Poder discussed a workaround for this here. Use the setospid to connect to an existing process and let that run the hanganalyze for you by including the dump keyword. Thanks to Martin Bach for pointing this out.
$ sqlplus -prelim / as sysdba
SQL> oradebug setospid
SQL> oradebug dump hanganalyze 3
Thanks Vonpire!
B agrain. Thanks Vonpire
https://oracle-base.com/articles/12c/emergency-monitoring-em12c
It’s B
Another answer with no explanation, please dont say anything at all
Feedback,
You want explanation, so read:
https://oracle-base.com/articles/12c/emergency-monitoring-em12c
and
This question is the same in Test 1Z0-060. Do you find this test.
B
Dear friend
Your post is very helpful,and summer is comming, all of us like oakley sunglasses,why we choose it? i think it is cool!thanks!
Ray Ban RB3811 Aviator Gold http://www.marvit.ru/media/import/RB/RB0000063_1_3.jpg
B