Checking Database performance - DB02

Hi All,
I had a query with DB02,
1. In v3.5 when we go to transaction DB02 and check the Tables and Indexes tab and look into Detailed Analysis,
we can specify the desired object for which we need the analysis.
2. In v7.0 if we see transaction DB02 where can we find a similar option?
Basically i want to check the size of the objects in the system.
Thanks in Advance.
Shweta

Hi Shweta,
Please use T Code ST14 for getting the size of Objects.This can give you Top 30 desired objects ( DSO, PSA, Fact Table, E Table etc).
Moreover if you need to perform any analysis regarging the objects size in your system , by use of this T code you can schedule a job and outout of the job will give you desired result.You can also specify the date range in which you want to find the object size.
And if you need size of few tables only , you can get this by DB02->Space-->Tables and Indexes.
Give the required Tablename or table space name.In display options select Sort by size.
Hope this helps.
Vikram

Similar Messages

  • Database Performance (DB02) interperting

    Hi,
    I was going over DB02 T-code. I need to know, how to read the <b>missing indexes</b> info. I saw some info that if any indexes supplied by SAP in DDIC is deleted, this error may popup.
    Can anyone help me out, to get more detailed info and interpertations of DB02 monitoring.

    the  importart info that you can find on DB02, are:
    ->space critical obj (ex. no space in tablespace)
    ->refresh -->dbcheck&update (if is not scheluded in db13)
    ->check-->db e abap dictionary
    ->current/statistics/free of tablespace (ex to know the size and history of the tablespace)
    About the missing index, this monitor checks possible problems with the db index: if some index will not result, problably the search on db can be veeeery slow (ex.  the missing it's possible after a reorg).
    Regards
    Cristian

  • Database Performance Monitoring

    Hi,
    I use oracle 11.2.0.2.0,IBM AIX 6.1 operating System.
    My client/User complainting that the Application process is taking long time than usual,especially when they implementing some module in their applications.
    So when i closely monitoring my production(LIVE) database at the time of implementation,im unable to find any issues in DB side.So what are all the possibile areas to be focus on this situation?
    I really thinks it could also possible that the issue belongs to the Network failure/bandwith running slow.
    So what i really expect is ,Are they any monitoring tool or any trigger applicable/available for this scenario?
    Looking for Helpful Answers..
    Regards
    Faiz

    for information ,Here i post my actuall scenario
    Only in two out of 200 client branches ,the application performance was taking long time than usual,
    So that i enable trace (TKPROOF)for that corresponding sessions,also i generate and analyze AWR report durig that particular time,
    I found that no issues from database side.Later i come to know the actual issue was being in the Network side(i.e Network speed was very poor).
    So henceforth,i have been asked that if the problem persists again,i need to make ensure that the problem which not belongs to Network part before go and check
    database performance.
    So any tool or monitoring script or any packages available to make ensure that the actuall problem not belongs to Network related issues,befor check DB performance.

  • How to check the performance of the database instance in oracle apps 11i

    hii everybody,
    i want to know,how to check the performance of the database instance using oracle applications 11i.your help highly appreciated,thanks.

    Pl do not post duplicates - how to check the performance of the server in oracle applications 11i

  • Check the database ( Performance , tuning ,  . . . . . . . , etc  )

    Dears,,
    If i have running database and i need to make check health for it for performance , tuning , . . . , etc
    Is there any steps or advisors or documentations to go ahead with them enable me to check the database health.
    Thanks & Regards,,

    Eng.Mohammed wrote:
    Dears,,
    If i have running database and i need to make check health for it for performance , tuning , . . . , etc
    Is there any steps or advisors or documentations to go ahead with them enable me to check the database health.
    Thanks & Regards,,
    One way to check for performance issues is to see if your telephone is ringing. If no one is calling to complain, then you don't have any problems.
    I'm only half joking. Which means I am half serious. While you shouldn't take a completely cavalier attitude toward performance, neither do you want to fall victim to Compulsive Tuning Disorder.
    Start with the 2-Day DBA manual. Follow up with the tuning guide. Both at tahiti.oracle.com
    And remember, no matter how much effort you put into tuning, there will always be a "Top Five" wait events. Is it worth 40 man hours of effort to get a 75% reduction in average response time? Really? Even if the average response time is already 0.5 seconds? Is the user going to be able to perceive that 0.38 seconds improvement?

  • Database Performance Checks

    Oracle : 10.2.0.3
    OS : Linux 64 bit
    Issue : Slow performance at 11-30PM complained by client.
    Checks done :
    1. Ran AWR between 11 PM and 12 Noon.
    CPUs : 4 SGA Size : 2,000M (100%) Buffer Cache : 1,584M (79.2%) Shared Pool 1,129M (56.4%)
    ADDM suggest SGA_TARGET to increase from 2000MB to 2500MB.
    2. top 5 events
    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    db file scattered read            1,952,811       4,804      2   30.5   User I/O
    CPU time                                          3,448          21.9          
    db file sequential read             149,712       1,921     13   12.2   User I/O
    read by other session               293,022         877      3    5.6   User I/O
    log file sync                         9,920         157     16    1.0     Commit
              -------------------------------------------------------------       3. Stats are upto date.
    4. Index rebuild requirement is not there
    SQL> SELECT name,height,lf_rows,del_lf_rows,(del_lf_rows/lf_rows)*100 as ratio FROM INDEX_STATS;
    no rows selected5. Average 100 sessions will connect to the database
    6. Checked all logs fr any disconnection details
    7. Application is running from weblogic
    Questions : How to certify the performance is good or slow from the above observations. I am able to feel the statistics are the similar for the different periods where I ran AWR report.
    : Other than the user as a DBA what are the other checks can be done to monitor the performance

    It's difficult to use AWR or Statspack to "certify" database performance is good. It just depends what "performance is good" means.
    Most of the time it's application response time which is the right metric: database response time is only a part of application response time and AWR/Statspack cannot easily link database response time and application response time.
    [11.2 Concepts Guide Principles of Application Design and Tuning| http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/cncptdev.htm#CHDEHHIJ] says
    >
    Define clear performance goals and keep historical records of metrics
    An important facet of development is determining exactly how the application is expected to perform and scale. For example, you should use metrics that include expected user load, transactions per second, acceptable response times, and so on. Good practice dictates that you maintain historical records of performance metrics. In this way, you can monitor performance proactively and reactively (see "Performance Diagnostics and Tuning").

  • Regarding Database Performance

    Hi All,
    I have installed *10gR2 on RHEL4 (4GB -- RAM, space is enough)*. One application (oracle ucm) is running on that. Its contains apache and content server. After 2-3 weeks, developers were saying taking long time for opening url. So done gather database statistics (after that daily gathering db stats using scheduler). After that, it was working fine. Again after week they are having the prob. They are doing lot of dml on db. Checked in os level using top command. But oracle ( installed entire application as oracle) user is not consuming that much memory. set pga_aggregate_target to about 500M. Sga (sga_max_size --- 950M) is auto tuning. db is of size 8GB. workarea_policy_size is auto.
    Please suggest any solutions for improving database performance.
    Thanks,
    Manikandan.

    daily gathering db stats using scheduler)Done by default on V10+
    Please suggest any solutions for improving database performance.Ready, Fire, Aim!
    Is any OS resource the bottleneck; CPU, RAM, IO, network?
    During slow period what is reported by AWR?
    Please read these:
    When your query takes too long
    When your query takes too long ...
    How to Post a SQL statement tuning request
    HOW TO: Post a SQL statement tuning request - template posting
    Edited by: sb92075 on Jul 27, 2010 10:01 AM

  • Check database integrity throws 665 error when executing check database integrity task in SSMS.

    I have read all other cases that relate to this error and cannot get this to work. Running SQL Server 2012 sp1 on Windows server 2012 R2. Disk space and permissions are fine, but I get the error below when I try and use the check database integrity task
    within my maintenance plan on both system and user databases. I have researched this and fragmentation is not the issue. I'm lost at this point and would appreciate at least some steps to try. databases are not "read only" as I have read this may
    contribute to the problem. All other maintenance tasks run fine.
    Error message from SQL LOG
    Check Database integrity on Local server connection
    Databases: All system databases
    Task start: 2014-01-13T11:00:04.
    Task end: 2014-01-13T11:00:04.
    Failed:(-1073548784) Executing the query "DBCC CHECKDB(N'master', NOINDEX)
    " failed with the following error: "A database snapshot cannot be created because it failed to start.
    A database snapshot cannot be created because it failed to start.
    MODIFY FILE encountered operating system error 665(The requested operation could not be completed due to a file system limitation) while attempting to expand the physical file 'E:\\SQLdata\\MSSQL11.MSSQLSERVER\\MSSQL\\DATA\\master.mdf:MSSQL_DBCC9'.
    The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
    The database could not be exclusively locked to perform the operation.
    Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous
    errors for more details.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
    Error Message from Log File Viewer in SSMS:
    Source: Check Database Integrity Task      Executing query "USE [ReportServer]  ".: 50% complete  End Progress  Error: 2014-01-13 11:31:54.92     Code: 0xC002F210    
    Source: Check Database Integrity Task Execute SQL Task     Description: Executing the query "DBCC CHECKDB(N'ReportServer')  WITH NO_INFOMSGS  " failed with the following error: "A database snapshot cannot be created
    because it failed to start.  A database snapshot cannot be created because it failed to start.  MODIFY FILE encountered operating system error 665(The requested operation could not be completed due to a file system limitation) while attempting to
    expand the physical file 'E:\SQLdata\MSSQL11.MSSQLSERVER\MSSQL\DATA\ReportServer.mdf:MSSQL_DBCC9'.  The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not
    support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.  The database could not be exclusively locked to perform the operation.  Check statement aborted. The database could not be checked as a database
    snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details.". Possible failure reasons: Problems with
    the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.  End Error  Progress: 2014-01-13 11:31:54.93     Source: Check Database Integrity Task     
    Executing query "USE [ReportServerTempDB]  ".: 50% complete  End Progress  Error: 2014-01-13 11:31:55.02     Code: 0xC002F210     Source: Check Database Integrity Task Execute SQL Task    
    Description: Executing the query "DBCC CHECKDB(N'ReportServerTempDB')  WITH NO_INFOM..." failed with the following error: "A database snapshot cannot be created because it failed to start.  A database snapshot cannot be created because
    it failed to start.  MODIFY FILE encountered operating system error 665(The requested operation could not be completed due to a file system limitation) while attempting to expand the physical file 'E:\SQLdata\MSSQL11.MSSQLSERVER\MSSQL\DATA\ReportServerTempDB.mdf:MSSQL_DBCC9'. 
    The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.".
    Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.  End Error  Progress: 2014-01-13 11:31:55.02     Source:
    Check Database Integrity Task      Executing query "USE [AddressUpload]  ".: 50% complete  End Progress  Error: 2014-01-13 11:31:55.13     Code: 0xC002F210     Source:
    Check Database Integrity Task Execute SQL Task     Description: Executing the query "DBCC CHECKDB(N'AddressUpload')  WITH NO_INFOMSGS  " failed with the following error: "A database snapshot cannot be created because
    it failed to start.  A database snapshot cannot be created because it failed to start.  MODIFY FILE encountered operating system error 665(The requested operation could not be completed due to a file system limitation) while attempting to expand
    the physical file 'E:\SQLData\MSSQL11.MSSQLSERVER\MSSQL\DATA\database1.mdf:MSSQL_DBCC9'.  The database snapshot for online checks could not be created. Either th...  The package execution fa...  The step failed.

    ReFS is NOT supported in use with SQL Server 2012. Once such item, which you've stumbled upon is the fact that alternate streams and sparse files are not implemented in ReFS and thus these issues are caused. You *could* force the checkdb to execute by using
    WITH TABLOCKX but that'll require exclusive access to the database for the duration of the checkdb scan and that's not something I would advise to do.
    Sean Gallardy | Blog |
    Twitter

  • Database Performance Problem

    Hi,
    I am running Oracle10g in Windows and i have
    SGA - 289406976
    Fixed Size- 1248576
    Variable Size - 96469696
    Database Buffer - 184549376
    Redo Buffer - 7139328
    i am enclosing the init.ora file for better understanding
    # Cache and I/O
    db_block_size=8192
    db_file_multiblock_read_count=16
    # Cursors and Library Cache
    open_cursors=300
    # Database Identification
    db_domain=""
    db_name=orcl
    # Diagnostics and Statistics
    background_dump_dest=D:\oracle\product\10.2.0/admin/orcl/bdump
    core_dump_dest=D:\oracle\product\10.2.0/admin/orcl/cdump
    user_dump_dest=D:\oracle\product\10.2.0/admin/orcl/udump
    # File Configuration
    control_files=("D:\oracle\product\10.2.0\oradata\orcl\control01.ctl", "D:\oracle\product\10.2.0\oradata\orcl\control02.ctl", "D:\oracle\product\10.2.0\oradata\orcl\control03.ctl")
    db_recovery_file_dest=D:\oracle\product\10.2.0/flash_recovery_area
    db_recovery_file_dest_size=2147483648
    # Job Queues
    job_queue_processes=10
    # Miscellaneous
    compatible=10.2.0.1.0
    # Processes and Sessions
    processes=150
    # SGA Memory
    sga_target=287309824
    # Security and Auditing
    audit_file_dest=D:\oracle\product\10.2.0/admin/orcl/adump
    remote_login_passwordfile=EXCLUSIVE
    # Shared Server
    dispatchers="(PROTOCOL=TCP) (SERVICE=orclXDB)"
    # Sort, Hash Joins, Bitmap Indexes
    pga_aggregate_target=95420416
    # System Managed Undo and Rollback Segments
    undo_management=AUTO
    undo_tablespace=UNDOTBS1
    and the Total Physical Memory - 1037864
    Available - 206124
    kindly pls explain why the database is running slow?Pls tell me what parameter shuld i change in the init.ora so that the database performance increases?

    Is only Oracle running slow?
    Are some query running slow?
    I think that you might not be able to increase performance
    by changing only oracle parameter.
    What kind of programs and services are running on your Windows?
    Are they disturbing <s>Oracle sleeping</s> Oracle running?
    Please check them first.
    Oops, I'm not native, so I have mistake in using word.
    Sorry.
    Message was edited by:
            ushitaki

  • Database performance is poor after upgrading to 9i

    hi Guys
    My system was upgraded to 9i by the third party after that I took over from that and I am getting the continuous complaints regarding performance of Database.
    there are 150 Users who connects using citrix , from different locations and DB size is 20 GB.
    this is my Init Ora file
    # Cache and I/O
    db_block_size = 4096
    db_cache_size=591396864
    db_file_multiblock_read_count=16
    # Cursors and Library cache
    open_cursors=3000
    # Database Identification
    db_domain=""
    db_name=db_live
    # Diagnostics and Statistics
    background_dump_dest=D:\oracle\admin\db_live\bdump
    core_dump_dest=D:\oracle\admin\db_live\cdump
    timed_statistics=TRUE
    user_dump_dest=D:\oracle\admin\db_live\udump
    # File Configuration
    control_files=("D:\oracle\oradata\db_live\control01.ctl","D:\oracle\oradata\db_live\control02.ctl","D:\oracle\oradata\db_live\control03.ctl")
    # Instance Identification
    instance_name = live
    # Job Queues
    job_queue_processes=10
    # MTS
    dispatchers = "(PROTOCOL=TCP)"
    # Miscellaneous
    aq_tm_processes = 1
    compatible=9.2.0.0.0
    # Optimizer
    hash_join_enabled=TRUE
    query_rewrite_enabled=FALSE
    star_transfformation_enabled=FALSE
    # Pools
    java_pool_size=0
    large_pool_size=145752064
    shared_pool_size=197132288
    # Processes and Sessions
    processes=400
    # Redo Log and Recovery
    fast_start_mttr_target=300
    # Security and Auditing
    remote_login_passwordfile=EXCLUSIVE
    # SORT, HASH Joins, Bitmap Indexes
    pga_aggregate_target=525336576
    sort_area_size=524288
    # System Managed Undo and Rollback Segments
    undo_management=AUTO
    undo_retention=10800
    undo_tablespace=UNDOTBS1
    I feel SGA size and Sort area size are not correct if we increase the value of both will it solve some my problem
    Abhi

    I have run the some scripts to check the performance
    Here is the ouput :
    Hit Ratio Section
    =========================
    BUFFER HIT RATIO
    =========================
    (should be > 70, else increase db_block_buffers in init.ora)
    Buffer Hit Ratio
    77
    logical_reads phys_reads phy_writes BUFFER HIT RATIO
    89,127,477 20,013,061 1,556,989 78
    =========================
    DATA DICT HIT RATIO
    =========================
    (should be higher than 90 else increase shared_pool_size in init.ora)
    Data Dict. Gets Data Dict. cache misses DATA DICT CACHE HIT RATIO
    11,785,386 40,955 99
    =========================
    LIBRARY CACHE MISS RATIO
    =========================
    (If > .1, i.e., more than 1% of the pins resulted in reloads, then
    increase the shared_pool_size in init.ora)
    executions Cache misses while executing LIBRARY CACHE MISS RATIO
    9,845,481 11,831 .0012
    =========================
    Library Cache Section
    =========================
    hit ratio should be > 70, and pin ratio > 70 ...
    NAMESPACE Hit ratio pin hit ratio reloads
    SQL AREA 70 94 7,293
    TABLE/PROCEDURE 99 98 4,529
    BODY 87 68 9
    TRIGGER 99 99 0
    INDEX 98 98 0
    CLUSTER 98 98 0
    OBJECT 100 100 0
    PIPE 100 100 0
    JAVA SOURCE 100 100 0
    JAVA RESOURCE 100 100 0
    JAVA DATA 100 100 0
    =========================
    REDO LOG BUFFER
    =========================
    redo log space requests 37
    Pool's Free Memory
    POOL NAME BYTES
    shared pool free memory 8,075,760
    large pool free memory 127,547,048
    SQL Summary Section
    Tot SQL run since startup SQL executing now
    4,727,276 3,833
    Lock Section
    =========================
    SYSTEM-WIDE LOCKS - all requests for locks or latches
    =========================
    Processing Locks and Latches, please standby...
    User Lock Type Mode Held
    XR Null
    Temp Segment Row-X (SX)
    SYNTECH Transaction Exclusive
    SYNTECH DML Row-S (SS)
    SYNTECH Transaction Exclusive
    SYNTECH DML Row-X (SX)
    SYNTECH DML Row-X (SX)
    SYNTECH DML Row-X (SX)
    SYNTECH Transaction Exclusive
    SYNTECH DML Row-S (SS)
    =========================
    DDL LOCKS - These are usually triggers or other DDL
    =========================
    User Owner Name Type Mode held
    SYNTECH SYS DBMS_TRANSACTIO Table/Procedure/Type Null
    SYNTECH SYS DBMS_TRANSACTIO Table/Procedure/Type Null
    SYNTECH SYNTECH SW_LUC_SEQ Table/Procedure/Type Null
    SYNTECH SYS DBMS_UTILITY Body Null
    SYNTECH SYS DBMS_UTILITY Body Null
    SYSTEM SYSTEM SYSTEM 18 Null
    SYNTECH SYS DBMS_UTILITY Table/Procedure/Type Null
    SYNTECH SYS DBMS_UTILITY Table/Procedure/Type Null
    SYSTEM SYS DBMS_OUTPUT Body Null
    SUMMIT SUMMIT SUMMIT 18 Null
    SUMMIT SUMMIT SUMMIT 18 Null
    User Owner Name Type Mode held
    SUMMIT SUMMIT SUMMIT 18 Null
    SUMMIT SUMMIT SUMMIT 18 Null
    SUMMIT SUMMIT SUMMIT 18 Null
    SUMMIT SUMMIT SUMMIT 18 Null
    SUMMIT SUMMIT SUMMIT 18 Null
    SUMMIT SUMMIT SUMMIT 18 Null
    SUMMIT SUMMIT SUMMIT 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    User Owner Name Type Mode held
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    User Owner Name Type Mode held
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    User Owner Name Type Mode held
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    User Owner Name Type Mode held
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    User Owner Name Type Mode held
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    User Owner Name Type Mode held
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYNTECH SYNTECH 18 Null
    SYNTECH SYS DBMS_TRANSACTIO Body Null
    User Owner Name Type Mode held
    SYNTECH SYS DBMS_TRANSACTIO Body Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    User Owner Name Type Mode held
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    User Owner Name Type Mode held
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    User Owner Name Type Mode held
    SUMMIT SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    User Owner Name Type Mode held
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYSTEM SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    User Owner Name Type Mode held
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    User Owner Name Type Mode held
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SUMMIT SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    User Owner Name Type Mode held
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYNTECH SYS DATABASE 18 Null
    SYSTEM SYS DBMS_OUTPUT Table/Procedure/Type Null
    SYNTECH SYS DBMS_APPLICATIO Table/Procedure/Type Null
    SYNTECH SYS DBMS_APPLICATIO Table/Procedure/Type Null
    SYSTEM SYS DBMS_APPLICATIO Table/Procedure/Type Null
    SYNTECH SYS DBMS_APPLICATIO Body Null
    SYNTECH SYS DBMS_APPLICATIO Body Null
    SYSTEM SYS DBMS_APPLICATIO Body Null
    =========================
    DML LOCKS - These are table and row locks...
    =========================
    User Owner Name Mode held
    SYNTECH SYNTECH SYJOBTRN Row-S (SS)
    SYNTECH SYNTECH JCINVTRN Row-X (SX)
    SYNTECH SYNTECH JCBATCH Row-S (SS)
    SYNTECH SYNTECH JCIVBK Row-X (SX)
    SYNTECH SYNTECH JCWSTG Row-S (SS)
    SYNTECH SYNTECH JCINVC Row-X (SX)
    Latch Section
    if miss_ratio or immediate_miss_ratio > 1 then latch
    contention exists, decrease LOG_SMALL_ENTRY_MAX_SIZE in init.ora
    NAME miss_ratio immediate_miss_ratio
    library cache .04 .24
    virtual circuit queues .42 .00
    Rollback Segment Section
    if any count below is > 1% of the total number of requests for data
    then more rollback segments are needed
    CLASS COUNT
    free list 0
    undo block 1
    undo header 201
    system undo block 0
    system undo header 0
    Tot # of Requests for Data
    89,163,600
    =========================
    ROLLBACK SEGMENT CONTENTION
    =========================
    If any ratio is > .01 then more rollback segments are needed
    NAME WAITS GETS Ratio
    SYSTEM 0 625 .00000
    _SYSSMU1$                              31      67196    .00046                 
    _SYSSMU2$                               0      30118    .00000                 
    _SYSSMU3$                              18      75372    .00024                 
    _SYSSMU4$                               9      36534    .00025                 
    _SYSSMU5$                              28     173253    .00016                 
    _SYSSMU6$                               0      31350    .00000                 
    _SYSSMU7$                               0      28957    .00000                 
    _SYSSMU8$                              10      62721    .00016                 
    _SYSSMU9$                               3      44480    .00007                 
    _SYSSMU10$                             37      42719    .00087                 
    NAME WAITS GETS Ratio
    _SYSSMU11$                              0      20228    .00000                 
    _SYSSMU12$                              1      19168    .00005                 
    Session Event Section
    if average-wait > 20 then contention might exists
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS AVERAGE_WAIT
    latch free 5 1 1
    latch free 2 0 1
    buffer busy waits 362 0 1
    buffer busy waits 1 0 25
    buffer busy waits 217 0 1
    log buffer space 4 0 5
    log file switch completion 4 0 3
    log file switch completion 7 0 3
    log file sync 253 0 1
    log file sync 12 1 11
    log file sync 307 1 1
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS AVERAGE_WAIT
    db file sequential read 776 0 1
    db file sequential read 53 0 3
    db file sequential read 2,791 0 1
    db file sequential read 2,125 0 1
    db file sequential read 728 0 1
    db file sequential read 12 0 1
    db file sequential read 1,710 0 1
    db file sequential read 237 0 1
    db file sequential read 1 0 1
    db file sequential read 404 0 1
    db file sequential read 731 0 1
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS AVERAGE_WAIT
    db file sequential read 1 0 1
    db file sequential read 18 0 1
    db file sequential read 11 0 3
    db file sequential read 4 0 1
    db file sequential read 64 0 4
    db file sequential read 119 0 1
    db file sequential read 1 0 1
    db file sequential read 3 0 2
    db file sequential read 511 0 2
    db file sequential read 608 0 1
    db file sequential read 2 0 1
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS AVERAGE_WAIT
    db file sequential read 6 0 1
    db file sequential read 5 0 1
    db file sequential read 80 0 1
    db file sequential read 74 0 2
    db file sequential read 40 0 3
    db file sequential read 876 0 1
    db file sequential read 2,791 0 1
    db file sequential read 5 0 1
    db file sequential read 2 0 1
    db file sequential read 315 0 1
    db file scattered read 7 0 1
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS AVERAGE_WAIT
    db file scattered read 15 0 1
    db file scattered read 5 0 4
    db file scattered read 8 0 1
    db file scattered read 2 0 1
    db file scattered read 1 0 1
    db file scattered read 8 0 1
    db file scattered read 129 0 1
    db file scattered read 7 0 5
    db file scattered read 1 0 1
    db file scattered read 6 0 1
    db file scattered read 4 0 1
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS AVERAGE_WAIT
    db file scattered read 2 0 1
    db file scattered read 5 0 4
    db file scattered read 4 0 3
    db file scattered read 4 0 1
    db file scattered read 10,487 0 1
    db file scattered read 2 0 1
    db file scattered read 3 0 1
    db file scattered read 2 0 1
    db file scattered read 3 0 1
    db file scattered read 13 0 2
    db file scattered read 17 0 1
    EVENT TOTAL_WAITS TOTAL_TIMEOUTS AVERAGE_WAIT
    db file scattered read 2 0 1
    db file scattered read 3 0 1
    db file parallel read 32 0 1
    db file parallel read 1 0 2
    db file parallel read 29 0 2
    db file parallel read 38 0 1
    db file parallel read 24 0 2
    db file parallel read 52 0 1
    db file parallel read 33 0 1
    undo segment extension 9 9 2
    76 rows selected.
    Queue Section
    average wait for queues should be near zero ...
    PADDR Queue type # queued WAIT TOTALQ AVG WAIT
    00 COMMON 0 3195556 10,273,816 .311038858
    1DCB67CC DISPATCHER 0 14654 10,649,458 .001376032
    2 rows selected.
    Multi-threaded Server Section
    If the following number is > 1
    then increase MTS_MAX_SERVERS parm in init.ora
    Avg wait per request queue
    .311037586853935493365783330857794608413 hundredths of seconds
    1 row selected.
    If the following number increases, consider adding dispatcher processes
    Avg wait per response queue
    .001376211356617059142626710087687462551 hundredths of seconds
    =========================
    DISPATCHER USAGE
    =========================
    (If Time Busy > 50, then change
    MTS_MAX_DISPATCHERS in init.ora)
    NAME STATUS IDLE BUSY Time Busy
    D000 WAIT 3,506,156 89,948 2.501
    Shared Server Processes
    0
    high-water mark for the multi-threaded server
    MAXIMUM_CONNECTIONS MAXIMUM_SESSIONS SERVERS_STARTED SERVERS_TERMINATED
    SERVERS_HIGHWATER
    157 157 1721 1721
    17
    file i/o should be evenly distributed across drives.
    # Name STATUS BYTES PHYRDS PHYWRTS
    1 F:\ORACLE\ORADATA\DB_LIVE\SYST SYSTEM 262,144,000 16239 735
    2 F:\ORACLE\ORADATA\DB_LIVE\UNDO ONLINE 2,222,981,120 1962 191422
    3 F:\ORACLE\ORADATA\DB_LIVE\CONQ ONLINE 17,179,860,992 2361254 111110
    4 F:\ORACLE\ORADATA\DB_LIVE\INDX ONLINE 26,214,400 20 18
    5 F:\ORACLE\ORADATA\DB_LIVE\SUMM ONLINE 162,529,280 303 60
    6 F:\ORACLE\ORADATA\DB_LIVE\TOOL ONLINE 10,485,760 20 18
    7 F:\ORACLE\ORADATA\DB_LIVE\USER ONLINE 26,214,400 20 18
    8 F:\ORACLE\ORADATA\DB_LIVE\CONQ ONLINE 1,263,534,080 2254864 123356
    SYSTEM_STATISTIC VALUE
    CPU used by this session 639,861
    CPU used when call started 639,807
    CR blocks created 27,293
    Cached Commit SCN referenced 0
    Commit SCN cached 0
    DBWR buffers scanned 1,494,581
    DBWR checkpoint buffers written 240,048
    DBWR checkpoints 18
    DBWR cross instance writes 0
    DBWR free buffers found 1,319,309
    DBWR fusion writes 0
    SYSTEM_STATISTIC VALUE
    DBWR lru scans 1,210
    DBWR make free requests 1,210
    DBWR revisited being-written buffer 0
    DBWR summed scan depth 1,494,581
    DBWR transaction table writes 271
    DBWR undo block writes 191,098
    DDL statements parallelized 0
    DFO trees parallelized 0
    DML statements parallelized 0
    OTC commit optimization attempts 0
    OTC commit optimization failure - setup 0
    SYSTEM_STATISTIC VALUE
    OTC commit optimization hits 0
    PX local messages recv'd 0
    PX local messages sent 0
    PX remote messages recv'd 0
    PX remote messages sent 0
    Parallel operations downgraded 1 to 25 pct 0
    Parallel operations downgraded 25 to 50 pct 0
    Parallel operations downgraded 50 to 75 pct 0
    Parallel operations downgraded 75 to 99 pct 0
    Parallel operations downgraded to serial 0
    Parallel operations not downgraded 0
    SYSTEM_STATISTIC VALUE
    RowCR - row contention 0
    RowCR attempts 0
    RowCR hits 0
    SQL*Net roundtrips to/from client 20,533,267
    SQL*Net roundtrips to/from dblink 0
    Unnecesary process cleanup for SCN batching 0
    active txn count during cleanout 82,931
    background checkpoints completed 17
    background checkpoints started 18
    background timeouts 42,216
    branch node splits 222
    SYSTEM_STATISTIC VALUE
    buffer is not pinned count 58,473,081
    buffer is pinned count 58,622,335
    bytes received via SQL*Net from client 690,006,487
    bytes received via SQL*Net from dblink 0
    bytes sent via SQL*Net to client 102,210,355,400
    bytes sent via SQL*Net to dblink 0
    calls to get snapshot scn: kcmgss 8,092,887
    calls to kcmgas 130,839
    calls to kcmgcs 87,223
    calls to kcmgrs 0
    change write time 16,834
    SYSTEM_STATISTIC VALUE
    cleanout - number of ktugct calls 91,022
    cleanouts and rollbacks - consistent read gets 15,130
    cleanouts only - consistent read gets 16,490
    cluster key scan block gets 126,689
    cluster key scans 74,722
    cold recycle reads 0
    commit cleanout failures: block lost 708
    commit cleanout failures: buffer being written 59
    commit cleanout failures: callback failure 49
    commit cleanout failures: cannot pin 0
    commit cleanout failures: hot backup in progress 0
    SYSTEM_STATISTIC VALUE
    commit cleanout failures: write disabled 0
    commit cleanouts 488,120
    commit cleanouts successfully completed 487,304
    commit txn count during cleanout 36,303
    consistent changes 155,131
    consistent gets 74,645,555
    consistent gets - examination 16,776,826
    current blocks converted for CR 4
    cursor authentications 55,278
    data blocks consistent reads - undo records applied 154,868
    db block changes 12,976,485
    SYSTEM_STATISTIC VALUE
    db block gets 14,531,153
    deferred (CURRENT) block cleanout applications 137,895
    deferred CUR cleanouts (index blocks) 0
    dirty buffers inspected 9,671
    enqueue conversions 11,684
    enqueue deadlocks 0
    enqueue releases 184,564
    enqueue requests 184,686
    enqueue timeouts 94
    enqueue waits 1
    exchange deadlocks 0
    SYSTEM_STATISTIC VALUE
    execute count 7,319,198
    free buffer inspected 10,181
    free buffer requested 19,253,045
    gcs messages sent 0
    ges messages sent 0
    global cache blocks corrupt 0
    global cache blocks lost 0
    global cache claim blocks lost 0
    global cache convert time 0
    global cache convert timeouts 0
    global cache converts 0
    SYSTEM_STATISTIC VALUE
    global cache cr block build time 0
    global cache cr block flush time 0
    global cache cr block receive time 0
    global cache cr block send time 0
    global cache cr blocks received 0
    global cache cr blocks served 0
    global cache current block flush time 0
    global cache current block pin time 0
    global cache current block receive time 0
    global cache current block send time 0
    global cache current blocks received 0
    SYSTEM_STATISTIC VALUE
    global cache current blocks served 0
    global cache defers 0
    global cache freelist waits 0
    global cache get time 0
    global cache gets 0
    global cache prepare failures 0
    global cache skip prepare failures 0
    global lock async converts 0
    global lock async gets 0
    global lock convert time 0
    global lock get time 0
    SYSTEM_STATISTIC VALUE
    global lock releases 0
    global lock sync converts 0
    global lock sync gets 0
    hot buffers moved to head of LRU 1,334,001
    immediate (CR) block cleanout applications 31,620
    immediate (CURRENT) block cleanout applications 256,895
    immediate CR cleanouts (index blocks) 0
    index fast full scans (direct read) 0
    index fast full scans (full) 6,363
    index fast full scans (rowid ranges) 0
    index fetch by key 7,199,288
    SYSTEM_STATISTIC VALUE
    index scans kdiixs1 2,173,768
    instance recovery database freeze count 0
    kcmccs called get current scn 0
    kcmgss read scn without going to GES 0
    kcmgss waited for batching 0
    leaf node 90-10 splits 137
    leaf node splits 20,302
    logons cumulative 2,347
    logons current 86
    messages received 60,379
    messages sent 60,378
    SYSTEM_STATISTIC VALUE
    native hash arithmetic execute 0
    native hash arithmetic fail 0
    next scns gotten without going to GES 0
    no buffer to keep pinned count 5
    no work - consistent read gets 55,487,127
    number of map misses 0
    number of map operations 0
    opened cursors cumulative 692,633
    opened cursors current 11,134
    opens of replaced files 0
    opens requiring cache replacement 0
    SYSTEM_STATISTIC VALUE
    parse count (failures) 35
    parse count (hard) 222,131
    parse count (total) 740,269
    parse time cpu 71,868
    parse time elapsed 79,481
    physical reads 20,026,636
    physical reads direct 1,052,614
    physical reads direct (lob) 0
    physical writes 1,557,017
    physical writes direct 1,130,421
    physical writes direct (lob) 0
    SYSTEM_STATISTIC VALUE
    physical writes non checkpoint 1,477,234
    pinned buffers inspected 344
    prefetch clients - 16k 0
    prefetch clients - 2k 0
    prefetch clients - 32k 0
    prefetch clients - 4k 0
    prefetch clients - 8k 0
    prefetch clients - default 223
    prefetch clients - keep 0
    prefetch clients - recycle 0
    prefetched blocks 14,445,041
    SYSTEM_STATISTIC VALUE
    prefetched blocks aged out before use 2,636
    process last non-idle time ################
    queries parallelized 0
    recovery array read time 0
    recovery array reads 0
    recovery blocks read 0
    recursive calls 1,911,332
    recursive cpu usage 4,012
    redo blocks written 3,597,536
    redo buffer allocation retries 337
    redo entries 6,634,895
    SYSTEM_STATISTIC VALUE
    redo log space requests 37
    redo log space wait time 284
    redo log switch interrupts 0
    redo ordering marks 3
    redo size 1,772,883,980
    redo synch time 6,781
    redo synch writes 27,527
    redo wastage 11,115,384
    redo write time 16,597
    redo writer latching time 5
    redo writes 51,171
    SYSTEM_STATISTIC VALUE
    remote instance undo block writes 0
    remote instance undo header writes 0
    rollback changes - undo records applied 88,835
    rollbacks only - consistent read gets 12,179
    rows fetched via callback 3,423,058
    serializable aborts 0
    session connect time ################
    session cursor cache count 0
    session cursor cache hits 0
    session logical reads 89,176,705
    session pga memory 35,556,660
    SYSTEM_STATISTIC VALUE
    session pga memory max 132,532,528
    session stored procedure space 0
    session uga memory 50,817,520
    session uga memory max 497,741,936
    shared hash latch upgrades - no wait 2,566,917
    shared hash latch upgrades - wait 32
    sorts (disk) 130
    sorts (memory) 196,268
    sorts (rows) 18,962,940
    summed dirty queue length 376,151
    switch current to new buffer 33,449
    SYSTEM_STATISTIC VALUE
    table fetch by rowid 39,128,298
    table fetch continued row 556,214
    table lookup prefetch client count 0
    table scan blocks gotten 32,208,464
    table scan rows gotten 2,455,389,745
    table scans (cache partitions) 0
    table scans (direct read) 0
    table scans (long tables) 3,754
    table scans (rowid ranges) 0
    table scans (short tables) 124,879
    total file opens 0
    SYSTEM_STATISTIC VALUE
    total number of slots 0
    transaction lock background get time 0
    transaction lock background gets 0
    transaction lock foreground requests 0
    transaction lock foreground wait time 0
    transaction rollbacks 366
    transaction tables consistent read rollbacks 1
    transaction tables consistent reads - undo records appl 260
    user calls 10,869,191
    user commits 27,014
    user rollbacks 411
    SYSTEM_STATISTIC VALUE
    workarea executions - multipass 36
    workarea executions - onepass 218
    workarea executions - optimal 131,726
    workarea memory allocated 888
    write clones created in background 1
    write clones created in foreground 48

  • Database Performance Slow

    Hi to all,
    My database performance is suddenly going slow. My PGA Cahe hit percentage remain in 96%.
    I will list out the findidngs I found...
    Some tables were not analyzed since Dec2007. Some tables were never analyzed.
    (Will the tables were analyzed the performance will be improved for this scenario)
    PGA Allocated is 400MB. But till now the max pga allocated is 95MB since Instance started (11 Nov 08 - Instance started date).
    (I persume we have Over allocated PGA can i reduce it to 200MB and increase the Shared pool and Buffer Cache 100MB each?)
    Memory Configuration:
    Buffer Cache: 504 MB
    Shared Pool: 600 MB
    Java Pool: 24MB
    Large Pool: 24MB
    SGA Max Size is: 1201.72 MB
    PGA Aggregate is: 400 MB
    My Database resided in Windows 2003 Server Standard Edition with 4GB of RAM.
    Please give me suggestions.
    Thanks and Regards,
    Vijayaraghavan K

    Vijayaraghavan Krishnan wrote:
    My database performance is suddenly going slow. My PGA Cahe hit percentage remain in 96%.
    Some tables were not analyzed since Dec2007. Some tables were never analyzed.
    PGA Allocated is 400MB. But till now the max pga allocated is 95MB since Instance started (11 Nov 08 - Instance started date).
    (I persume we have Over allocated PGA can i reduce it to 200MB and increase the Shared pool and Buffer Cache 100MB each?)
    You are in an awkward situtation - your database is behaving badly, but it has been in an unhealthy state for a very long time, and any "simple" change you make to address the performance could have unpredictable side effects.
    At this moment you have to think at two levels - tactical and strategic.
    Tactical - is there anything you can do in the short term to address the immediate problem.
    Strategic - what is the longer-term plan to sort out the state of the database.
    Strategically, you should be heading for a database with correct indexing, representative data statistics, optimium resource allocation, minimum hacking in the parameter file, and (probably) implementation of "system statistics".
    Tactically, you need to find out which queries (old or new) have suddenly introduced an extra work load, or whether there has been an increase in the number of end-users, or other tasks running on the machine.
    For a quick and dirty approach you could start by checking v$sql every few minutes for recent SQL that might be expensive; or run checks for SQL that has executed a very large number of times, or has used a lot of CPU, or has done a lot of disk I/O or buffer gets.
    You could also install statspack and start taking snapshots hourly at level 7, then run off reports covering intervals when the system is slow - again a quick check would be to look at the "SQL ordered by .." sections of the report to the expensive SQL.
    If you are lucky, there will be a few nasty SQL statements that you can identify as responsible for most of your resource usage - then you can decide what to do about them
    Regarding pga_aggregate_target: this is a value that is available for sharing across all processes; from the name you've used, I think you may be looking at a figure for a single specific process - so I wouldn't reduce the pga_aggregate_target just yet.
    If you want to post a statspack report to the forum, we may be able to make a few further suggestions. (Use the "code" tags - in curly brackets { } to make the report readable in a fixed fontRegards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "The temptation to form premature theories upon insufficient data is the bane of our profession."
    Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear".

  • Database performance: avg. DB time is high

    My system is ECC6, MSSQL 2005 64 bit.
    I got a ERA report from my solution manager and it showed that we had a performance problem.
    Our performance overview is red because of the database performance.
    The avg. DB time in ms is 2768890,3. It's very high.
    Could you please help us on this issue?
    Leo

    Hai,
    There might number of reasons for high DB time.
    Check your I/O statistics, check your table structure, create Indexes if needed for efficient table access.
    You can schedule Optimize statistics in DB13 to get the statistics upto date which helps DB to get the best possible way to access data from your DB.
    Analyse the DB buffers and adjust them to get optimal performance. (Should be done by experienced DB admins).
    Check the below links....
    http://help.sap.com/saphelp_nw70/helpdata/EN/f2/31add7810c11d288ec0000e8200722/frameset.htm
    http://help.sap.com/saphelp_nw70/helpdata/EN/f2/31add7810c11d288ec0000e8200722/frameset.htm
    You can also take help from SAP to analyze your case.
    Regards,
    Yoganand.V

  • How to check the performance of a report

    plz tell me all the ways to check the performance of a report
    if u send me the step wise then it will be really helpful to me
    awaiting for u r reply

    I. Non Database Performance
    Dead Code (Program -> Check -> Extended Prog. Check) - unused subroutines appear as warnings under PERFORM/FORM interfaces. - unused variables appear as warnings under Field attributes. Transaction code is SLIN. This will also catch literals (section III below).
    When possible use MOVE instead of MOVE-CORRESPONDING (move bseg to *bseg or move t_prps[] to t_prps2[] if you want to copy entire table or t_prps to t_prps2 if you only want to copy header line.)
    Code executed more than once should be placed in a form routine.
    SORT and READ TABLE t_tab WITH KEY ... BINARY SEARCH when possible especially against non-buffered table (Data Dictionary -> Technical Info)
    SORT tables BY fields
    Avoid unnecessary moves to table header areas.
    Subroutine parameters should be typed for efficiency and to help prevent coding and runtime errors.
    II. Database Performanc
    Avoid ORDER BY unless there is index on the columns - sort internal table instead
    SELECT SINGLE when possible
    SELECT fields FROM database table INTO TABLE t_tab (an internal table) - Lengthy discussion.
    Views (inner join) are a fast way to access information from multiple tables. Be aware that the result set only includes rows that appear in both tables.
    Use subqueries when possible.
    "FOR ALL ENTRIES IN..." (outer join) are very fast but keep in the mind the special features and 3 pitfalls of using it.
    (a) Duplicates are removed from the answer set as if you had specified "SELECT DISTINCT"... So unless you intend for duplicates to be deleted include the unique key of the detail line items in your select statement. In the data dictionary (SE11) the fields belonging to the unique key are marked with an "X" in the key column.
    (b) If the "one" table (the table that appears in the clause FOR ALL ENTRIES IN) is empty, all rows in the "many" table (the table that appears in the SELECT INTO clause ) are selected. Therefore make sure you check that the "one" table has rows before issuing a select with the "FOR ALL ENTRIES IN..." clause.
    (c) If the 'one' table (the table that appears in the clause FOR ALL ENTRIES IN) is very large there is performance degradation Steven Buttiglieri created sample code to illustrate this.
    Where clause should be in order of index See example.
    This is important when there are multiple indexes for a table and you want to make sure a specific index is used. This will change when we convert from a "rules based" Oracle optimizer to a "cost based" Oracle optimizer. You should be aware of a bug in Oracle, lovingly referred to as the "3rd Column Blues". Click here for more information on indexes.
    Where clause should contain key fields in an appropriate db index or buffered tables. As long as we are using the Oracle Cost Based Optimizer, be aware fo the "Third Column Blues", an Oracle bug.
    Avoid nested SELECTs (SELECT...ENDSELECT within another SELECT...ENDSELECT). Load data in internal tables instead. See item 3 above.
    Use SQL statistical functions when possible (max, sum, ...)
    Delete all rows from a table. A where clause is mandatory. Specifying the client is the most efficient way.
    Put Check statements into where clause - caveat: Make sure that the index is still being used after you add the additional selection criteria. If the select statement goes from using an index to doing a db scan (reading each row in the database without going through an index) get it out of the where clause and go back to using "Check"!
    III. Literals
    Codes ('MD') should use contants (c_medical)
    Longer text should use text elements. Sample code is a good example because it uses the text element in conjunction with the hard coded text. This documents the text element and provides for the possibility of multi-language support.
    IV. Miscellaneous
    Use CASE statement instead of IF...ELSEIF when possible (It is only possible in equality tests)
    Nested If - encounter most likely to fail first (specific to general)
    And - encounter most likely to fail first (specific to general)
    OR's - encounter most likely to succeed first (general to specific)
    Variables should use Like when possible
    Subroutine usage - don't place decision to execute in the subroutine
    If not ( t_prps[] is initial ) (instead of describe table t_prps lines sy-tfill, if sy-tfill > 0...)
    New document types confirmed with the configuration team via MIT-ABAP mail list prior to coding a report to access the data.
    Dates need to be properly formatted using the user's default settings. For the explanation of the BDC example check out the developer's standards.
    regards,
    suryaprakash.

  • Checking the performance of Pl/SQL Procedure

    I have a PL/SQL procedure of 10,000 lines, & I dont have any Tool of performance checking only thing I have is SQL Client & database how whould I check the performance of the procedure

    Why do you want to check the performance? Have you indentified a specific problem?
    It is not easy to to "simply check the performance" of code. Let's say it has an elapsed execution time of 90 seconds. What does that tell you? Fast? Slow? Average? What does 90 seconds tell you about the resource utilisation? Nothing much - are resources being red lined for those 90 seconds or not?
    So unless there is a specific performance problem that has been diagnosed, e.g. the process uses too much PGA memory, you cannot really identify a performance problem.
    What you can do is use DBMS_PROFILE (Oracle supplied PL/SQL package) to profile the execution time of the code. This will tell you which pieces of the code are slower than others. This allows you to focus on area where possible optimisation can reduce overall execution time - or it could be that these areas are already optimised.
    What you can miss with this approach is a small loop that takes a few seconds to execute - less than 1% of the total elapsed execution time. But this loop can be very wrong and should have taken a few millisecs to do. A month later running against big production data volumes, this loop's runtime changes into minutes and over 50% of the overall execution time of the process.
    You may look at the FOR CURSOR FETCH loop and see that it has been optimised. Great, so you move on to look at the next piece of code. Only, there are other loop constructs that can be exponentially faster than this loop - like a bulk processing loop instead.
    You may look at a SQL that seems slow, but after investigation it seems to be optimal. And it could well be. But performance can be increased by 80% by not touching the SQL and instead changing the table's structure from a normal heap table to a ranged partitioned table.
    The bottom line is that there are no magic wands and crystal balls that can be used to check performance and tell you that "abc" is wrong. Tools can tell you what is slow, what is resource expensive - but it cannot tell you whether the code does what it is suppose to do in the best and most effective way. Only a programmer can. Which means that things like code reviews, design walk-thru's and so on, are critical pieces to ensure that the code is performant and can scale.

  • Oracle database performance after server reboot

    hi masters,
    this is not some kind of question, but a discussion. some statements come from our client that after weekly reboot of system, the oracle database performance is low for some time and increase after some time(say 2 days).
    i think it is but obvious, because at reboot oracle flushes all cache, and temporary space, so it need to re parse the sql statements and perform some disc I/O's so it might need some time and hence performance will degrade.
    but at the same time some people claim that after reboot their database performance is better than their normal performance for some days. it seems controversial that's why i am posting it here.
    what might be the reason behind this?? prior can have a valid reason of hard parsing, but what with second case??
    any clarification is highly appreciated...
    thank you
    regadrs
    VD

    Vikrant,
    You should wait for some time buddy, its weekend ;-) .
    this is not some kind of question, but a discussion. some statements come from our client that after weekly reboot of system, the oracle database performance is low for some time and increase after some time(say 2 days).i think it is but obvious, because at reboot oracle flushes all cache, and temporary space, so it need to re parse the sql statements and perform some disc I/O's so it might need some time and hence performance will degrade.
    >
    I would start from saying that checking the performance when the system just started, is a wrong approach. There would be lots of IOs , parsing, calculations(related to memory allocations) happening so there would be a delay/bad performance at that time. Very simple example can be parsing, another can be memory allocation. Oracle doesn't allocate the entire memory in the instance startup that is allocated to the memory areas but allocates just the bare minimum that is needed to start the instance and than after the startup, it keeps on allocating the memory. So surely enough, with the startup and after a while of it, there would be a different performance than that after the instance hsa already been started and the workload informations have started coming up.
    Its correct that Oracle would deallocate all the caches with the reboot as the instance is on the memory(physical) and with the reboot , that would be flushed including the SGA which is allocated over it. Temporary tablespace is now not freed with the reboot. I guess its a rather illogical thing to do but that's what is there now. Oracle keeps the segment allocated even after the reboot is issued, hence the reason for larger temporary tablespaces.
    >
    but at the same time some people claim that after reboot their database performance is better than their normal performance for some days. it seems controversial that's why i am posting it here.
    what might be the reason behind this?? prior can have a valid reason of hard parsing, but what with second case??
    >
    This should not come as a surprise once we understand what might be happening with this process. Assume a situation where you have undersized caches. For example, shared pool . which is very heavily used for database , if this is going to be undersized and you are not using automatic memory management, you won't be enjoying the dynamic management of this parameter. Now, if you do lots of parsing , thanks to your wrongly written queries, you would eventually end up filling up shared pool to its max thus leaving no space for incoming new hard parsed cursors. Here , if you can't manage to add more memory to add to it, the only solution left would be to flush the shared pool( as good as rebooting the db because this would do the same) and than make space for the new cursors. The performance is going to be better becausethe cursors would not be getting flushed out immediately and will be kept in the shared pool as long as its not filled up again.Once you have reached to limit of it, again there would be performance benefit. So there are always odds added to the statements like this that I rebuilt my index , I got better, I rebooted my server, my querie are much faster now. Most of the time when these kind of statements are given, they are based on what we have seen, without understading what actually might have happened. So I would siggest to hear the statement but not take them as a rule of thumb to follow.
    Hope this all makes some sense for you and would help somewhat.
    Aman....

Maybe you are looking for