Awr Statistics

Hi all,
11.2.0.3
Aix 6.1
I run AWR stats gathering every hour on top of the hour, in our PROD database for 24 hrs a day. Is it possible to select the window (which hour time range) in a certain day was our database the busiest, meaning most resource intensive? by just using a sql query? or Do I need to run each time range 24 times and compare the 24 report results?
Thanks a lot,
zxy

Hi,
normally a database is busy when the application is busy. An application should have its own performance metrics (KPIs or key performance indicators) defined. E.g. a database for an online store application is probably the busiest when the application is processing maximum number of orders per unit time.
If you are unfamiliar with workload periodicity for a certain application, you can approach the problem from a different angle, e.g. look at physical or logical reads, or CPU usage, and pick the hour when this metric has maximum value. Within this approach you should first of all be looking at resource which is scarce for this database. I.e. if a database is CPU-bound, then you should be looking first of all at periods of maximum CPU usage.
For every metric it's possible to compose a query which would identify the hour or the snapshot when it reaches a local maximum.
Best regards,
Nikolay

Similar Messages

AWR Statistics gathering is taking hours...

Is it normal in 10g to have the following job run for hours?
EXEC SYS.DBMS_SCHEDULER.RUN_JOB('GATHER_STATS_JOB');
It takes like 4 hours sometimes to run - we run it once a day..Thank you!

AWR is the automatic workload repository - which is similar in mechanism to statspack, taking regular snapshots of the dynamic performance views.
The gather_stats_job has nothing to do with the operation of the AWR, beyond the fact that AWR data is stored in tables, so the gather_stats_job may decided to collect stats on those tables from time to time.
The default action for gather_stats_job is to collect stats for all tables with missing or stale statistics. The sample size for each table is chosen automatically (effectively by trial and error starting with a very small sample. Histograms are also collected automatically, based on a check of which columns have been used historically for "where" clauses combined with a sample to check if such columns show skewed data patterns.
If you do a lot of inserts, updates, and deletes on this particular database, you are more likely to end up with table statistics becoming stale more frequently, leading to longer lists of tables that need stats recalculated.
You may find that Oracle is generating too many histograms, and histograms can take a long time to construct. If this is the case, then you could consider changing the default setting for stats collection to skip the automatic histogram generation and add code to build histograms only on the columns that you think need them.
[addendum: you say you are running gather_stats_job daily - but it runs automatically every weekday at 10:00 pm and all weekend; did you disable the standard job, or did you mean that you were just letting the standard job).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." Stephen Hawking.

Interpret DB Time in AWR statistics.....

We are running multiple Oracle instances on the one database server, and are trying to measure the proportion of time that each instance uses, by analysing AWR reports.
We are having trouble understanding the meaning of the "DB Time" statistic, near the top of the report. A sample is shown below:
{color:#000000}Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 16777 20-Oct-08 00:00:34 687 5.8
End Snap: 16945 27-Oct-08 00:00:13 667 .5
Elapsed: 10,079.65 (mins)
DB Time: 11,164.25 (mins)
{color}
The two snapshots are one week apart, so the "Elapsed Time" make sense - there are 10080 minutes in a week
We are not sure how the "DB Time" can be 11,164 minutes?? Does this quantity relate to the number of processors/cores on the machine?
Any help would be appreciated.
Thanks
Gavin

Hi,
DBTime is the time that is based on the number of sessions which are at the moment active and are doing some thing in the system. So if there are, for example, 3 sessions active and the instance is up from 30 minutes, the db time would be reported as 90 minutes. You may want to look at this doc link which explains it with a pic,
http://download.oracle.com/docs/cd/B19306_01/server.102/b28051/tdppt_method.htm#CIHCDGCI
The idea bascially is to find the area using this in the database where the maximum time is spent as its based on both, cpu and wait time. If we can reduce the wait time, that time can be used in doing some thing productive.
Edit:
I just remebered that Doug had written a very good piece of blogpost for the same topic. That would help in better understanding of it.
http://oracledoug.com/serendipity/index.php?/archives/1429-Time-Matters-DB-Time.html
HTH
Aman....
Edited by: Aman.... on Oct 27, 2008 12:19 PM

Gather_table_stats and AWR

Hi all,
i would like to disable automatic gathering of table statistics with dbms_scheduler.disable(name => 'SYS.GATHER_STATS_JOB'), because we like to gather statistics every time immediatly after we batch load our tables in our data warehouse. Is it right that this job is also needed for AWR and that oracle will not save system statistics once per hour if i disable this job?
Database version is 10gR2.
Thanks,
Robert

user1367414 wrote:
Hi all,
i would like to disable automatic gathering of table statistics with dbms_scheduler.disable(name => 'SYS.GATHER_STATS_JOB'), because we like to gather statistics every time immediatly after we batch load our tables in our data warehouse. Is it right that this job is also needed for AWR and that oracle will not save system statistics once per hour if i disable this job?
Database version is 10gR2.Robert,
the recommended way to disable automatic statistics collection on the non-Oracle objects in 10g is:
exec DBMS_STATS.SET_PARAM('AUTOSTATS_TARGET', 'ORACLE')
This way the job still gets executed but collects only statistics on the dictionary / AWR / etc. (owned by Oracle) tables. If you disable the job completely, your dictionary statistics might get outdated, potentially leading to suboptimal dictionary performance.
By the way:
"Oracle Database 10g uses a scheduled job, GATHER_STATS_JOB, to collect AWR statistics."This is a bit misleading, the job's purpose is to collect object statistics, as already mentioned the AWR snapshots are controlled differently (and by default are taken every hour, not only during the maintenance windows).
Another way you could handle your requirement would be to lock the statistics of the affected table or schemas by using DBMS_STATS.LOCK_TABLE/SCHEMA_STATS. This way these tables/schemas will be skipped by the default gathering job, and you need then to use the "FORCE=>true" parameter when gathering statistics individually. Note that there is one peculiarity with this approach: If you create/rebuild indexes on a table having the statistics locked, the default option "COMPUTE STATISTICS" of 10g doesn't apply any more, so it doesn't update the statistics of the index automatically in the dictionary, and there is unfortunately no "force" parameter available in the CREATE/ALTER INDEX command. You would need to either temporarily unlock the statistics or gather the index statistics separately (which means additional work for the database).
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/
Edited by: Randolf Geist on Jan 18, 2009 12:17 PM
Added note about lock statistics approach

Transaction execution time and block size

Hi,
I have Oracle Database 11g R2 64 bit database on Oracle Linux 5.6. My system has ONE hard drive.
Recently I experimented with 8.5 GB database in TPC-E test. I was watching transaction time for 2K,4K,8K Oracle block size. Each time I started new test on different block size, I would created new database from scratch to avoid messing something up (each time SGA and PGA parameters ware identical).
In all experiments a gave to my own tablespace (NEWTS) different configuration because of oracle block-datafile size limits :
2K oracle block database had 3 datafiles, each 7GB.
4K oracle block database had 2 datafiles, each 10GB.
8K oracle block database had 1 datafile of 20GB.
Now best transaction (tranasaction execution) time was on 8K block, little longer tranasaction time had 4K block, but 2K oracle block had definitly worst transaction time.
I identified SQL query(when using 2K and 4K block) that was creating hot segments on E_TRANSACTION table, that is largest table in database (2.9GB), and was slowly executed (number of executions was low compared to 8K numbers).
Now here is my question. Is it possible that multiple datafiles are reasone for this low transaction times. I have AWR reports from that period, but as someone who is still learning things about DBA, I would like to asq, how could I identify this multi-datafile problem (if that is THE problem), by looking inside AWR statistics.
THX to all.

>
It's always interesting to see the results of serious attempts to quantify the effects of variation in block sizes, but it's hard to do proper tests and eliminate side effects.
I have Oracle Database 11g R2 64 bit database on Oracle Linux 5.6. My system has ONE hard drive.A single drive does make it a little too easy for apparently random variation in performance.
Recently I experimented with 8.5 GB database in TPC-E test. I was watching transaction time for 2K,4K,8K Oracle block size. Each time I started new test on different block size, I would created new database from scratch to avoid messing something up Did you do anything to ensure that the physical location of the data files was a very close match across databases - inner tracks vs. outer tracks could make a difference.
(each time SGA and PGA parameters ware identical).Can you give us the list of parameters you set ? As you change the block size, identical parameters DON'T necessarily result in the same configuration. Typically a large change in response time turns out to be due to changes in execution plan, and this can often be associated with different configuration. Did you also check that the system statistics were appropriately matched (which doesn't mean identical cross all databases).
In all experiments a gave to my own tablespace (NEWTS) different configuration because of oracle block-datafile size limits :
2K oracle block database had 3 datafiles, each 7GB.
4K oracle block database had 2 datafiles, each 10GB.
8K oracle block database had 1 datafile of 20GB.If you use bigfile tablespaces I think you can get 8TB in a single file for a tablespace.
Now best transaction (tranasaction execution) time was on 8K block, little longer tranasaction time had 4K block, but 2K oracle block had definitly worst transaction time.We need some values here, not just "best/worst" - it doesn't even begin to get interesting unless you have at least a 5% variation - and then it has to be consistent and reproducible.
I identified SQL query(when using 2K and 4K block) that was creating hot segments on E_TRANSACTION table, that is largest table in database (2.9GB), and was slowly executed (number of executions was low compared to 8K numbers).Query, or DML ? What do you mean by "hot" ? Is E_TRANSACTION a partitioned table - if not then it consists of one segment, so did you mean to say "blocks" rather than segments ? If blocks, which class of blocks ?
Now here is my question. Is it possible that multiple datafiles are reasone for this low transaction times. I have AWR reports from that period, but as someone who is still learning things about DBA, I would like to asq, how could I identify this multi-datafile problem (if that is THE problem), by looking inside AWR statistics.On a single disc drive I could probably set something up that ensured you got different performance because of different numbers of files per tablespace. As SB has pointed out there are some aspects of extent allocation that could have an effect - roughly speaking, extents for a single object go round-robin on the files so if you have small extent sizes for a large object then a tablescan is more likely to result in larger (slower) head movements if the tablespace is made from multiple files.
If the results are reproducible, then enable extended tracking (dbms_monitor, with waits) and show us what the tkprof summaries for the slow transactions look like. That may give us some clues.
Regards
Jonathan Lewis

Very slow day

Hi all,
11.2.0.1
Aix 6.1
Yesterday Jan 15, 2014, we experienced very slow performance in our App. The webpage is hanging or disconnecting often and many transaction were dropped or not processed.
My boss told me to investigate the issue and find the cause. Again this topic is the most unmastered part of my carrier as dba.
There is no solid way I have found for a template for a clear solution. I have gathered 1 week worth of AWR stats reports just to campare baselines because that is what is always heard here.
Given a week awr statistics can you help me how to identify the cause of performance problem yesterday?
https://app.box.com/s/dna3i7auq1mel6gl1c4v
https://app.box.com/s/mumevcqqgu5c0b1mal4o
https://app.box.com/s/f24z3caboyknfyxhhcaj
https://app.box.com/s/xas3ra0qz081jp1ynso5
https://app.box.com/s/1ftb87kd2relqzzl9mnm
https://app.box.com/s/qqthfm6vpwdc3o5t1dfr
Kindly open report in notepad++ as this is in 500 linesize.
Thanks a lot,
pK

I already mentioned the db & OS version above
The application is just 3rd party developed in java.
Yes - but that is just one SMALL part of the info mentioned in that link about how to ask a question. Go back and read it again - especially the part about the info needed for a tuning request.
You also aren't responding to the questions or suggestions others have already posted. Alvaro posted this:
These logs you have provided are completely unformated and next to impossible to read. Why not just post the AWR HTML parts that are interesting? Such as: Time model, Top 5 Waits, Load profile.
Also, a one week AWR report is not very useful in your case. Focus on an AWR derived from the snapshots that make up the period the problem occurred.
The only comment you made was a sarcastic one about the formatting.
Why didn't you comment about the AWR suggestion that was made? If you want responders to help you have to be responsive to their comments. They are trying to help you.
You also never responded to the reply by Gayu0726:
To solve:
Identify the tables which read most.
Create index for the tables.
If index is already there, try to analyze it and gather statistics.
Check whether the index are in usable form.
You marked the reply 'helpful' but never said a word about whether you did those things and what the result was.
Himmy got the same treatment:
If this is an OLTP database can you try gathering stats on all tables of schemas used by the application.
Did you do that? Are the stats current? Why didn't you respond to let us know WHAT you are doing to solve the problem?
In short you seem to be relying on us to solve your problem and haven't provided ANY feedback about what, if anything, you are doing to solve it:
Yesterday Jan 15, 2014, we experienced very slow performance in our App. The webpage is hanging or disconnecting often and many transaction were dropped or not processed.
That's a good start to defining the problem.
My boss told me to investigate the issue and find the cause. Again this topic is the most unmastered part of my carrier as dba.
And it will likely continue to be 'unmastered' until you actually press the keyboard with your fingers and start doing things yourself.
There is no solid way I have found for a template for a clear solution.
If you 'experienced very slow performance' then, by definition, you MUST know that previously the performance was 'faster'.
That means that SOMETHING changed. The 'template' you seek is to determine WHAT CHANGED.
I have gathered 1 week worth of AWR stats reports just to campare baselines because that is what is always heard here.
Ok - so did you actually COMPARE the base lines to see what was different? What did you find was different? Why haven't you posted here and told us what you found that was different?
You have to use a process just like in those picture games for kids where they show two pictures and ask them: find the objects in the two pictures that are different.
Picture #1 - fast performance
Picutre #2 - slow performance
1. What changed between picture #1 and picture #2?
2. Did the amount of data in the tables (which you haven't told us anything about) change?
3. Did the statistics change? Or perhaps no one updated them lately?
4. Did the execution plans of any of the key queries change?
5. and so on, and so on
If you don't have picture #1 you will have a hard time comparing picture #2 to anything.
It is YOUR responsibility to post the information needed to help you. Post the info re stats, tables, execution plans, etc.

Redo IOPS Estimation Method

Hi,
We are trying to estimate the IOPS for a group of applications for a client using AWRs.
We estimated the database IOPS using the following AWR statistics:
- physical read total IO requests & physical write total IO requests
This appears correct, however it does not include redo IOPS. By using the following related stats and formula:
- redo blocks written / redo writes,
Then, the number of blocks per write can be obtained
Is it correct to assume that the result (blocks per write) does equate to an disk IO operation ?
Thanks
Oli

olidev wrote:
This estimation will provide performance requirements for the new target storage system. At this stage, irrespective of the target underlying SAN RAID design.Interesting. In my experience the major factor in deciding on a new storage system has always been a budgetary one - not a performance one. As is in "+we have approximately $x to spend, we need zTB, what is available and best suited?+"
Personally, I do not think in-depth I/O analysis is a meaningful exercise to determine performance requirements for a new storage system. Several reasons. Complexity. Effort. And the very real likelihood that due to the complexity of the I/O layers, something or some component will not be calculated or understood correctly, or will be very different on the new storage system, making this performance calculation exercise mostly useless (and possible dangerously so).
A simple thing as a large memory cache can make a major difference between one storage system and another. Something like RAID5 vs RAID10 can make a major performance difference on the same storage system where there are no ASIC-type capabilities to offload parity calculations.
So it is critical that is such a performance analysis and calculation exercise be done, real technical experts (at I/O layer level) be consulted. Mistakes cannot be afforded if you want to do detailed analysis and use those results for accurate performance calculation for purchasing new kit.
I would rather get a general view from the o/s itself of what the bytes/sec read and write rates are to the current storage devices and ensure that the new storage system can sustain that easily. This is a higher level view of the basic size of the I/O pipe you need - and despite being a basic view, provides a fair one for making a decision on storage array selection and purchasing.
If I/O performance is that critical, budget not a factor, then why even bother with a detailed technical analysis and performance calculations? Why not simply go for something high-end like a SSD storage array?

Oracle 11G - Oracle AWR export import Query Statistics.

I have Oracle 11G, i have seen the sql statements through Historical AWR option from Top Activites in performance tab. Can i export all AWR query statistics from production machine so that i can analyze all logs after importing it.
How can i know all statistical sql ( information ) and performace of production machine ?
any help ?

Hello,
have you checked the DBA_HIST* objects to see what / how was imported?
If the awr export dosn't get the contents of the rolling buffer, then you won't see any session statistics that are only there. If you want to get the contents of the rolling buffer you have to dump the contents of it with :
oradebug setmypid
oradebug dump ashdump 10
and load it into your "test" database.
But before doing this I suggest you read the related metalink documentation if any!!!
Regards,
Franky

AWR snapshot not generatedand how to compare statistics with a baseline

01. AWR snapshot not being generated even after setting looks fine
02. compare a captured set of statistics with a baseline.
i m not much clear on this, please help as i have this requirement at hand.
Thanks a lot in advance.

01.
SQL> show parameter statis
NAME TYPE VALUE
statistics_level string TYPICAL
I explicitly run and did cntl^C as it looks running endless... (waited almost 2-3 hours).
SQL> exec dbms_workload_repository.create_snapshot;
^CBEGIN dbms_workload_repository.create_snapshot; END;
ERROR at line 1:
ORA-01013: user requested cancel of current operation
looks like job_name is enabled.
GATHER_STATS_JOB TRUE WEEKNIGHT_WINDOW
freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0
GATHER_STATS_JOB TRUE WEEKEND_WINDOW
freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0
anything else can be checked, i dont have access to OEM..must be done at SQL prompt.
02. thanks for info. i understand.. how do we compare set of snapshots with baseline(which is actually pair/range of snapshot kept for further comparison)
no access to OEM. must be done at SQL prompt.
please help in both. thanks ...

Shared Pool Statistics - awr report -m 10.2.0.1

Hi,
I'm new to reading awr report and performance tuning.
I have the below in my statspack.
Do i need to increase my shared pool?
Any one can advise and explain "% Memory for SQL w/exec" and "% SQL with executions>1"
Shared Pool Statistics
Begin End
Memory Usage %: 95.78 97.71
% SQL with executions>1: 51.51 80.85
% Memory for SQL w/exec> 1: 67.88 82.46
thanks!

user21123 wrote:
The sweet point for the shared pool Memory Usage % is at about ~70%-80% because of aging out. You are at ~90%. It would be advisable to increase the shared pool, but if you're using 10g SGA_TARGET and SGA_MAX_SIZE, then that might require increasing those parameters. It depends how your AWR report looks for the Buffer Cache.
What makes you think this ?
In an OLTP system you hope for 100% shareable SQL, and correct allocation for the other objects, which would lead to 100% usage. In realistic terms, you're likely to get a few percent (which is often the shared_pool_reserved) free because there's a constant turn-over of non-shareable SQL.
If you're always seeing 70% - 80%, then there are several scenraios that might explain the figure. One is that you've simply made shared pool a bit too big. At the opposite extreme you might be constantly flushing 20%-30% of the material from the shared pool because it has become so fragmented that you have to clear a lot of garbage to create a small amount of contiguous space.
The best guideline to follow is to check whether you appear to be losing a significant amount of time on libarary cache and shared pool latches, using up an undesirable amount of CPU on parse time, see lots of reloads (without corresponding invalidations) in v$librarycache.
Without further information, we really can't say how good or bad the situation is. In fact, it's possible that the information that +"50% of your SQL has been shared, 50% has been single use"+ is a possible indicator that the shared_pool_size is too small, and we are filling the excess space with garbage rather than keeping the garbage (and library cache search time) to a minimum.
I would be interested to hear the thinking behind your suggestion, though.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." Stephen Hawking.

** MISSING ** entry for owner and object_name in AWR Segment statistics

Hello,
I have an AWR report which shows entries like this in the segment statistics section:
Segments by Physical Reads
    Owner       Tablespace Name          Object Name           Subobject Name   Obj. Type     Logical Reads   %Total
** MISSING **   USERS             ** MISSING: 205065/205065   ** MISSING **     UNDEFINED     3,967           2.60
APP_USER        USERS             SYS_LOB0000123236C00006$$                     LOB           3,747           2.45
** MISSING **   USERS             ** MISSING: 205069/205069   ** MISSING **     UNDEFINED     3,521           2.30Is this something I should be worried about?
If yes, what could be the cause for such an entry?
My Oracle version:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
On a RHEL (not sure about the version though)

Kuljeet Pal Singh wrote:
whats the value of control_management_pack_access in your database.
Is this something I should be worried about? i don't see any issue as the missing object also not doing much IO.
however you may get the detail from v$segment_statistics
query you may find from below post.
Top accessed table
Thanks for the answer, but for what should I query?
It doesn't show me a segment name, only the text ** MISSING ** which clearly isn't one of my segments.
I'm not concerned about the I/O it generates, I'm concerned about the fact that there is no segment name in the report.
Could this be caused by tables/indexes that were created during the snapshot and were no longer available when the report was generated?

Statistics -- ADDM,AWR

Hi Everyone,
Please help in understand ADDM report and AWR report I didn't understand a bit
from that but my boss is shouting at me since 2 days to understand and I've no
experience in DBA first job...
Thankyou,
Cheers,
Slash

If you have no DBA experience ... and your boss is shouting at you ... do yourself a huge favor ... go home ... update your resume ... drop it on the boss's desk ... and tell him you don't tolerate abuse.
That he can either apologize to you in front of everyone that heard the yelling or you are walking out the door.
No apology ... walk!
The chance of you learning anything about ADDM and AWR in less than a month,
assuming you were already a DBA who could read a StatsPack is remarkably close to zero.
I understand this advice is coming from a different country and a different culture but here that kind of abusive behavior wouldn't be tolerated.

AWR reporting

Hi All,
Ora 11gR1
Our PROD system is experiencing very slow performance during 5PM to 6PM. Maybe because of users running batch jobs and report program during this time.
So I run AWR during this period with BEGIN SNAP at 5:00pm and END SNAP TIME at 6PM.
Is this the right way to obtain the right report to analyze with performance problem?
Thanks a lot,

Hi,
AWR contains a bunch of statistics. During the performance issue, some of these statistics can have abnormal values, which gives you an idea as to what is causing the problem. If you only look at the duration of the problem, then you see the symptom with maximum clarity. If you are looking at a large interval, then the symptom will be not as clear.
Consider an example: imagine that from 5 pm to 6 pm your database was processing a job that was committing too often, which lead to excessive waits on 'log file sync' events. During this hour, the problem was responsible for 50% of the database time: 1800 seconds out of 3600. 50% is a large number which will definitely make it to the top, so you'd be able to see the problem clearly. But if you look at a 2 hour interval, it will fall down to roughly 25%, 1800 seconds out of 7200. If you make the interval yet larger, then the percentage would fall further down and so on and so forth. Finally, it will fall down to such a small value that the symptom will be 'buried' among other irrelevant statistics and you won't be able to see what was going on.
That's what I mean by 'dilution' of statistics, and that's why it is essential to AWR period to be as close to the duration of the problem as possible.
Best regards,
Nikolay

AWR - Database Performance Slow

If my Whole Database Performance is slow,
running AWR report include current time statistics when the DB Performance is slow ?

The default AWR Snapshot Interval is 1 hour. So, if you have the default implementation, you will be able to create an AWR report for the period 10am to 11am. It will not reflect what or why "slowness" occurred at 10:45. The statistics in the AWR report will be a summation / averaging of all the activity in the entire hour.
You could modify the Snapshot Interval (using dbms_workload_repository.modify_snapshot_settings) to have Oracle collect snapshots every 15minutes. But that will apply after the change has been made. So, if you have a slowness subsequently, you will be able to investigate it with the AWR report for that period. But what has been collected in the past at hourly intervals cannot be refined any further.
Hemant K Chitale

AWR Report - no data!!

Oracle Version: 11.1.0.7 64x
OS Version: Windows 2008 Server 64x
Hi There,
We're just trying to generate a awr report for one of our databases and the report is coming out with no data.
statistics_level parameter is set to "TYPICAL"; any idea to what's going on please?
Thanks
SQL>
SQL> @?/rdbms/admin/awrrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
   DB Id    DB Name      Inst Num Instance
1391811405 WEBTST              1 webtst
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter 'html' for an HTML report, or 'text' for plain text
Defaults to 'html'
Enter value for report_type: text
Type Specified: text
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   DB Id     Inst Num DB Name      Instance     Host
* 1391811405        1 WEBTST       webtst       WEBDBTST
Using 1391811405 for database Id
Using          1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
Enter value for num_days: 1
Listing the last day's Completed Snapshots
                                                        Snap
Instance     DB Name        Snap Id    Snap Started    Level
webtst       WEBTST           43973 12 May 2011 00:00      1
                              43974 12 May 2011 01:00      1
                              43975 12 May 2011 02:00      1
                              43976 12 May 2011 03:00      1
                              43977 12 May 2011 04:00      1
                              43978 12 May 2011 05:00      1
                              43979 12 May 2011 06:00      1
                              43980 12 May 2011 07:00      1
                              43981 12 May 2011 08:00      1
                              43982 12 May 2011 09:00      1
                              43983 12 May 2011 10:00      1
                              43984 12 May 2011 11:00      1
                              43985 12 May 2011 11:02      1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 43984
Begin Snapshot Id specified: 43984
Enter value for end_snap: 43985
End   Snapshot Id specified: 43985
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_43984_43985.txt. To use this name,
press <return> to continue, otherwise enter an alternative.
Enter value for report_name:
Using the report name awrrpt_1_43984_43985.txt
WARNING (-20023)
ORA-20023: Missing start and end values for time model stat: parse time elapsed
WARNING (-20023)
ORA-20023: Missing start and end values for time model stat: DB CPU
WARNING (-20016)
ORA-20016: Missing value for SGASTAT: free memory
WARNING (-20016)
ORA-20016: Missing value for SGASTAT: free memory
WARNING (-20009)
ORA-20009: Missing System Statistic logons current
WARNING (-20009)
ORA-20009: Missing System Statistic logons current
WARNING (-20009)
ORA-20009: Missing System Statistic opened cursors current
WARNING (-20009)
ORA-20009: Missing System Statistic opened cursors current
WARNING (-20023)
ORA-20023: Missing start and end values for time model stat: sql execute elapsed
WARNING (-20008)
ORA-20008: Missing Init.ora parameter undo_management
WARNING (-20008)
ORA-20008: Missing Init.ora parameter db_block_size
WARNING (-20016)
ORA-20016: Missing value for SGASTAT: log_buffer
WARNING (-20023)
ORA-20023: Missing start and end values for time model stat: DB time
WARNING (-20008)
ORA-20008: Missing Init.ora parameter timed_statistics
WARNING (-20008)
ORA-20008: Missing Init.ora parameter timed_statistics
WARNING (-20008)
ORA-20008: Missing Init.ora parameter statistics_level
WARNING (-20008)
ORA-20008: Missing Init.ora parameter statistics_level
WARNING (-20008)
ORA-20008: Missing Init.ora parameter sga_target
WARNING (-20008)
ORA-20008: Missing Init.ora parameter pga_aggregate_target
WARNING (-20023)
ORA-20023: Missing start and end values for time model stat: background cpu time
WARNING (-20023)
ORA-20023: Missing start and end values for time model stat: background elapsed
WARNING (-20023)
ORA-20023: Missing start and end values for time model stat: connection manageme
WARNING (-20016)
ORA-20016: Missing value for SGASTAT: buffer_cache
WARNING (-20016)
ORA-20016: Missing value for SGASTAT: buffer_cache
WARNING: Since the DB Time is less than one second, there was
         minimal foreground activity in the snapshot period.
         Some of the percentage values will be invalid.
WORKLOAD REPOSITORY report for
DB Name         DB Id    Instance     Inst Num Startup Time    Release     RAC
WEBTST        1391811405 webtst              1 29-Apr-11 04:50 11.1.0.7.0 NO
Host Name        Platform                         CPUs Cores Sockets Memory(GB)
WEBDBTST         Microsoft Windows x86 64-bit                           .00
              Snap Id      Snap Time      Sessions Curs/Sess
Begin Snap:     43984 12-May-11 11:00:01
End Snap:     43985 12-May-11 11:02:00
   Elapsed:                1.98 (mins)
   DB Time:                0.00 (mins)
Cache Sizes                       Begin        End
~~~~~~~~~~~                  ---------- ----------
               Buffer Cache:MM Std Block Size:K
           Shared Pool Size:         0M         0M      Log Buffer:K
ORA-01403: no data found
Error encountered in Report Summary
Continuing to Report Sections
Time Model Statistics              DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Operating System Statistics         DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Operating System Statistics - DetailDB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Foreground Wait Class               DB/Inst: WEBTST/webtst Snaps: 43984-43985
-> s - second, ms - millisecond -    1000th of a second
-> ordered by wait time desc, waits desc
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
-> Captured Time accounts for % of Total DB time            .00 (s)
-> Total FG Wait Time:    (s) DB CPU time:            .00 (s)
                                                                  Avg
                                      %Time       Total Wait     wait
Wait Class                      Waits -outs         Time (s)     (ms) %DB time
DB CPU                                                     0              100.0
Foreground Wait Events             DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Background Wait Events             DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Wait Event Histogram               DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Service Statistics                 DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Service Wait Class Stats            DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by Elapsed Time        DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by CPU Time            DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by Gets                DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by Reads               DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by Executions          DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by Parse Calls         DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by Sharable Memory     DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
SQL ordered by Version Count       DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Instance Activity Stats            DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Instance Activity Stats - Absolute ValuesDB/Inst: WEBTST/webtst Snaps: 43984
                  No data exists for this section of the report.
Instance Activity Stats - Thread ActivityDB/Inst: WEBTST/webtst Snaps: 43984-
                  No data exists for this section of the report.
Tablespace IO Stats                DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
File IO Stats                      DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Buffer Pool Statistics             DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Instance Recovery Stats             DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Buffer Pool Advisory                       DB/Inst: WEBTST/webtst Snap: 43985
                  No data exists for this section of the report.
PGA Aggr Summary                   DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
PGA Aggr Target Stats               DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
PGA Aggr Target Histogram           DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
PGA Memory Advisory                        DB/Inst: WEBTST/webtst Snap: 43985
                  No data exists for this section of the report.
Shared Pool Advisory                      DB/Inst: WEBTST/webtst Snap: 43985
                  No data exists for this section of the report.
SGA Target Advisory                        DB/Inst: WEBTST/webtst Snap: 43985
                  No data exists for this section of the report.
Streams Pool Advisory                      DB/Inst: WEBTST/webtst Snap: 43985
                  No data exists for this section of the report.
Java Pool Advisory                         DB/Inst: WEBTST/webtst Snap: 43985
                  No data exists for this section of the report.
Buffer Wait Statistics              DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Enqueue Activity                   DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Undo Segment Summary               DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Undo Segment Stats                  DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Latch Activity                     DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Latch Sleep Breakdown              DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Latch Miss Sources                 DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Mutex Sleep Summary                 DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Parent Latch Statistics            DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Child Latch Statistics              DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Segments by Row Lock Waits         DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Segments by ITL Waits               DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Segments by Buffer Busy Waits       DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Dictionary Cache Stats             DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Library Cache Activity              DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Memory Dynamic Components          DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Memory Resize Operations Summary    DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Memory Resize Ops                   DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Process Memory Summary             DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
sum
SGA breakdown difference            DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Streams CPU/IO Usage               DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Streams Capture                     DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Streams Apply                       DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Buffered Queues                     DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Buffered Subscribers                DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Rule Set                            DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Persistent Queues                   DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Persistent Subscribers              DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
Resource Limit Stats                      DB/Inst: WEBTST/webtst Snap: 43985
                  No data exists for this section of the report.
init.ora Parameters                DB/Inst: WEBTST/webtst Snaps: 43984-43985
                  No data exists for this section of the report.
End of Report

SQL> show parameter statistics
NAME                                 TYPE        VALUE
optimizer_use_pending_statistics     boolean     FALSE
statistics_level                     string      TYPICAL
timed_os_statistics                  integer     0
timed_statistics                     boolean     TRUE
SQL>
SQL> SELECT statistics_name,
2             session_status,
3             system_status,
4             activation_level,
5             session_settable
6      FROM   v$statistics_level
7      ORDER BY statistics_name;
STATISTICS_NAME                                                  SESSION_ SYSTEM_S ACTIVAT SES
Active Session History                                           ENABLED ENABLED TYPICAL NO
Adaptive Thresholds Enabled                                      ENABLED ENABLED TYPICAL NO
Automated Maintenance Tasks                                      ENABLED ENABLED TYPICAL NO
Bind Data Capture                                                ENABLED ENABLED TYPICAL NO
Buffer Cache Advice                                              ENABLED ENABLED TYPICAL NO
Global Cache Statistics                                          ENABLED ENABLED TYPICAL NO
Longops Statistics                                               ENABLED ENABLED TYPICAL NO
MTTR Advice                                                      DISABLED DISABLED TYPICAL NO
Modification Monitoring                                          ENABLED ENABLED TYPICAL NO
PGA Advice                                                       ENABLED ENABLED TYPICAL NO
Plan Execution Sampling                                          ENABLED ENABLED TYPICAL YES
Plan Execution Statistics                                        DISABLED DISABLED ALL     YES
SQL Monitoring                                                   ENABLED ENABLED TYPICAL YES
Segment Level Statistics                                         ENABLED ENABLED TYPICAL NO
Shared Pool Advice                                               ENABLED ENABLED TYPICAL NO
Streams Pool Advice                                              ENABLED ENABLED TYPICAL NO
Threshold-based Alerts                                           ENABLED ENABLED TYPICAL NO
Time Model Events                                                ENABLED ENABLED TYPICAL YES
Timed OS Statistics                                              DISABLED DISABLED ALL     YES
Timed Statistics                                                 ENABLED ENABLED TYPICAL YES
Ultrafast Latch Statistics                                       ENABLED ENABLED TYPICAL NO
Undo Advisor, Alerts and Fast Ramp up                            ENABLED ENABLED TYPICAL NO
V$IOSTAT_* statistics                                            ENABLED ENABLED TYPICAL NO
23 rows selected.
SQL>Thanks
Edited by: rsar001 on May 12, 2011 11:33 AM

Awr Statistics

Similar Messages

Maybe you are looking for