Oracle Database 11g Real Application Testing
Oracle Database 11g Real Application Testing
2
Real Application Testing
• Value
• Reduces testing cost Deploy
• Improves testing quality
• Business Benefit Test
Change
• Faster technology adoption
• Lower risk
Remediate
3
Database Replay
4
The Need for Database Replay
5
Database Replay
• Recreate actual production database workload in test
environment
• Identify, analyze and fix potential instabilities before making
changes to production
• Capture Workload in Production
• Capture full production workload with real load &
concurrency info
• Move the captured workload to test system
• Replay Workload in Test
• Make the desired changes in test system
• Replay workload with production load & concurrency
• Honor commit ordering
• Analyze & Report
• Errors
• Data divergence Analysis & Reporting
• Performance divergence
6
Database Replay: Supported Changes
…
Changes
Unsupported
Middle Tier
Changes Supported
•Database Upgrades, Patches
•Schema, Parameters Recording of
External Client
•RAC nodes, Interconnect Requests
•OS Platforms, OS Upgrades Storage
•CPU, Memory
•Storage
•Etc.
7
Comparison of LoadRunner & DB Replay
Testing e-Business Suite
80
80
Time Taken (Days)
60
40
24
20 20
20 5 LoadRunner
4 0 0 2 5 DB Replay
0
Install & Setup Understand Identify Key Generate Run Test
Application Transactions Workload
Usage
8
Why DB Replay?
From: To:
Artificial workloads Production workloads
9
Database Replay Overview
10
Step 1: Workload Capture
• All external client requests Production System
captured in binary files
Client Client Client
• System background, internal …
activity excluded
File System
• Minimal performance
overhead for capture Middle Tier
Storage
11
Capture Options
• Workload can be filtered to customize what is captured
• Filter Types
• Inclusion Filters: Specifies which sessions should be captured
• Exclusion Filters: Specifies which sessions should NOT be
captured
• Filter Attributes: Workload capture can be filtered using any of the
following session attributes
• User
• Program
• Module
• Action
• Service
• Session ID
• Workload capture can be run on-demand or scheduled to run at
later time
12
Step 2: Process Workload Files
• Setup test system
• Logically similar data as production Test System
• Use RMAN to physically restore
production db from backup
• Use Snapshot standby
• Use imp/exp, Data Pump, etc. File 1
File 1
• Processing transforms captured
File 2
data into replay files and
generates necessary meta-data File 2
…
• Must be done on same version of
…
database as replay system File n
13
Step 3: Replay Workload
• Replay Driver is a special client
program that consumes
processed workload and sends Replay Driver
requests to the replay system
Replay Replay
Client Client
• Replay requests preserve
timing, concurrency and
dependencies seen on the
capture system File 1
14
Replay Options
• Synchronized Replay
• Workload is replayed in full synchronized mode
• Exact same concurrency and timing as production workload
• Transaction commit order is honored
• Ensures minimal data divergence
• Unsynchronized Replay
• Workload can be replayed in unsynchronized mode
• Useful for load/stress testing
• High Data Divergence
• Three (3) parameters provided to control degree of synchronization
• Think time synchronization
• Commit order synchronization
• Connect (logon) time synchronization
15
Replay Options
• Unsynchronized Replay Parameters
• Think time synchronization
• Controls think time between database calls
• Auto (Default): Adjusts think time so as to maintain captured request rate
• Percentage
• 0% No think time, highest possible request rate
• <100% Higher request rate
• 100% Exact think time
• >100% Lower request rate
• Commit order synchronization
• Controls commit order between transactions
• In asynchronous mode, commit order not honored – transactions are
committed as soon as commit call is issued
• Connect (logon) time synchronization
• Controls when sessions are created
• 0%: All session are connected immediately
• 100% (Default): Sessions connect at same time as in captured system
16
Replay Options
• Number of Replay Clients
• Configurable by user
• Client Calibration Advisor recommends number of replay
clients needed for specific workload
• Replay clients are multithreaded clients that can drive
multiple workload sessions each
17
Analysis & Reporting
18
Workload Types Supported
Supported
• All SQL (DML, DDL, PLSQL) with practically all types of binds
• Full LOB functionality (Cursor based and direct OCI)
• Local transactions
• Login/Logoffs
• Session switching
• Limited PL/SQL RPCs
Limitations
• Direct path load, import/export
• OCI based object navigation (ADTs) and REF binds
• Streams, non-PL/SQL based AQ
• Distributed txns, remote describe/commit operations
• Flashback
• Shared Server
19
EM Interface: DB Replay Summary
20
Best Practices
• Capture
• Provide adequate disk space for captured workload (binary files)
• Database restart (Optional): Recommended to minimize divergence during
replay
• For RAC, use shared file system
• Test System Setup
• Ensure data in test is identical to production as of capture start time to
minimize data divergence during replay
• Use RMAN backup/restore or Snapshot Standby feature to setup test system
• Reset system clock to same time as production if application logic involves
SYSDATE usage
• Process Workload
• Processing workload has performance overhead and can possibly take a
long time
• Process workload on test system after rather than production system
• Replay
• Use Client Calibration Advisor to identify number of replay clients needed to
replay workload properly
21
DB Replay Security Model
• Any “Non-SYS” user with DBA Role
• SYSDBA role is not mandatory
• Does not have to be the user whose workload is captured
• “Execute” privileges on DBMS_WORLOAD_CAPTURE/REPLAY
procedures
• DBMS_WORKLOAD_CAPTURE
• START_CAPTURE, FINISH_CAPTURE, REPORT(), ADD_FILTER,
DELETE_FILTER
• DBMS_WORKLOAD_REPLAY
• PROCESS_CAPTURE,INITIALIZE_REPLAY, PREPARE_REPLAY(),
START_REPLAY(), CANCEL(), REPORT, ADD_FILTER,
REMAP_CONNECTION
22
SQL Performance
Analyzer (SPA)
23
SQL Performance Analyzer (SPA)
Capture SQL
… … Use SQL Tuning
Oracle DB Advisor to tune
regression
Storage
24
SPA Benefits
25
SQL Performance Analyzer Workflow
26
Step 1: Capture SQL Workload
Production Database
• SQL tuning set’s filtering and ranking
capabilities filters out undesirable SQL
27
Step 2: Move SQL Workload to Test System
Cursor Cache
28
Step 3: Execute SQL Before Making Change
29
Step 4: Execute SQL After Making Change
• Manually implement the planned
SQL Tuning Set
change:
Fetch Next SQL • Database upgrade
• Implementation of tuning recommendations
• Schema changes
• Statistics gathering
• Database parameter changes,
Test Execute
• OS/hardware changes, etc.
30
Step 5: Compare & Analyze Performance
• Compare performance using different
Completed Completed
metrics
• Elapsed Time
nge Chang
e
ef or e Cha After • Parse Time
B
• Execute Elapsed Time
• Execute CPU Time
• Buffer Gets
• Disk Reads
Compare • Disk Writes
SQL Performance • Optimizer Cost
• SPA Report shows impact of change
for each SQL
• Improved SQL
Analysis Report
• Regressed SQL
• Unchanged SQL
• SQL with Errors
• Tune regressed SQL using SQL
Tuning Advisor
• Analysis results can be used to seed
SQL Performance Analyzer SQL Plan Management repository
31
EM Interface: SPA Report
32
SPA Security Model
33
Q&
A