Statspack for 8.0.5

Does anyone know how to get the statspack scripts for version 8.0.5?
Thanks,
Maher

According to this article, statspack officially exist since 8.1.6, but you can back ported to run on 8.0, some small modification needed.
http://www.dba-oracle.com/art_statspack.htm

Similar Messages

  • Statspack for slow database

    Guys,
    This is my first time i generated a statspack report as the users were complaining slow response from datbase.
    This report is taken when the reports that takes a long time were run.
    This is my statspack report.
    Message was edited by:
    jkestely

    Hi,
    FYI, some tuning guru's are developing an open source free tool to help analyze STATSPACK and AWR reports, which is helpful to beginners:
    http://www.statspackanalyzer.com
    Also, It may be be a good idea to publish your prouction SQL here (or anywhere else). I've seen DBA's get canned for disclosing proprietary details about their employers database . . . .
    Also, a short duration snapshot is not so bad, and I often do on minute snaps when diagnosing a system. Anyhow, here are some observations from SP analyzer:
    Hope this helps. . . .
    Donald K. Burleson
    Author of "Oracle 9i High Performance Tuning with STATSPACK" by Oracle Press
    You have enabled system-level parallel query. This can influence the cost-based optimizer to favor full-table scans over index access. Consider using parallel hints instead, or invoking parallelism at the session level.
    You may have an application issue causing excessive rollbacks with 47.62% rollbacks per transaction. Due to Oracle´s assumption of a commit, the rollback process is very expensive and should only be used when necessary. You can identify the specific SQL and user session that is executing the rollbacks by querying the v$sesstat view.
    Remember that some applications may automatically perform rollback operations (commit-then-rollback or rollback-then-exit) after each commit. If this is the case, speak with your application developers to find out if there is a way to disable this. While these "empty rollbacks" do not incur performance expense, it will case this metric to appear very high.
    You have high latch free waits of 1.3 per transaction. The latch free wait occurs when the process is waiting for a latch held by another process. Check the later section for the specific latch waits. Latch free waits are usually due to SQL without bind variables, but buffer chains and redo generation can also cause them.
    You have 27,717.0 consistent gets examination per second. "Consistent gets - examination" is different than regular consistent gets. It is used to read undo blocks for consistent read purposes, but also for the first part of an index read and hash cluster I/O.
    You have 203,044 table fetch continued row actions during this period. Migrated/chained rows always cause double the I/O for a row fetch and "table fetch continued row" (chained row fetch) happens when we fetch BLOB/CLOB columns (if the avg_row_len > db_block_size), when we have tables with > 255 columns, and when PCTFREE is too small. You may need to reorganize the affected tables with the dbms_redefintion utility and re-set your PCTFREE parameters to prevent future row chaining.
    You have 1.1 long table full-table scans per second. This might indicate missing indexes, and you can run plan9i.sql to identify the specific tables and investigate the SQL to see if an index scan might result in faster execution. If your large table full table scans are legitimate, look at optimizing your db_file_multiblock_read_count parameter.
    You have high small table full-table scans, at 1.7 per second. Verify that your KEEP pool is sized properly to cache frequently referenced tables and indexes.
    You are not using your KEEP pool to cache frequently referenced tables and indexes. This may cause unnecessary I/O. When configured properly, the KEEP pool guarantees full caching of popular tables and indexes. Remember, an average buffer get is often 100 times faster than a disk read.
    Any table or index that consumes > 10% of the data buffer, or tables & indexes that have > 50% of their blocks residing in the data buffer should be cached into the KEEP pool. You can fully automate this process using scripts.

  • Daily stats required from statspack for graph of month activity

    Hi All,
    I am trying to get a graph of index io on a daily basis, the trouble is the stats are cumulative since database startup and the database is rarely bounced. So what I actually get is a growing value for each day. I expect there is a simple way to correct my code in sqlplus. ( Otherwise PL/SQL beckons)
    Here is my code:
    Select to_char(snap_time, 'YYYY-MON-DD') "Day of Mnth",
    avg(time_waited_micro)/1000 "index wait duration"
    FROM
    perfstat.stats$system_event se,
    Perfstat.stats$snapshot sn
    WHERE se.snap_id = sn.snap_id
    and se.event='db file sequential read'
    and sn.snap_time between (sysdate - 50) and sysdate
    GROUP BY to_char(snap_time, 'YYYY-MON-DD')
    order by to_date(to_char(snap_time, 'YYYY-MON-DD'),'YYYY-MON-DD') ;
    Thanks in Advance

    Hi All,
    I am trying to get a graph of index io on a daily basis, the trouble is the stats are cumulative since database startup and the database is rarely bounced. So what I actually get is a growing value for each day. I expect there is a simple way to correct my code in sqlplus. ( Otherwise PL/SQL beckons)
    Here is my code:
    Select to_char(snap_time, 'YYYY-MON-DD') "Day of Mnth",
    avg(time_waited_micro)/1000 "index wait duration"
    FROM
    perfstat.stats$system_event se,
    Perfstat.stats$snapshot sn
    WHERE se.snap_id = sn.snap_id
    and se.event='db file sequential read'
    and sn.snap_time between (sysdate - 50) and sysdate
    GROUP BY to_char(snap_time, 'YYYY-MON-DD')
    order by to_date(to_char(snap_time, 'YYYY-MON-DD'),'YYYY-MON-DD') ;
    Thanks in Advance

  • Error in creating perfstat user for statspack

    Hi Friends,
    DB: 11.2.0.2, SE and 64 bit
    OS: RHEL 5.7
    My DB is on SE and hence i cannot use the diagonistic pack so when i am trying to use Statspack for the same, i am facing the following error when i am trying to create Perfstat user.
    SQL> @?/rdbms/admin/spcreate
    Choose the PERFSTAT user's password
    Not specifying a password will result in the installation FAILING
    Enter value for perfstat_password: perfstat
    perfstat
    Choose the Default tablespace for the PERFSTAT user
    Below is the list of online tablespaces in this database which can
    store user data. Specifying the SYSTEM tablespace for the user's
    default tablespace will result in the installation FAILING, as
    using SYSTEM for performance data is not supported.
    Choose the PERFSTAT users's default tablespace. This is the tablespace
    in which the STATSPACK tables and indexes will be created.
    TABLESPACE_NAME CONTENTS STATSPACK DEFAULT TABLESPACE
    INDUS_SML_DATA PERMANENT
    INDUS_SML_INDEX PERMANENT
    PERFSTAT PERMANENT
    SYSAUX PERMANENT *
    USERS PERMANENT
    Pressing <return> will result in STATSPACK's recommended default
    tablespace (identified by *) being used.
    Enter value for default_tablespace: PERFSTAT
    Using tablespace PERFSTAT as PERFSTAT default tablespace.
    Choose the Temporary tablespace for the PERFSTAT user
    Below is the list of online tablespaces in this database which can
    store temporary data (e.g. for sort workareas). Specifying the SYSTEM
    tablespace for the user's temporary tablespace will result in the
    installation FAILING, as using SYSTEM for workareas is not supported.
    Choose the PERFSTAT user's Temporary tablespace.
    TABLESPACE_NAME CONTENTS DB DEFAULT TEMP TABLESPACE
    TEMP TEMPORARY *
    Pressing <return> will result in the database's default Temporary
    tablespace (identified by *) being used.
    Enter value for temporary_tablespace: TEMP
    Using tablespace TEMP as PERFSTAT temporary tablespace.
    ... Creating PERFSTAT user
    ... Installing required packages
    ... Creating views
    ... Granting privileges
    NOTE:
    SPCUSR complete. Please check spcusr.lis for any errors.
    SQL>
    SQL> --
    SQL> -- Build the tables and synonyms
    SQL> connect perfstat/&&perfstat_password
    Connected.
    SQL> @@spctab
    SQL> Rem
    SQL> Rem $Header: rdbms/admin/spctab.sql /st_rdbms_11.2.0/1 2010/08/13 10:06:01 kchou Exp $
    SQL> Rem
    SQL> Rem spctab.sql
    SQL> Rem
    SQL> Rem Copyright (c) 1999, 2010, Oracle and/or its affiliates.
    SQL> Rem All rights reserved.
    SQL> Rem
    SQL> Rem NAME
    SQL> Rem spctab.sql
    SQL> Rem
    SQL> Rem DESCRIPTION
    SQL> Rem SQL*PLUS command file to create tables to hold
    SQL> Rem start and end "snapshot" statistical information
    SQL> Rem
    SQL> Rem NOTES
    SQL> Rem Should be run as STATSPACK user, PERFSTAT
    SQL> Rem
    SQL> Rem MODIFIED (MM/DD/YY)
    SQL> Rem kchou 08/11/10 - Bug#9800868 - Add Missing Idle Events for
    SQL> Rem 11.2.0.2for Statspack & Standby Statspack
    SQL> Rem kchou 08/11/10 - Bug#9800868 - Add missing idle events to 11.2.0.2
    SQL> Rem cgervasi 05/13/09 - add idle event: cell worker idle
    SQL> Rem cgervasi 04/02/09 - bug8395154: missing idle events
    SQL> Rem rhlee 02/22/08 -
    Rem cdgreen 03/14/07 - 11 F2SQL> Rem shsong 06/14/07 - Add idle events
    SQL> Rem cdgreen 02/28/07 - 5908354
    SQL> Rem cdgreen 04/26/06 - 11 F1
    SQL> Rem cdgreen 06/26/06 - Increase column length
    SQL> Rem cdgreen 05/10/06 - 5215982
    SQL> Rem cdgreen 05/24/05 - 4246955
    SQL> Rem cdgreen 04/18/05 - 4228432
    SQL> Rem cdgreen 03/08/05 - 10gR2 misc
    SQL> Rem vbarrier 02/18/05 - 4081984
    SQL> Rem cdgreen 10/29/04 - 10gR2_sqlstats
    SQL> Rem cdgreen 07/16/04 - 10gR2
    SQL> Rem cdialeri 03/25/04 - 3516921
    SQL> Rem vbarrier 02/12/04 - 3412853
    SQL> Rem cdialeri 12/04/03 - 3290482
    SQL> Rem cdialeri 11/05/03 - 3202706
    SQL> Rem cdialeri 10/14/03 - 10g - streams - rvenkate
    SQL> Rem cdialeri 08/05/03 - 10g F3
    SQL> Rem cdialeri 02/27/03 - 10g F2: baseline, purge
    SQL> Rem vbarrier 02/25/03 - 10g RAC
    SQL> Rem cdialeri 11/15/02 - 10g F1
    SQL> Rem cdialeri 09/27/02 - sleep4
    SQL> Rem vbarrier 03/20/02 - 2143634
    SQL> Rem vbarrier 03/05/02 - Segment Statistics
    SQL> Rem cdialeri 02/07/02 - 2218573
    SQL> Rem cdialeri 01/30/02 - 2184717
    SQL> Rem cdialeri 01/11/02 - 9.2 - features 2
    SQL> Rem cdialeri 11/30/01 - 9.2 - features 1
    SQL> Rem cdialeri 04/22/01 - Undostat changes
    SQL> Rem cdialeri 03/02/01 - 9.0
    SQL> Rem cdialeri 09/12/00 - sp_1404195
    SQL> Rem cdialeri 04/07/00 - 1261813
    SQL> Rem cdialeri 03/20/00 - Support for purge
    SQL> Rem cdialeri 02/16/00 - 1191805
    SQL> Rem cdialeri 01/26/00 - 1169401
    SQL> Rem cdialeri 11/01/99 - Enhance, 1059172
    SQL> Rem cmlim 07/17/97 - Added STATS$SQLAREA to store top sql stmts
    SQL> Rem gwood 10/16/95 - Version to run as sys without using many view
    SQL> Rem cellis.uk 11/15/89 - Created
    SQL> Rem
    SQL>
    SQL> set showmode off echo off;
    If this script is automatically called from spcreate (which is
    the supported method), all STATSPACK segments will be created in
    the PERFSTAT user's default tablespace.
    Using PERFSTAT tablespace to store Statspack objects
    ... Creating STATS$SNAPSHOT_ID Sequence
    Sequence created.
    create public synonym STATS$SNAPSHOT_ID for STATS$SNAPSHOT_ID
    ERROR at line 1:
    ORA-00955: name is already used by an existing object
    Disconnected from Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
    Kindly suggest on the same..
    BR

    @?/rdbms/admin/spdrop
    drop public synonym STATS$SNAPSHOT_ID;
    try again

  • HOW TO REVIEW STATSPACK REPORT

    dear all
    i have sucessfully done with statspack
    i know how to analyse with
    1.Instance Efficiency Percentages (Target 100%)
    2.Top 5 Timed Events
    3. Buffer Gets Executions Gets per Exec %Total Time
    4.tablespace
    but i want to explore more on statspack pls let me know how to analyse more on report
    please let me know where i can find it
    regards

    Sagar,
    Jonathan Lewis has discussed about what to read in statspack report and what not as serious of articles on his blog.
    http://jonathanlewis.wordpress.com/tag/oracle/statspack/
    For me, I felt, they are worth to read and understand.
    Jaffar

  • STATSPACK Performance Question / Discrepancy

    I'm trying to troubleshoot a performance issue and I'm having trouble interpreting the STATSPACK report. It seems like the STATSPACK report is missing information that I expect to be there. I'll explain below.
    Header
    STATSPACK report for
    Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
    ~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
              2636235846 testdb              1 30-Jan-11 16:10 11.2.0.2.0  NO
    Host Name             Platform                CPUs Cores Sockets   Memory (G)
    ~~~~ ---------------- ---------------------- ----- ----- ------- ------------
         TEST             Microsoft Windows IA (     4     2       0          3.4
    Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
    ~~~~~~~~    ---------- ------------------ -------- --------- ------------------
    Begin Snap:       3427 01-Feb-11 06:40:00       65       4.4
      End Snap:       3428 01-Feb-11 07:00:00       66       4.1
       Elapsed:      20.00 (mins) Av Act Sess:       7.3
       DB time:     146.39 (mins)      DB CPU:       8.27 (mins)
    Cache Sizes            Begin        End
    ~~~~~~~~~~~       ---------- ----------
        Buffer Cache:       192M       176M   Std Block Size:         8K
         Shared Pool:       396M       412M       Log Buffer:    10,848K
    Load Profile              Per Second    Per Transaction    Per Exec    Per Call
    ~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
          DB time(s):                7.3                2.0        0.06        0.04
           DB CPU(s):                0.4                0.1        0.00        0.00
           Redo size:            6,366.0            1,722.1
       Logical reads:            1,114.6              301.5
       Block changes:               35.8                9.7
      Physical reads:               44.9               12.1
    Physical writes:                1.5                0.4
          User calls:              192.2               52.0
              Parses:              101.5               27.5
         Hard parses:                3.6                1.0
    W/A MB processed:                0.1                0.0
              Logons:                0.1                0.0
            Executes:              115.1               31.1
           Rollbacks:                0.0                0.0
        Transactions:                3.7As you can see a significant amount of time was spent in database calls (DB Time) with relatively little time on CPU (DB CPU). Initially that made me think there were some significant wait events.
    Top 5 Timed Events                                                    Avg %Total
    ~~~~~~~~~~~~~~~~~~                                                   wait   Call
    Event                                            Waits    Time (s)   (ms)   Time
    log file sequential read                        48,166         681     14    7.9
    CPU time                                                       484           5.6
    db file sequential read                         35,357         205      6    2.4
    control file sequential read                    50,747          23      0     .3
    Disk file operations I/O                        16,518          18      1     .2
              -------------------------------------------------------------However, looking at the Top 5 Timed Events I don't see anything out of the ordinary given my normal operations. the log file sequential read may be a little slow but it doesn't make up a significant portion of the execution time.
    Based on an Excel/VB spreadsheet I wrote, which converts STATSPACK data to graphical form, I suspected that there was a wait event not listed here. So I decided to query the data directly. Here is the query and result.
    SQL> SELECT wait_class
      2       , event
      3       , delta/POWER(10,6) AS delta_sec
      4  FROM
      5  (
      6          SELECT syev.snap_id
      7               , evna.wait_class
      8               , syev.event
      9               , syev.time_waited_micro
    10               , syev.time_waited_micro - LAG(syev.time_waited_micro) OVER (PARTITION BY syev.event ORDER BY syev.snap_id) AS delta
    11          FROM   perfstat.stats$system_event syev
    12          JOIN   v$event_name                evna  ON  evna.name     = syev.event
    13          WHERE  syev.snap_id IN (3427,3428)
    14  )
    15  WHERE delta > 0
    16  ORDER BY delta DESC
    17  ;
    ?WAIT_CLASS               EVENT                                                                        DELTA_SEC
    Idle                      SQL*Net message from client                                                  21169.742
    Idle                      rdbms ipc message                                                            19708.390
    Application               enq: TM - contention                                                       7199.819
    Idle                      Space Manager: slave idle wait                                             3001.719
    Idle                      DIAG idle wait                                                             2382.943
    Idle                      jobq slave wait                                                            1258.829
    Idle                      smon timer                                                                 1220.902
    Idle                      Streams AQ: qmn coordinator idle wait                                      1204.648
    Idle                      Streams AQ: qmn slave idle wait                                            1204.637
    Idle                      pmon timer                                                                 1197.898
    Idle                      Streams AQ: waiting for messages in the queue                              1197.484
    Idle                      Streams AQ: waiting for time management or cleanup tasks                    791.803
    System I/O                log file sequential read                                                    681.444
    User I/O                  db file sequential read                                                     204.721
    System I/O                control file sequential read                                                 23.168
    User I/O                  Disk file operations I/O                                                     17.737
    User I/O                  db file parallel read                                                        14.536
    System I/O                log file parallel write                                                       7.618
    Commit                    log file sync                                                                 7.150
    User I/O                  db file scattered read                                                        3.488
    Idle                      SGA: MMAN sleep for component shrink                                          2.461
    User I/O                  direct path read                                                              1.621
    Other                     process diagnostic dump                                                       1.418
    ... snip ...So based on the above it looks like there was a significant amount of time spent in enq: TM - contention
    Question 1
    Why does this wait event not show up in the Top 5 Timed Events section? Note that this wait event is also not listed in any of the other wait events sections either.
    Moving on, I decided to look at the Time Model Statistics
    Time Model System Stats  DB/Inst: testdb  /testdb    Snaps: 3427-3428
    -> Ordered by % of DB time desc, Statistic name
    Statistic                                       Time (s) % DB time
    sql execute elapsed time                         8,731.0      99.4
    PL/SQL execution elapsed time                    1,201.1      13.7
    DB CPU                                             496.3       5.7
    parse time elapsed                                  26.4        .3
    hard parse elapsed time                             21.1        .2
    PL/SQL compilation elapsed time                      2.8        .0
    connection management call elapsed                   0.6        .0
    hard parse (bind mismatch) elapsed                   0.5        .0
    hard parse (sharing criteria) elaps                  0.5        .0
    failed parse elapsed time                            0.0        .0
    repeated bind elapsed time                           0.0        .0
    sequence load elapsed time                           0.0        .0
    DB time                                          8,783.2
    background elapsed time                             87.1
    background cpu time                                  2.4Great, so it looks like I spent >99% of DB Time in SQL calls. I decided to scroll to the SQL ordered by Elapsed time section. The header information surprised me.
    SQL ordered by Elapsed time for DB: testdb    Instance: testdb    Snaps: 3427 -3
    -> Total DB Time (s):           8,783
    -> Captured SQL accounts for    4.1% of Total DB Time
    -> SQL reported below exceeded  1.0% of Total DB TimeIf I'm spending > 99% of my time in SQL, I would have expected the captured % to be higher.
    Question 2
    Am I correct in assuming that a long running SQL that started before the first snap and is still running at the end of the second snap would not display in this section?
    Question 3
    Would that answer my wait event question above? Ala, are wait events not reported until the action that is waiting (execution of a SQL statement for example) is complete?
    So I looked a few snaps past what I have posted here. I still haven't determined why the enq: TM - contention wait is not displayed anywhere in the STATSPACK reports. I did end up finding an interesting PL/SQL block that may have been causing the issues. Here is the SQL ordered by Elapsed time for a snapshot that was taken an hour after the one I posted.
    SQL ordered by Elapsed time for DB: testdb    Instance: testdb    Snaps: 3431 -3
    -> Total DB Time (s):           1,088
    -> Captured SQL accounts for ######% of Total DB Time
    -> SQL reported below exceeded  1.0% of Total DB Time
      Elapsed                Elap per            CPU                        Old
      Time (s)   Executions  Exec (s)  %Total   Time (s)  Physical Reads Hash Value
      26492.65           29     913.54 ######    1539.34             480 1013630726
    Module: OEM.CacheModeWaitPool
    BEGIN EMDW_LOG.set_context(MGMT_JOB_ENGINE.MODULE_NAME, :1); BEG
    IN MGMT_JOB_ENGINE.process_wait_step(:2);END; EMDW_LOG.set_conte
    xt; END;I'm still not sure if this is the problem child or not.
    I just wanted to post this to get your thoughts on how I correctly/incorrectly attacked this problem and to see if you can fill in any gaps in my understanding.
    Thanks!

    Centinul wrote:
    I'm still not sure if this is the problem child or not.
    I just wanted to post this to get your thoughts on how I correctly/incorrectly attacked this problem and to see if you can fill in any gaps in my understanding.
    I think you've attacked the problem well.
    It has prompted me to take a little look at what's going on, running 11.1.0.6 in my case, and something IS broken.
    The key predicate in statspack for reporting top 5 is:
                      and e.total_waits         > nvl(b.total_waits,0)In other words, an event gets reported if total_waits increased across the period.
    So I've been taking snapshots of v$system_event and looking at 10046 trace files at level 8. The basic test was as simple as:
    <ul>
    Session 1: lock table t1 in exclusive mode
    Session 2: lock table t1 in exclusive mode
    </ul>
    About three seconds after session 2 started to wait, v$system_event incremented total_waits (for the "enq: TM - contention" event). When I committed in session 1 the total_waits figure did not change.
    Now do this after waiting across a snapshot:
    We start to wait, after three seconds we record a wait, a few minutes later perfstat takes a snapshot.
    30 minutes later "session 1" commits and our wait ends, but we do not increment total_waits, but we record 30+ minutes wait time.
    30 minutes later perfstat takes another snapshot
    The total_waits has not changed between the start and end snapshot even though we have added 30 minutes to the "enq: TM - contention" in the interim.
    The statspack report loses our 30 minutes from the Top N.
    It's a bug - raise an SR.
    Edit: The AWR will have the same problem, of course.
    Regards
    Jonathan Lewis
    Edited by: Jonathan Lewis on Feb 1, 2011 7:07 PM

  • Urgt:How to identify TOP 5 SQL using more CPU time  without using statspack

    How to identify the TOP 5 SQL queries which are consuming more CPU time during the timespan of 24 hours for entire database. There are N number of users who have issued sql queries, out of which few users have disconnected and few user are still connected to the database(I need to consider all sessions). My database version is 9.0.1. I don't want to use statspack. Is there any way to identify TOP 5 SQL consuming more CPU time without affecting the performance of the database. Can any one help me on this? Its urgent!!. I don't want to use statspack becasue it degrades the performance and i cannot afford to run it for 24 hours.

    You don't run statspack for 24 hours, that would infact be pointless...
    Run statspack for say a 10 or 15 minute window during a particular "busy" period on your database. If you run it for longer then all the useful data will have been "averaged out". You want a snapshot in time, not an average over the day.

  • PCTFREE too low for a table

    Hi,
    Looking at the Server Statistics in Toad, I see that I have "PCTFREE too low for a table". How do I know which table?
    Thanks,
    Johanna

    Don't know much about "Toad Statistics" but which version of database are you on?? and are you using LMT?? Run statspack for more accurate statistics and it will be helpfull to identify the root cause. Are you experiencing any performance problems??
    Daljit Singh

  • Which tool is used for Oracle 11g performance tuning?

    Hi all
    I used statspack for 9i's performance tuning.
    But with 11g R2 now I want to know which way are you using to do performance tuning?
    Statspack? OSW? RDA? ADDM? Or other ways?
    Thank you.

    schavali wrote:
    I would start with Automatic Workload Repository (AWR) reports to identify the bottleneck
    MOS Doc 390374.1 - Oracle Performance Diagnostic Guide (OPDG)
    MOS Doc 748642.1 - What is AWR( Automatic workload repository ) and How to generate the AWR report?
    HTH
    SriniThanks for your answer.
    To read the MOS documents I need a Oracle Customer ID , is that right ?
    (Where to get that ID ? Our company bought Oracle 10g without any Customer IDs in it )
    Best Wishes.

  • Problem with statspack

    I have created statspack for snap(0)
    while seeing report
    it ask begin and end_snap ids..... here what i have to specify
    plz anyone help me...

    hi,
    first connect to perfstat user with password
    2) sql> exec statspack.snap;
    pl/sql procedure successfully completed.
    => snap shot 1 or any other number will be created.
    then do some changes in the table like insert,update, delete, etc
    again use after sometime
    sql> exec statspack.snap
    pl/sql procedure successfully completed.
    now run the spreport.sql script
    it will show the snap shot number existing and ask for begin and end snapshot numbers
    you give the numbers generated.
    then give the path where the text file to be stored. You can statspack report.

  • Database Activity Tracking

    Hey Gang,
    I need to track the User and table activity. My goal is to find out what tables are static and which are not. Which user classes should be changed and how access should be assigned. This will also allow me to tune the database accordingly.

    Instead of trying to track individual user and table usage look at statspack for issues related to tuning the database. Generally unless you really did a poor job laying out and configuring your db to begin with the db does not need much tuning. The SQL is another story.
    Look into the following
    ver 9+ monitor command in DBA Admin, SQL manual
    ver all Audit command in DBA Admin manual, SQL manual
    ver 8.1+ Db event triggers (logon) DBA Concepts and Admin
    HTH -- Mark D Powell --

  • Problem with the Database....

    I have something wrong with my production Instance... The Database server CPU goes up to 70%. I executed some performance queries and I get the following ..
    BUFFER_GETS SQL_TEXT
    74434 SELECT count(*) FROM ...............
    74166 SELECT PAYROLL,.............
    71063 SELECT ........
    214 rows selected.
    I get 214 rows whose buffer_gets > 70000.... What steps we need to perform to tun the database?

    What you just did is the first step. You identified the top SQLs running on your system. You can use Oracle Top SQL, Precise, Quest Central or any other GUI tools to identify the top SQLs easily. Or use the built in STATSPACK for that.
    From there, you want to make sure that all SQLs are part of your application code, and are not developer queries used for reports (prepare a different database for that purpose). If the count(*) query is a valid statement, you should think if a materialized view is something you can work with instead of counting the data in each statement.
    In short:
    - Find the top ten queries in you DB.
    - Identify the execution plans for each statement. Resolve full table scans and bad joins. Make sure the data is accessed in an optimized way.
    - Look for a way to use mviews to summarize data in advance.
    Good luck,
    Idan Magal.

  • Thread 1 cannot allocate new log, sequence in Alert log

    Could someone help, I am getting the below message in my alert log
    System: AIX6.1 - Oracle 11r2
    GROUP#     THREAD#     MEMBER                                  ARCHIVED     STATUS             MB
    1     1     +DATA01/mydb/redolog_group1_member1     NO         INACTIVE             1536
    1     1     +DATA01/mydb/redolog_group1_member2     NO         INACTIVE             1536
    2     1     +DATA01/mydb/redolog_group2_member2     NO         CURRENT          1536
    2     1     +DATA01/mydb/redolog_group2_member1     NO         CURRENT          1536
    3     1     +DATA01/mydb/redolog_group3_member2     NO         INACTIVE             1536
    3     1     +DATA01/mydb/redolog_group3_member1     NO         INACTIVE             1536
    Tue Jul 10 18:37:48 2012
    Thread 1 advanced to log sequence 28831 (LGWR switch)
      Current log# 1 seq# 28831 mem# 0: +DATA01/mydb/redolog_group1_member1
      Current log# 1 seq# 28831 mem# 1: +DATA01/mydb/redolog_group1_member2
    Tue Jul 10 19:12:01 2012
    Thread 1 advanced to log sequence 28832 (LGWR switch)
      Current log# 2 seq# 28832 mem# 0: +DATA01/mydb/redolog_group2_member1
      Current log# 2 seq# 28832 mem# 1: +DATA01/mydb/redolog_group2_member2
    Tue Jul 10 19:39:00 2012
    Thread 1 cannot allocate new log, sequence 28833
    Private strand flush not complete
    Tue Jul 10 19:39:18 2012
      Current log# 2 seq# 28832 mem# 0: +DATA01/mydb/redolog_group2_member1
      Current log# 2 seq# 28832 mem# 1: +DATA01/mydb/redolog_group2_member2
    Tue Jul 10 19:41:21 2012
    Thread 1 advanced to log sequence 28833 (LGWR switch)
      Current log# 3 seq# 28833 mem# 0: +DATA01/mydb/redolog_group3_member1
      Current log# 3 seq# 28833 mem# 1: +DATA01/mydb/redolog_group3_member2
    Tue Jul 10 20:15:28 2012
    Thread 1 cannot allocate new log, sequence 28834
    Private strand flush not complete
      Current log# 3 seq# 28833 mem# 0: +DATA01/mydb/redolog_group3_member1
      Current log# 3 seq# 28833 mem# 1: +DATA01/mydb/redolog_group3_member2
    Tue Jul 10 20:16:21 2012Could an increase on the redo log file sizes solve this problem? Unfortunately I do not have a test platform, where I could have tested this.

    mseberg wrote:
    It just a warning. I would read these two notes:
    I suspect the OP is more worried about the apparent two minute gap between the "cannot switch" and the "advanced" at     19:39:18 and 19:41:12 respectively. Did the switch really have to wait for that two minutes, or is this a spurious threat caused by an anomaly in the writing of the alert log.
    As a cross check, I would examine v$event_histogram (or an AWR/Statspack for the interval) for time spent in the event "log file switch (private strand flush incomplete)". In prinicple I wouldn't expect to see waits longer than a few (less than 10) milliseconds; if the histogram shows long waits consistent with the alert log reports than I'd contact Oracle because something odd is happening.
    (Footnote - it's possible that the event times out after a limited interval, log file sync used to time out after 1 second and has recently changed to something shorter and adjustable, so 2 seconds may (for example) appear as 20 x 0.1 seconds.)
    Regards
    Jonathan Lewis

  • JDBC, SQL*Net wait interface, performance degradation on 10g vs. 9i

    Hi All,
    I came across performance issue that I think results from mis-configuration of something between Oracle and JDBC. The logic of my system executes 12 threads in java. Each thread performs simple 'select a,b,c...f from table_xyz' on different tables. (so I have 12 different tables with cardinality from 3 to 48 millions and one working thread per table).
    In each thread I'm creating result set that is explicitly marked as forward_only, transaction is set read only, fetch size is set to 100000 records. Java logic processes records in standard while(rs.next()) {...} loop.
    I'm experiencing performance degradation between execution on Oracle 9i and Oracle 10g of the same java code, on the same machine, on the same data. The difference is enormous, 9i execution takes 26 hours while 10g execution takes 39 hours.
    I have collected statspack for 9i and awr report for 10g. Below I've enclosed top wait events for 9i and 10g
    ===== 9i ===================
    Avg
    Total Wait wait Waits
    Event Waits Timeouts Time (s) (ms) /txn
    db file sequential read 22,939,988 0 6,240 0 0.7
    control file parallel write 6,152 0 296 48 0.0
    SQL*Net more data to client 2,877,154 0 280 0 0.1
    db file scattered read 26,842 0 91 3 0.0
    log file parallel write 3,528 0 83 23 0.0
    latch free 94,845 0 50 1 0.0
    process startup 93 0 5 50 0.0
    log file sync 34 0 2 46 0.0
    log file switch completion 2 0 0 215 0.0
    db file single write 9 0 0 33 0.0
    control file sequential read 4,912 0 0 0 0.0
    wait list latch free 15 0 0 12 0.0
    LGWR wait for redo copy 84 0 0 1 0.0
    log file single write 2 0 0 18 0.0
    async disk IO 263 0 0 0 0.0
    direct path read 2,058 0 0 0 0.0
    slave TJ process wait 1 1 0 12 0.0
    ===== 10g ==================
    Avg
    %Time Total Wait wait Waits
    Event Waits -outs Time (s) (ms) /txn
    db file scattered read 268,314 .0 2,776 10 0.0
    SQL*Net message to client 278,082,276 .0 813 0 7.1
    io done 20,715 .0 457 22 0.0
    control file parallel write 10,971 .0 336 31 0.0
    db file parallel write 15,904 .0 294 18 0.0
    db file sequential read 66,266 .0 257 4 0.0
    log file parallel write 3,510 .0 145 41 0.0
    SQL*Net more data to client 2,221,521 .0 102 0 0.1
    SGA: allocation forcing comp 2,489 99.9 27 11 0.0
    log file sync 564 .0 23 41 0.0
    os thread startup 176 4.0 19 106 0.0
    latch: shared pool 372 .0 11 29 0.0
    latch: library cache 537 .0 5 10 0.0
    rdbms ipc reply 57 .0 3 49 0.0
    log file switch completion 5 40.0 3 552 0.0
    latch free 4,141 .0 2 0 0.0
    I put full blame for the slowdown on SQL*Net message to client wait event. All I could find about this event is that it is a network related problem. I assume it would be true if database and client were on different machines.. However in my case they are on them very same machine.
    I'd be very very grateful if someone could point me in the right direction, i.e. give a hint what statistics should I analyze further? what might cause this event to appear? why probable cause (that is said be outside db) affects only 10g instance?
    Thanks in advance,
    Rafi.

    Hi Steven,
    Thanks for the input. It's a fact that I did not gather statistics on my tables. My understanding is that statistics are useful for queries more complex than simple select * from table_xxx. In my case tables don't have indexes. There's no filtering condition as well. Full table scan is what I actually want as all software logic is inside the java code.
    Explain plans are as follows:
    ======= 10g ================================
    PLAN_TABLE_OUTPUT
    Plan hash value: 1141003974
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 259 | 2 (0)| 00:00:01 |
    | 1 | TABLE ACCESS FULL| xxx | 1 | 259 | 2 (0)| 00:00:01 |
    In sqlplus I get:
    SQL> set autotrace traceonly explain statistics;
    SQL> select * from xxx;
    36184384 rows selected.
    Elapsed: 00:38:44.35
    Execution Plan
    Plan hash value: 1141003974
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 259 | 2 (0)| 00:00:01 |
    | 1 | TABLE ACCESS FULL| xxx | 1 | 259 | 2 (0)| 00:00:01 |
    Statistics
    1 recursive calls
    0 db block gets
    3339240 consistent gets
    981517 physical reads
    116 redo size
    26535700 bytes received via SQL*Net from client
    2412294 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    36184384 rows processed
    ======= 9i =================================
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | | | |
    | 1 | TABLE ACCESS FULL | xxx | | | |
    Note: rule based optimization
    In sqlplus I get:
    SQL> set autotrace traceonly explain statistics;
    SQL> select * from xxx;
    36184384 rows selected.
    Elapsed: 00:17:43.06
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE
    1 0 TABLE ACCESS (FULL) OF 'xxx'
    Statistics
    0 recursive calls
    1 db block gets
    3306118 consistent gets
    957515 physical reads
    100 redo size
    23659424 bytes sent via SQL*Net to client
    26535867 bytes received via SQL*Net from client
    2412294 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    36184384 rows processed
    Thanks for pointing me difference in table scans. I infer that 9i is doing single-block full table scan (db file sequential read) while 10g is using multi-block full table scan (db file scattered read).
    I now have theory that 9i is faster because sequential reads use continuous buffer space while scattered reads use discontinuous buffer space. Since I'm accessing data 'row by row' in jdbc 10g might have an overhead in providing data from discontinuous buffer space. This overhead shows itself as SQL*Net message to client wait. Is that making any sense?
    Is there any way I could force 10g (i.e. with hint) to use sequential reads instead of scattered reads for full table scan?
    I'll experiment with FTS tuning in 10g by enabling automatic multi-block reads tuning (i.e. db_file_multiblock_read_count=0 instead of 32 as it is now). I'll also check if response time improves after statistics are gathered.
    Please advice if you have any other ideas.
    Thanks & regards,
    Rafi.

  • Which SQL statement is he running?

    I have some oracle processes which are consuming a big fraction of the CPU resources and the load is so big that no users can connect (except with connect / as sysdba). Knowing their PID (from the UNIX top command), and connecting internally on Oracle, is there a way to know which statements are currently being performed by these users?
    NB: Database in question is Oracle 10g.

    Just because users cannot connect does not mean the problem is a "load" problem.
    What does v$session_wait show that connected sessions are waiting on? Are any sessions lock waited?
    If there are lockwaited sessions are any of the Oracle rdbms background sessions involved in the lock problem?
    In situations where people cannot connect or take five minutes to do so the problem usually comes down to improper configuration of the database, poor design of the most heavily hit section of an application, or your are especially lucky and have managed to hit a bug.
    In the absence of a locking problem or every session waiting on the same resouce then a statspack for a short duration is worth a shot (providing it will run).
    HTH -- Mark D Powell --

Maybe you are looking for