Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Agenda
This presentation summarizes some of the key diagnostic tools
that can be utilized when dealing with various Demantra errors
and problems.
Focus on the following areas:
Installation
Data model
Data loading (EP_Load and Integration Interfaces)
DB deadlocks and internal errors
Web Application troubleshooting:
Application memory errors
WS performance
Engine errors
Installation
The installer includes a configurable log file that can trace the
install process.
Data Model:
When having data model errors there are few traces that can be
analyzed:
An Export of the Data model
Review db_audit_log table for object changes made by the
upgrade.
LOG_DATA_MODEL table (an automatic LOG_IT log).
Data Loading:
Data loading includes 2 aspects Ep_Load stored procedures and
Integration Interface.
Each one of them can be monitored both for tracking errors as well
as tracking performance problems.
Ep_Load performance:
Count of data from the staging tables.
DB_Params table Ep_Load performance related parameters
Execute Call_DM_Build_Procedures after changing
parallelization parameters in DB_Params
DB HW definitions.
System Memory Disk IO and CPU Utilization monitoring- Either
system performance monitor or Linux top events
AWR /ADDM reports.
10
11
Engine errors:
Always provide a full Engine log (manager and engine) with
relevant logging option.
DB errors:
Engine log with Sql logging depends on where the DB error is Engine
manager or engine2k.
Processor error:
Engine log with DebugPro logging groups 100/110.
12
Engine performance:
AWR report
Check whether CPU Hyper threading enabled on Engine servers Disable if
its enabled
Engine Blades/Server + DB HW definitions.
DB/Engine Blades Memory Disk IO and CPU Utilization Monitoring - Either
system performance monitor or Linux top events.
13
Appedix
Configure auditing capabilities for BM configuration
changes:
Client expression Evaluator
14
15
log_date
session_id
os_user
host_name
module
user_id
object_type
object_name
old_value
new_value
Message
16
17
New file
created
18
19
20
21
Reviewing an AWR
Introduction
22
Reviewing an AWR
Important report sections
Report has a DB overview section
Lists the Top 5 waits Important for troubleshooting performance bottlenecks
23
Reviewing an AWR
SQL related sections
SQL Time Model statistics are important for SQL tuning
For better performance, you want DB CPU time to be high compared to the total SQL processing time
Time may be spent in parsing and IO, reducing these would typically be the primary focus of the tuning
exercise, which indicate IO issues
Efficiencies listed are typically close to 100%, with decent memory settings
24
Reviewing an AWR
Verify Memory Settings
PGA_Aggregate_Target
SGA_Target, SGA_MAX_SIZE
Efficiencies listed are typically close to 100%, with decent memory settings
Buffer Pool statistics (default, 16k) show, how efficiently buffer cache is being used - Can
be used for sizing
Low Hits indicate relevant memory settings need to be increased
25
Configure log
26
Export
27
LOG_IT:
LOG_IT is a logging mechanism for Demantra PL/SQL database
procedure code. It is analogous to log4j in Java.
LOG_IT can be used to trace a procedure flow, show variable
values, and record performance timing without having to run a
debugger.
LOG_IT is only available for a limited number of procedures (like
CHAINING , PROPORT,SIMULATION and more) but the list
keeps growing.
The available procedures are listed in the LOG_IT_PARAMS table.
28
LOG_IT (cont):
How to use LOG_IT:
The customer / support can enable the logging and the contents
of the log table.
Some important points to remember:
It uses a sequential key to write logs so you know exactly the order of the log.
Each main procedure writes to one log table. ie PROPORT writes to the
LOG_PROPORT table.
Sub procedures can be set up to write to the same log table.
INSERT_UNITS and DYN_INSERT_UNITS_BRANCH_ID both write to
LOG_INSERT_UNITS.
Log tables are usually overwritting each run (truncated).
Logging is enabled by setting the LOGGING_LEVEL to be greater than 0 for
a specific procedure in the LOG_IT_PARAMS table.
29
LOG_IT (cont):
Logging levels:
0 = No logging
1 = Procedure and sub procedure 'start' and 'end' logs. (SP,EP)
2 = Procedure progress markers (labels) (M)
3 = Procedure data , values held in specific variables (D) (also
temp procedures and tables are not dropped)
4 = Sub Procedure progress markers (labels) (M)
5 = Sub Procedure data , values held in specific variables (D)
6 = Procedure Data, values from with in loops (L)
7 = Sub procedure progress markers inside loops (M)
8 = Sub procedure data from inside loops (L)
30
LOG_IT (cont):
31
LOG_IT (cont):
The logging is enabled by setting the LOGGING_LEVEL above 0
for a specific procedure in the LOG_IT_PARAMS table. When
you commit the change to LOG_IT_PARAMS a trigger re-writes
and compiles the procedure LOG_IT which then contains a list of
procedures that it will process.
Note: before 7.3.1.1 -Only one LOG_IT_PARAMS row should be
changed between each commit because of the way the trigger
works.
Note- LOG_IT has some performance impact on the procedures it
logs, it should not be used at a normal production mode (all log
levels should be 0 for runtime operations).
32
33
34
35