tuning – Technology Geek

I am going to talk about Some Oracle Statistics Table that will be useful for tuning your database , and gathering information about your database , these table are very useful

For example Dynamic Performance View :
**The below query will gives you the most sql statement taking more time in the CPU .
1-Select Sql_text , executions from v$sqlstats where cpu_time > 1000 ;
**Below Query Gives you some Details about Specific Machine
2-Select * from v$session where machine = ‘OSAMA_PC’ and where
logon_time > sysdate -1 ;
**finally , Lock in your database
3- select sid,ctime from v$lock where block > 0 ;

Statistics Tables are :
**Display System Wide Statistics :
V$Sysstat
V$Statname
V$Sesstat

**Display System Wide Statistics :

V$Sgastat
V$Event_name
V$system_event

**Display Session-Related Statistics
V$statname
V$Session
V$Session _Event
V$Session_Wait

**Display Service-Related Statistics
V$Service_stats
V$Services
V$Service_event
V$Service_wait_Class

**Display Information About Wait Class :

V$Session_Wait_Class
V$System_Wait_Class
V$Service_Wait_Class

**Display Session Wait

V$Session_Event : Session Wait By event for each session had to wait .
V$Session_Wait : Session Wait By Event For current active session that are waiting .
V$System_Event : Total waits for an event (All Session Together).

Wait Event : Information About session that had to wait or must wait for Different Reasons (V$Event_name).

Some Other Useful Tables :
-V$SQL
-V$SQLAREA

Thank You
Osama Mustafa

TKPROF And Oracle Trace Analysis

Posted on November 10, 2011December 23, 2018 by Osama Mustafa in Database

What is the TKPROF ??!!

The TKPROF program :

converts Oracle trace files into a more readable form. If you have a problem query you can user TKPROF to get more information.

But first you need to enable this tools since its unactivated in oracle to start using it follow the below steps :

1-ALTER SYSTEM SET TIMED_STATISTICS = TRUE;

2-we need table called PLAN_TABLE if its dosen’t found create it by following steps :

@ORACLE_HOME\rdbms\admin\utlxplan.sql
CREATE PUBLIC SYNONYM PLAN_TABLE FOR SYS.PLAN_TABLE;
GRANT SELECT, INSERT, UPDATE, DELETE ON SYS.PLAN_TABLE TO PUBLIC;

3-after doing the Previous steps , now you can use the amazing tools for example :

ALTER SESSION SET SQL_TRACE = TRUE;

SELECT COUNT(*)
FROM   dual;

ALTER SESSION SET SQL_TRACE = FALSE;

OR Another Way to trace file :

TKPROF

explain=user/password@service table=sys.plan_table

Output will be like :

********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

 SELECT COUNT(*)
 FROM   dual

call    count    cpu elapsed    disk   query current     rows
------- -----  ----- ------- ------- ------- -------  -------
Parse       1   0.02    0.02       0       0       0        0
Execute     1   0.00    0.00       0       0       0        0
Fetch       2   0.00    0.00       0       1       4        1
------- -----  ----- ------- ------- ------- -------  -------
total       4   0.02    0.02       0       1       4        1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 121  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE 
      1   TABLE ACCESS FULL DUAL

Thank you

Osama mustafa

Auditing Vs Performance on Oracle Database

Posted on July 28, 2011December 23, 2018 by Osama Mustafa in Database

You show this (part of a) AWR report to the DBA and he proudly concludes: disable auditing, it is killing the performance! And thus, quite often Oracle database auditing is not enabled. And here are the 3 main reasons why auditing is not turned on:

– DBAs, developers, etc. are not familiar with this feature: For those who are not familiar with auditing.

– Security is not considered important and necessary: For those who do not consider auditing important, I wish them luck. They are anyway not interested in what I have to say..

– Performance is being hit by enabling auditing: For the ones having issues with performance when auditing is enabled, here is something.

There are 3 major reasons why performance suffers when auditing is enabled: too much is being audited, AUD$ still hangs in the SYSTEM tablespace and surprise, surprise: the Oracle bugs.

1. Too much is being audited. If it is a new database, spend some time with all parties involved on what to audit. The reality however is something like that: go-live day is getting closer, oh do we have auditing enabled? How do you enable it, can you give me the command please. And it should not go like that. You first decide on the value of audit_trail and then audit what is really needed, do not audit repetitive commands that generate too many inserts into the AUD$ table for it can grow very fast indeed.

If it is an existing database, check first what is being audited. To find out system audited stuff run the following:

select * from DBA_PRIV_AUDIT_OPTS

union all

select * from DBA_STMT_AUDIT_OPTS;

Note that the difference between the two views above is very small and I have not found yet a place with explanation about the difference. The documentation says that DBA_STMT_AUDIT_OPTS describes the current system auditing options across the system and by user while DBA_PRIV_AUDIT_OPTS describes the current system privileges being audited across the system and by user. Puzzled? Me too.

For example, AUDIT SYSTEM belongs only to DBA_PRIV_AUDIT_OPTS while PROFILE, PUBLIC SYNONYM, DATABASE LINK, SYSTEM AUDIT, SYSTEM GRANT and ROLE belong only to DBA_STMT_AUDIT_OPTS.

On the other hand, CREATE PUBLIC DATABASE LINK, EXEMPT ACCESS POLICY, CREATE EXTERNAL JOB, DROP USER and ALTER DATABASE belong to both views, get it

For the auditing options on all objects, check DBA_OBJ_AUDIT_OPTS.

2. AUD$ still hangs in the SYSTEM tablespace. The system tablespace might be fragmented. Starting 11gR2, Oracle supports moving the AUD$ table out of the SYSTEM tablespace. But first, noaudit your policy or stop the auditing.

If still running 11.1.0 or a below, here is how to do it:

create tablespace AUDIT_DATA datafile ...;

create table AUDX tablespace AUDIT_DATA as select * from AUD$;

rename AUD$ to AUD$$;

rename AUDX to AUD$;

create index i_aud2 on AUD$(sessionid, ses$tid) tablespace AUDIT_DATA;

Remember to purge the records on regular basis. Do not just delete them but move them to a centralized auditing repository. Use the new DBMS_AUDIT_MGMT package. C In urgent cases, it is safe to run truncate table AUD$;

If you use FGA, remember to move also FGA_LOG$ away from the SYSTEM tablespace:

BEGIN

  DBMS_AUDIT_MGMT.set_audit_trail_location(

    audit_trail_type           => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,

    audit_trail_location_value => 'AUDIT_DATA');

END;

/

3. Oracle bugs. If you enable auditing you might get several bugs for free, most old ones should be fixed in 11.2.0.2, don’t know about the new ones