This section covers the following advanced concepts:
This section presents several recommendations related to using Oracle as your ZENworks database, including:
Renice the Redo log writer process in Linux DB servers: Change the Nice priority of the REDO LOG writer process to improve the performance:
Command : $ renice -20 -p <<spid>>
ZENworks give its best performance with the manual memory management. Total memory can be divided into 3 parts.
20% RAM for the Operating system
PGA: Can be calculated using the following SQL statement:
select&hwm*(2048576+a.value+b.value) pga_size from v$parameter a, v$parameter b
where a.name = 'sort_area_size' and b.name = 'hash_area_size'; hwm is the number of database connections.
SGA: Rest of the memory can be used as SGA.
db_writer_processes: Change this initialization parameter to increase the number of processes. For ZENworks, the number of db_writer_processes can be the number of hard disks.
UNDO tablespace should be large enough to handle the amount of UNDO generated by ZENworks. If both parameters are not configured properly, then a ORA-01555: Snapshot too old, rollback segment too small error will be raised.
To estimate the UNDO tablespace size and UNDO_RETENTION value, check the below links:
Oracle requires constant tuning and monitoring of various parameters to achieve the best throughput.
To monitor and trace the issues, Oracle provided the following tools:
TKProf
Statspack
Oracle Enterprise Manager - Tuning Pack (cost option)
Old UTLBSTAT.SQL and UTLESTAT.SQL - Begin and end stats monitoring
ADDM (Automated Database Diagnostics Monitor) introduced in Oracle 10g
Session trace:
To start a SQL trace for the current session, execute:
ALTER SESSION SET sql_trace = true;
ALTER SESSION SET tracefile_identifier = mysqltrace;
To stop SQL tracing for the current session, execute:
ALTER SESSION SET sql_trace = false;
Tracing an entire database:
To enable SQL tracing for the entire database, execute:
ALTER SYSTEM SET sql_trace = true SCOPE=MEMORY;
To stop SQL Tracing:
ALTER SYSTEM SET sql_trace = false SCOPE=MEMORY;
The following query gives the Folder location, File size and File name details of the Trace file:
SELECT * FROM V$PARAMETER WHERE NAME IN ('tracefile_identifier', 'user_dump_dest', 'max_dump_file_size', 'timed_statistics');
The default trace file name is “INSTANCE_PID_ora_TRACEID.trc”, where:
INSTANCE is the name of the Oracle instance.
PID is the operating system process ID (V$PROCESS.OSPID).
TRACEID is a character string of your choosing.
TKPROF is used for formatting a trace file into a more readable format for performance analysis.
tkprof filename1 filename2 [waits=yes|no] [sort=option] [print=n]
[aggregate=yes|no] [insert=filename3] [sys=yes|no] [table=schema.table] [explain=user/password] [record=filename4] [width=n]
TRCSESS allows trace information from multiple trace files to be identified and consolidated into a single trace file.
trcsess [output=output_file_name] [session=session_id] [clientid=client_id] [service=service_name] [action=action_name]
[module=module_name] [trace_files]
For more information, see: http://docs.oracle.com/cd/E11882_01/server.112/e16638/sqltrace.htm#PFGRF01020.
The scripts below should be created in the ZENworks user using SQL*PLUS or SQL Developer. This user should have alter session privileges. After the trace is completed, these triggers can be dropped or disabled.
CREATE OR REPLACE TRIGGER
ZENWORKS.after_logon_trg
AFTER LOGON ON
ZENWORKS.SCHEMA
DECLARE
V_NAME VARCHAR2(100);
BEGIN
DBMS_SESSION.set_identifier('ZENworks');
EXECUTE IMMEDIATE 'ALTER SESSION SET timed_statistics=TRUE';
EXECUTE IMMEDIATE 'ALTER SESSION SET MAX_DUMP_FILE_SIZE=UNLIMITED';
SELECT SYS_CONTEXT('USERENV','HOST') INTO V_NAME FROM dual;
EXECUTE IMMEDIATE 'ALTER SESSION SET TRACEFILE_IDENTIFIER='''||trim(substr(trim(v_name),1,10))||'_'||to_char(sysdate,'DD')||'''';
EXECUTE IMMEDIATE 'ALTER SESSION SET EVENTS ''10046 trace name context forever, level 12''';
END;
/
CREATE OR REPLACE TRIGGER ZENWORKS.before_logoff_trg
BEFORE LOGOFF
ON ZENWORKS.SCHEMA
BEGIN
EXECUTE IMMEDIATE 'ALTER SESSION SET timed_statistics=FALSE';
EXECUTE IMMEDIATE 'ALTER SESSION SET EVENTS ''10046 trace name context off''';
END;
/
Oracle provides V$ views to identify these bottlenecks and provide recommendations:
CPU usage related views:
V$SYSSTAT
V$SESSTAT
Memory Related views:
V$MEMORY_TARGET_ADVICE
V$SGA_TARGET_ADVICE
V$PGA_TARGET_ADVICE
You can use the queries in this section to identify highly used tables and segments.
select disk_reads, sql_text from v$sqlarea where disk_reads > 10000 order by disk_reads desc;
select buffer_gets, sql_text from v$sqlarea where buffer_gets > 200000 order by buffer_gets desc;
select * from V$segment_Statistics;
SELECT T.OWNER,T.TABLE_NAME,LR.VALUE+PR.VALUE AS TOTAL_READS FROM (SELECT owner,object_name,value FROM v$segment_statistics WHERE statistic_name='logical reads') lr,
(SELECT owner,object_name,value FROM v$segment_statistics
WHERE statistic_name='logical reads') pr, dba_tables t WHERE lr.owner=pr.owner AND lr.object_name=pr.object_name AND LR.OWNER=T.OWNER AND LR.OBJECT_NAME=T.TABLE_NAME
and T.owner like 'ZENWORKS%' ORDER BY 3 desc;
Oracle databases require constant tuning and monitoring of various parameters to get the best throughput. However, changing the configuration can have a negative impact.
Consider the following questions if you notice an impact to performance:
Has OPTIMIZER_MODE been changed in INIT<SID>.ORA?
Has the DEGREE of parallelism been defined or changed on any table?
Have the statistics changed?
Has the SPFILE/ INIT<SID>.ORA parameter, DB_FILE_MULTIBLOCK_READ_COUNT, been changed?
Has the INIT<SID>.ORA parameter, SORT_AREA_SIZE, been changed?
Have any other INIT<SID>.ORA parameters been changed?
Which tables are currently analyzed? Were they previously analyzed? (That is, was the query using RBO and now CBO?)
Have the tables been re-analyzed? Were the tables analyzed using an estimate or a compute? If estimate, what percentage was used?