Oracle数据库高可用性最佳实践指南

需积分: 10 179 浏览量更新于2024-07-29 收藏 4.2MB PDF 举报

"Oracle High Availability Architecture and Practices Manual" Oracle数据库的高可用性架构与实践手册是一本详尽的指南，涵盖了Oracle在10g Release 2 (10.2)版本中的高可用性解决方案。这本书深入讲解了如何管理和配置Oracle环境以确保其高度可用，同时提供了监控的最佳实践。书中涉及的关键技术包括Real Application Clusters (RAC)、Data Guard、Automatic Storage Management (ASM)等。 1. **Real Application Clusters (RAC)**：RAC是Oracle提供的一个关键组件，它允许多个实例在同一集群的不同节点上共享同一数据库。RAC通过消除单点故障，提高了系统的可用性和性能，因为当一个节点或实例出现故障时，其他节点可以接管工作。 2. **Data Guard**：Data Guard是一种用于保护数据库免受数据丢失和计划内/计划外停机的技术。它创建并维护了一个或多个备用数据库，这些备用数据库与主数据库同步，可以在主数据库出现问题时迅速接管，实现故障切换。 3. **Automatic Storage Management (ASM)**：ASM是Oracle的内置存储管理系统，它简化了磁盘组的管理和数据存储。ASM自动处理磁盘故障，支持数据的快速恢复，并且可以优化I/O性能。 4. **High Availability Best Practices**：手册中详细阐述了实现高可用性的最佳实践，包括配置建议、监控策略、故障预防和恢复流程。这些实践可以帮助管理员优化系统性能，减少宕机时间，并确保业务连续性。 5. **Monitoring**：有效的监控是保持Oracle系统高可用性的关键。手册会指导如何设置和使用Oracle的监控工具，以便及时发现和解决问题，防止小问题演变成大故障。 6. **Disaster Recovery and Business Continuity Planning**：手册还会涵盖灾难恢复计划和业务连续性规划，这包括如何配置远程Data Guard副本，以及在灾难发生时如何快速恢复服务。 7. **License Agreement and Intellectual Property**：Oracle程序包含了专有信息，它们的使用和披露受到特定许可协议的限制，并受到版权、专利和其他知识产权法律的保护。文档中还提到了反向工程、拆解或反编译程序的限制。这本书是Oracle数据库管理员的宝贵资源，它提供了一套全面的方法来构建和维护高可用性的Oracle环境，以确保企业的关键业务不受中断。通过遵循其中的指导，可以显著提高系统的稳定性和可靠性。

Configuring Storage

2-2 Oracle Database High Availability Best Practices

2.1.1 Evaluate Database Performance Requirements and Storage Performance

Capabilities

Characterize your database performance requirements using different application

workloads. Extract statistics during your target workloads by getting the beginning

and end statistical snapshots. Example target workloads include:

■ Average load

■ Peak load

■ Batch processing

The necessary statistics can be derived from Automatic Workload Repository (AWR)

reports or gathered from the GV$SYSSTAT view. Along with understanding the

database performance requirements, the performance capabilities of a storage array

must be evaluated.

Low-cost storage arrays, low-cost storage networks, and Oracle Database 10g can in

combination create a low-cost storage grid with excellent performance and availability.

Low-cost storage is most successfully deployed for databases with certain types of

performance and availability requirements. Compared to traditional high-end storage

arrays, low-cost storage arrays have excellent data throughput and superior price for

each gigabyte. However, low-cost storage arrays do not have better I/O rates for OLTP

type applications than traditional storage, although the cost for each I/O per second is

comparable. The Oracle Resilient Low-Cost Storage Initiative is designed to help

customers reduce IT spending and promote use of low-cost storage arrays in both

departmental and enterprise environments.

The Oracle Database flash recovery area is an ideal candidate for low-cost storage.

Because the flash recovery area contains recovery related files that are typically

accessed with sequential 1MB streams, the performance characteristics of low-cost

storage are well suited for the flash recovery area. The flash recovery area can be

configured to use low-cost storage while the database area remains on traditional

storage.

2.1.2 Use Automatic Storage Management (ASM) to Manage Database Files

ASM is a vertical integration of both the file system and the volume manager built

specifically for Oracle database files. It extends the concept of stripe and mirror

everything (SAME) to optimize performance, while removing the need for manual I/O

tuning (distributing the datafile layout to avoid hot spots). ASM helps manage a

dynamic database environment by letting you grow the database size without shutting

down the database to adjust the storage allocation. ASM also enables low-cost

modular storage to deliver higher performance and greater availability by supporting

mirroring as well as striping.

ASM should be used to manage all database files. However, ASM can be phased into

your environment initially supporting only the flash recovery area. This approach is

See Also:

■ Chapter 16 "Migrating Databases To and From ASM with

Recovery Manager" in the Oracle Database Backup and Recovery

Advanced User's Guide

■ Oracle Database 10g Release 2 Automatic Storage Management

Overview and Technical Best Practices at

http://www.oracle.com/technology/products/databas

e/asm/pdf/asm_10gr2_bptwp_sept05.pdf

■ Oracle ASMLib Web site at

http://www.oracle.com/technology/tech/linux/asmli

b/index.html

■ Oracle Database Administrator's Guide for more information on

configuring Automatic Storage Management

Note: Using a flash recovery area by setting DB_RECOVERY_FILE_

DEST requires that you also set DB_RECOVERY_FILE_DEST_SIZE to

bound the amount of disk space used by the flash recovery area. DB_

RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE are

dynamic parameters that allow you to change the destination and size

of the flash recovery area.

Configuring Storage

Configuring for High-Availability 2-5

The advantage of this approach is:

■ Higher I/O bandwidth available, because both disk groups are spread over all

available spindles. This advantage is considerable for the database area disk group

for I/O intensive applications.

The disadvantages are:

■ A double disk failure may result in the loss of both disk groups, requiring the use

of a standby database or tape backups for recovery.

■ An ASM rebalance operation following a disk failure is longer, because both disk

groups are affected.

■ Higher initial administrative efforts are required to partition each disk properly.

2.1.4 Use Disk Multipathing Software to Protect from Path Failure

Disk multipathing software aggregates multiple independent I/O paths into a single

logical path. The path abstraction provides I/O load balancing across host bus

adapters (HBA) and nondisruptive failovers when there is a failure in the I/O path.

Disk multipathing software should be used in conjunction with ASM.

When specifying disk names during disk group creation in ASM, the logical device

representing the single logical path should be used. For example, when using Device

Mapper on Linux 2.6, a logical device path of /dev/dm-0 may be the aggregation of

physical disks /dev/sdc and /dev/sdh. Within ASM, the asm_diskstring

parameter should contain /dev/dm-* to discover the logical device /dev/dm-0, and

that logical device should be used during disk group creation:

asm_diskstring='/dev/dm-*'

CREATE DISKGROUP DATA DISK

'/dev/dm-0','/dev/dm-1','/dev/dm-2','/dev/dm-3';

2.1.5 Use Redundancy to Protect from Disk Failure

When setting up redundancy to protect from hardware failures, there are two options

to consider:

■ Storage array based RAID

■ ASM redundancy

Oracle recommends that you configure redundancy in the storage array by enabling

RAID protection, such as RAID1 (mirroring) or RAID5 (striping plus parity). For

example, to create an ASM disk group where redundancy is provided by the storage

array, first create the RAID-protected logical unit numbers (LUNs) in the storage

array, and then create the ASM disk group using the EXTERNAL REDUNDANCY clause:

CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK

'/devices/lun1','/devices/lun2','/devices/lun3','/devices/lun4';

If the storage array does not offer the desired level of redundancy, or if there is a need

to configure redundancy across multiple storage arrays, then use ASM redundancy.

See Also:

■ Oracle Database Backup and Recovery Basics for information on

setting up and sizing the flash recovery area

■ Oracle Database Administrator's Guide for information on automatic

storage management

Configuring Storage

2-6 Oracle Database High Availability Best Practices

ASM provides redundancy with the use of failure groups, which are defined during

disk group creation. ASM redundancy can be either Normal redundancy, where files

are two-way mirrored, or high redundancy, where files are three-way mirrored. Once a

disk group is created, the redundancy level cannot be changed.

Failure group definition is specific to each storage setup, but these guidelines should

be followed:

■ If every disk is available through every I/O path, as would be the case if using

disk multipathing software, then leave each disk in its own failure group. This is

the default ASM behavior if creating a disk group without explicitly defining

failure groups.

CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK

'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4',

'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

■ If every disk is not available through every I/O path, then define failure groups to

protect against the piece of hardware that you are concerned about failing. Here

are three examples:

– For an array with two controllers where each controller sees only half of the

drives, create a disk group with two failure groups, one for each controller, to

protect against controller failure:

CREATE DISKGROUP DATA NORMAL REDUNDANCY

FAILGROUP controller1 DISK

'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4'

FAILGROUP controller2 DISK

'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

– For an array with two controllers where every disk is seen through both

controllers, create a disk group with each disk in its own failure group:

CREATE DISKGROUP DATA NORMAL REDUNDANCY

DISK

'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4',

'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

– For a storage network with multiple storage arrays, you want to mirror across

storage arrays, then create a disk group with two failure groups, one for each

array, to protect against array failure:

CREATE DISKGROUP DATA NORMAL REDUNDANCY

FAILGROUP array1 DISK

'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4'

FAILGROUP array2 DISK

'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4';

When determining the proper size of a disk group that is protected with ASM

redundancy, enough free space must exist in the disk group so that when a disk fails

ASM can automatically reconstruct the contents of the failed drive to other drives in

the disk group while the database remains online. The amount of space required to

ensure ASM can restore redundancy following disk failure is in the column

REQUIRED_MIRROR_FREE_MB in the V$ASM_DISKGROUP view. The amount of free

space that can be safely used in a disk group, taking mirroring into account, and yet be

able to restore redundancy after a disk failure is in the column USABLE_FILE_MB in

the V$ASM_DISKGROUP view. USABLE_FILE_MB should always be greater than zero.

If USABLE_FILE_MB falls below zero, then more disks should be added to the disk

group.

剩余175页未读，继续阅读

PrudentWoo

粉丝: 394
资源: 10

Oracle数据库高可用性最佳实践指南

Oracle High Availability Architecture

Oracle High Availability, Disaster Recovery, and Cloud Services

Oracle Database High Availability Best Practices 11g Release 2 (

Oracle Maximum Availability Architecture：构建高可用系统

Oracle OpenStack for Oracle Linux High Availability Guide

Oracle Database High Availability Overview 11g Release 2 (11.2)

Best practices for MySQL High Availability.pdf

Oracle Database 11g Release 2 High Availability

PHP Scalability and High Availability

High Availability with Oracle Database 11g Release 2

最新资源