Gathering system statistics in 10g

I am confused. I read in the Oracle® Database Performance Tuning Guide, for 10g Release 1, that the system statistics are NOT automatically generated and must be manually generated using DBMS_STATS. However, when I query V$SESSTAT, V$STATNAME and V$OSSTAT I have records returned.
I thought that DBMS_STATS was no longer used in 10g and that everything was automatic. Does anyone know which is correct? If I have data in those views does that mean that system statistics have been run?
Thanks!

You can still manually collect stats in 10g using DBMS_STATS, but 10g can also perform statistics collection on stale tables automatically, when enabled. Our other DBA was involved in setting up that item, but I think the Oracle tool involved is the Automatic Workload Repository.
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10752/autostat.htm
-Chuck

Similar Messages

  • Survey : are you gathering system statistics in Production env ?

    Does it help ?
    what work/effort did you do before you implemented stats in production ? did you first do it in dev and then test and then QA etc. or directly in producton ?
    What queries changed execution plans - any specific things you want to mention on how it influenced Oracle CBO ?
    please mention how big your database is and whether it is OLTP/DSS and which Oracle release you are running in production etc. so that we can get the background info as well.
    thanks

    ow001294, what kind of statistics are you asking about?
    If you are on version 10+ then Oracle by default generates and saves certain system and session statistics in the AWR.
    Generally speaking it is not a bad idea to use the STATSPACK package to take 5 or 10 minute snapshots of your database activity on a regular basis and generate and save the reports. The early reports serve as a baseline to compare later reports to.
    Trying to keep track of every query plan seems impractical for anyting but a very small system.
    HTH -- Mark D Powell --

  • Gather system statistics

    Hi Friends,
    I want to gather system statistics in my Oracle 9.2.07 (windows) environment...
    created one statistics table...
    execute DBMS_STATS.CREATE_STAT_TABLE ('SYS','MY_STATS');
    (2) Gathering SYSTEM Statistics Script during office hours ( 8 hours) (8am to 4pm)
    begin
    execute dbms_stats.gather_system_stats(
    gathering_mode=> 'interval',
    interval => 480,
    stattab=> 'MY_STATS',
    STATID=> 'OLTP');
    END;
    REM
    REM
    REM END of Script
    REM===================================================
    (3) Import the Collected System Statistics
    Import the statistics daily around 8AM...because..users starts entering the transactions....
    variable jobno number;
    begin
    dbms_job.submit(:jobno,'dbms_stats.import_system_stats(''IMAL_STATS'',''OLTP'');',
    SYSDATE,'SYSDATE+1');
    COMMIT;
    END;
    ========================================================
    OLAP..also i will collect during night time....
    gathering system statiscs will end after 4pm....so..it takes system statistics during 8 hours interval time...and i am going to import them next day 8am..
    is this the correct method????.please sched some light on this...

    Hi,
    Oracle recommends to gather system statistics from oracle 9i onwards....this the line from Oracle 9i R2 document...
    Oracle9i Database Performance Tuning Guide and Reference
    Release 2 (9.2)
    Gathering System Statistics
    System statistics enable the optimizer to consider a system's I/O and CPU performance and utilization. For each plan candidate, the optimizer computes estimates for I/O and CPU costs. It is important to know the system characteristics to pick the most efficient plan with optimal proportion between I/O and CPU cost.
    System I/O characteristics depend on many factors and do not stay constant all the time. Using system statistics management routines, database administrators can capture statistics in the interval of time when the system has the most common workload. For example, database applications can process OLTP transactions during the day and run OLAP reports at night. Administrators can gather statistics for both states and activate appropriate OLTP or OLAP statistics when needed. This enables the optimizer to generate relevant costs with respect to available system resource plans.
    When Oracle generates system statistics, it analyzes system activity in a specified period of time. Unlike table, index, or column statistics, Oracle does not invalidate already parsed SQL statements when system statistics get updated. All new SQL statements are parsed using new statistics. Oracle Corporation highly recommends that you gather system statistics.The DBMS_STATS.GATHER_SYSTEM_STATS routine collects system statistics in a user-defined timeframe. You can also set system statistics values explicitly using DBMS_STATS.SET_SYSTEM_STATS. Use DBMS_STATS.GET_SYSTEM_STATS to verify system statistics.
    So better performanace, as per above document, we need system statistics.
    if not needed.why it is not need...can u please describe this...
    Message was edited by:
    bsubbu

  • System Statistics (sreadtim mreadtim)

    I have gathered system statistics for my 9.2.0.8 database on a number of occasions. I consistently find that sreadtim is greater than mreadtim. Is this correct?
    Regards,
    Gavin

    gwrayner wrote:
    I have gathered system statistics for my 9.2.0.8 database on a number of occasions. I consistently find that sreadtim is greater than mreadtim. Is this correct?
    Regards,
    GavinYou might take a look at the following two links:
    http://jonathanlewis.wordpress.com/2007/05/20/system-stats-strategy/
    http://jonathanlewis.wordpress.com/2008/10/02/upgrades/
    Typically, sreadtim should be less than mreadtim - although caching at the file system or SAN level is able to throw off the timing calculations.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Best practices for gathering statistics in 10g

    I would like to get some opinions on what is considered best practice for gathering statistics in 10g. I know that 10g has auto statistics gathering, but that doesn't seem to be very effective as I see some table stats are way out of date.
    I have recommended that we have at least a weekly job that generates stats for our schema using DBMS_STATS (DBMS_STATS.gather_schema_stats). Is this the right approach to generate object stats for a schema and keep it up to date? Are index stats included in that using CASCADE?
    Is it also necessary to gather system stats? I welcome any thoughts anyone might have. Thanks.

    Hi,
    Is this the right approach to generate object stats for a schema and keep it up to date? The choices of executions plans made by the CBO are only as good as the statistics available to it. The old-fashioned analyze table and dbms_utility methods for generating CBO statistics are obsolete and somewhat dangerous to SQL performance. As we may know, the CBO uses object statistics to choose the best execution plan for all SQL statements.
    I spoke with Andrew Holsworth of Oracle Corp SQL Tuning group, and he says that Oracle recommends taking a single, deep sample and keep it, only re-analyzing when there is a chance that would make a difference in execution plans (not the default 20% re-analyze threshold).
    I have my detailed notes here:
    http://www.dba-oracle.com/art_otn_cbo.htm
    As to system stats, oh yes!
    By measuring the relative costs of sequential vs. scattered I/O, the CBO can make better decisons. Here are the data items collected by dbms_stats.gather_system_stats:
    No Workload (NW) stats:
    CPUSPEEDNW - CPU speed
    IOSEEKTIM - The I/O seek time in milliseconds
    IOTFRSPEED - I/O transfer speed in milliseconds
    I have my notes here:
    http://www.dba-oracle.com/t_dbms_stats_gather_system_stats.htm
    Hope this helps. . . .
    Don Burleson
    Oracle Press author
    Author of “Oracle Tuning: The Definitive Reference”
    http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

  • MBRC and SYSTEM STATISTICS in Oracle 10g database.

    Hi All,
    I am performing database upgrade from Oracle 8i Solaris to Oracle 10g HP-UX using exp/imp method.
    But i do have some doubts regarding MBRC and System statistics.
    MBRC in Oracle 10g is automatically adjusted if MBRC parameter is not set, but i found value 128 as shown below.
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
    PL/SQL Release 10.2.0.4.0 - Production
    CORE    10.2.0.4.0      Production
    TNS for HPUX: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    SQL> sho parameter multi
    NAME                                 TYPE                             VALUE
    db_file_multiblock_read_count        integer                          128Also i performed one simple full table scan to test it...but db file scattered read is performing on 128 blocks. So i dont think 128 is suitable and is automatic, i mean MBRC is not set accrodingly it always uses 128.
    Does this MBRC value affects whole database performance?
    Regarding SYSTEM STATISTICS i found below result:
    SQL> select * from AUX_STATS$
    SNAME                          PNAME                               PVAL1 PVAL2
    SYSSTATS_INFO                  STATUS                                    COMPLETED
    SYSSTATS_INFO                  DSTART                                    11-09-2009 04:59
    SYSSTATS_INFO                  DSTOP                                     11-09-2009 04:59
    SYSSTATS_INFO                  FLAGS                                   1
    SYSSTATS_MAIN                  CPUSPEEDNW                     128.239557
    SYSSTATS_MAIN                  IOSEEKTIM                              10
    SYSSTATS_MAIN                  IOTFRSPEED                           4096
    SYSSTATS_MAIN                  SREADTIM
    SYSSTATS_MAIN                  MREADTIM
    SYSSTATS_MAIN                  CPUSPEED
    SYSSTATS_MAIN                  MBRC
    SYSSTATS_MAIN                  MAXTHR
    SYSSTATS_MAIN                  SLAVETHRNow whether NOWORKLOAD or WORKLOAD is better, and this server is still under building process....so how can i collect WORKLOAD stats as high load on this server can't be performed?? Is it really require to gather system statistics, what will happen with NOWORLOAD stats?
    I have not seen single database where system stats are gathered in our organisation having more than 2000 databases.
    -Yasser

    Maybe this article written by Tom Kite helps:
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:499197100346264909

  • Oracle 10g - System Statistics

    Hello guys,
    i've got a question foru you :-))
    If i generate new system statistics (cpu load, i/o load, etc.), are the execution plans in the sga going invalid?
    Some time ago i tested it with new statistics on tables/indeces and if i generate new statistics for tables/indeces, all execution plans that refer to the object (table/indeces) are going invalid.
    But under 10g, what about system stats? Are all execution plans going invalid, if new system statistics are generated? The system stats are needed to decide which access path is better.. so it would be suggestive .... i believe this would cause massive parse load.
    Thanks for your answers
    Regards
    Stefan

    From the Performance Tuning Guide, Chapter 14 Managing Optimizer Statistics
    Unlike table, index, or column statistics, Oracle does not invalidate already parsed SQL statements when system statistics get updated. All new SQL statements are parsed using new statistics.
    http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#sthref1468

  • Best Way to gather statistics in 10g

    Hi All,
    What is the best way to gather optimizer statistics in 10g databases? We are currently following the default automatic statistics gathering feature of 10g. But we feel it has got some shortcomings. For many of the tables the stats are not up to date. Also we have hit one bug in 10g which can cause "cursor: pin S wait on X " during stats gathering (As given in metalink note).
    So what do you experts feel about the issue. What would be the best way to gather stats=> manual or auto?
    Regards
    Satish

    The right reply to your question is "it depends". It depends on your application systems,
    the amount of change that your data suffers during time and your queries. You can choose what statistics to gather and when. You have to know your data and your application, though. There is no simple answer, right for everyone, which could be dispensed and set as a "golden
    rule". The great site with many useful articles about statistics is Wolfgang Breitling's site:
    www.centrexcc.com. That is for starters. Your question is far from trivial and is not easily answered. The best reply you can get is "it depends".

  • How to select all  indexes in a schema , for gathering the statistics

    In OEM 10g , How can we select all the indexes in a particular schema for gathering the statistics.
    For example , consider the schema got 1500 indexes. When i clicked on select all , it is selecting 10 indexes in one stretch ( all which are present in that page).
    For 1500 indexes , i have to make 150 such selection.
    How can we avoid it.
    In 9i OEM, its quite simple. With just 1 mouse clicke , we can select all the indexes .
    Thanks
    Naveen
    314 439 9554

    On the Administration Tab of the instance, choose Statistics Management - Manage Optimizer Statistics, then Gather Optimizer Statistics and click Continue. You then get a choice of Database, Schema, Tables or Indexes.
    Stupid that you have to supply an OS username and password to do this but anyway.

  • Average system statistics

    Hi all,
    I have a package which captures system statistics into a user specified table using the usual method:
    --1. Create user defined stats table to store stats
    DBMS_STATS.CREATE_STAT_TABLE (ownanme => 'STAT_ADM' ,stattab=>'STAT_LOG' ,tblspace=>'STATS');
    -- 2. Collect statistics under workload and store them in user stats table:
    DBMS_STATS.GATHER_SYSTEM_STATS (gathering_mode => 'INTERVAL' ,interval => 120 ,stattab => 'STAT_LOG' ,statid => 'SYS_YYYMMDDHH24MISS');
    When applying the system stats I would like to obtain an average of the system statistics stored in my user defined table over a time period, and use this average to set the system statistics, ideally also storing the average in the same table first so I can reuse or have a log. I'm not sure how to go about doing this since the stats table stores two values for a single capture and has some strange and missing values in some cases. Does anyone have any ideas or code which can I assist me please?
    STATID T VERSION FLAGS C1 C2 C3 C4 C5 N1
    N4 N5 N6 N7 N8 N9 N10 N11 N12 D1 R1
    R2 CH1
    THU_20090312130 S 4 0 COMPLETED 03-12-2009 13:00 03-12-2009 1 CPU_SERIO
    0 4:00
    444755765 879118370 313803318 850441300 10067568 9385896 0 8 4085027062
    THU_20090312130 S 4 0 PARIO 41110528
    0
    0
    Any help is greatly appreciated. Thanks.

    cwong wrote:
    Hi all,
    I have a package which captures system statistics into a user specified table using the usual method:
    --1. Create user defined stats table to store stats
    DBMS_STATS.CREATE_STAT_TABLE (ownanme => 'STAT_ADM' ,stattab=>'STAT_LOG' ,tblspace=>'STATS');
    -- 2. Collect statistics under workload and store them in user stats table:
    DBMS_STATS.GATHER_SYSTEM_STATS (gathering_mode => 'INTERVAL' ,interval => 120 ,stattab => 'STAT_LOG' ,statid => 'SYS_YYYMMDDHH24MISS');
    When applying the system stats I would like to obtain an average of the system statistics stored in my user defined table over a time period, and use this average to set the system statistics, ideally also storing the average in the same table first so I can reuse or have a log. I'm not sure how to go about doing this since the stats table stores two values for a single capture and has some strange and missing values in some cases. Does anyone have any ideas or code which can I assist me please?I'm not sure if your approach is reasonable. Do you expect to see such dramatic differences between the measurements that you want to apply some special logic to the system statistics gathered? Can you come up with an concrete example how you think that you're going to have an added value by doing so?
    Anyway, if you want to manipulate system statistics you shouldn't fiddle around with the statistics table itself, but use the documented API to get and set the values:
    DBMS_STATS.GET_SYSTEM_STATS/SET_SYSTEM_STATS
    These can be used on user-defined statistics tables, so you should be able to get your statistics, massage them somehow and write them back using a new STATID identifier.
    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/

  • Time Series Format of Operating System Statistics - "Please Ignore"

    Hi List,
    On the AWR report we see the "Operating System Statistics" section.. since generating multiple AWR reports is daunting and takes a lot of time and I'm only interested on particular columns of dba_hist_osstat (where that particular section of AWR pulls the data)... I'd like to have an output like this:
    SNAP_ID BUSY_TIME LOAD NUM_CPUS PHYSICAL_MEMORY_BYTES
    244 6792 .23 1 169520
    245 1603 .04 1 154464
    246 28415 .05 1 5148
    Problem is, the dba_hist_osstat values are stored as rows...
    select * from dba_hist_osstat where snap_id = 244;
    244     2607950532     1     0     NUM_CPUS     1
    244     2607950532     1     1     IDLE_TIME     57153
    244     2607950532     1     2     BUSY_TIME     5339
    244     2607950532     1     3     USER_TIME     1189
    244     2607950532     1     4     SYS_TIME     4077
    244     2607950532     1     5     IOWAIT_TIME     2432
    244     2607950532     1     6     NICE_TIME     0
    244     2607950532     1     14     RSRC_MGR_CPU_WAIT_TIME     0
    244     2607950532     1     15     LOAD     0.099609375
    244     2607950532     1     1008     PHYSICAL_MEMORY_BYTES     300536
    So I got this query to walk through all the SNAP_IDs with the following output. I'd just like to format particular columns like the one I mentioned (above) for the data to be more meaningful and to be easily loaded on excel for visualization. Well I can also do this on "Instance Activity Stats" (dba_hist_sysstat) and other stuff..
    select
    b.snap_id, substr(e.stat_name, 1, 35) as name,
    (case when e.stat_name like 'NUM_CPU%' then e.value
    when e.stat_name = 'LOAD' then e.value
    when e.stat_name = 'PHYSICAL_MEMORY_BYTES' then e.value
    else e.value - b.value
    end) as value
    from dba_hist_osstat b,
    dba_hist_osstat e
    where
    b.stat_name = 'BUSY_TIME' and
    b.dbid = 2607950532
    and e.dbid = 2607950532
    and b.instance_number = 1
    and e.instance_number = 1
    and e.snap_id = b.snap_id + 1
    and b.stat_id = e.stat_id
    order by snap_id, name asc
    SNAP_ID NAME VALUE
    244     BUSY_TIME     6792
    245     BUSY_TIME     1603
    246     BUSY_TIME     28415
    BTW, try to generate AWR reports on a particular SNAP_IDs, the value you get from the query will be the same on the report...
    - Karl Arao
    karlarao.wordpress.com
    Edited by: Karl Arao on Jan 31, 2010 12:07 PM

    I got the final version of the script...
    SELECT s0.snap_id,
    TO_CHAR(s0.END_INTERVAL_TIME,'YYYY-Mon-DD HH24:MI:SS') snap_start,
    TO_CHAR(s1.END_INTERVAL_TIME,'YYYY-Mon-DD HH24:MI:SS') snap_end,
    round(EXTRACT(DAY FROM s1.END_INTERVAL_TIME - s0.END_INTERVAL_TIME) * 1440 + EXTRACT(HOUR FROM s1.END_INTERVAL_TIME - s0.END_INTERVAL_TIME) * 60 + EXTRACT(MINUTE FROM s1.END_INTERVAL_TIME - s0.END_INTERVAL_TIME) + EXTRACT(SECOND FROM s1.END_INTERVAL_TIME - s0.END_INTERVAL_TIME) / 60, 2) ela_min,
    s1t1.value - s1t0.value AS busy_time,
    s2t1.value AS load,
    s3t1.value AS num_cpus,
    s4t1.value AS physical_memory_bytes
    FROM dba_hist_snapshot s0,
    dba_hist_snapshot s1,
    dba_hist_osstat s1t0,
    dba_hist_osstat s1t1,
    dba_hist_osstat s2t1,
    dba_hist_osstat s3t1,
    dba_hist_osstat s4t1
    WHERE s0.dbid = 2607950532
    AND s1t0.dbid = s0.dbid
    AND s1t1.dbid = s0.dbid
    AND s2t1.dbid = s0.dbid
    AND s3t1.dbid = s0.dbid
    AND s4t1.dbid = s0.dbid
    AND s0.instance_number = 1
    AND s1t0.instance_number = s0.instance_number
    AND s1t1.instance_number = s0.instance_number
    AND s2t1.instance_number = s0.instance_number
    AND s3t1.instance_number = s0.instance_number
    AND s4t1.instance_number = s0.instance_number
    AND s1.snap_id = s0.snap_id + 1
    AND s1t0.snap_id = s0.snap_id
    AND s1t1.snap_id = s0.snap_id + 1
    AND s2t1.snap_id = s0.snap_id + 1
    AND s3t1.snap_id = s0.snap_id + 1
    AND s4t1.snap_id = s0.snap_id + 1
    AND s1t0.stat_name = 'BUSY_TIME'
    AND s1t1.stat_name = s1t0.stat_name
    AND s2t1.stat_name = 'LOAD'
    AND s3t1.stat_name = 'NUM_CPUS'
    AND s4t1.stat_name = 'PHYSICAL_MEMORY_BYTES'
    ORDER BY snap_id ASC
    SNAP_ID SNAP_START          SNAP_END          ELA_MIN BUSY_TIME     LOAD     NUM_CPUS PHYSICAL_MEMORY_BYTES
    244 2010-Jan-14 12:38:36 2010-Jan-14 13:03:23     24.78 6792 .239257813     1          169520
    245 2010-Jan-14 13:03:23 2010-Jan-14 13:10:38     7.25 1603 .049804688     1          154464
    246 2010-Jan-14 13:10:38 2010-Jan-14 14:00:39     50.02 28415 .059570313     1          5148
    247 2010-Jan-14 14:00:39 2010-Jan-14 15:00:42     60.04 8993     0     1          29292
    248 2010-Jan-14 15:00:42 2010-Jan-15 23:56:37     1975.92 -46770 .049804688     1          311216
    249 2010-Jan-15 23:56:37 2010-Jan-16 01:00:40     64.05 17722 .659179688     1          109880
    250 2010-Jan-16 01:00:40 2010-Jan-16 02:00:42     60.03 7089 .229492188     1          43576
    251 2010-Jan-16 02:00:42 2010-Jan-16 10:05:01     484.31 -23928     0     1          310720
    252 2010-Jan-16 10:05:01 2010-Jan-16 11:01:02     56.03 8906 .099609375     1          186432
    From the AWR...
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 244 14-Jan-10 12:38:36 25 1.8 <-- same from above output (start & end)
    End Snap: 245 14-Jan-10 13:03:23 24 2.0
    Elapsed: 24.78 (mins) <-- same from above output (4th col)
    DB Time: 0.32 (mins)
    ... output snipped ...
    Operating System Statistics DB/Inst: IVRS/ivrs Snaps: 244-245
    Statistic Total
    BUSY_TIME 6,792 <-- same from above output (5th col)
    IDLE_TIME 141,649
    IOWAIT_TIME 4,468
    NICE_TIME 0
    SYS_TIME 4,506
    USER_TIME 2,115
    LOAD 0
    RSRC_MGR_CPU_WAIT_TIME 0
    PHYSICAL_MEMORY_BYTES 169,520 <-- same from above output (last col)
    NUM_CPUS 1
    And comming from the original query.. all output is similar above..
    select
    b.snap_id, substr(e.stat_name, 1, 35) as name,
    (case when e.stat_name like 'NUM_CPU%' then e.value
    when e.stat_name = 'LOAD' then e.value
    when e.stat_name = 'PHYSICAL_MEMORY_BYTES' then e.value
    else e.value - b.value
    end) as value
    from dba_hist_osstat b,
    dba_hist_osstat e
    where
    b.stat_name = 'LOAD' and
    b.dbid = 2607950532
    and e.dbid = 2607950532
    and b.instance_number = 1
    and e.instance_number = 1
    and e.snap_id = b.snap_id + 1
    and b.stat_id = e.stat_id
    order by snap_id, name asc
    SNAP_ID NAME                     VALUE
    244 LOAD                .239257813
    245 LOAD                .049804688
    246 LOAD                .059570313
    247 LOAD                          0
    248 LOAD                .049804688
    249 LOAD                .659179688
    250 LOAD                .229492188
    251 LOAD                          0
    252 LOAD                .099609375
    Hope this helps...
    - Karl Arao
    karlarao.wordpress.com

  • Time Series Format of Operating System Statistics

    On the AWR report we see the "Operating System Statistics" section.. since generating multiple AWR reports is daunting and takes a lot of time and I'm only interested on particular columns of dba_hist_osstat (where that particular section of AWR pulls the data)... I'd like to have an output like this:
    SNAP_ID BUSY_TIME LOAD NUM_CPUS PHYSICAL_MEMORY_BYTES
    244 6792 .23 1 169520
    245 1603 .04 1 154464
    246 28415 .05 1 5148
    Problem is, the dba_hist_osstat values are stored as rows...
    select * from dba_hist_osstat where snap_id = 244;
    244 2607950532 1 0 NUM_CPUS 1
    244 2607950532 1 1 IDLE_TIME 57153
    244 2607950532 1 2 BUSY_TIME 5339
    244 2607950532 1 3 USER_TIME 1189
    244 2607950532 1 4 SYS_TIME 4077
    244 2607950532 1 5 IOWAIT_TIME 2432
    244 2607950532 1 6 NICE_TIME 0
    244 2607950532 1 14 RSRC_MGR_CPU_WAIT_TIME 0
    244 2607950532 1 15 LOAD 0.099609375
    244 2607950532 1 1008 PHYSICAL_MEMORY_BYTES 300536
    So I got this query to walk through all the SNAP_IDs with the following output. I'd just like to format particular columns like the one I mentioned (above) for the data to be more meaningful and to be easily loaded on excel for visualization. Well I can also do this on "Instance Activity Stats" (dba_hist_sysstat) and other stuff..
    select
    b.snap_id, substr(e.stat_name, 1, 35) as name,
    (case when e.stat_name like 'NUM_CPU%' then e.value
    when e.stat_name = 'LOAD' then e.value
    when e.stat_name = 'PHYSICAL_MEMORY_BYTES' then e.value
    else e.value - b.value
    end) as value
    from dba_hist_osstat b,
    dba_hist_osstat e
    where
    b.stat_name = 'BUSY_TIME' and
    b.dbid = 2607950532
    and e.dbid = 2607950532
    and b.instance_number = 1
    and e.instance_number = 1
    and e.snap_id = b.snap_id + 1
    and b.stat_id = e.stat_id
    order by snap_id, name asc
    SNAP_ID NAME VALUE
    244 BUSY_TIME 6792
    245 BUSY_TIME 1603
    246 BUSY_TIME 28415
    BTW, try to generate AWR reports on a particular SNAP_IDs, the value you get from the query will be the same on the report...
    - Karl Arao
    karlarao.wordpress.com

    Hi Jonathan,
    Thanks for the input, I'll explore rewriting the query using those functions. But for now it serves the purpose of knowing/characterizing the workload, and also having a clear view of the capacity, requirement, and utilization without the hassle of generating AWR reports on each snap_id...
    This will also be useful for visualization and predictive analysis..
    BTW, I've used the following tables:
    - dba_hist_snapshot
    - dba_hist_osstat
    - dba_hist_sys_time_model
    - dba_hist_sysstat
                                                                    AWR CPU and IO Workload Report
                    Total                                Total                 Total
            Snap   C        CPU                               Oracle                 OS                                                         Oracle RMAN  OS
      Snap         Dur   P       Time            DB      DB        Bg       RMAN         CPU       Busy     OS     CPU   Physical         IOPs      IOPs     IOPs       IO r         IO w      Redo  Sess     Exec    CPU  CPU CPU
        ID         (m)   U        (s)          Time     CPU       CPU        CPU         (s)       Time    Load     (s)     Memory            r      w     redo     (mb)/s       (mb)/s    (mb)/s Start       /s      %    %     %
       345       10.01   1     600.60         18.33      6.99      4.78       0.00       11.77    7467.00    0.30    74.67   71300.00        2.691     1.494     0.152      0.302        0.045     0.010    26    2.169      2    0  12
       344       10.04   1     602.40         67.32     46.23      4.89       0.00       51.12   10755.00    0.79   107.55   66852.00       11.954     1.582     0.226      0.173        0.020     0.005    24    4.724      8    0  18
       343       10.02   1     601.20         40.74     15.31      5.29       0.00       20.60    8188.00    0.80    81.88   79724.00        7.683     1.143     0.546      0.137        0.015     0.005    24    7.991      3    0  14
       342       10.01   1     600.60         12.21      6.95      4.60       0.00       11.55    7283.00    0.15    72.83   83972.00        1.122     0.749     0.143      0.012        0.009     0.003    24    7.051      2    0  12
       341       10.01   1     600.60          3.49      1.30      3.71       0.00        5.00    6107.00    0.79    61.07   86716.00        0.336     0.666     0.225      0.004        0.007     0.003    24    2.511      1    0  10
       340       10.01   1     600.60          2.01      1.34      4.21       0.00        5.55    6495.00    0.15    64.95   88028.00        0.341     0.909     0.155      0.003        0.010     0.003    24    2.130      1    0  11
       339        9.05   1     543.00        167.66     72.09      4.67       0.00       76.76   12248.00    0.39   122.48   88668.00      120.223     1.024     0.302     13.920        0.015     0.006    30    5.532     14    0  23
       338       10.05   1     603.00       1324.58    435.67     11.64       0.00      447.31   46982.00    4.29   469.82   50048.00      659.343     9.504     3.736     73.372        0.322     0.025    31   95.922     74    0  78
       337       10.14   1     608.40       2140.32    296.60     29.13       0.00      325.73   39908.00    4.45   399.08  111276.00      332.237    16.039     4.277     28.269        0.328     0.028    30  118.437     54    0  66
       336       10.12   1     607.20       1861.91    141.92     29.59       0.00      171.51   22773.00    3.20   227.73   27880.00      100.339     9.433     4.298     10.210        0.166     0.029    31  110.417     28    0  38
       335       10.06   1     603.60       1871.36    142.33     30.50       0.00      172.84   24254.00    3.51   242.54    3400.00      107.760    37.863    16.120      3.183        0.479     0.110    24  457.200     29    0  40
       334       10.01   1     600.60          1.68      0.96      2.92       0.00        3.88    2515.00    0.44    25.15   23912.00        0.012     0.664     0.152      0.000        0.008     0.002    24    2.592      1    0     4
       333       10.01   1     600.60          1.52      0.96      2.98       0.00        3.95    1068.00    0.00    10.68   67312.00        0.010     0.773     0.145      0.000        0.011     0.003    24    1.935      1    0     2
       332       10.01   1     600.60          5.02      4.70      2.97       0.00        7.67    1606.00    0.08    16.06   68600.00        0.018     0.661     0.155      0.000        0.008     0.003    24    3.362      1    0     3- Karl Arao
    karlarao.wordpress.com

  • How to setup System propterty in 10g EM

    Can anyone tell me how to setup System property in 10g EM or any system config file?
    My existing application has following code to access System property:
    this.logDir = System.getProperty("ServletLogDirectory");
    My current application server is oas 4.0. I am upgrading the application from oas 4.0 to 10g.
    Thanks in advance
    Don

    On the OAS Control's OC4J section, there is a place you can set the OC4J instance server settings. You can create certain number of JVMs and their runtime properties.

  • Exadata and System Statistics

    Hi, there,
    This might be a dumb question – but is it necessary to gather system statistics on Exadata machines?
    I (fairly) recently migrated my Production EDW from a V2 quarter-rack to an X3-2 quarter-rack. On a “normal” system, if I migrated the database to a different (faster) server, I would look at regathering the system statistcs.
    Is this something that’s sensible or worthwhile with Exadata?
    Mark

    Hi Mark,
    Before you gather system stats you can run the following sql to get your current values.
    SET SERVEROUTPUT ON
    DECLARE
      STATUS VARCHAR2(20);
      DSTART DATE;
      DSTOP DATE;
      PVALUE NUMBER;
      PNAME VARCHAR2(30);
    BEGIN
       PNAME := 'CPUSPEEDNW';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('cpuspeednw                  : '||pvalue);
       PNAME := 'IOSEEKTIM';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('ioseektime in ms            : '||pvalue);
       PNAME := 'IOTFRSPEED';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('iotfrspeef                  : '||pvalue);
       PNAME := 'SREADTIM';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('single block readtime in ms : '||pvalue);
       PNAME := 'MREADTIM';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('multi block readtime in ms  : '||pvalue);
       PNAME := 'CPUSPEED';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('cpuspeed                    : '||pvalue);
       PNAME := 'MBRC';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('multiblock read count       : '||pvalue);
       PNAME := 'MAXTHR';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('max threads                 : '||pvalue);
       PNAME := 'SLAVETHR';
       DBMS_STATS.GET_SYSTEM_STATS(status, dstart, dstop, pname, pvalue);
       DBMS_OUTPUT.PUT_LINE('slave threads               : '||pvalue);
      END;
    Best advice I can give would be to check Doc ID 1274318.1 and search for dbms_stats.
    Regards,
    Tycho

  • Collection of System Statistics

    Hi,
    Could you please tell how to collect system statistics? If I have 50 Databases on one system, can I collect them in one database and export them in the other databases? The load with 50 databases pro system is anything but constant. Until now, the strategy was to not collect the statistics in order to not degrade the performance. Now the customer want to implement system stats.
    How to do that?
    Thanks
    Laurent

    Could you please tell how to collect system statistics? If I have 50 Databases on one system, can I collect them in one database and export them in the other databases?You can. But, personally, I'll not do so because the value MBRC (which is very important!) is strongly database-dependent.
    Until now, the strategy was to not collect the
    statistics in order to not degrade the performance.There is no performance degradation! A collection means:
    1) getting a first set of values from V$/X$
    2) waiting some time... 1 hour, 1 day, ...
    3) getting a second set of values from V$/X$
    4) do some computations with the two sets of values
    As you can see step 1 and 3 performs only very simple queries, step 2 does nothing and step 4 are only few computations.
    Therefore, IMHO, you should simple collect the statistics on each database separately.
    A remark...
    Carefully test the application with system statistics. The generate execution plans can be very different with and without system stats!!!!
    Laurent,
    The above answer is from one of the oracle expert of optimizer, he worte several papers and did many presentations. I like the question you asked here and I approched him for the solution.
    My thanks to Chris.
    Jaffar

Maybe you are looking for