Transcript What is a Standby Database

Oracle-käyttäjäpäivät 15.11.2001
Marko Hotti, Senior Sales Consultant 9i
Oraclen HA-ratkaisut
-DataGuard
-Real Application Clusters
-Online Backup/Recovery
Integrated Management
Toolset
Availability
Content
iCache
Forms
JServer
Apps
Parallel
Replication
Server
Failsafe
Standby Logminer
Intermedia
Text
Spatial
Express
Administration
Underlying
Framework
Apache
iFS
Warehouse
Builder
DBA Management Pack
Job
System
Event
System
Data
Security
Discovery
Collection
System
Management Packs
Busines
s logic
Apps
App Server
Oracle Enterprise Manager
Database
3
Problem Investigation
 I/O bottlenecks
 Excessive sorting to
disk
 Contention problems
 Space management
problems
 Instance configuration
problems
 User response time
problems
TOPsql
TOPsessions
Lock Monitor
Tablespace Map
Oracle Expert
Performance Overview
Database challenges
 Availability
 Availability
 Availability
 Scalability
 Manageability
Problems
 DBA drops the right table - wrong database
–
Mistake
 An OS bug scribbles on Oracle files
–
Physical corruption
 A batch update job is mistakenly run twice
–
Logical corruption
 Performance is bad, table has 1 million extents
–
–
Too small initial and next extents in design phase
Next offline time for db is within 8 months  must do it
online
Oracle9i - Architected for
Continuous Data Availability
System Failures
Unplanned
Downtime
Planned
Downtime
Data Failures &
Disasters
• Real Application Clusters
• Oracle Parallel Failsafe
• Data Guard
• Recovery Manager
Human Errors
• FlashBack Query
Routine Admin
• Dynamic Reconfiguration
Maintenance
• Online Redefinition

New Oracle9i High
Availability
Features
Data Recovery
–
–
–
–
–
–
–
 Online
Block level media
Operations
recovery
Trial Recovery
Tolerate corrupt
redo logs
Self-describing
backups
Policy based
automated backup
and recovery
Stored backup
configurations
Resumable backup
and restore
–
–
–
–
–
 Self-Service
Correction
– Flashback Query
Unlimited online
indexing
– Row level
operations
change history
Online table
 Miscellaneous
redefinition and
– Quiesce DB for
reorganization
maintenance
Dynamic buffer
– Online add
cache/shared
column/site for
pool resizing
replication
Online
groups
ANALYZE
– Offline
VALIDATE
Diagnostics
Online add and
remove CPU
New Oracle9i High
Availability Features
 Fast Fault Recovery  Data Protection
–
–
–
Minimal I/O crash
recovery
Time-based limit on
crash recovery
Resumable space
allocation
–
–
–
–
 Log Analysis
–
–
LogMiner
Query by content of
change
–
–
–
 Cluster
Recovery
Zero data loss
standby
Logical standby
Push-Button standby
automation
Delayed apply
standby
Network outage
tolerance
Near real-time
reporting
Tolerate corrupt logs
–
–
–
–
Non-disruptive
cluster
reconfiguration
Disk heartbeat
validates
network
heartbeat
Integrated
Oracle Parallel
Fail Safe
Multi-node Fail
Safe for
Windows 2000
Other Oracle HA Related
Features
 Unlimited Row Level





Locking
Read Consistency
Transparent
Application Failover
Recovery Manager
Tablespace Point-inTime Recovery
Database Security








Partitioned Tables
Parallel “Everything”
Advanced Queuing
Replication
Fail Safe
Database Resource
Manager
Read-Only
Tablespaces
Oracle Enterprise
Manager
Why Have a Standby Database
A standby database enables the creation
and maintenance of one or more
duplicate, or standby copies of your
production database
In the event of disaster at the production
site, the standby database can be
activated to take over the data serving
needs of the enterprise
What is a Standby Database
Primary
Site
Standby
Site
Log Data
Primary
Database




Standby
Database
Replica of Primary database
As primary database is modified, changes are propagated to
(possibly remote) standby databases
Primary database is open and active. Standby database is either
in recovery or open read-only
If something goes wrong with primary, activate standby
Benefits of Standby Databases
 Standby is application transparent
No application code changes are required
– Standby has minimal impact on the Primary
database
– Standby can keep up with very high transaction
rates
– Standby can be started/stopped while the primary
database is opened
 Standby database can be queried read-only
 One of the most popular high availability solutions
used by Oracle customers
–
Oracle9i Data Guard Protects
From All Causes of Data Loss
Hardware & System Error
49%
Human Error
Computer Viruses
36%
7%
Software Corruption
4%
Natural Disasters
3%
- The Disaster Recovery Journal 2001
Benefits of Standby Databases
 Standby databases have traditionally been
thought of as a disaster recovery solution
 Standby databases are useful for much more
–
Protect against user errors
 Standby can delay applying the changes to avoid errors that
may occur on the primary (note: changes are still shipped
normally)
–
Protect against data corruption
 File system corruptions, overwritten volumes do not
propagate
–
Reduces downtime for planned outages such as
operating system or hardware upgrades
Oracle9i Data Guard Broker
Provides monitoring and management capability
Standby
Site
Broker Agent
Broker Agent
Clients
Primary
Site
Log Data
Production
Database
Standby
Database
Broker: GUI Data Guard Manager or Command Line Interfaces
Data Guard Broker
 Unified, data-protected
configuration
 Monitoring, Control, and
Automation
Data
Guard
Manager
–
–
Job
Service
Event
Service
Security Discovery
Service
Service
Oracle Management Server
Command Line Interface
GUI Interface
 One-command failover
and switchover
 Configuration Wizard
makes setup easy
 Event Service used for
alerts
Protection from Human Error
Primary
Site
Standby
Site
Optional
Delayed
Apply
Production
Database
Standby
Database
Tunable delayed apply used to catch human errors
Oracle9i Data Guard Log Data Flow
Primary Standby
Site
Site
LGWR
Valid
Log
Records
Online
Log Files
Choose to affirm log
writes to disk
RFS
Synchronous
or Asynchronous
Oracle Net transport
Standby
Database
Standby
Redo
Log Files
ARCH
Optional
Delayed
Apply
MRP
Achieved
Log Files
Simultaneous log writes to online logs and standby logs
Flexible Data Availability
Modes
Protection Mode
Guaranteed
(Sync Log Writes)
Risk of Data Loss
Production Impact
Zero
High
(Handles Double Failures) (No Fallback Mode)
Instant
(Sync Log Writes)
Zero
(If only primary fails)
High
(Has Fallback Mode)
Rapid
(Asynchronous)
Minimal
Low
(Async Log Writes)
Delayed
High
(Archive Logs Only) (Current Online Log Lost)
Low
Instant Protection Mode
Primary
Site
Standby
Site
LGWR
Synch.
Network
Transport
Production
Database
Standby
Redo
Log Files
Online
Log Files
Fallback to Delayed Mode if standby down or unreachable
Guaranteed Protection Mode
No Unprotected Updates - Handles Double Failures
Primary
Site
Standby
Site
LGWR
Synchronous
Network
Transport
Production
Database
Standby
Redo
Log Files
Online
Log Files
Stalls primary if standby site down or unreachable
Rapid Protection Mode
Primary
Server
Production
Database
LGWR
Standby
Site
Network
Send
Async.
Net
Transport
Standby
Redo
Log Files
Online
Log Files
Log Writer returns control to primary after write to Network
Delayed Protection Mode
Primary
Site
Full
Online
Log Files
ARCH
Standby
Site
Archived
Log Files
Archived
Log Files
Changes propagated to standby site when online logs fill
Handling Gaps in Log Sequences
Primary
Site
FAL
Server
Achieved
Log Files
Standby
Site
Fetch Missing
Redo Log Files
Standby
Database
FAL
Client
RFS
MRP
Achieved
Log Files
The fetch archive log (FAL) server gets missing logs
More Than a Standby server
Standby
Server
Reporting
Tape
Tape
Standby
Database
Recovery
Manager
Backups
Tape
Standby database can be used to offload reporting
and backups using Recovery Manager
Oracle9i R2 Logical Standby
Log Data
Read
Only
Apply logs
Production
Database
Physical
Standby Database
Transform Log Files to
SQL statements
Apply SQL statements
Customers can optimize logical standby for
queries by adding new
indexes, views etc.
Read
Write
Logical
Standby Database
Oracle9i Data Guard Vs.
Clusters



Clusters address system issues
– Provide rapid and automatic recovery from failures that
don’t effect data (node death, DB crash, …)
– Can provide increased scalability
Data Guard addresses data issues
– Does not share disk nor run in lock step
– Can recover from human errors
– Can protect against data corruptions
– Can be remote
– Does not require any special hardware or cluster software
Standby and clusters are complementary
Oracle9i Data Guard
Vs. Remote Mirroring
 Remote Mirroring is Simple and Complete
Propagates changes to non-database data
 Data Guard is Resilient and Efficient
– Logical application of changes prevents many data
corruptions from propagating
– Standby allows change application to be delayed
– Standby performs better than remote mirroring since
only changes are transferred
–
 7x less data and 27x less I/O for Oracle Mail Database
–
Standby can be opened read-only while changes are
still propagating
Oracle9i Data Guard Summary
 Data Guard maintains a real-time copy of your
data to protect against all causes of data loss
–
Zero data loss failover without third party remote
mirroring
Efficiently propagates changes made to primary
database
On catastrophe, failover to a local or remote site
Leverages standby for backups, maintenance, and
reporting
Avoids propagating mistakes and corruption's
Simple to install, configure, manage, and maintain
–
Requires no change to the application
–
–
–
–
–
Summary
Oracle9i Data Guard
is the best solution in the industry
for protecting customer data
Any customer that is serious about
high availability should use Oracle9i
Data Guard
Oracle9i Real Application
Clusters
 Oracle9i Real Application Clusters is
designed for today’s most demanding
deployments
–
–
–
Server consolidation means very large
user populations
Critical e-business requires full time
service
Rapid growth shortens capacity
planning
Choosing A Deployment
Platform
A Single SMP
 Scales to multiple
CPUs
 Doesn’t scale
beyond one node
 Multiple single
points of failure
Users
Choosing A Deployment
Platform
Failover Clustering
 Fault tolerant
systems; highly
available
 Doesn’t scale
beyond one node
Users
Oracle Parallel Server
Grow your DATA
Grow your USERS
Grow PROCESSING
POWER
Users
Real Application Clusters
Grow your DATA
Grow your USERS
Grow PROCESSING
POWER
Cache Fusion:
Performance of a
SHARED CACHE
Users
Real Application Clusters
Architecture
Centralized
Management
Console
High Speed
Switch or
Interconnect
Network
Low Latency Interconnect
VIA or Proprietary
Users
No Single
Point Of Failure
Clustered
Database Servers
Hub or
Switch
Fabric
Mirrored Disk
Subsystem
Storage Area Network
Drive and Exploit
Industry Advances in
Clustering
Full Cache Fusion
 Oracle9i Cache Fusion increases performance and
scalability
–
–
Data is shipped directly over high speed interconnect
Minimize disk I/O
Node A
Node B
Request
Data Transfer
Database
buffers
Database
buffers
Database
Cache Fusion Manages
Inter Instance Block Requests
 Readers and writers
accessing instance
A gain access to
blocks in instance
B’s buffer cache
 All types of block
access
 Coordination by
Global Cache
Service
Request
for Block
Cache A
Block
Status in
Cache B
Read
Read
Write
Write
Read
Write
Read
Write
Resource Simplification and
Automation
 Automatic Global Cache Service configuration
–
–
No INIT.ORA parameters required
Improved inter-instance efficiency and memory
management for block transfers
 Dynamic resource affinity
–
–
GCS resources dynamically remastered reducing
overhead
Cache layer determines policy for remastering
Oracle9i Real Application
Clusters Scalability with SAP
83%
Scalability
Standard SAP SD Light Benchmark
1,200
1,200
1,000
800
# Users
868
600
400
480
200
0
Single Node
Running on Compaq 4 Processor Computers
2 Nodes
3 Nodes
Oracle9iDB Cluster
Performance
Oracle E-Business Suite 11i Scalability
4,000
3,500
3,648
3,000
2,500
# Users
2,000
1,900
1,500
1,000
500
1,026
0
Single Node
Running on HP Computers
2 Nodes
4 Nodes
89%
Scalability
Backup and Recovery
with RMAN &
Oracle9i
TM
Structures Required for
Recovery
Database
Needing
Recovery
Step 1: Rolling Forward
(Redo Log Applied)
also for Rollback segments
Database with
Committed and
Uncommitted
Transactions
Step 2: Rolling Back
(Rollback Segments Applied)
Uncommitted Transaction
Committed Transaction
Database with
Only Committed
Transactions
Backup and Recovery for VLDB
 VLDB systems impose stringent
requirements on backup and recovery
–
Operational complexity for backup and
recovery must be managed
–
Possibility of human error needs to be avoided
Backups must be scalable, reliable, and fully
utilize all available media hardware
Backups must be proportional to the size of
transactional changes, not to the size of
database
DIGITAL DATA STORAGE
–
–
–
Recovery time must be proportional to the
amount of data recovered
Database-Managed Backups
 Oracle9i provides integrated, automated,
database-managed backups
–
Location and content of backup files is managed by the
RDBMS
–
Recovery is aware of the available
backup files
 Operating system backups are still available
–
Operating system backups use the Oracle7TM style of
“BEGIN … END BACKUP” commands on a tablespace
Oracle9i Manages
Backup and Recovery
Enterprise
Manager
Third-Party
Tool
Recovery
Catalog
API
Recovery
Manager
 Fully managed by the
system
–
Recovery catalog
–
Minimizes operational errors
 Easy-to-use graphical
interface via Oracle9i
Enterprise Manager
Oracle9i
Server
TM
Disk
Tape
Disk
Tape
Disk
Tape
Disk
Tape
Tertiary Storage Subsystem:
EMC/Epoch, Legato, StorageTek, IBM, and HP
 Media management API
allows ISV tools to provide
tape management
Oracle9i Recovery Manager
Enterprise
Manager
Third-Party
Tool
API
Recovery
Catalog
Recovery
Manager
Oracle9i
server
Disk
Tape
Disk
Tape
Disk
Tape
Disk
Tape
Tertiary Storage Subsystem:
EMC/Epoch, Legato, StorageTek, IBM, and HP
 Oracle9i Recovery
Manager creates
backups and
restores/recovers from
them
 Oracle´9i Recovery
Manager reduces
human error in critical
situations
 Oracle9i Recovery
Manager tracks
backups and chooses
appropriate backups for
restore operations
Recovery Catalog
Enterprise
Manager
Third-Party
Tool
API
Recovery
Catalog
Recovery
Manager
Oracle9i
Server
Disk
Tape
Disk
Tape
Disk
Tape
Disk
Tape
Tertiary Storage Subsystem:
EMC/Epoch, Legato, StorageTek, IBM, and HP
 Oracle9i Recovery Manager
maintains a repository called
the Recovery Catalog
 Recovery Catalog is a set of
tables stored in a different
database than the database
being managed
 The Recovery Catalog contains
backup history
 A Recovery Catalog is not
necessary for operations;
recovery information can be
derived from control files
Oracle9i
Recovery Manager
Interfaces
Enterprise
Manager
Recovery
Catalog
API
Third-Party
Tool
 Oracle9i Recovery Manager
commands can be executed
via
–
Oracle9i
server
–
 Oracle9i Recovery Manager
provides wizards to assist in
creating backup and
recovery scripts
Recovery
Manager
Disk
Tape
Disk
Tape
Oracle Enterprise Manager
Command line mode
Disk
Tape
Disk
Tape
Tertiary Storage Subsystem:
EMC/Epoch, Legato, StorageTek, IBM, and HP
Oracle9i Recovery Manager Summary
Oracle9i Recovery Manager
Provides Support for:
 Managing operational complexity for
backup and recovery
 Making backups proportional to the size of
transaction changes, not to the size of
database
 Making the recovery time proportional to
the amount of data recovered
 Minimizing the possibility of human errors
Q U E S T I O N S
A N S W E R S
http://otn.oracle.com/deploy/availability