RAC DB Report
Hi ,
We have a RAC setup in Production environment , and I am just a general user on RAC DB.
I have to get Information about RAC DB,Instances,Nodes and other metrics.
Now my question is
1: What are the Metrics to make Report of RAC DB.
2: how to collect those data.
thanx
Manish
Hello;
You can get Db version by logging into SQL Plus on one of the nodes. ( assuming you have permissions )
If EM Grid is setup and you have access that can also give you a ton of information.
Otherwise without access your best option is to write up detailed questions and ask the DBA to provide answers.
Best Regards
mseberg
Similar Messages
-
RAC conflict with symantic Antivirus
HI Guru!
I have heard that Symantic Antivirus version 10 conflict with Oracle RAC.I mean if I install the Symantic Antivirus in my RAC server there may be problem with RAC.Is it true??
Please inform me in detail if anybody knows about this.
Thanks in advance
mokaremI assume you're talking about RAC on Windows. Specific problems with Symantec Antivirus software are not known to me, but it's a fact sometimes antivirus programs interfere with Oracle,not only in the context of RAC. There's a metalink note about this:
RAC install reports 'access denied' error while copying files to remote node
Doc ID:373470.1
But there are no general rules, you have to check it out in every single case.
Werner -
How to include optimizer hints in Discoverer
We have a Discoverer report which used to run fine prior to DB migration from (9.2.0.6 to 10G Rac 10.2.0.4).
Since the database is migrated to 10g RAC same reports is running for longer time and failes with ROW_ID error,
we ran the sql generated by the report in SQL Plus with below optimizer hint.
Select /*+ optimizer_features_enable('9.2.0') */
this query ran well with optimizer hint, but i am wondering how to use the optimizer hint in Discoverer Plus/Desktop.
Select /*+ optimizer_features_enable('9.2.0') */
C.EMPLOYEE_NUMBER||' '||A.EMPLOYEE_NAME, A.REPORTS_TO, C.SERVICE_CODE, COUNT(B.ACCOUNT_NUMBER)
FROM PSTAGE.NEW_EMPLOYEE_MASTER A,
PSTAGE.NEW_ALL_WORK_ORDER_MASTER B,
PSTAGE.NEW_ALL_WORK_ORDER_DETAIL C
WHERE ( ( B.WORK_ORDER_NUMBER = C.WORK_ORDER_NUMBER AND B.SITE_ID = C.SITE_ID )
AND ( A.EMPLOYEE_NUMBER = C.EMPLOYEE_NUMBER AND A.SITE_ID = C.SITE_ID ) )
AND ( B.WO_STATUS <> 'CN' )
AND ( C.EMPLOYEE_NUMBER = ANY(SELECT S254_200018.EMPLOYEE_NUMBER
FROM PSTAGE.NEW_EMPLOYEE_MASTER S254_199317,
PSTAGE.NEW_ALL_WORK_ORDER_MASTER S254_199854,
PSTAGE.NEW_ALL_WORK_O
Thanks in advanceHi Sunil
In the Administrator tool, you can add hints to the driving folder used in your query. A first glance at your report seems to indicate that B might be the driver.
If you launch the Administrator tool, open the business area then right-click on the folder in question you can select Properties. The second to last property is called Optimizer hints. Try setting the same hint in here exactly the way you would do it inside SQL.
I am not 100% sure whether this would take as this isn't a folder hint per se, but it is worth a try. You might also want to look at this thread: how to design Optimizer hints to the generated SQL
Another thing to check is to look at the code that is being generated by your Discoverer worksheets. Do you by chance see a NOREWRITE hint being added? This is a common issue with newer systems. This hint tells the database that the query cannot be rewritten which in most cases will cause poor performance. If this is happening to you I advise you to disable that hint. This is done by editing the pref.txt and adding a new preference called
Out of the box, Discoverer Plus will sometimes add the NOREWRITE hint. This will cause Plus worksheets to operate much slower than Desktop worksheets. You can disable the NOREWRITE hint by adding a new preference called UseNoRewriteHint to pref.txt in the Database section. After you have done this you will have to run the apply preferences script.
[Database]
UseNoRewriteHint = 0
Be sure to close all of your IE windows so that a new JVM is loaded.
For example, you might turn on UseNoRewriteHint (i.e. set it to 1) if you want users to always query against the latest data (e.g. created today), even though this might be slower than querying the summary data (e.g. created yesterday). The NOREWRITE hint instructs the optimizer to disable query rewrite for the query block, which overrides the setting of the parameter QUERY_REWRITE_ENABLED.
Default Value: 0
Valid Values
0 = Do not add the NOREWRITE hint. This is the one I recommend.
1 = Do add the NOREWRITE hint.
Another possible area is with query prediction. This is taken from an Oracle Note: Under some circumstance when you run a query against an Oracle 10g database, the queryprediction might take up the majority of time and CPU may hit 100%.
The cause for this is an an Oracle10g (10.1) database issue but seeing as you are on 10.2 this might not be an issue any more. I throw it out there just in case you still hvae issues and want to raise this with Oracle. The last I heard is that the root cause was still under investigation in an unpublished Bug:4024370. There was a workaround to the issue:
1. Disable Query Prediction (strongly recommended anyway):
For Plus/Viewer:
Edit pref.txt on the middle-tier server and set QPPEnable=0
Run the applypreferences script (.sh or .bat)
For Desktop:
Edit the registry and set QPPEnable=0
HKEY_CURRENT_USERS\Software\ORACLE\Discoverer <version>\Database
2. If you still wish to use Query Prediction while the database issue is being investigate, then you can configure the Query Predictor to use the Explain Plan method rather than the Dynamic Views method.
For Plus/Viewer:
Edit pref.txt on the middle-tier server and set QPPObtainCostMethod=0
Run the applypreferences script (.sh or .bat)
For Desktop:
Edit the registry and set QPPObtainCostMethod=0
HKEY_CURRENT_USERS\Software\ORACLE\Discoverer <version>\Database
Hope this helps
Best wishes
Michael -
Correct steps to reload ASM disks into a running ASM instance on Linux RHEL
Hi guys,
i hope this is the correct forum, awfully i did not found any document specifically talking abou this.
first of all let me explain quickly my goal: in my server (it contains the same data of 3 production RACs for reporting purposes) i would like to shutdown a single instance (i have 3) and realod his disks to refresh the data or because for some reason its mount into ASM is failed.
this is a mix of Oracle ASM and Linux stuff...
on this server there is a shell script that perform the following steps:
1) shutdown 3 instances of 11g (11.2.0.2.0 with patch for asm already installed for bug... dont remember)
2) shutdown ASM instance
3) stop ASMLIB
4) stop multipathd
5) remove all disks devices from linux
6) take a snapshot on the 3 production RACs
7) remap the disks to this server (SAN stuff)
8) rescan the disks
9) start ASMLIB
10) start ASM instance
11) mount the DiskGroups
12) start 3 oracle instances
this works fine... my problem is when i try to refresh the disks of just 1 of the 3 instances, i perform the following steps:
1) stop instance ABC
2) dismount ABC diskgroups related to ABC instance
3) wait 5 seconds (dont ask... if idid it without ASM still have the disks locked)
4) delete the ASMLIB disks (oracleasm deletedisk XYZ) relate to such diskgroups
5) remove mpaths related to the disks that need to be refreshed or correctly mounted oneagain
6) remove devices
7) unmap disks on SAN
8) take snapshot (clone disks)
9) map disks from SAN
10) delete bindings file
11) rescan devices
12) execute multipath command (to rebuild bindings file)
13) execute oracleasm scandisks
14) mount DiskGroups
15) start instance ABC
actually i dont understand why the OS (or specifically ASMLIB) do not recognize me anymore one of the ASMLIB disk
do you have any idea ? or im completly crazy doing that ?
best regards,
LucaHi,
well this step
4) delete the ASMLIB disks (oracleasm deletedisk XYZ) relate to such diskgroups
is not good. Because it will clear the ASM Header and as a result ASM will never again be able to detect the disks.
So it is clear that "scnadisks" later will not see the disks, because you wiped them.
Worse: You did the snapshot after deleting them... this gets tricky to get them "repaired" again.
However there is the possibility to relabel a dropped ASM disks. You need to open an SR for this, since the procedure to restore the lost ASM header is not that simple..
Regards
Sebastian -
We have a 3 node RAC system with AIX machines.
We have been seeing an issue with Cluster Waits.
Example: run a query it can take 10 sec. sometimes and then 200 secs another time.
(we get the same explain plan and hash plan) . The 200 sec query has large Cluster waits. 38 to 45%
In gerneral what could be causing those cluster waits?Hi,
bgeiss wrote:
We have a 3 node RAC system with AIX machines.
We have been seeing an issue with Cluster Waits.
Example: run a query it can take 10 sec. sometimes and then 200 secs another time.Generating Automatic Workload Repository Reports> (we get the same explain plan and hash plan) . The 200 sec query has large Cluster waits. 38 to 45%
>
In gerneral what could be causing those cluster waits?
How is the health of your cluster?
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/autostat.htm#PFGRF02601
Generating an Oracle RAC AWR Report
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/autostat.htm#CHDCFBJC
Post here Report of AWR when you run the query.
Please format your report.
When you post code/report/query, or any formatted text, on this site, type these 6 characters:
(small letters only, inside curly brackets) before and after sections of formatted text, to preserve spacing.
Regards,
Levi Pereira
Edited by: Levi Pereira on Aug 17, 2011 2:11 PM
Edited by: Levi Pereira on Aug 17, 2011 2:12 PM -
How can I have a collective AWR report for RAC database in 10gR2 and 11gR1?
Plz correct me here
awrrpt.sql takes the snapshot at the instance level and incase we have 5 instances we have to take 5 awr reports for a particular period.correct???
If above is true ,any wayout to collect a single collective AWR report for RAC database which includes information on all the instances in Oracle 10g R2 or 11gR1 ?
Thanks in advance
GaganI have never come across a way for this. though I can n't say it is not there.
But I guess it may not be feasible too becuase as we know the current AWR report contains data which is specific for one instance.
Various hit ratios, top events, instance effeciency reports.... what not ..
It would be really nice to see something is a new format where it lists values from each instance in a single report.. I guess such a thing Does not exiist as of now. -
Reporting Services connections are getting dropped by Oracle RAC
My current customer is using Oracle RAC (11g) for their data store. They currently are using SQL Server Reporting Services to connect to it. We are experiencing an issue where the connection appears to be redirected at the server which causes the connection to be lost with the client.
I am curious if this is "by design" or if we need to review some configuration settings to better handle this.
We have 3 VIPs fronting the RAC and they are all specified in the TNSNAMES.ORA file.
Any feedback or input on this issue would be greatly appreciated.Hi,
I suggest you look at:
http://www.oracle.com/technetwork/database/clustering/overview/awm11gr2-130711.pdf
and the similar paper from 11.1:
http://www.oracle.com/technetwork/database/clustering/overview/awmrac11g-133673.pdf
This explains the basic concept, of how clients should connect to the database, and probably clarifies your issue.
In generall Oracle will not redirect during runtime, only during connection time.
This however should not be of an issue, if you connect to a service. (You shouldn't connect to a SID since 8.1.7 anymore).
Regards
Sebastian -
How to have RAC accept Forms and Reports connection to non specific node?
Hi all,
I have posted this in the Forms forum w/ no result, hoping someone here can help;
Oracle Forms and Reports services, not the entire app server. Version 10.1.2.0.2, one server
Oracle database, RAC Version 11.1.0.6.0, 3 nodes
Instance=RMSTEST
Nodes = RMSTEST1, RMSTEST2, RMSTEST3
I can TNSPING RMSTEST w/o issue
When I have userid in formsweb.cfg = user/pw@RMSTEST we are being prompted when logging into forms and reports to supply the password for the RMSTEST instance, enter the password and we are in.
So we changed this in formsweb.cfg = user/pw@RMSTEST? (?= any of the nodes 1-3) and the password prompt is no longer being requested.
What do I need to do to have Forms and Reports connect to the RMSTEST cluster directly for it to determine which node to connect to instead of having an unbalanced node(s)?
Thanks,
SteveThis is what I have;
RMSTEST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.111)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.112)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.113)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RMSTEST)
LISTENERS_RMSTEST =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.111)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.112)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.113)(PORT = 1521))
RMSTEST3 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.113)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RMSTEST)
(INSTANCE_NAME = RMSTEST3)
RMSTEST2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.112)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RMSTEST)
(INSTANCE_NAME = RMSTEST2)
RMSTEST1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.3.12.111)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RMSTEST)
(INSTANCE_NAME = RMSTEST1)
) -
hi masters,
we have 2 node RAC on RHEL 4.7 (both) with same parameters set.
i would like to know, if for performance tuning we need report of both RAc node and database, or statspack report of both RAC node will do???
i have collected report for both nodes but not database, as i think instances on nodes represent the load on database....
please correct if i ma wrong....
any suggestion is appreciable//
thanks and regards
VDdb_file_multiblock_read_count its a dynamic parameter,
db_file_multiblock_read_count is one of the parameters used to minimize I/O during full table scans. It specifies the maximum number of blocks read in one I/O operation during a sequential scan. The total number of I/Os needed to perform a full table scan depends on such factors as the size of the table, the multiblock read count, and whether parallel execution is being utilized for the operation.
The maximum value is always less than the operating system's maximum I/O size expressed (NEED TO FIND OUT WHAT THIS IS AT THE O/S LEVEL) as Oracle blocks ((max I/O size)/db_block_size). If set to a value greater than the maximum, then the maximum is used. See db_block_size before setting.
Note the relationship between db_block_size and db_file_multiblock_read_count. At the physical level in UNIX, Oracle always reads in a minimum of 64K blocks. Therefore, the values of db_file_multiblock_read_count and db_block_size should be set such that their product is 64K. For example, the following table shows the recommended settings based upon the db_block_size:
db_block_size db_file_multiblock_read_count value
4K 16
8K 8
16K 4
32K 2
In that case, you make sure the reporters have a tnsnames.ora that says SERVER=DEDICATED and the OLTP-type people use one that has SERVER=SHARED in it; configure the DISPATCHERS and SHARED_SERVER parameters for the instance and then those that can benefit from shared servers can do so and those that wouldn't won't be stealing shared processes from those that can!
sql>select server from gv$session;
Cheers,
Raaam...!! -
Want to upgrade RAC 10.2.0.2 database (2 instances) to 10.2.0.5. DB size is 4 TB. Contains mostly .pdf files, reports. I do not have test/upgrade environment. How much time I can expect it will take?
How much the upgrade process depends of database size, in this case?
I have fast boxes IBM AIX 5.3 , 64 b.Appreciate your comments ...
Yes, sound stupid, regarding test environment, but in reality, is not that much:
-I do have "preprod" environment, (2 instances RAC) same releases of OS, OCW,RAC ... but DB size is 40 GB!!! It has all the objects as production, but (again but) it does not have physical standby, as production has. This is not that unusual, knowing that production DB grows very fast, and very large, and business do not want to keep preprod, dev, test databases same HUGE size as production is. Savings ...
-My DB upgrade depends if application running on top of it is certified for higher RDBMS release ... looks like they have some problems.
-Very encouraging sounds comment that DB upgrade does not depend that much of the DB size ...
- i do not recall from where this info came, but I have heard that R 11.* treats PDF files in different way that R10 did it ... and because of that, process of upgrading big databases which have many items of that type (pdf) can take very long. Any idea about this?
-Brian, thx ... I'm trying hard to provide DB simmilar size in UPG environment and face all possible pitfalls before I go in production...thx for youe advice. I'm relly interested in how upgrade to 11.* from 10.* traets my pdf-s ... All my TBs comming from pdfs. Everi advice will be wellcome ... -
Concurrent Reports failing after migrating to UNIX and RAC
Hi,
One of our customer was running Oracle Apps 11i (11.5.10.2) with Apps Tier on Windows 2003 and Db Tier on Sun Spark Solaris. Recently they migrated and upgraded the Apps Tier to Sun Spark Solaris and the db tier to Oracle 10g R2 RAC.
Since then some of the concurrent reports (custom) in the Arabic interface are not working properly. We found out that when the report is run and when the session NLS_LANG is explicitly set to AMERICAN in the Before Report Trigger the report runs fine. But if the NLS_LANG is "ARABIC" the reports returns error like "Program was terminated by signal 11" in Arabic.
As a workaround we have put NLS_LANG=american in before report trigger to alter the session as a workaround.
Any hint to resolve this issue?
Rgds
ThiruHi,
Plz find the below log file.
+-----------------------------
| Starting concurrent program execution...
+-----------------------------
Arguments
P_ACCOUNT_ID='550454'
P_INSTANCE_ID='1503139'
P_ORG_ID='101'
P_USER_NAME='MOSTAFA'
APPLLCSP Environment Variable set to :
XML_REPORTS_XENVIRONMENT is :
/u01/mmapps/mmappsora/8.0.6/guicommon6/tk60/admin/Tk2Motif_UTF8.rgb
XENVIRONMENT is set to /u01/mmapps/mmappsora/8.0.6/guicommon6/tk60/admin/Tk2Motif_UTF8.rgb
Current NLS_LANG and NLS_NUMERIC_CHARACTERS Environment Variables are :
AMERICAN_AMERICA.UTF8
stat_low = 8B
stat_high = 0
emsg:was terminated by signal 11
Start of log messages from FND_FILE
End of log messages from FND_FILE
Program was terminated by signal 11
Concurrent Manager encountered an error while running Oracle*Report for your concurrent request 3626976.
Review your concurrent request log and/or report output file for more detailed information.
Executing request completion options...
------------- 1) PUBLISH -------------
Beginning post-processing of request 3626976 on node ALHAMRA at 20-JUL-2010 08:56:04.
Post-processing of request 3626976 failed at 20-JUL-2010 08:56:04 with the error message:
One or more post-processing actions failed. Consult the OPP service log for details.
Finished executing request completion options.
Concurrent request completed
Current system time is 20-JUL-2010 08:56:04
--------------------------------------------------------------------------- -
Oracle 9.2 RAC + 9iAS Rel 1 (Forms 6i & Reports 6i) Compatibility
Hi,
How do i know the Oracle 9i RAC Database With Oracle 9i Release 1 Application Server ( using Forms 6i/ Reports 6i ) Compatibility
ABkHi,
Try using Ceritifcation Matrix http://www.oracle.com/technology/support/metalink/index.html
Cheers,
Rodrigo Mufalani
http://mufalani.blogspot.com -
STATSPACK Report in Oracle RAC
Dear friends,
When I tried to make a STASPACK report on RAC nodes, I got the following error:
The starting snap_id doesnot belong to this instance.
When I tried using the other node, I got hte error:
The ending snap_id doesnot belong to this instance.
Is there any thing to do special for RAC expect for the constraint of STATSPACK be of level 7 or higher.
Regards,
Aravind K RSnapshots are different for different nodes. Please put the correct snap ID for gathering the statpack report.
Regards
Asif Kabir -
I have an issue with generating ASH Report on Oracle 11gR2 (11.2.0.1) RAC (2-nodes) on HP-UX. Its working on one node but not the other.
When I ran ashrpt.sql, its accepting all the inputs and hangs, its not ending. When I trace the session I get the following,
Ioctl ASYNC_CONFIG error, errno = 1
Ioctl ASYNC_CONFIG error, errno = 1
WAIT #5: nam='control file sequential read' ela= 373 file#=0 block#=1 blocks=1 obj#=581 tim=70344326749
WAIT #5: nam='control file sequential read' ela= 425 file#=0 block#=16 blocks=1 obj#=581 tim=70344327317
WAIT #5: nam='control file sequential read' ela= 433 file#=0 block#=18 blocks=1 obj#=581 tim=70344327784
WAIT #5: nam='control file sequential read' ela= 278 file#=0 block#=281 blocks=1 obj#=581 tim=70344328098
WAIT #5: nam='control file sequential read' ela= 331 file#=0 block#=1 blocks=1 obj#=581 tim=70344329323
WAIT #5: nam='control file sequential read' ela= 308 file#=0 block#=16 blocks=1 obj#=581 tim=70344329727
WAIT #5: nam='control file sequential read' ela= 364 file#=0 block#=18 blocks=1 obj#=581 tim=70344330124
WAIT #5: nam='control file sequential read' ela= 383 file#=0 block#=180 blocks=1 obj#=581 tim=70344330541
WAIT #5: nam='asynch descriptor resize' ela= 2 outstanding #aio=0 current aio limit=0 new aio limit=2142 obj#=581 tim=70344330586
Ioctl ASYNC_CONFIG error, errno = 1
Ioctl ASYNC_CONFIG error, errno = 1
WAIT #5: nam='control file sequential read' ela= 310 file#=0 block#=1 blocks=1 obj#=581 tim=70344363432
WAIT #5: nam='control file sequential read' ela= 414 file#=0 block#=16 blocks=1 obj#=581 tim=70344363961
WAIT #5: nam='control file sequential read' ela= 202 file#=0 block#=18 blocks=1 obj#=581 tim=70344364196
WAIT #5: nam='control file sequential read' ela= 360 file#=0 block#=281 blocks=1 obj#=581 tim=70344364592
WAIT #5: nam='control file sequential read' ela= 181 file#=0 block#=1 blocks=1 obj#=581 tim=70344365663
WAIT #5: nam='control file sequential read' ela= 354 file#=0 block#=16 blocks=1 obj#=581 tim=70344366182
WAIT #5: nam='control file sequential read' ela= 325 file#=0 block#=18 blocks=1 obj#=581 tim=70344366541
WAIT #5: nam='control file sequential read' ela= 364 file#=0 block#=180 blocks=1 obj#=581 tim=70344366939
WAIT #5: nam='asynch descriptor resize' ela= 1 outstanding #aio=0 current aio limit=0 new aio limit=2142 obj#=581 tim=70344366984
Ioctl ASYNC_CONFIG error, errno = 1
Ioctl ASYNC_CONFIG error, errno = 1
...............................................................................does anybody has similar problem?Hi,
Yes, its possible.
1. First create the tabular form on the table you want to update
2. Go and edit the SQL Query , add all the tables and columns that you want
3. Now edit the report attributes and remove the references to Table/Column in the source of all the non-base table columns.
It has to be a 2 step process, the wizard does not allow you to enter a query of the type you have.
Regards, -
Active session Spike on Oracle RAC 11G R2 on HP UX
Dear Experts,
We need urgent help please, as we are facing very low performance in production database.
We are having oracle 11G RAC on HP Unix environment. Following is the ADDM report. Kindly check and please help me to figure it out the issue and resolve it at earliest.
---------Instance 1---------------
ADDM Report for Task 'TASK_36650'
Analysis Period
AWR snapshot range from 11634 to 11636.
Time period starts at 21-JUL-13 07.00.03 PM
Time period ends at 21-JUL-13 09.00.49 PM
Analysis Target
Database 'MCMSDRAC' with DB ID 2894940361.
Database version 11.2.0.1.0.
ADDM performed an analysis of instance mcmsdrac1, numbered 1 and hosted at
mcmsdbl1.
Activity During the Analysis Period
Total database time was 38466 seconds.
The average number of active sessions was 5.31.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 CPU Usage 1.44 | 27.08 1
2 Interconnect Latency .07 | 1.33 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
Finding 1: CPU Usage
Impact is 1.44 active sessions, 27.08% of total activity.
Host CPU was a bottleneck and the instance was consuming 99% of the host CPU.
All wait times will be inflated by wait for CPU.
Host CPU consumption was 99%.
Recommendation 1: Host Configuration
Estimated benefit is 1.44 active sessions, 27.08% of total activity.
Action
Consider adding more CPUs to the host or adding instances serving the
database on other hosts.
Action
Session CPU consumption was throttled by the Oracle Resource Manager.
Consider revising the resource plan that was active during the analysis
period.
Finding 2: Interconnect Latency
Impact is .07 active sessions, 1.33% of total activity.
Higher than expected latency of the cluster interconnect was responsible for
significant database time on this instance.
The instance was consuming 110 kilo bits per second of interconnect bandwidth.
20% of this interconnect bandwidth was used for global cache messaging, 21%
for parallel query messaging and 7% for database lock management.
The average latency for 8K interconnect messages was 42153 microseconds.
The instance is using the private interconnect device "lan2" with IP address
172.16.200.71 and source "Oracle Cluster Repository".
The device "lan2" was used for 100% of interconnect traffic and experienced 0
send or receive errors during the analysis period.
Recommendation 1: Host Configuration
Estimated benefit is .07 active sessions, 1.33% of total activity.
Action
Investigate cause of high network interconnect latency between database
instances. Oracle's recommended solution is to use a high speed
dedicated network.
Action
Check the configuration of the cluster interconnect. Check OS setup like
adapter setting, firmware and driver release. Check that the OS's socket
receive buffers are large enough to store an entire multiblock read. The
value of parameter "db_file_multiblock_read_count" may be decreased as a
workaround.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional Information
Miscellaneous Information
Wait class "Application" was not consuming significant database time.
Wait class "Cluster" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Concurrency" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Wait class "User I/O" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
Hard parsing of SQL statements was not consuming significant database time.
The database's maintenance windows were active during 100% of the analysis
period.
----------------Instance 2 --------------------
ADDM Report for Task 'TASK_36652'
Analysis Period
AWR snapshot range from 11634 to 11636.
Time period starts at 21-JUL-13 07.00.03 PM
Time period ends at 21-JUL-13 09.00.49 PM
Analysis Target
Database 'MCMSDRAC' with DB ID 2894940361.
Database version 11.2.0.1.0.
ADDM performed an analysis of instance mcmsdrac2, numbered 2 and hosted at
mcmsdbl2.
Activity During the Analysis Period
Total database time was 2898 seconds.
The average number of active sessions was .4.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 Top SQL Statements .11 | 27.65 5
2 Interconnect Latency .1 | 24.15 1
3 Shared Pool Latches .09 | 22.42 1
4 PL/SQL Execution .06 | 14.39 2
5 Unusual "Other" Wait Event .03 | 8.73 4
6 Unusual "Other" Wait Event .03 | 6.42 3
7 Unusual "Other" Wait Event .03 | 6.29 6
8 Hard Parse .02 | 5.5 0
9 Soft Parse .02 | 3.86 2
10 Unusual "Other" Wait Event .01 | 3.75 4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
Finding 1: Top SQL Statements
Impact is .11 active sessions, 27.65% of total activity.
SQL statements consuming significant database time were found. These
statements offer a good opportunity for performance improvement.
Recommendation 1: SQL Tuning
Estimated benefit is .05 active sessions, 12.88% of total activity.
Action
Investigate the PL/SQL statement with SQL_ID "d1s02myktu19h" for
possible performance improvements. You can supplement the information
given here with an ASH report for this SQL_ID.
Related Object
SQL statement with SQL_ID d1s02myktu19h.
begin dbms_utility.validate(:1,:2,:3,:4); end;
Rationale
The SQL Tuning Advisor cannot operate on PL/SQL statements.
Rationale
Database time for this SQL was divided as follows: 13% for SQL
execution, 2% for parsing, 85% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "d1s02myktu19h" was executed 48 times and had
an average elapsed time of 7 seconds.
Rationale
Waiting for event "library cache pin" in wait class "Concurrency"
accounted for 70% of the database time spent in processing the SQL
statement with SQL_ID "d1s02myktu19h".
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"63wt8yna5umd6" are responsible for 100% of the database time spent on
the PL/SQL statement with SQL_ID "d1s02myktu19h".
Related Object
SQL statement with SQL_ID 63wt8yna5umd6.
begin DBMS_UTILITY.COMPILE_SCHEMA( 'TPAUSER', FALSE ); end;
Recommendation 2: SQL Tuning
Estimated benefit is .02 active sessions, 4.55% of total activity.
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"fk3bh3t41101x".
Related Object
SQL statement with SQL_ID fk3bh3t41101x.
SELECT MEM.MEMBER_CODE ,MEM.E_NAME,Pol.Policy_no
,pol.date_from,pol.date_to,POL.E_NAME,MEM.SEX,(SYSDATE-MEM.BIRTH_DATE
) AGE,POL.SCHEME_NO FROM TPAUSER.MEMBERS MEM,TPAUSER.POLICY POL WHERE
POL.QUOTATION_NO=MEM.QUOTATION_NO AND POL.BRANCH_CODE=MEM.BRANCH_CODE
and endt_no=(select max(endt_no) from tpauser.members mm where
mm.member_code=mem.member_code AND mm.QUOTATION_NO=MEM.QUOTATION_NO)
and member_code like '%' || nvl(:1,null) ||'%' ORDER BY MEMBER_CODE
Rationale
The SQL spent 92% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "fk3bh3t41101x" was executed 14 times and had
an average elapsed time of 4.9 seconds.
Rationale
At least one execution of the statement ran in parallel.
Recommendation 3: SQL Tuning
Estimated benefit is .02 active sessions, 3.79% of total activity.
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"7mhjbjg9ntqf5".
Related Object
SQL statement with SQL_ID 7mhjbjg9ntqf5.
SELECT SUM(CNT) FROM (SELECT COUNT(PROC_CODE) CNT FROM
TPAUSER.TORBINY_PROCEDURE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
:B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND PR_EFFECTIVE_DATE<=
:B2 AND PROC_CODE = :B1 UNION SELECT COUNT(MED_CODE) CNT FROM
TPAUSER.TORBINY_MEDICINE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
:B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND M_EFFECTIVE_DATE<= :B2
AND MED_CODE = :B1 UNION SELECT COUNT(LAB_CODE) CNT FROM
TPAUSER.TORBINY_LAB WHERE BRANCH_CODE = :B6 AND QUOTATION_NO = :B5
AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND L_EFFECTIVE_DATE<= :B2 AND
LAB_CODE = :B1 )
Rationale
The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 0% for SQL execution,
0% for parsing, 100% for PL/SQL execution and 0% for Java execution.
Rationale
SQL statement with SQL_ID "7mhjbjg9ntqf5" was executed 31 times and had
an average elapsed time of 3.4 seconds.
Rationale
Top level calls to execute the SELECT statement with SQL_ID
"a11nzdnd91gsg" are responsible for 100% of the database time spent on
the SELECT statement with SQL_ID "7mhjbjg9ntqf5".
Related Object
SQL statement with SQL_ID a11nzdnd91gsg.
SELECT POLICY_NO,SCHEME_NO FROM TPAUSER.POLICY WHERE QUOTATION_NO
=:B1
Recommendation 4: SQL Tuning
Estimated benefit is .01 active sessions, 3.03% of total activity.
Action
Investigate the SELECT statement with SQL_ID "4uqs4jt7aca5s" for
possible performance improvements. You can supplement the information
given here with an ASH report for this SQL_ID.
Related Object
SQL statement with SQL_ID 4uqs4jt7aca5s.
SELECT DISTINCT USER_ID FROM GV$SESSION, USERS WHERE UPPER (USERNAME)
= UPPER (USER_ID) AND USERS.APPROVAL_CLAIM='VC' AND USER_ID=:B1
Rationale
The SQL spent only 0% of its database time on CPU, I/O and Cluster
waits. Therefore, the SQL Tuning Advisor is not applicable in this case.
Look at performance data for the SQL to find potential improvements.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "4uqs4jt7aca5s" was executed 261 times and had
an average elapsed time of 0.35 seconds.
Rationale
At least one execution of the statement ran in parallel.
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"91vt043t78460" are responsible for 100% of the database time spent on
the SELECT statement with SQL_ID "4uqs4jt7aca5s".
Related Object
SQL statement with SQL_ID 91vt043t78460.
begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
4); end;
Recommendation 5: SQL Tuning
Estimated benefit is .01 active sessions, 3.03% of total activity.
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"7kt28fkc0yn5f".
Related Object
SQL statement with SQL_ID 7kt28fkc0yn5f.
SELECT COUNT(*) FROM TPAUSER.APPROVAL_MASTER WHERE APPROVAL_STATUS IS
NULL AND (UPPER(CODED) = UPPER(:B1 ) OR UPPER(PROCESSED_BY) =
UPPER(:B1 ))
Rationale
The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "7kt28fkc0yn5f" was executed 1034 times and
had an average elapsed time of 0.063 seconds.
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"91vt043t78460" are responsible for 100% of the database time spent on
the SELECT statement with SQL_ID "7kt28fkc0yn5f".
Related Object
SQL statement with SQL_ID 91vt043t78460.
begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
4); end;
Finding 2: Interconnect Latency
Impact is .1 active sessions, 24.15% of total activity.
Higher than expected latency of the cluster interconnect was responsible for
significant database time on this instance.
The instance was consuming 128 kilo bits per second of interconnect bandwidth.
17% of this interconnect bandwidth was used for global cache messaging, 6% for
parallel query messaging and 8% for database lock management.
The average latency for 8K interconnect messages was 41863 microseconds.
The instance is using the private interconnect device "lan2" with IP address
172.16.200.72 and source "Oracle Cluster Repository".
The device "lan2" was used for 100% of interconnect traffic and experienced 0
send or receive errors during the analysis period.
Recommendation 1: Host Configuration
Estimated benefit is .1 active sessions, 24.15% of total activity.
Action
Investigate cause of high network interconnect latency between database
instances. Oracle's recommended solution is to use a high speed
dedicated network.
Action
Check the configuration of the cluster interconnect. Check OS setup like
adapter setting, firmware and driver release. Check that the OS's socket
receive buffers are large enough to store an entire multiblock read. The
value of parameter "db_file_multiblock_read_count" may be decreased as a
workaround.
Symptoms That Led to the Finding:
Inter-instance messaging was consuming significant database time on this
instance.
Impact is .06 active sessions, 14.23% of total activity.
Wait class "Cluster" was consuming significant database time.
Impact is .06 active sessions, 14.23% of total activity.
Finding 3: Shared Pool Latches
Impact is .09 active sessions, 22.42% of total activity.
Contention for latches related to the shared pool was consuming significant
database time.
Waits for "library cache lock" amounted to 5% of database time.
Waits for "library cache pin" amounted to 17% of database time.
Recommendation 1: Application Analysis
Estimated benefit is .09 active sessions, 22.42% of total activity.
Action
Investigate the cause for latch contention using the given blocking
sessions or modules.
Rationale
The session with ID 17 and serial number 15595 in instance number 1 was
the blocking session responsible for 34% of this recommendation's
benefit.
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is .1 active sessions, 24.96% of total activity.
Finding 4: PL/SQL Execution
Impact is .06 active sessions, 14.39% of total activity.
PL/SQL execution consumed significant database time.
Recommendation 1: SQL Tuning
Estimated benefit is .05 active sessions, 12.5% of total activity.
Action
Tune the entry point PL/SQL "SYS.DBMS_UTILITY.COMPILE_SCHEMA" of type
"PACKAGE" and ID 6019. Refer to the PL/SQL documentation for addition
information.
Rationale
318 seconds spent in executing PL/SQL "SYS.DBMS_UTILITY.VALIDATE#2" of
type "PACKAGE" and ID 6019.
Recommendation 2: SQL Tuning
Estimated benefit is .01 active sessions, 1.89% of total activity.
Action
Tune the entry point PL/SQL
"SYSMAN.EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS" of type "PACKAGE" and
ID 68654. Refer to the PL/SQL documentation for addition information.
Finding 5: Unusual "Other" Wait Event
Impact is .03 active sessions, 8.73% of total activity.
Wait event "DFS lock handle" in wait class "Other" was consuming significant
database time.
Recommendation 1: Application Analysis
Estimated benefit is .03 active sessions, 8.73% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits. Refer to
Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .03 active sessions, 8.27% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits in Service
"mcmsdrac".
Recommendation 3: Application Analysis
Estimated benefit is .02 active sessions, 5.05% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits in Module "TOAD
9.7.2.5".
Recommendation 4: Application Analysis
Estimated benefit is .01 active sessions, 3.21% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits in Module
"toad.exe".
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
Finding 6: Unusual "Other" Wait Event
Impact is .03 active sessions, 6.42% of total activity.
Wait event "reliable message" in wait class "Other" was consuming significant
database time.
Recommendation 1: Application Analysis
Estimated benefit is .03 active sessions, 6.42% of total activity.
Action
Investigate the cause for high "reliable message" waits. Refer to
Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .03 active sessions, 6.42% of total activity.
Action
Investigate the cause for high "reliable message" waits in Service
"mcmsdrac".
Recommendation 3: Application Analysis
Estimated benefit is .02 active sessions, 4.13% of total activity.
Action
Investigate the cause for high "reliable message" waits in Module "TOAD
9.7.2.5".
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
Finding 7: Unusual "Other" Wait Event
Impact is .03 active sessions, 6.29% of total activity.
Wait event "enq: PS - contention" in wait class "Other" was consuming
significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .03 active sessions, 6.29% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits. Refer to
Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .02 active sessions, 6.02% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits in Service
"mcmsdrac".
Recommendation 3: Application Analysis
Estimated benefit is .02 active sessions, 4.93% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits with
P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
"3599" respectively.
Recommendation 4: Application Analysis
Estimated benefit is .01 active sessions, 2.74% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits in Module
"Inbox Reader_92.exe".
Recommendation 5: Application Analysis
Estimated benefit is .01 active sessions, 2.74% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits in Module
"TOAD 9.7.2.5".
Recommendation 6: Application Analysis
Estimated benefit is .01 active sessions, 1.37% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits with
P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
"3598" respectively.
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
Finding 8: Hard Parse
Impact is .02 active sessions, 5.5% of total activity.
Hard parsing of SQL statements was consuming significant database time.
Hard parses due to cursor environment mismatch were not consuming significant
database time.
Hard parsing SQL statements that encountered parse errors was not consuming
significant database time.
Hard parses due to literal usage and cursor invalidation were not consuming
significant database time.
The Oracle instance memory (SGA and PGA) was adequately sized.
No recommendations are available.
Symptoms That Led to the Finding:
Contention for latches related to the shared pool was consuming
significant database time.
Impact is .09 active sessions, 22.42% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is .1 active sessions, 24.96% of total activity.
Finding 9: Soft Parse
Impact is .02 active sessions, 3.86% of total activity.
Soft parsing of SQL statements was consuming significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .02 active sessions, 3.86% of total activity.
Action
Investigate application logic to keep open the frequently used cursors.
Note that cursors are closed by both cursor close calls and session
disconnects.
Recommendation 2: Database Configuration
Estimated benefit is .02 active sessions, 3.86% of total activity.
Action
Consider increasing the session cursor cache size by increasing the
value of parameter "session_cached_cursors".
Rationale
The value of parameter "session_cached_cursors" was "100" during the
analysis period.
Symptoms That Led to the Finding:
Contention for latches related to the shared pool was consuming
significant database time.
Impact is .09 active sessions, 22.42% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is .1 active sessions, 24.96% of total activity.
Finding 10: Unusual "Other" Wait Event
Impact is .01 active sessions, 3.75% of total activity.
Wait event "IPC send completion sync" in wait class "Other" was consuming
significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .01 active sessions, 3.75% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits. Refer
to Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .01 active sessions, 3.75% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits with P1
("send count") value "1".
Recommendation 3: Application Analysis
Estimated benefit is .01 active sessions, 2.59% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits in
Service "mcmsdrac".
Recommendation 4: Application Analysis
Estimated benefit is .01 active sessions, 1.73% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits in
Module "TOAD 9.7.2.5".
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional Information
Miscellaneous Information
Wait class "Application" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
CPU was not a bottleneck for the instance.
Wait class "Network" was not consuming significant database time.
Wait class "User I/O" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 100% of the analysis
period.
Please help.Hello experts...
Please do the needful... It's really very urgent.
Thanks,
Syed
Maybe you are looking for
-
Any ideas? Works fine in classic Yahoo mail. But in the "new" Yahoo mail, there is not even an option to open in new tab when I right click the message to be opened. Interestingly enough, I can right click open to new tab on any other link on the
-
Hello, I would like to schedule with an agent some reports in OBIEE 11g that must be exported in excel format to a specific local directory. There is a need for a group of OBIEE users to have a set of reports ready (exported in .xlsx) every morning.
-
AS Java 7.01 Install - Port Error
Experts, I'm in the process of installing NetweaverAS Java (only no ABAP) 7.01 instance on Lunix Redhat 5. I am getting the following error after starting sapinst: Logon Error: Connection to SAPisnt could not be established, see following message Cou
-
Microsoft apps just showed up in my software updater. Has any other E6 user installed this? Looking for comments/Reviews. Solved! Go to Solution.
-
Novice Question ... If the outside of a brochure is the return address and where you would put your address label, would you back the inside up head to head or head to foot? My problem is wanting to make sure when it is tri-folded the open ends wher