PK FJoa,mimetypeapplication/epub+zipPKFJMETA-INF/container.xml PKYuPKFJOEBPS/partpage3.htmu Appendixes

Part III

Appendixes

This part contains the following appendixes:

PKMPKFJOEBPS/rman.htm Using RMAN to Back Up and Restore Files

11 Using RMAN to Back Up and Restore Files

This chapter describes backup strategies using Oracle Recovery Manager (RMAN) with Data Guard and standby databases. RMAN can perform backups with minimal effect on the primary database and quickly recover from the loss of individual datafiles, or the entire database. RMAN and Data Guard can be used together to simplify the administration of a Data Guard configuration.

This chapter contains the following topics:


Note:

Because a logical standby database is not a block-for-block copy of the primary database, you cannot use a logical standby database to back up the primary database.


See Also:


11.1 About RMAN File Management in a Data Guard Configuration

RMAN uses a recovery catalog to track filenames for all database files in a Data Guard environment. A recovery catalog is a database schema used by RMAN to store metadata about one or more Oracle databases. The catalog also records where the online redo logs, standby redo logs, tempfiles, archived redo logs, backup sets, and image copies are created.

11.1.1 Interchangeability of Backups in a Data Guard Environment

RMAN commands use the recovery catalog metadata to behave transparently across different physical databases in the Data Guard environment. For example, you can back up a tablespace on a physical standby database and restore and recover it on the primary database. Similarly, you can back up a tablespace on a primary database and restore and recover it on a physical standby database.


Note:

Backups of logical standby databases are not usable at the primary database.

Backups of standby control files and nonstandby control files are interchangeable. For example, you can restore a standby control file on a primary database and a primary control file on a physical standby database. This interchangeability means that you can offload control file backups to one database in a Data Guard environment. RMAN automatically updates the filenames for database files during restore and recovery at the databases.

11.1.2 Association of Backups in a Data Guard Environment

The recovery catalog tracks the files in the Data Guard environment by associating every database file or backup file with a DB_UNIQUE_NAME. The database that creates a file is associated with the file. For example, if RMAN backs up the database with the unique name of standby1, then standby1 is associated with this backup. A backup remains associated with the database that created it unless you use the CHANGE ... RESET DB_UNIQUE_NAME to associate the backup with a different database.

11.1.3 Accessibility of Backups in a Data Guard Environment

The accessibility of a backup is different from its association. In a Data Guard environment, the recovery catalog considers disk backups as accessible only to the database with which it is associated, whereas tape backups created on one database are accessible to all databases. If a backup file is not associated with any database, then the row describing it in the recovery catalog view shows null for the SITE_KEY column. By default, RMAN associates files whose SITE_KEY is null with the target database.

RMAN commands such as BACKUP, RESTORE, and CROSSCHECK work on any accessible backup. For example, for a RECOVER COPY operation, RMAN considers only image copies that are associated with the database as eligible to be recovered. RMAN considers the incremental backups on disk and tape as eligible to recover the image copies. In a database recovery, RMAN considers only the disk backups associated with the database and all files on tape as eligible to be restored.

To illustrate the differences in backup accessibility, assume that databases prod and standby1 reside on different hosts. RMAN backs up datafile 1 on prod to /prmhost/disk1/df1.dbf on the production host and also to tape. RMAN backs up datafile 1 on standby1 to /sbyhost/disk2/df1.dbf on the standby host and also to tape. If RMAN is connected to database prod, then you cannot use RMAN commands to perform operations with the /sbyhost/disk2/df1.dbf backup located on the standby host. However, RMAN does consider the tape backup made on standby1 as eligible to be restored.


Note:

You can FTP a backup from a standby host to a primary host or vice versa, connect as TARGET to the database on this host, and then CATALOG the backup. After a file is cataloged by the target database, the file is associated with the target database.

11.2 About RMAN Configuration in a Data Guard Environment

In a Data Guard configuration, the process of backing up control files, datafiles, and archived logs can be offloaded to the standby system, thereby minimizing the effect of backups on the production system. These backups can be used to recover the primary or standby database.

RMAN uses the DB_UNIQUE_NAME initialization parameter to distinguish one database site from another database site. Thus, it is critical that the uniqueness of DB_UNIQUE_NAME be maintained in a Data Guard configuration.

Only the primary database must be explicitly registered using the RMAN REGISTER DATABASE command. You do this after connecting RMAN to the recovery catalog and primary database as target.

Use the RMAN CONFIGURE command to set the RMAN configurations. When the CONFIGURE command is used with the FOR DB_UNIQUE_NAME option, it sets the RMAN site-specific configuration for the database with the DB_UNIQUE_NAME you specify.

For example, after connecting to the recovery catalog, you could use the following commands at an RMAN prompt to set the default device type to SBT for the BOSTON database that has a DBID of 1625818158. The RMAN SET DBID command is required only if you are not connected to a database as target.

SET DBID 1625818158;
CONFIGURE DEFAULT DEVICE TYPE TO SBT FOR DB_UNIQUE_NAME BOSTON;

11.3 Recommended RMAN and Oracle Database Configurations

This section describes the following RMAN and Oracle Database configurations, each of which can simplify backup and recovery operations:

Configuration Assumptions

The configurations described in this section make the following assumptions:

  • The standby database is a physical standby database, and backups are taken only on the standby database. See Section 11.9.1 for procedural changes if backups are taken on both primary and standby databases.

  • An RMAN recovery catalog is required so that backups taken on one database server can be restored to another database server. It is not sufficient to use only the control file as the RMAN repository because the primary database will have no knowledge of backups taken on the standby database.

    The RMAN recovery catalog organizes backup histories and other recovery-related metadata in a centralized location. The recovery catalog is configured in a database and maintains backup metadata. A recovery catalog does not have the space limitations of the control file and can store more historical data about backups.

    A catalog server, physically separate from the primary and standby sites, is recommended in a Data Guard configuration because a disaster at either site will not affect the ability to recover the latest backups.


    See Also:

    Oracle Database Backup and Recovery User's Guide for more information about managing a recovery catalog

  • All databases in the configuration use Oracle Database 11g Release 1 (11.1).

  • Oracle Secure Backup software or 3rd-party media management software is configured with RMAN to make backups to tape.

11.3.1 Oracle Database Configurations on Primary and Standby Databases

The following Oracle Database configurations are recommended on every primary and standby database in the Data Guard environment:

  • Configure a fast recovery area for each database (the recovery area is local to a database).

    The fast recovery area is a single storage location on a file system or Oracle Automatic Storage Management (Oracle ASM) disk group where all files needed for recovery reside. These files include the control file, archived logs, online redo logs, flashback logs, and RMAN backups. As new backups and archived logs are created in the fast recovery area, older files (which are either outside of the retention period, or have been backed up to tertiary storage) are automatically deleted to make room for them. In addition, notifications can be set up to alert the DBA when space consumption in the fast recovery area is nearing its predefined limit. The DBA can then take action, such as increasing the recovery area space limit, adding disk hardware, or decreasing the retention period.

    Set the following initialization parameters to configure the fast recovery area:

    DB_RECOVERY_FILE_DEST = <mount point or Oracle ASM Disk Group>
    DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>
    

    See Also:

    Oracle Database Backup and Recovery User's Guide for more information about configuring a fast recovery area

  • Use a server parameter file (SPFILE) so that it can be backed up to save instance parameters in backups.

  • Enable Flashback Database on primary and standby databases.

    When Flashback Database is enabled, Oracle Database maintains flashback logs in the fast recovery area. These logs can be used to roll the database back to an earlier point in time, without requiring a complete restore.


    See Also:

    Oracle Database Backup and Recovery User's Guide for more information about enabling Flashback Database

11.3.2 RMAN Configurations at the Primary Database

To simplify ongoing use of RMAN, you can set a number of persistent configuration settings for each database in the Data Guard environment. These settings control many aspects of RMAN behavior. For example, you can configure the backup retention policy, default destinations for backups to tape or disk, default backup device type, and so on. You can use the CONFIGURE command to set and change RMAN configurations. The following RMAN configurations are recommended at the primary database:

  1. Connect RMAN to the primary database and recovery catalog.

  2. Configure the retention policy for the database as n days:

    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS;
    

    This configuration lets you keep the backups necessary to perform database recovery to any point in time within the specified number of days.

    Use the DELETE OBSOLETE command to delete any backups that are not required (per the retention policy in place) to perform recovery within the specified number of days.

  3. Specify when archived logs can be deleted with the CONFIGURE ARCHIVELOG DELETION POLICY command. For example, if you want to delete logs after ensuring that they shipped to all destinations, use the following configuration:

    CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
    

    If you want to delete logs after ensuring that they were applied on all standby destinations, use the following configuration:

    CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
    
  4. Configure the connect string for the primary database and all standby databases, so that RMAN can connect remotely and perform resynchronization when the RESYNC CATALOG FROM DB_UNIQUE_NAME command is used. When you connect to the target instance, you must provide a net service name. This requirement applies even if the other database instance from where the resynchronization is done is on the local host. The target and remote instances must use the same SYSDBA password, which means that both instances must already have password files. You can create the password file with a single password so you can start all the database instances with that password file. For example, if the TNS alias to connect to a standby in Boston is boston_conn_str, you can use the following command to configure the connect identifier for the BOSTON database site:

    CONFIGURE DB_UNIQUE_NAME BOSTON CONNECT IDENTIFIER 'boston_conn_str';
    

    Note that the 'boston_conn_str' does not include a username and password. It contains only the Oracle Net service name that can be used from any database site to connect to the BOSTON database site.

    After connect identifiers are configured for all standby databases, you can verify the list of standbys by using the LIST DB_UNIQUE_NAME OF DATABASE command.


See Also:


11.3.3 RMAN Configurations at a Standby Database Where Backups are Performed

The following RMAN configurations are recommended at a standby database where backups are done:

  1. Connect RMAN to the standby database (where backups are performed) as target, and to the recovery catalog.

  2. Enable automatic backup of the control file and the server parameter file:

    CONFIGURE CONTROLFILE AUTOBACKUP ON;
    
  3. Skip backing up datafiles for which there already exists a valid backup with the same checkpoint:

    CONFIGURE BACKUP OPTIMIZATION ON;
    
  4. Configure the tape channels to create backups as required by media management software:

    CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '<channel parameters>';
    
  5. Specify when the archived logs can be deleted with the CONFIGURE ARCHIVELOG DELETION POLICY command.

    Because the logs are backed up at the standby site, it is recommended that you configure the BACKED UP option for the log deletion policy.


See Also:

Oracle Database Backup and Recovery User's Guide for more information about enabling deletion policies for archived redo logs

11.3.4 RMAN Configurations at a Standby Where Backups Are Not Performed

The following RMAN configurations are recommended at a standby database where backups are not done:

  1. Connect RMAN to the standby database as target, and to the recovery catalog.

  2. Enable automatic deletion of archived logs once they are applied at the standby database:

    CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
    

11.4 Backup Procedures

This section describes the RMAN scripts and procedures used to back up Oracle Database in a Data Guard configuration. The following topics are covered:


Note:

Oracle's Maximum Availability Architecture (MAA) best practices recommend that backups be taken at both the primary and the standby databases to reduce MTTR, in case of double outages and to avoid introducing new site practices upon switchover and failover.

Backups of Server Parameter Files

Prior to Oracle Database 11g, backups of server parameter files (SPFILEs) were assumed to be usable at any other standby database. However, in practice, it is not possible for all standby databases to use the same SPFILE. To address this problem, RMAN does not allow an SPFILE backup taken at one database site to be used at another database site. This restriction is in place only when the COMPATIBLE initialization parameter is set to 11.0.0.

The standby database allows you to offload all backup operations to one specific standby database, except the backups of SPFILE. However, if the COMPATIBLE initialization parameter is set to 11.0.0, the SPFILE can be backed up to disk and cataloged manually at standby sites where backups are written to tape. The additional metadata stored in SPFILE backup sets enables RMAN to identify which database SPFILE is contained in which backup set. Thus, the appropriate SPFILE backup is chosen during restore from tape.

11.4.1 Using Disk as Cache for Tape Backups

The fast recovery area on the standby database can serve as a disk cache for tape backup. Disk is used as the primary storage for backups, with tape providing long term, archival storage. Incremental tape backups are taken daily and full tape backups are taken weekly. The commands used to perform these backups are described in the following sections.

11.4.1.1 Commands for Daily Tape Backups Using Disk as Cache

When deciding on your backup strategy, Oracle recommends that you take advantage of daily incremental backups. Datafile image copies can be rolled forward with the latest incremental backups, thereby providing up-to-date datafile image copies at all times. RMAN uses the resulting image copy for media recovery just as it would use a full image copy taken at that system change number (SCN), without the overhead of performing a full image copy of the database every day. An additional advantage is that the time-to-recover is reduced because the image copy is updated with the latest block changes and fewer redo logs are required to bring the database back to the current state.

To implement daily incremental backups, a full database backup is taken on the first day, followed by an incremental backup on day two. Archived redo logs can be used to recover the database to any point in either day. For day three and onward, the previous day's incremental backup is merged with the datafile copy and a current incremental backup is taken, allowing fast recovery to any point within the last day. Redo logs can be used to recover the database to any point during the current day.

The script to perform daily backups looks as follows (the last line, DELETE ARCHIVELOG ALL is only needed if the fast recovery area is not used to store logs):

RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RECOVER COPY OF DATABASE WITH TAG 'OSS';
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE;
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL;
BACKUP BACKUPSET ALL;
DELETE ARCHIVELOG ALL;

The standby control file will be automatically backed up at the conclusion of the backup operation because the control file auto backup is enabled.

Explanations for what each command in the script does are as follows:

  • RESYNC CATALOG FROM DB_UNIQUE_NAME ALL

    Resynchronizes the information from all other database sites (primary and other standby databases) in the Data Guard setup that are known to recovery catalog. For RESYNC CATALOG FROM DB_UNIQUE_NAME to work, RMAN should be connected to the target using the Oracle Net service name and all databases must use the same password file.

  • RECOVER COPY OF DATABASE WITH TAG 'OSS'

    Rolls forward level 0 copy of the database by applying the level 1 incremental backup taken the day before. In the example script just shown, the previous day's incremental level 1 was tagged OSS. This incremental is generated by the BACKUP DEVICE TYPE DISK ... DATABASE command. On the first day this command is run there will be no roll forward because there is no incremental level 1 yet. A level 0 incremental will be created by the BACKUP DEVICE TYPE DISK ... DATABASE command. Again on the second day there is no roll forward because there is only a level 0 incremental. A level 1 incremental tagged OSS will be created by the BACKUP DEVICE TYPE DISK ... DATABASE command. On the third and following days, the roll forward will be performed using the level 1 incremental tagged OSS created on the previous day.

  • BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE

    Create a new level 1 incremental backup. On the first day this command is run, this will be a level 0 incremental. On the second and following days, this will be a level 1 incremental.

  • BACKUP DEVICE TYPE SBT ARCHIVELOG ALL

    Backs up archived logs to tape according to the deletion policy in place.

  • BACKUP BACKUPSET ALL

    Backs up any backup sets created as a result of incremental backup creation.

  • DELETE ARCHIVELOG ALL

    Deletes archived logs according to the log deletion policy set by the CONFIGURE ARCHIVELOG DELETION POLICY command. If the archived logs are in a fast recovery area, then they are automatically deleted when more open disk space is required. Therefore, you only need to use this command if you explicitly want to delete logs each day.

11.4.1.2 Commands for Weekly Tape Backups Using Disk as Cache

To back up all recovery-related files to tape, use the following command once a week:

BACKUP RECOVERY FILES;

This ensures that all current incremental, image copy, and archived log backups on disk are backed up to tape.

11.4.2 Performing Backups Directly to Tape

Oracle's Media Management Layer (MML) API lets third-party vendors build a media manager, software that works with RMAN and the vendor's hardware to allow backups to sequential media devices such as tape drives. A media manager handles loading, unloading, and labeling of sequential media such as tapes. You must install Oracle Secure Backup or third-party media management software to use RMAN with sequential media devices.

Take the following steps to perform backups directly to tape, by default:

  1. Connect RMAN to the standby database (as the target database) and recovery catalog.

    
  2. Execute the CONFIGURE command as follows:

    CONFIGURE DEFAULT DEVICE TYPE TO SBT;
    

In this scenario, full backups are taken weekly, with incremental backups taken daily on the standby database.


See Also:

Oracle Database Backup and Recovery User's Guide for more information about how to configure RMAN for use with a media manager

11.4.2.1 Commands for Daily Backups Directly to Tape

Take the following steps to perform daily backups directly to tape:

  1. Connect RMAN to the standby database (as target database) and to the recovery manager.

  2. Execute the following RMAN commands:

    RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
    BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG; 
    DELETE ARCHIVELOG ALL;
    

These commands resynchronize the information from all other databases in the Data Guard environment. They also create a level 1 incremental backup of the database, including all archived logs. On the first day this script is run, if no level 0 backups are found, then a level 0 backup is created.

The DELETE ARCHIVELOG ALL command is necessary only if all archived log files are not in a fast recovery area.

11.4.2.2 Commands for Weekly Backups Directly to Tape

One day a week, take the following steps to perform a weekly backup directly to tape:

  1. Connect RMAN to the standby database (as target database) and to the recovery catalog.

  2. Execute the following RMAN commands:

    BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
    DELETE ARCHIVELOG ALL;
    

These commands resynchronize the information from all other databases in the Data Guard environment, and create a level 0 database backup that includes all archived logs.

The DELETE ARCHIVELOG ALL command is necessary only if all archived log files are not in a fast recovery area.

11.5 Registering and Unregistering Databases in a Data Guard Environment

Only the primary database must be explicitly registered using the REGISTER DATABASE command. You do this after connecting RMAN to the recovery catalog and primary database as TARGET.

A new standby is automatically registered in the recovery catalog when you connect to a standby database or when the CONFIGURE DB_UNIQUE_NAME command is used to configure the connect identifier.

To unregister information about a specific standby database, you can use the UNREGISTER DB_UNIQUE_NAME command. When a standby database is completely removed from a Data Guard environment, the database information in the recovery catalog can also be removed after you connect to another database in the same Data Guard environment. The backups that were associated with the database that was unregistered are still usable by other databases. You can associate these backups with any other existing database by using the CHANGE BACKUP RESET DB_UNIQUE_NAME command.

When the UNREGISTER DB_UNIQUE_NAME command is used with the INCLUDING BACKUPS option, the metadata for all the backup files associated with the database being removed is also removed from the recovery catalog.

11.6 Reporting in a Data Guard Environment

Use the RMAN LIST, REPORT, and SHOW commands with the FOR DB_UNIQUE_NAME clause to view information about a specific database.

For example, after connecting to the recovery catalog, you could use the following commands to display information for a database with a DBID of 1625818158 and to list the databases in the Data Guard environment. The SET DBID command is required only if you are not connected to a database as TARGET. The last three commands list archive logs, database file names, and RMAN configuration information for a database with a DB_UNIQUE_NAME of BOSTON.

SET DBID 1625818158;
LIST DB_UNIQUE_NAME OF DATABASE;
LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME BOSTON;
REPORT SCHEMA FOR DB_UNIQUE_NAME BOSTON;
SHOW ALL FOR DB_UNIQUE_NAME BOSTON;

11.7 Performing Backup Maintenance in a Data Guard Environment

The files in a Data Guard environment (datafiles, archived logs, backup pieces, image copies, and proxy copies) are associated with a database through use of the DB_UNIQUE_NAME parameter. Therefore, it is important that the value supplied for DB_UNIQUE_NAME be unique for each database in a Data Guard environment. This information, along with file-sharing attributes, is used to determine which files can be accessed during various RMAN operations.

File sharing attributes state that files on disk are accessible only at the database with which they are associated, whereas all files on tape are assumed to be accessible by all databases. RMAN commands such as BACKUP and RESTORE, as well as other maintenance commands, work according to this assumption. For example, during a roll-forward operation of an image copy at a database, only image copies associated with the database are rolled forward. Likewise, all incremental backups on disk and all incremental backups on tape will be used to roll forward the image copies. Similarly, during recovery operations, only disk backups associated with the database and files on tape will be considered as sources for backups.


See Also:

Oracle Database Backup and Recovery Reference for detailed information about RMAN commands

11.7.1 Changing Metadata in the Recovery Catalog

You can use the RMAN CHANGE command with various operands to change metadata in the recovery catalog, as described in the following sections.

Changing File Association from One Standby Database to Another

Use the CHANGE command with the RESET DB_UNIQUE_NAME option to alter the association of files from one database to another within a Data Guard environment. The CHANGE command is useful when disk backups or archived logs are transferred from one database to another and you want to use them on the database to which they were transferred. The CHANGE command can also change the association of a file from one database to another database, without having to directly connect to either database using the FOR DB_UNIQUE_NAME and RESET DB_UNIQUE_NAME TO options.

Changing DB_UNIQUE_NAME for a Database

If the value of the DB_UNIQUE_NAME initialization parameter changes for a database, the same change must be made in the Data Guard environment. The RMAN recovery catalog, after connecting to that database instance, will know both the old and new value for DB_UNIQUE_NAME. To merge the information for the old and new values within the recovery catalog schema, you must use the RMAN CHANGE DB_UNIQUE_NAME command. If RMAN is not connected to the instance with the changed DB_UNIQUE_NAME parameter, then the CHANGE DB_UNIQUE_NAME command can also be used to rename the DB_UNIQUE_NAME in the recovery catalog schema. For example, if the instance parameter value for a database was changed from BOSTON_A to BOSTON_B, the following command should be executed at the RMAN prompt after connecting to a target database and recovery catalog:

CHANGE DB_UNIQUE_NAME FROM BOSTON_A TO BOSTON_B;

Making Backups Unavailable or Removing Their Metadata

Use CHANGE command options such as AVAILABLE, UNAVAILABLE, KEEP, and UNCATALOG to make backups available or unavailable for restore and recovery purposes, and to keep or remove their metadata.


See Also:

Oracle Database Backup and Recovery Reference for more information about the RMAN CHANGE command

11.7.2 Deleting Archived Logs or Backups

Use the DELETE command to delete backup sets, image copies, archived logs, or proxy copies. To delete only files that are associated with a specific database, you must use the FOR DB_UNIQUE_NAME option with the DELETE command.

File metadata is deleted for all successfully deleted files associated with the current target database (or for files that are not associated with any known database). If a file could not be successfully deleted, you can use the FORCE option to remove the file's metadata.

When a file associated with another database is deleted successfully, its metadata in the recovery catalog is also deleted. Any files that are associated with other databases, and that could not be successfully deleted, are listed at the completion of the DELETE command, along with instructions for you to perform the same operation at the database with which the files are associated (files are grouped by database). Note that the FORCE option cannot be used to override this behavior. If you are certain that deleting the metadata for the non-deletable files will not cause problems, you can use the CHANGE RESET DB_UNIQUE_NAME command to change the metadata for association of files with the database and use the DELETE command with the FORCE option to delete the metadata for the file.


See Also:

Oracle Database Backup and Recovery Reference for more information about the RMAN DELETE command

11.7.3 Validating Recovery Catalog Metadata

Use the CROSSCHECK command to validate and update file status in the recovery catalog schema. To validate files associated with a specific database, use the FOR DB_UNIQUE_NAME option with the CROSSCHECK command.

Metadata for all files associated with the current target database (or for any files that are not associated with any database), will be marked AVAILABLE or EXPIRED according to the results of the CROSSCHECK operation.

If a file associated with another database is successfully inspected, its metadata in the recovery catalog is also changed to AVAILABLE. Any files that are associated with other databases, and that could not be inspected successfully, are listed at the completion of the CROSSCHECK command, along with instructions for you to perform the same operation at the database with which the files are associated (files are grouped by site). If you are certain of the configuration and still want to change status metadata for unavailable files, you can use the CHANGE RESET DB_UNIQUE_NAME command to change metadata for association of files with the database and execute the CROSSCHECK command to update status metadata to EXPIRED.


See Also:

Oracle Database Backup and Recovery Reference for more information about the RMAN CROSSCHECK command

11.8 Recovery Scenarios in a Data Guard Environment

The examples in the following sections assume you are restoring files from tape to the same system on which the backup was created. If you need to restore files to a different system, you need to configure the channels for that system before executing restore and recover commands. You can set the configuration for a nonexistent database using the SET DBID command and the CONFIGURE command with FOR DB_UNIQUE_NAME. See the Media Management documentation for more information about how to access RMAN backups from different systems.

The following scenarios are described in this section:

11.8.1 Recovery from Loss of Datafiles on the Primary Database

You can recover from loss of datafiles on the primary database by using backups or by using the files on a standby database, as described in the following sections.

Using Backups

Issue the following RMAN commands to restore and recover datafiles. You must be connected to both the primary and recovery catalog databases.

RESTORE DATAFILE n,m...;
RECOVER DATAFILE n,m...;

Issue the following RMAN commands to restore and recover tablespaces. You must be connected to both the primary and recovery catalog databases.

RESTORE TABLESPACE tbs_name1, tbs_name2, ...
RECOVER TABLESPACE tbs_name1, tbs_name2, ...

Using Files On a Standby Database

As of Oracle 11g, you can use files on a standby database to recover a lost datafile. This works well if the standby is up-to-date and the network connection is sufficient enough to support the file copy between the standby and primary.

Start RMAN and take the following steps to copy the datafiles from the standby to the primary:

  1. Connect to the standby database as the target database:

    CONNECT TARGET sys@standby
    

    You are prompted for a password:

    target database Password: password
    
  2. Connect to the primary database as the auxiliary database:

    CONNECT AUXILIARY sys@primary
    

    You are prompted for a password:

    target database Password: password
    
  3. Back up the datafile on the standby host across the network to a location on the primary host. For example, suppose that /disk1/df2.dbf is the name of datafile 2 on the standby host. Suppose that /disk8/datafile2.dbf is the name of datafile 2 on the primary host. The following command would copy datafile 2 over the network to /disk9/df2copy.dbf:

    BACKUP AS COPY DATAFILE 2 AUXILIARY FORMAT '/disk9/df2copy.dbf';
    
  4. Exit the RMAN client as follows:

    EXIT;
    
  5. Start RMAN and connect to the primary database as target, and to the recovery catalog:

    CONNECT TARGET sys@primary;
    target database Password: password
    
    CONNECT CATALOG rman@catdb;
    recovery catalog database Password: password
    
  6. Use the CATALOG DATAFILECOPY command to catalog this datafile copy so that RMAN can use it.:

    CATALOG DATAFILECOPY '/disk9/df2copy.dbf';
    

    Then use the SWITCH DATAFILE command to switch the datafile copy so that /disk9/df2copy.dbf becomes the current datafile:

    RUN {
      SET NEWNAME FOR DATAFILE 2 TO '/disk9/df2copy.dbf';
      SWITCH DATAFILE 2;
    }
    

11.8.2 Recovery from Loss of Datafiles on the Standby Database

To recover the standby database after the loss of one or more datafiles, you must restore the lost files to the standby database from the backup using the RMAN RESTORE DATAFILE command. If all the archived redo log files required for recovery of damaged files are accessible on disk by the standby database, restart Redo Apply.

If the archived redo log files required for recovery are not accessible on disk, use RMAN to recover the restored datafiles to an SCN/log sequence greater than the last log applied to the standby database, and then restart Redo Apply to continue the application of redo data, as follows:

  1. Connect SQL*Plus to the standby database.

  2. Stop Redo Apply using the SQL ALTER DATABASE ... statement.

  3. In a separate terminal, start RMAN and connect to both the standby and recovery catalog databases (use the TARGET keyword to connect to the standby instance).

  4. Issue the following RMAN commands to restore and recover datafiles on the standby database:

    RESTORE DATAFILE <n,m,...>;
    RECOVER DATABASE;
    

    To restore a tablespace, use the RMAN 'RESTORE TABLESPACE tbs_name1, tbs_name2, ...' command.

  5. At the SQL*Plus prompt, restart Redo Apply using the SQL ALTER DATABASE ... statement.


See Also:

Section 7.3 and Section 7.4 for more information about starting and stopping Redo Apply

11.8.3 Recovery from Loss of a Standby Control File

Oracle software allows multiplexing of the standby control file. To ensure the standby control file is multiplexed, check the CONTROL_FILES initialization parameter, as follows:

SQL> SHOW PARAMETER CONTROL_FILES;

NAME                                 TYPE        VALUE
 ------------------------------------ ----------- ------------------------------
control_files                        string      <cfilepath1>,<cfilepath2>

If one of the multiplexed standby control files is lost or is not accessible, Oracle software stops the instance and writes the following messages to the alert log:

ORA-00210: cannot open the specified controlfile
ORA-00202: controlfile: '/disk1/oracle/dbs/scf3_2.f'
ORA-27041: unable to open file

You can copy an intact copy of the control file over the lost copy, then restart the standby instance using the following SQL statements:

SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

You can restore the control file from backups by executing the RESTORE CONTROLFILE command and then the RECOVER DATABASE command. The RECOVER DATABASE command automatically fixes the file names in the control file to match the files existing at that database, and recovers the database to the most recently received log sequence at the database.

The other alternative is to create a new control file from the primary database, copy it to all multiplexed locations, and manually rename the data file names to match files existing on disk.

11.8.4 Recovery from Loss of the Primary Control File

Oracle software allows multiplexing of the control file on the primary database. If one of the control files cannot be updated on the primary database, the primary database instance is shut down automatically.

You can restore the control file from backups by executing the RESTORE CONTROLFILE command and the RECOVER DATABASE command. The RECOVER DATABASE command automatically fixes the file names in the control file to match the files existing at that database, and recovers the database.

The other alternative is to create a new control file using CREATE CONTROLFILE SQL command. It is possible to re-create the control file provided all data files and online logs are not lost.


See Also:

Oracle Database Backup and Recovery User's Guide for detailed information about using RMAN to recover from the loss of control files

11.8.5 Recovery from Loss of an Online Redo Log File

Oracle recommends multiplexing the online redo log files. The loss of all members of an online redo log group causes Oracle software to terminate the instance. If only some members of a log file group cannot be written, they will not be used until they become accessible. The views V$LOGFILE and V$LOG contain more information about the current status of log file members in the primary database instance.

When Oracle software is unable to write to one of the online redo log file members, the following alert messages are returned:

ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/disk1/oracle/dbs/t1_log1.f'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

If the access problem is temporary due to a hardware issue, correct the problem and processing will continue automatically. If the loss is permanent, a new member can be added and the old one dropped from the group.

To add a new member to a redo log group, issue the following statement:

SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n;

You can issue this statement even when the database is open, without affecting database availability.

If all members of an inactive group that has been archived are lost, the group can be dropped and re-created.

In all other cases (loss of all online log members for the current ACTIVE group, or an inactive group which has not yet been archived), you must fail over to the standby database. Refer to Chapter 8 for the failover procedure.

11.8.6 Incomplete Recovery of the Primary Database

Incomplete recovery of the primary database is normally done in cases such as when the database is logically corrupted (by a user or an application) or when a tablespace or datafile was accidentally dropped from database.

Depending on the current database checkpoint SCN on the standby database instances, you can use one of the following procedures to perform incomplete recovery of the primary database. All the procedures are in order of preference, starting with the one that is the least time consuming.

Using Flashback Database Using Flashback Database is the recommended procedure when the Flashback Database feature is enabled on the primary database, none of the database files are lost, and the point-in-time recovery is greater than the oldest flashback SCN or the oldest flashback time. See Section 13.3 for the procedure to use Flashback Database to do point-in-time recovery.

Using the standby database instance This is the recommended procedure when the standby database is behind the desired incomplete recovery time, and Flashback Database is not enabled on the primary or standby databases:

  1. Recover the standby database to the desired point in time.

    RECOVER DATABASE UNTIL TIME 'time';
    

    Alternatively, incomplete recovery time can be specified using the SCN or log sequence number:

    RECOVER DATABASE UNTIL SCN incomplete recovery SCN';
    RECOVER DATABASE UNTIL LOGSEQ incomplete recovery log sequence number THREAD thread number;
    
  2. Open the standby database in read-only mode to verify the state of database.

    If the state is not what is desired, use the LogMiner utility to look at the archived redo log files to find the right target time or SCN for incomplete recovery. Alternatively, you can start by recovering the standby database to a point that you know is before the target time, and then open the database in read-only mode to examine the state of the data. Repeat this process until the state of the database is verified to be correct. Note that if you recover the database too far (that is, past the SCN where the error occurred) you cannot return it to an earlier SCN.

  3. Activate the standby database using the SQL ALTER DATABASE ACTIVATE STANDBY DATABASE statement. This converts the standby database to a primary database, creates a new resetlogs branch, and opens the database. See Section 9.4 to learn how the standby database reacts to the new reset logs branch.

Using the primary database instance If all of the standby database instances have already been recovered past the desired point in time and Flashback Database is not enabled on the primary or standby database, then this is your only option.

Use the following procedure to perform incomplete recovery on the primary database:

  1. Use LogMiner or another means to identify the time or SCN at which all the data in the database is known to be good.

  2. Using the time or SCN, issue the following RMAN commands to do incomplete database recovery and open the database with the RESETLOGS option (after connecting to catalog database and primary instance that is in MOUNT state):

    RUN 
    {
    SET UNTIL TIME 'time';
    RESTORE DATABASE;
    RECOVER DATABASE;
    }
    ALTER DATABASE OPEN RESETLOGS;
    

After this process, all standby database instances must be reestablished in the Data Guard configuration.

11.9 Additional Backup Situations

The following sections describe how to modify the backup procedures for other configurations, such as when the standby and primary databases cannot share backup files; the standby instance is only used to remotely archive redo log files; or the standby database filenames are different than the primary database.

11.9.1 Standby Databases Too Geographically7 Distant to Share Backups

If the standby databases are far apart from one another, the backups taken on them may not be easily accessible by the primary system or other standby systems. Perform a complete backup of the database on all systems to perform recovery operations. The fast recovery area can reside locally on the primary and standby systems (that is, the fast recovery area does not have to be the same for the primary and standby databases).

In this scenario, you can still use the general strategies described in Section 11.8, with the following exceptions:

  • Backup files created by RMAN must be tagged with the local system name, and with RESTORE operations that tag must be used to restrict RMAN from selecting backups taken on the same host. In other words, the BACKUP command must use the TAG system name option when creating backups; the RESTORE command must use the FROM TAG system name option; and the RECOVER command must use the FROM TAG system name ARCHIVELOG TAG system name option.

  • Disaster recovery of the standby site:

    1. Start the standby instance in the NOMOUNT state using the same parameter files with which the standby was operating earlier.

    2. Create a standby control file on the primary instance using the SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename statement, and use the created control file to mount the standby instance.

    3. Issue the following RMAN commands to restore and recover the database files:

      RESTORE DATABASE FROM TAG 'system name';
      RECOVER DATABASE FROM TAG 'system name' ARCHIVELOG TAG 'system name';
      
    4. Restart Redo Apply.

The standby instance will fetch the remaining archived redo log files.

11.9.2 Standby Database Does Not Contain Datafiles, Used as a FAL Server

Use the same procedure described in Section 11.4, with the exception that the RMAN commands that back up database files cannot be run against the FAL server. The FAL server can be used as a backup source for all archived redo log files, thus off-loading backups of archived redo log files to the FAL server.

11.9.3 Standby Database File Names Are Different From Primary Database


Note:

As of Oracle Database 11g, the recovery catalog can resynchronize the file names from each standby database site. However, if the file names from a standby database were never resynchronized for some reason, then you can use the procedure described in this section to do so.

If the database filenames are not the same on the primary and standby databases that were never resynchronized, the RESTORE and RECOVER commands you use will be slightly different. To obtain the actual datafile names on the standby database, query the V$DATAFILE view and specify the SET NEWNAME option for all the datafiles in the database:

RUN 
{
SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE';
SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE';
…
…
 SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE';
 RESTORE {DATAFILE <n,m,…> | TABLESPACE tbs_name_1, 2, …| DATABASE;
SWITCH DATAFILE ALL; 
RECOVER DATABASE {NOREDO};
}

Similarly, the RMAN DUPLICATE command should also use the SET NEWNAME option to specify new filenames during standby database creation. Or you could set the LOG_FILE_NAME_CONVERT and DB_FILE_NAME_CONVERT parameters.


See Also:

Section 13.5, "Creating a Standby Database That Uses OMF or Oracle ASM" for information about precedence rules when both the DB_FILE_NAME_CONVERT and DB_CREATE_FILE_DEST parameters are set on the standby

11.10 Using RMAN Incremental Backups to Roll Forward a Physical Standby Database

In some situations, RMAN incremental backups can be used to synchronize a physical standby database with the primary database. You can use the RMAN BACKUP INCREMENTAL FROM SCN command to create a backup on the primary database that starts at the current SCN of the standby, which can then be used to roll the standby database forward in time.

The steps described in this section apply to situations in which RMAN incremental backups may be useful because the physical standby database either:

  • Lags far behind the primary database

  • Has widespread nologging changes

  • Has nologging changes on a subset of datafiles


Note:

Oracle recommends the use of a recovery catalog when performing this operation. These steps are possible without a recovery catalog, but great care must be taken to correct the file names in the restored control file.


See Also:

Oracle Database Backup and Recovery User's Guide for more information about RMAN incremental backups

11.10.1 Steps for Using RMAN Incremental Backups

Except where stated otherwise, the following steps apply to all three situations just listed.

  1. Stop Redo Apply on the standby database:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    
  2. On the standby database, compute the FROM SCN for the incremental backup. This is done differently depending on the situation:

    • On a standby that lags far behind the primary database, query the V$DATABASE view and record the current SCN of the standby database:

      SQL> SELECT CURRENT_SCN FROM V$DATABASE;
      
      CURRENT_SCN
      -----------
           233995
      
    • On a standby that has widespread nologging changes, query the V$DATAFILE view to record the lowest FIRST_NONLOGGED_SCN:

      SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE -
      > WHERE FIRST_NONLOGGED_SCN>0;
      
      MIN(FIRST_NONLOGGED_SCN)
      ------------------------
                        223948
      
    • On a standby that has nologging changes on a subset of datafiles, query the V$DATAFILE view, as follows:

      SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE -
      > WHERE FIRST_NONLOGGED_SCN > 0;
      
      FILE#      FIRST_NONLOGGED_SCN
      ---------- -------------------
               4              225979
               5              230184
      
  3. Connect to the primary database as the RMAN target and create an incremental backup from the current SCN (for a standby lagging far behind the primary) or from the lowest FIRST_NONLOGGED_SCN (for a standby with widespread nologging changes) of the standby database that was recorded in step 2:

    RMAN> BACKUP INCREMENTAL FROM SCN 233995 DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
    

    If the standby has nologging changes on a subset of datafiles, then create an incremental backup for each datafile listed in the FIRST_NONLOGGED_SCN column (recorded in step 2), as follows:

    RMAN> BACKUP INCREMENTAL FROM SCN 225979 DATAFILE 4 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY';
    RMAN> BACKUP INCREMENTAL FROM SCN 230184 DATAFILE 5 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY';
    

    The BACKUP commands shown generate datafile backups, as well as a control file backup that will be used in step 7.

  4. If the backup pieces are not on shared storage, then transfer all the backup pieces created on the primary to the standby:

    scp /tmp/ForStandby_* standby:/tmp
    
  5. If you had to copy the backup pieces in the previous step, or if you are not connected to the recovery catalog for the entire process, then you must catalog the new backup pieces on the standby (otherwise, go on to the next step):

    RMAN> CATALOG START WITH '/tmp/ForStandby';
    
  6. Connect to the standby database as the RMAN target and execute the REPORT SCHEMA statement to ensure that the standby database site is automatically registered and that the files names at the standby site are displayed:

    RMAN> REPORT SCHEMA;
    
  7. Connect to the standby database as the RMAN target and apply incremental backups by executing the following commands. Note that the RESTORE STANDBY CONTROLFILE FROM TAG command only works if you are connected to the recovery catalog for the entire process. Otherwise, you must use the RESTORE STANDBY CONTROLFILE FROM '<control file backup filename>' command.

    RMAN> STARTUP FORCE NOMOUNT;
    RMAN> RESTORE STANDBY CONTROLFILE FROM TAG 'FORSTANDBY';
    RMAN> ALTER DATABASE MOUNT;
    RMAN> RECOVER DATABASE NOREDO;
    

    Note:

    If a recovery catalog is used, then the RMAN RECOVER command will fix the path names for datafiles in the standby control file. If no recovery catalog is used, then you must manually edit the file names in your standby control file or use the RMAN SET NEWNAME command to assign the datafile names. See Oracle Database Backup and Recovery Reference for more information about the RMAN RECOVER and SET NEWNAME commands.

  8. On standbys that have widespread nologging changes or that have nologging changes on a subset of datafiles, query the V$DATAFILE view to verify there are no datafiles with nologged changes. The following query should return zero rows:

    SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE -
    > WHERE FIRST_NONLOGGED_SCN > 0;
    

    Note:

    The incremental backup will become obsolete in 7 days, or you can remove it now using the RMAN DELETE command.

  9. Start Redo Apply on the physical standby database:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
    > USING CURRENT LOGFILE DISCONNECT FROM SESSION;
    
PKΞ_77PKFJOEBPS/whatsnew.htmUj What's New in Oracle Data Guard?

What's New in Oracle Data Guard?

The features and enhancements described in this preface were added to Oracle Data Guard in Oracle Database 11g.

Oracle Database 11g Release 2 (11.2.0.3) New Features in Oracle Data Guard

The following new features are specific to SQL Apply in Oracle Data Guard 11g Release 2 (11.2.0.3):

  • Support for XMLType data stored as binary XML

  • Support for XMLType data stored in object-relational format

Support for both these storage formats requires that the primary database be running Oracle Database 11g Release 2 (11.2.0.3) or higher with a redo compatibility setting of 11.2.0.3 or higher. See "Datatype Considerations" for more information about supported data types.

New Features in Oracle Data Guard 11.2

The following sections describe the new features and enhancements that were added in Oracle Data Guard 11g Release 2 (11.2):

New 11.2 Features Common to Redo Apply and SQL Apply

  • As of Oracle Database 11g Release 2 (11.2.0.2), Oracle Data Guard is fully integrated with Oracle Real Application Clusters One Node (Oracle RAC One Node).

  • A Data Guard configuration can now consist of a primary database and up to 30 standby databases.

  • The FAL_CLIENT database initialization parameter is no longer required.

  • The default archive destination used by the Oracle Automatic Storage Management (Oracle ASM) feature and the fast recovery area feature has changed from LOG_ARCHIVE_DEST_10 to LOG_ARCHIVE_DEST_1.

  • Redo transport compression is no longer limited to compressing redo data only when a redo gap is being resolved. When compression is enabled for a destination, all redo data sent to that destination is compressed.

  • The new ALTER SYSTEM FLUSH REDO SQL statement can be used at failover time to flush unsent redo from a mounted primary database to a standby database, thereby allowing a zero data loss failover to be performed even if the primary database is not running in a zero data loss data protection mode. See Section 8.2.2 for more information.

New 11.2 Features Specific to Redo Apply

  • You can configure apply lag tolerance in a real-time query environment by using the new STANDBY_MAX_DATA_DELAY parameter.

  • You can use the new ALTER SESSION SYNC WITH PRIMARY SQL statement to ensure that a suitably configured physical standby database is synchronized with the primary database as of the time the statement is issued.

  • The V$DATAGUARD_STATS view has been enhanced to a greater degree of accuracy in many of its columns, including apply lag and transport lag.

  • You can view a histogram of apply lag values on the physical standby. To do so, query the new V$STANDBY_EVENT_HISTOGRAM view.

  • A corrupted data block in a primary database can be automatically replaced with an uncorrupted copy of that block from a physical standby database that is operating in real-time query mode. A corrupted block in a physical standby database can also be automatically replaced with an uncorrupted copy of the block from the primary database.


See Also:

Section 9.2, "Opening a Physical Standby Database" for more information about each of these features

New 11.2 Features Specific to SQL Apply

  • Logical standby databases support tables with basic table compression, OLTP table compression, and Hybrid Columnar Compression.


    See Also:


  • Logical standby and the LogMiner utility support tables with SecureFiles LOB columns. Compression and encryption operations on SecureFiles LOB columns are also supported. (De-duplication operations and fragment-based operations are not supported.)

  • Changes made in the context of XA global transactions on an Oracle RAC primary database are replicated on a logical standby database.

  • Online redefinition performed at the primary database using the DBMS_REDEFINITION PL/SQL package is transparently replicated on a logical standby database.

  • Logical Standby supports the use of editions at the primary database, including the use of edition-based redefinition to upgrade applications with minimal downtime.


    See Also:


  • Logical standby databases support Streams Capture. This allows you to offload processing from the primary database in one-way information propagation configurations and make the logical standby the hub that propagates information to multiple databases. Streams Capture can also propagate changes that are local to the logical standby database.

New Features in Oracle Data Guard 11.1

The following sections describe the new features and enhancements that were added in Oracle Data Guard 11g Release 1 (11.1):

New 11.1 Features Common to Redo Apply and SQL Apply

  • Compression of redo traffic over the network in a Data Guard configuration

    This feature improves redo transport performance when resolving redo gaps by compressing redo before it is transmitted over the network.


    See Also:

    "COMPRESSION" attribute

  • Redo transport response time histogram

    The V$REDO_DEST_RESP_HISTOGRAM dynamic performance view contains a histogram of response times for each SYNC redo transport destination. The data in this view can be used to assist in the determination of an appropriate value for the LOG_ARCHIVE_DEST_n NET_TIMEOUT attribute.


    See Also:

    "NET_TIMEOUT" attribute

  • Faster role transitions

  • Strong authentication for redo transport network sessions

    Redo transport network sessions can now be authenticated using SSL. This provides strong authentication and makes the use of remote login password files optional in a Data Guard configuration.

  • Simplified Data Guard management interface

    The SQL statements and initialization parameters used to manage a Data Guard configuration have been simplified through the deprecation of redundant SQL clauses and initialization parameters.


    See Also:


  • Enhancements around DB_UNIQUE_NAME

    You can now find the DB_UNIQUE_NAME of the primary database from the standby database by querying the new PRIMARY_DB_UNIQUE_NAME column in the V$DATABASE view. Also, Oracle Data Guard release 11g ensures each database's DB_UNIQUE_NAME is different. After upgrading to 11g, any databases with the same DB_UNIQUE_NAME will not be able to communicate with each other.

  • Use of physical standby database for rolling upgrades

    A physical standby database can now take advantage of the rolling upgrade feature provided by a logical standby. Through the use of the new KEEP IDENTITY clause option to the SQL ALTER DATABASE RECOVER TO LOGICAL STANDBY statement, a physical standby database can be temporarily converted into a logical standby database for the rolling upgrade, and then reverted back to the original configuration of a primary database and a physical standby database when the upgrade is done.

  • Heterogeneous Data Guard Configuration

    This feature allows a mix of Linux and Windows primary and standby databases in the same Data Guard configuration.

New 11.1 Features Specific to Redo Apply

New 11.1 Features Specific to SQL Apply

  • Support Transparent Data Encryption (TDE)

    Data Guard SQL Apply can be used to provide data protection for the primary database with Transparent Data Encryption enabled. This allows a logical standby database to provide data protection for applications with advanced security requirements.

  • Dynamic setting of Data Guard SQL Apply parameters

    You can now configure specific SQL Apply parameters without requiring SQL Apply to be restarted. Using the DBMS_LOGSTDBY.APPLY_SET package, you can dynamically set initialization parameters, thus improving the manageability, uptime, and automation of a logical standby configuration.

    In addition, the APPLY_SET and APPLY_UNSET subprograms include two new parameters: LOG_AUTO_DEL_RETENTION_TARGET and EVENT_LOG_DEST.


    See Also:

    DBMS_LOGSTDBY PL/SQL package in the Oracle Database PL/SQL Packages and Types Reference

  • Enhanced Oracle RAC switchover support for logical standby databases

    When switching over to a logical standby database where either the primary database or the standby database is using Oracle RAC, the SWITCHOVER command can be used without having to shut down any instance, either at the primary or at the logical standby database.

  • Enhanced DDL handling in Oracle Data Guard SQL Apply

    SQL Apply will execute parallel DDLs in parallel (based on availability of parallel servers).

  • Use of the PL/SQL DBMS_SCHEDULER package to create Scheduler jobs on a standby database

    Scheduler Jobs can be created on a standby database using the PL/SQL DBMS_SCHEDULER package and can be associated with an appropriate database role so that they run when intended (for example, when the database is the primary, standby, or both).

PK6.UUPKFJ OEBPS/toc.htm Oracle Data Guard Concepts and Administration , 11g Release 2 (11.2)

Contents

List of Examples

List of Figures

List of Tables

Preface

What's New in Oracle Data Guard?

Part I Concepts and Administration

1 Introduction to Oracle Data Guard

2 Getting Started with Data Guard

3 Creating a Physical Standby Database

4 Creating a Logical Standby Database

5 Data Guard Protection Modes

6 Redo Transport Services

7 Apply Services

8 Role Transitions

9 Managing Physical and Snapshot Standby Databases

10 Managing a Logical Standby Database

11 Using RMAN to Back Up and Restore Files

12 Using SQL Apply to Upgrade the Oracle Database

13 Data Guard Scenarios

Part II Reference

14 Initialization Parameters

15 LOG_ARCHIVE_DEST_n Parameter Attributes

16 SQL Statements Relevant to Data Guard

17 Views Relevant to Oracle Data Guard

Part III Appendixes

A Troubleshooting Data Guard

B Upgrading and Downgrading Databases in a Data Guard Configuration

C Data Type and DDL Support on a Logical Standby Database

D Data Guard and Oracle Real Application Clusters

E Creating a Standby Database with Recovery Manager

F Setting Archive Tracing

Index

PKɱ6,PKFJOEBPS/log_apply.htmA; Apply Services

7 Apply Services

This chapter describes how redo data is applied to a standby database. It includes the following topics:

7.1 Introduction to Apply Services

Apply services automatically apply redo to standby databases to maintain synchronization with the primary database and allow transactionally consistent access to the data.

By default, apply services waits for a standby redo log file to be archived before applying the redo that it contains. However, you can enable real-time apply, which allows apply services to apply the redo in the current standby redo log file as it is being filled. Real-time apply is described in more detail in Section 7.2.1.

Apply services use the following methods to maintain physical and logical standby databases:

  • Redo Apply (physical standby databases only)

    Uses media recovery to keep the primary and physical standby databases synchronized.

  • SQL Apply (logical standby databases only)

    Reconstitutes SQL statements from the redo received from the primary database and executes the SQL statements against the logical standby database.

The sections in this chapter describe Redo Apply, SQL Apply, real-time apply, and delayed apply in more detail.

7.2 Apply Services Configuration Options

This section contains the following topics:

7.2.1 Using Real-Time Apply to Apply Redo Data Immediately

If the real-time apply feature is enabled, apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.

Use the ALTER DATABASE statement to enable the real-time apply feature, as follows:

  • For physical standby databases, issue the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE statement.

  • For logical standby databases, issue the ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE statement.

Real-time apply requires a standby database that is configured with a standby redo log and that is in ARCHIVELOG mode.

Figure 7-1 shows a Data Guard configuration with a local destination and a standby destination. As the remote file server (RFS) process writes the redo data to standby redo log files on the standby database, apply services can recover redo from standby redo log files as they are being filled.

Figure 7-1 Applying Redo Data to a Standby Destination Using Real-Time Apply

Description of Figure 7-1 follows

7.2.2 Specifying a Time Delay for the Application of Archived Redo Log Files

In some cases, you may want to create a time lag between the time when redo data is received from the primary site and when it is applied to the standby database. You can specify a time interval (in minutes) to protect against the application of corrupted or erroneous data to the standby database. When you set a DELAY interval, it does not delay the transport of the redo data to the standby database. Instead, the time lag you specify begins when the redo data is completely archived at the standby destination.


Note:

If you define a delay for a destination that has real-time apply enabled, the delay is ignored.

Specifying a Time Delay

You can set a time delay on primary and standby databases using the DELAY=minutes attribute of the LOG_ARCHIVE_DEST_n initialization parameter to delay applying archived redo log files to the standby database. By default, there is no time delay. If you specify the DELAY attribute without specifying a value, then the default delay interval is 30 minutes.

Canceling a Time Delay

You can cancel a specified delay interval as follows:

  • For physical standby databases, use the NODELAY keyword of the RECOVER MANAGED STANDBY DATABASE clause:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
    
  • For logical standby databases, specify the following SQL statement:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
    

These commands result in apply services immediately beginning to apply archived redo log files to the standby database, before the time interval expires.

7.2.2.1 Using Flashback Database as an Alternative to Setting a Time Delay

As an alternative to setting an apply delay, you can use Flashback Database to recover from the application of corrupted or erroneous data to the standby database. Flashback Database can quickly and easily flash back a standby database to an arbitrary point in time.

See Chapter 13 for scenarios showing how to use Data Guard with Flashback Database, and Oracle Database Backup and Recovery User's Guide for more information about enabling and using Flashback Database.

7.3 Applying Redo Data to Physical Standby Databases

By default, the redo data is applied from archived redo log files. When performing Redo Apply, a physical standby database can use the real-time apply feature to apply redo directly from the standby redo log files as they are being written by the RFS process.

This section contains the following topics:

7.3.1 Starting Redo Apply

To start apply services on a physical standby database, ensure the physical standby database is started and mounted and then start Redo Apply using the SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement.

You can specify that Redo Apply runs as a foreground session or as a background process, and enable it with real-time apply.

  • To start Redo Apply in the foreground, issue the following SQL statement:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
    

    If you start a foreground session, control is not returned to the command prompt until recovery is canceled by another session.

  • To start Redo Apply in the background, include the DISCONNECT keyword on the SQL statement. For example:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
    

    This statement starts a detached server process and immediately returns control to the user. While the managed recovery process is performing recovery in the background, the foreground process that issued the RECOVER statement can continue performing other tasks. This does not disconnect the current SQL session.

  • To start real-time apply, include the USING CURRENT LOGFILE clause on the SQL statement. For example:

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
    

7.3.2 Stopping Redo Apply

To stop Redo Apply, issue the following SQL statement:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

7.3.3 Monitoring Redo Apply on Physical Standby Databases

To monitor the status of apply services on a physical standby database, see Section 9.5.1. You can also monitor the standby database using Oracle Enterprise Manager. Also, see the Oracle Database Reference for complete reference information about views.

7.4 Applying Redo Data to Logical Standby Databases

SQL Apply converts the data from the archived redo log or standby redo log into SQL statements and then executes these SQL statements on the logical standby database. Because the logical standby database remains open, tables that are maintained can be used simultaneously for other tasks such as reporting, summations, and queries.

This section contains the following topics:

7.4.1 Starting SQL Apply

To start SQL Apply, start the logical standby database and issue the following statement:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

To start real-time apply on the logical standby database to immediately apply redo data from the standby redo log files on the logical standby database, include the IMMEDIATE keyword as shown in the following statement:

SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

7.4.2 Stopping SQL Apply on a Logical Standby Database

To stop SQL Apply, issue the following statement on the logical standby database:

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

When you issue this statement, SQL Apply waits until it has committed all complete transactions that were in the process of being applied. Thus, this command may not stop the SQL Apply processes immediately.

7.4.3 Monitoring SQL Apply on Logical Standby Databases

To monitor SQL Apply, see Section 10.3. You can also monitor the standby database using Oracle Enterprise Manager. See Appendix A, "Troubleshooting Data Guard" and Oracle Data Guard Broker.

PK%[AAPKFJOEBPS/concepts.htm Introduction to Oracle Data Guard

1 Introduction to Oracle Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.

With Data Guard, administrators can optionally improve production database performance by offloading resource-intensive backup and reporting operations to standby systems.

This chapter includes the following topics that describe the highlights of Oracle Data Guard:

1.1 Data Guard Configurations

A Data Guard configuration consists of one production database and one or more standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided they can communicate with each other. For example, you can have a standby database on the same system as the production database, along with two standby databases on other systems at remote locations.

You can manage primary and standby databases using the SQL command-line interfaces or the Data Guard broker interfaces, including a command-line interface (DGMGRL) and a graphical user interface that is integrated in Oracle Enterprise Manager.

1.1.1 Primary Database

A Data Guard configuration contains one production database, also referred to as the primary database, that functions in the primary role. This is the database that is accessed by most of your applications.

The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters (Oracle RAC) database.

1.1.2 Standby Databases

A standby database is a transactionally consistent copy of the primary database. Using a backup copy of the primary database, you can create up to thirty standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database.

Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle RAC database.

The types of standby databases are as follows:

  • Physical standby database

    Provides a physically identical copy of the primary database, with on disk database structures that are identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database, through Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database.

    As of Oracle Database 11g release 1 (11.1), a physical standby database can receive and apply redo while it is open for read-only access. A physical standby database can therefore be used concurrently for data protection and reporting.

  • Logical standby database

    Contains the same logical information as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database through SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executes the SQL statements on the standby database.

    A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This allows users to access a logical standby database for queries and reporting purposes at any time. Also, using a logical standby database, you can upgrade Oracle Database software and patch sets with almost no downtime. Thus, a logical standby database can be used concurrently for data protection, reporting, and database upgrades.

  • Snapshot Standby Database

    A snapshot standby database is a fully updatable standby database.

    Like a physical or logical standby database, a snapshot standby database receives and archives redo data from a primary database. Unlike a physical or logical standby database, a snapshot standby database does not apply the redo data that it receives. The redo data received by a snapshot standby database is not applied until the snapshot standby is converted back into a physical standby database, after first discarding any local updates made to the snapshot standby database.

    A snapshot standby database is best used in scenarios that require a temporary, updatable snapshot of a physical standby database. Note that because redo data received by a snapshot standby database is not applied until it is converted back into a physical standby, the time needed to recover from a primary database failure is directly proportional to the amount of redo data that needs to be applied.

1.1.3 Configuration Example

Figure 1-1 shows a typical Data Guard configuration that contains a primary database that transmits redo data to a standby database. The standby database is remotely located from the primary database for disaster recovery and backup operations. You can configure the standby database at the same location as the primary database. However, for disaster recovery purposes, Oracle recommends you configure standby databases at remote locations.

Figure 1-1 Typical Data Guard Configuration

Description of Figure 1-1 follows

1.2 Data Guard Services

The following sections explain how Data Guard manages the transmission of redo data, the application of redo data, and changes to the database roles:

  • Redo Transport Services

    Control the automated transfer of redo data from the production database to one or more archival destinations.

  • Apply Services

    Apply redo data on the standby database to maintain transactional synchronization with the primary database. Redo data can be applied either from archived redo log files, or, if real-time apply is enabled, directly from the standby redo log files as they are being filled, without requiring the redo data to be archived first at the standby database.

  • Role Transitions

    Change the role of a database from a standby database to a primary database, or from a primary database to a standby database using either a switchover or a failover operation.

1.2.1 Redo Transport Services

Redo transport services control the automated transfer of redo data from the production database to one or more archival destinations.

Redo transport services perform the following tasks:

  • Transmit redo data from the primary system to the standby systems in the configuration

  • Manage the process of resolving any gaps in the archived redo log files due to a network failure

  • Automatically detect missing or corrupted archived redo log files on a standby system and automatically retrieve replacement archived redo log files from the primary database or another standby database

1.2.2 Apply Services

The redo data transmitted from the primary database is written to the standby redo log on the standby database. Apply services automatically apply the redo data on the standby database to maintain consistency with the primary database. It also allows read-only access to the data.

The main difference between physical and logical standby databases is the manner in which apply services apply the archived redo data:

  • For physical standby databases, Data Guard uses Redo Apply technology, which applies redo data on the standby database using standard recovery techniques of an Oracle database, as shown in Figure 1-2.

Figure 1-2 Automatic Updating of a Physical Standby Database

Description of Figure 1-2 follows

  • For logical standby databases, Data Guard uses SQL Apply technology, which first transforms the received redo data into SQL statements and then executes the generated SQL statements on the logical standby database, as shown in Figure 1-3.

Figure 1-3 Automatic Updating of a Logical Standby Database

Description of Figure 1-3 follows

1.2.3 Role Transitions

An Oracle database operates in one of two roles: primary or standby. Using Data Guard, you can change the role of a database using either a switchover or a failover operation.

A switchover is a role reversal between the primary database and one of its standby databases. A switchover ensures no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role.

A failover is when the primary database is unavailable. Failover is performed only in the event of a failure of the primary database, and the failover results in a transition of a standby database to the primary role. The database administrator can configure Data Guard to ensure no data loss.

The role transitions described in this documentation are invoked manually using SQL statements. You can also use the Oracle Data Guard broker to simplify role transitions and automate failovers using Oracle Enterprise Manager or the DGMGRL command-line interface, as described in Section 1.3.

1.3 Data Guard Broker

The Data Guard broker is a distributed management framework that automates the creation, maintenance, and monitoring of Data Guard configurations. You can use either the Oracle Enterprise Manager graphical user interface (GUI) or the Data Guard command-line interface (DGMGRL) to:

  • Create and enable Data Guard configurations, including setting up redo transport services and apply services

  • Manage an entire Data Guard configuration from any system in the configuration

  • Manage and monitor Data Guard configurations that contain Oracle RAC primary or standby databases

  • Simplify switchovers and failovers by allowing you to invoke them using either a single key click in Oracle Enterprise Manager or a single command in the DGMGRL command-line interface.

  • Enable fast-start failover to fail over automatically when the primary database becomes unavailable. When fast-start failover is enabled, the Data Guard broker determines if a failover is necessary and initiates the failover to the specified target standby database automatically, with no need for DBA intervention.

In addition, Oracle Enterprise Manager automates and simplifies:

  • Creating a physical or logical standby database from a backup copy of the primary database

  • Adding new or existing standby databases to an existing Data Guard configuration

  • Monitoring log apply rates, capturing diagnostic information, and detecting problems quickly with centralized monitoring, testing, and performance tools


See Also:

Oracle Data Guard Broker for more information

1.3.1 Using Oracle Enterprise Manager Grid Control

Oracle Enterprise Manager Grid Control (also referred to as Enterprise Manager in this book) provides a web-based interface for viewing, monitoring, and administering primary and standby databases in a Data Guard configuration. Enterprise Manager's easy-to-use interfaces, combined with the broker's centralized management and monitoring of the Data Guard configuration, enhance the Data Guard solution for high availability, site protection, and data protection of an enterprise.

From the Central Console of Enterprise Manager Grid Control, you can perform all management operations either locally or remotely. You can view home pages for Oracle databases, including primary and standby databases and instances, create or add existing standby databases, start and stop instances, monitor instance performance, view events, schedule jobs, and perform backup and recovery operations.

1.3.2 Using the Data Guard Command-Line Interface

The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts. You can perform most of the activities required to manage and monitor the databases in the configuration using DGMGRL. See Oracle Data Guard Broker for complete DGMGRL reference information and examples.

1.4 Data Guard Protection Modes

In some situations, a business cannot afford to lose data regardless of the circumstances. In other situations, the availability of the database may be more important than any potential data loss in the unlikely event of a multiple failure. Finally, some applications require maximum database performance at all times, and can therefore tolerate a small amount of data loss if any component should fail. The following descriptions summarize the three distinct modes of data protection.

Maximum availability This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to the standby redo log on at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.

This protection mode ensures zero data loss except in the case of certain double faults, such as failure of a primary database after failure of the standby database.

Maximum performance This is the default protection mode. It provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.

Maximum protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.

All three protection modes require that specific redo transport options be used to send redo data to at least one standby database.


See Also:


1.5 Client Failover

A high availability architecture requires a fast failover capability for databases and database clients.

Client failover encompasses failure notification, stale connection cleanup, and transparent reconnection to the new primary database. Oracle Database provides the capability to integrate database failover with failover procedures that automatically redirect clients to a new primary database within seconds of a database failover.


See Also:

  • Oracle Data Guard Broker for information about Fast Application Notification (FAN) and Fast Connection Failover (FCF) configuration requirements specific to Data Guard

  • The Maximum Availability Architecture client failover best practices white paper at

    http://www.oracle.com/goto/maa


1.6 Data Guard and Complementary Technologies

Oracle Database provides several unique technologies that complement Data Guard to help keep business critical systems running with greater levels of availability and data protection than when using any one solution by itself. The following list summarizes some Oracle high-availability technologies:

  • Oracle Real Application Clusters (Oracle RAC)

    Oracle RAC enables multiple independent servers that are linked by an interconnect to share access to an Oracle database, providing high availability, scalability, and redundancy during failures. Oracle RAC and Data Guard together provide the benefits of both system-level, site-level, and data-level protection, resulting in high levels of availability and disaster recovery without loss of data:

    • Oracle RAC addresses system failures by providing rapid and automatic recovery from failures, such as node failures and instance crashes. It also provides increased scalability for applications.

    • Data Guard addresses site failures and data protection through transactionally consistent primary and standby databases that do not share disks, enabling recovery from site disasters and data corruption.

    Many different architectures using Oracle RAC and Data Guard are possible depending on the use of local and remote sites and the use of nodes and a combination of logical and physical standby databases. See Appendix D, "Data Guard and Oracle Real Application Clusters" and Oracle Database High Availability Overview for Oracle RAC and Data Guard integration.

  • Flashback Database

    The Flashback Database feature provides fast recovery from logical data corruption and user errors. By allowing you to flash back in time, previous versions of business information that might have been erroneously changed or deleted can be accessed once again. This feature:

    • Eliminates the need to restore a backup and roll forward changes up to the time of the error or corruption. Instead, Flashback Database can roll back an Oracle database to a previous point-in-time, without restoring datafiles.

    • Provides an alternative to delaying the application of redo to protect against user errors or logical corruptions. Therefore, standby databases can be more closely synchronized with the primary database, thus reducing failover and switchover times.

    • Avoids the need to completely re-create the original primary database after a failover. The failed primary database can be flashed back to a point in time before the failover and converted to be a standby database for the new primary database.

    See Oracle Database Backup and Recovery User's Guide for information about Flashback Database, and Section 7.2.2 for information describing the application of redo data.

  • Recovery Manager (RMAN)

    RMAN is an Oracle utility that simplifies backing up, restoring, and recovering database files. Like Data Guard, RMAN is a feature of the Oracle database and does not require separate installation. Data Guard is well integrated with RMAN, allowing you to:

    • Use the Recovery Manager DUPLICATE command to create a standby database from backups of your primary database.

    • Take backups on a physical standby database instead of the production database, relieving the load on the production database and enabling efficient use of system resources on the standby site. Moreover, backups can be taken while the physical standby database is applying redo.

    • Help manage archived redo log files by automatically deleting the archived redo log files used for input after performing a backup.

    See Appendix E, "Creating a Standby Database with Recovery Manager" and Oracle Database Backup and Recovery User's Guide.

1.7 Summary of Data Guard Benefits

Data Guard offers these benefits:

  • Disaster recovery, data protection, and high availability

    Data Guard provides an efficient and comprehensive disaster recovery and high availability solution. Easy-to-manage switchover and failover capabilities allow role reversals between primary and standby databases, minimizing the downtime of the primary database for planned and unplanned outages.

  • Complete data protection

    Data Guard can ensure zero data loss, even in the face of unforeseen disasters. A standby database provides a safeguard against data corruption and user errors. Because the redo data received from a primary database is validated at a standby database, storage level physical corruptions on the primary database do not propagate to the standby database. Similarly, logical corruptions or user errors that cause the primary database to be permanently damaged can be resolved.

  • Efficient use of system resources

    The standby database tables that are updated with redo data received from the primary database can be used for other tasks such as backups, reporting, summations, and queries, thereby reducing the primary database workload necessary to perform these tasks, saving valuable CPU and I/O cycles.

  • Flexibility in data protection to balance availability against performance requirements

    Oracle Data Guard offers maximum protection, maximum availability, and maximum performance modes to help enterprises balance data availability against system performance requirements.

  • Automatic gap detection and resolution

    If connectivity is lost between the primary and one or more standby databases (for example, due to network problems), redo data being generated on the primary database cannot be sent to those standby databases. Once a connection is reestablished, the missing archived redo log files (referred to as a gap) are automatically detected by Data Guard, which then automatically transmits the missing archived rejdo log files to the standby databases. The standby databases are synchronized with the primary database, without manual intervention by the DBA.

  • Centralized and simple management

    The Data Guard broker provides a graphical user interface and a command-line interface to automate management and operational tasks across multiple databases in a Data Guard configuration. The broker also monitors all of the systems within a single Data Guard configuration.

  • Integration with Oracle Database

    Data Guard is a feature of Oracle Database Enterprise Edition and does not require separate installation.

  • Automatic role transitions

    When fast-start failover is enabled, the Data Guard broker automatically fails over to a synchronized standby site in the event of a disaster at the primary site, requiring no intervention by the DBA. In addition, applications are automatically notified of the role transition.

PK?PKFJOEBPS/rac_support.htmE Data Guard and Oracle Real Application Clusters

D Data Guard and Oracle Real Application Clusters

An Oracle Data Guard configuration can consist of any combination of single-instance and Oracle Real Application Clusters (Oracle RAC) multiple-instance databases. This chapter summarizes the configuration requirements and considerations that apply when using Oracle Data Guard with Oracle RAC databases. It contains the following sections:

D.1 Configuring Standby Databases in an Oracle RAC Environment

You can configure a standby database to protect a primary database using Oracle RAC. The following table describes the possible combinations of instances in the primary and standby databases:

Instance CombinationsSingle-Instance Standby DatabaseMulti-Instance Standby Database
Single-instance primary databaseYesYes
Multi-instance primary databaseYesYes

In each scenario, each instance of the primary database transmits its redo data to an instance of the standby database.

D.1.1 Setting Up a Multi-Instance Primary with a Single-Instance Standby

Figure D-1 illustrates an Oracle RAC database with two primary database instances (a multi-instance primary database) transmitting redo data to a single-instance standby database.

Figure D-1 Transmitting Redo Data from a Multi-Instance Primary Database

Description of Figure D-1 follows

In this case, Instance 1 of the primary database archives redo data to local archived redo log files 1, 2, 3, 4, 5 and transmits the redo data to the standby database destination, while Instance 2 archives redo data to local archived redo log files 32, 33, 34, 35, 36 and transmits the redo data to the same standby database destination. The standby database automatically determines the correct order in which to apply the archived redo log files.

To set up a primary database in an Oracle RAC environment

Follow the instructions in Chapter 3 (for physical standby database creation) or Chapter 4 (for logical standby database creation) to configure each primary instance.

To set up a single instance standby database

Follow the instructions in Chapter 3 (for physical standby database creation) or Chapter 4 (for logical standby database creation) to define the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_FORMAT parameters to specify the location of the archived redo log files and standby redo log files.

D.1.2 Setting Up Oracle RAC Primary and Standby Databases

This section describes how to configure an Oracle RAC primary database to send redo data to an Oracle RAC standby database.

D.1.2.1 Configuring an Oracle RAC Standby Database to Receive Redo Data

Perform the following steps to configure an Oracle RAC standby database to receive redo data from a primary database:

  1. Create a standby redo log on the standby database. The redo log files in the standby redo log must reside in a location that can be accessed by all of the standby database instances, such as on a cluster file system or Oracle ASM instance. See Section 6.2.3.1 for more information about creating a standby redo log.

  2. Configure standby redo log archival on each standby database instance. The standby redo log must be archived to a location that can be accessed by all of the standby database instances, and every standby database instance must be configured to archive the standby redo log to the same location. See Section 6.2.3.2 for more information about configuring standby redo log archival.

D.1.2.2 Configuring an Oracle RAC Primary Database to Send Redo Data

Configure each instance of the Oracle RAC primary database to send its redo data to the Oracle RAC standby database. Section 6.2.2 describes how to configure an Oracle database instance to send redo data to another database.

Oracle recommends the following best practices when configuring an Oracle RAC primary database to send redo data to an Oracle RAC standby database:

  1. Use the same LOG_ARCHIVE_DEST_n parameter on each primary database instance to send redo data to a given standby database.

  2. Set the SERVICE attribute of each LOG_ARCHIVE_DEST_n parameter that corresponds to a given standby database to the same net service name.

  3. The net service name should resolve to an Oracle Net connect descriptor that contains an address list, and that address list should contain connection data for each standby database instance.

D.2 Configuration Considerations in an Oracle RAC Environment

This section contains the Data Guard configuration information that is specific to Oracle RAC environments. It contains the following topics:

D.2.1 Format for Archived Redo Log Filenames

The format for archived redo log filenames is in the form of log_%parameter, where %parameter can include one or more of the parameters in Table D-1.

Table D-1 Directives for the LOG_ARCHIVE_FORMAT Initialization Parameter

DirectivesDescription

%a

Database activation ID.

%A

Database activation ID, zero filled.

%d

Database ID.

%D

Database ID, zero filled.

%t

Instance thread number.

%T

Instance thread number, zero filled.

%s

Log file sequence number.

%S

Log file sequence number, zero filled.

%r

Resetlogs ID.

%R

Resetlogs ID, zero filled.


For example:

LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc

The thread parameters %t or %T are mandatory for Oracle RAC to uniquely identify the archived redo log files with the LOG_ARCHIVE_FORMAT parameter.

D.2.2 Data Protection Modes

If any instance of an Oracle RAC primary database loses connectivity with a standby database, all other primary database instances stop sending redo to the standby database for the number of seconds specified on the LOG_ARCHIVE_DEST_n REOPEN attribute, after which all primary database instances attempt to reconnect to the standby database.

The following list describes the behavior of the protection modes in Oracle RAC environments:

  • Maximum protection configuration

    If a lost destination is the last participating SYNC destination, the instance loses connectivity and will be shut down. Other instances in an Oracle RAC configuration that still have connectivity to the standby destinations will recover the lost instance and continue sending to their standby destinations. Only when every instance in an Oracle RAC configuration loses connectivity to the last standby destination will the primary database be shut down.

D.2.3 Role Transitions

This section contains information about switchovers.

D.2.3.1 Switchovers

For an Oracle RAC database, only one primary instance can be active during a switchover when the target database is a physical standby. Therefore, before a switchover to a physical standby database, shut down all but one primary instance. After the switchover completes, restart the instances that were shut down during the switchover. This limitation does not exist when performing a switchover to a logical standby database.


Note:

The SQL ALTER DATABASE statement used to perform the switchover automatically creates redo log files if they do not already exist. Because this can significantly increase the time required to complete the COMMIT operation, Oracle recommends that you manually add redo log files when creating physical standby databases.

D.3 Troubleshooting

This section provides help troubleshooting problems with Oracle RAC.

D.3.1 Switchover Fails in an Oracle RAC Configuration

When your database is using Oracle RAC, active instances prevent a switchover from being performed. When other instances are active, an attempt to switch over fails with the following error message:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY; 

ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY * 
ORA-01105: mount is incompatible with mounts by other instances 

Action: Query the GV$INSTANCE view as follows to determine which instances are causing the problem:

SQL> SELECT INSTANCE_NAME, HOST_NAME FROM GV$INSTANCE - 
> WHERE INST_ID <> (SELECT INSTANCE_NUMBER FROM V$INSTANCE);

INSTANCE_NAME HOST_NAME 
------------- --------- 
INST2         standby2 

In the previous example, the identified instance must be manually shut down before the switchover can proceed. You can connect to the identified instance from your instance and issue the SHUTDOWN statement remotely, for example:

SQL> CONNECT SYS@standby2 AS SYSDBA
Enter Password:
SQL> SHUTDOWN;
SQL> EXIT
PK\JEEPKFJ OEBPS/toc.ncxw Oracle® Data Guard Concepts and Administration, 11g Release 2 (11.2) Cover Title and Copyright Information Contents List of Examples List of Figures List of Tables Preface What's New in Oracle Data Guard? Part I Concepts and Administration 1 Introduction to Oracle Data Guard 2 Getting Started with Data Guard 3 Creating a Physical Standby Database 4 Creating a Logical Standby Database 5 Data Guard Protection Modes 6 Redo Transport Services 7 Apply Services 8 Role Transitions 9 Managing Physical and Snapshot Standby Databases 10 Managing a Logical Standby Database 11 Using RMAN to Back Up and Restore Files 12 Using SQL Apply to Upgrade the Oracle Database 13 Data Guard Scenarios Part II Reference 14 Initialization Parameters 15 LOG_ARCHIVE_DEST_n Parameter Attributes 16 SQL Statements Relevant to Data Guard 17 Views Relevant to Oracle Data Guard Part III Appendixes A Troubleshooting Data Guard B Upgrading and Downgrading Databases in a Data Guard Configuration C Data Type and DDL Support on a Logical Standby Database D Data Guard and Oracle Real Application Clusters E Creating a Standby Database with Recovery Manager F Setting Archive Tracing Index Copyright PKE|wPKFJOEBPS/img/sbydb031.gif!|GIF89a}}}@@@...]]]mmmNNNԺķٵͿ---```000վiii 򭭭111jjjhhh񳳳lllEEE222kkk///DDDPPPFFFGGGaaa444^^^ZZZݓ\\\JJJYYYeee[[[IIIKKKMMMcccLLLbbbRRROOOUUU___QQQ333dddgggfffTTTSSSHHHXXXVVV555ܧWWW,,,pppxxx%%%<<<$$$sss>>>!,H*\ȰÇ#JHŃriǏ CIɓ(S\ɲ˗0cT @c.pɳϟ@ JѣH*]ʴ)O[57tJիXj &έ`ÊKӨ7]˶۵lۻx5]{ ̶/j +^ةač#K4.À)kެː@gp Ab\lVz롣fӖEg 2U@[Z:'[`^mo?m҉O=[V\q @~@ 0`T` 6hD$g"V]=t. G-ω[xdfx[䭷:=wa(ilyx֥Ifjqpy47'< 0 !-e&ʍe- `8-ӗ"8hH}ɩ>Мz :$|S k¬](o@eiV.f kg"Tj}a=`j 4:Txv )_DgSx6ٍ&b§_.½b0.KQm+oc@vq]T|~iN%ZV,:)w"l=ܨKи$ШOV2`qIzXFKQSw^:ҏ Y`bIQ"N)P~/HB7f-an4"ZMĢx-ޭ`!whv"2:)xg"o^ 0UK (|@r!=#s x# /5dRih)󑀌!ŏd r[l!mt g\JOH5p UsZ=hirJwya >"1+LA !#:BR&XĢ5P&fNb2PX- jd'c '`p$:1| $g8~-x\ч.B:6e&:Q XԢGQ:̓ B(V v@Ӛ~_NuꅞFjP@. H* A8u{TH@[u TA Z2AC%rQw,d&@R /ͮLgZSt;~zGERTA@5S*VU~5c-YϪֵp+]Wկ,a {X$ld'K\6@g}Њ5mjW׾}mmq[nq*lhs+R |W>0&+x/ֱX%[.[˜f5a-b%6 Lgж t'-cɽَ M8w>t! @iJS5 Pd35!FMSԧބI հgjָεw^׺xbػxtf;MjZ⹵nZط ǍleN nqݹx zmb{WwnoyGOpu{ znģ{-_W@2~n?1NN9̏=\m|#9Ń.t˼>:MN8ԣS]Vus1':9DfxǾ nu>kt6ީWNߡ-x~>x{+o<#?sKo/ͫ5虞Г{ G]~a7_o<;' .Oг<5|9p/[= q>ʇv!o?cxL} h=mDlD/=ɍs^򟿷u ~l#wnww=Ȁqg|Xx8} "~t(*,؂.)X !0X6x8~zF1<CD6у_t&}@eAH YtO7La4K3@eWHY\nPH`!da op$ik8Ymno^h"a 2ρb*!ˆ1MaXE1Y!腴23R!%138!2$BKaʼnjx 5%ЅUݱ"2!)_[:46xA%wpYWQ>3$??=Yq膃`h1a0b;"wYوc$3q2בYp6~F_ k،H09 h 't5hYw =P} 15b:-2*!ըrY$ɏDh `  r*;_p ( DCq4Pmm8 :A5) *+ؕ=Q8pX, %Yb C%2?!_җ#4H&W2"b,DqVvQa{12kZ);$'s p>2KC%R!"qOp QGyQC;kf0Iң&ĩ+"0T67SA2G;#(c0C#+I2bHўA$RS3 `q ^@Q;aKaƾa6fakfگk[뷾c\TV<\pf5kvZVsg|6\uhc* ]f]VY_va+fEfuiFZ rBL\h|G- V|XlZ9|Zfi ['ƿw&#g6v)LI#o,3L5,mǫǷP},zVƂl'l˅ȒXʬʬL˲<P˶|˧ L0Œ\ŬȜȜY b 6|ͭGc3;@YxЖCPHobSGX>ǮNS^ZEپ~ݎ-FVHn~G#^틄ąTI?_pIJTJ4TJ4K KK$LƄ/ɤLL$MTMՄM״MMNDNpNNoNOr0OdOkOOOiPL_PN/P0 PvPQEQKpQQQ R#pR)u]S2]4SE^eD]0 ^USU\UVbEV__s%dW}WM6XEeVX5a^4jvܿALā&\3hIďc5RIh.]l8SoSro^u^x TMEUO_o_Vin/EF|e UXW27amZp@0VĦ :tPP oH#$0b\sl!ERK)<0R&$znRF=A O,Ҵ$IVZѡ2Yl W6a=yRvY)ReDաn@W^i_$" b!X $E0`p#6lP /R'dѢ R8†#NhSɕ/gv^uٵon]-ŏ'{կg_|{=i>}3z(U~. @t9z \f 0Rv O8{A.tOCtLV'XsGXk5V.s9^U֝hֺ`\XWfsVhvjs6l1jFq]1>b>%`s-DW]v݅w[xR8y4_ͥ`8Y\\U )5uty ?6XPR%yGYFP k7Yd!(eYCu@gOubg tiꣅN=Z댸3f5Cvm;nwnDo{pP`W|qODJ|r+S9[p|s;sC}tK[ t[wm:skQWw{]v}~ug{uW^s}y{G}賿@Hs#u#Wu[{`l)"C`7O.@$ďw(\\wp+`.Pk`">-D- b4g6,`\  "wLNfsCB -p 0D\؉-PG?:ьԣw;yqIEÀ{PH[<vE x t-p(2!h;D B[1]t(JNQs pW'G\h򎸠#VGqwKXBWBpEK9,a]9[Ї , La*\-CeN`3=Mr\-m.vT > f憹b)kz'Oީ=>CPhP;y뤠 [@&-d49FR!o5DfiD)"`cAIY7g% Q[3web A&XJs2oQpE&oṾ 9+P/-scHJdU2 ,HKZN3=9RwmYּ`3kB9[P[t!iK.Uz40# ē#Ԝ1D<YY~+ [}i):UD@-B>(@J|:J  ߊ~b4[o49D8:::?  8g xFQ@[4,&|r.]Ѐ6u;P3#Y}IF& a QuL[6>N&bF"^Ru/` ]n2\}< .(OgtY7 WX݉- Pĺ4l`0c:{vu+M2 "hW,baŭ1Nᡮ6-p-MF&l/t@ l܌^nlz K H!ȝס7"o xpG\x-~qR!Y=q8oQ+gy]r\3l~s@;y|SAC"~t5$]ID5pATTrc[9ss]D'ёt;]HA 8`^1'cL2nЌ4^N &MiW A;R>w ^,̾] 5 X4Df|'S^ o2`O$g{S Z4$ViPG>A`8b OқI%z˴-}f6߽;PK!!PKFJOEBPS/img/sbydb044.gifJaGIF89ajٿ???񻻻謬sss@@@333999///___;;;>>>oooɷʶvvvOOOƼ<<$Сw^hbʼn ?n!H$)3TPfCm9M;khМCUzTN8&Z񢀊bZUծ6:wU;bڵ*|V@l]x-uW{\yreJ|y`浛=wYmhңߕpZuխa[<t {wソǭP7 V~qb!7psϱG>]{uݹLxџGzῗmmc|q`G"H`1`.\$*t!Nȡ@ء#FbȢ'b$8\B9*=A 4dEs$:$O%S2飓WB[Re b9`JVV)tix|矀*蠄Z[o袌6裐F*餏"f馜v駠i)jꩨꪞZ**무$zr< &vʅ;кD ->Nv}Fn@Ůö8Eҋn ;lB+;7;f;;kƶRmW\к L-ml8; r+.Cj70cqDjhrky+qhvȡK2S}tKӮY1unƴ:7N0o!Լ,gpۭ/ \Jm:OK[ťߞsYF+nz> Yo{l;786YLڿ!3uʌ{&4Mf|f.AޡA_B@p!ܠnhJ+Cx tw)@ "|("ե&:PH*ZX̢.zBܜA tc=9Lטz#%6q|Gj az `*Ue X*#$6 l]j& wuWXV 9U&`>0;X WHQ/w! Aw A >}4, Rا3;pHM1+^-n m6Enc)YʒW7`JiP @W6n&_dvً`R+m}ֽaUHg @X oUpT`͙-]z`mϻߒ7ҵ@&+$6.=ps;5!VۈTbV ؚxŦE%|K Ad+e.Iqo6dk'4p@\2O3;"Ǥ(LtS 0q1ߗOuLJE3zt~@p>+mW{t]VQKeTۢphG[Zͪ uf&lz͂Bv@ZTw9ث}DMWڬYr4mZN pmDMWw %Tq@@-fzV%kK_ƻZ܃ɭv@){ f kq;Ֆgr%I%;IAm(wK{c{o }  )`(?@ARyYVfX@\Cίu|}6L?$tR[YRٍ̭(g~FsLq1Wp_Ђ8hpH-CMT`GX}GK~|vLlTmh'b"HˆpXJ{(ȇ!`_ Zj;FЈ"w>*O'''r'Fpv㸏pPH|aT!Hhy3 Qh Yj-D7BR+UG*I >IhXj3>-_`6}HrRhE'$M(#y2%iR)X)_-KF(2) [8b5)*pp>Rti`wgkʴoPx8!h  ( (kYv3vwYВq]ՄUVUvyi9rxgyR]pi6yXw}ғa ( /X-Bw-oYcH@JY*b&:VSfw@@ lI`zB F0=)+bPG`OEWJ)K'Z(8쪹^+`[' 0\`q෮70 MpVY@;BFۓ* h 늸Pk VvuWZ)iۂ߹KYO]'_۹ 盾 *40 ,&@ KN[DwR{|Rȷ B10pIMQ̿[uv{Rԋb\ƮI [ `Gp |U fP6`E\/'$v{-% P ;Pa1\KÌ=A<ĕ|HLPLLb ZZeeʄ6;}ּ̋ @ ۞p{|\qbY^7_F( )|,`gzI ؠ콈+˹kLɖ,ş\'Zl<`{7TRUT.r@uU( ` D+Mo -@JlnkecWW=p:(#l WGpǘ ӆsm29m;,S{|6mHTlWM(Ym"Ѝp`D`=Ilh݇x o}kT6^DqU]aCU('%0@PhlI -p UP=r] 8]ÚÜӓB-ڜ,ϥ IfMk\%}R-0w. [Ke`m@pU@-%''VZ]m pi @-G}s0}'3ٍӐڙ n|vT=]0uiUz)(nݹ a -@^_n<Uխ'U*(C'E~޹K>J Pr@83x|t <#33(P梊oNԤ}t.uRTɗK6,=@ C= NV\xa&m@pTR9VA>q /"e FpVo^4s.;'䅾LkkKF``+ P >$@C0®!,E=Ϧ]-~MP?TWP.z,b}f 'n9) ./?.boࡍ>oGo۠ )P$8 %@X DP!4hE',XC;>|" ИtNA b С#LDP (P[B(J]!hd;0ihhK+HŰ$MX)(TQ Z.fc sq"E2n] ]iԥa^! enEmLn) '^\0`1C#^άY#G E4R%K0esgϟA=tiӧQVB_Z$kd j+j.ҋ/0Sl  J 02>@A0([c % KbqFgl f6.xDݪ 8B4Ȅ[9$ D0:β iNJi^i|J(BJ)J* ON8 @뮼+#0p Ph:TH2Ha wBuTQk4T[;&pU yM)tׁz1ZW.J0NLpdoܔ/Nx5S#ВA,$tCT4Fw,}Ј|s#|ˆw&L 0wz @aߑ { w8N K6F`Due[kWHO8i"%@bg㌅6î$T/؄䔂!3w,to.x4BDE%\L޹bAbx6 8|C ؝I SP)|sPPeYs'b>A$lagهz:)i,8{k;3=?tP m0Q++{!!S-(Co@tpAQOs\ tC; =NHYD9\Ѧd4fiwbZ%e yU) "6u-g6{On\x8w0q@2> BDƹ37@04AxF4ьP`H 4ewt:\h5Mx2O񤦭Y[͓Sgӡ{o<V*ؾIWHH,uXr-R[,NG&@0RDdYk86zD%:da|t4XDoZOk$G5n-kC4[@mrl|ضz/nwH`|EY d?8.>~m19LbʘUH8<@,@M#p`8\ sG%o:KiӆWNMm[ʻڷN,5'˶C D Ѓ iweV$pa;**@2:E`Rl+_񹌚58FFJ܆ vCpRQIach& !)"K8Ο^+d:j& ]ך:ϧzRj*Z!F6!VYps{+ؕ (h:j Xxn-8Y̴иYC0=]$ Btu/\+Skl-)Z72WH@Bw`/)L"F@ܨ  +a,;͂0"OH]g-F.9<;Y2R\a:JI @t*,$T2 UҖ 2*&8SU7e>DA]jXI\5]E$9ԝ$ܑ./,xV +hN";5Q!6 m;&1U| \r9Qk`wkvpy3W %l0>VX @!a\08<&ZF *@1؁N0zE>! :Pl >UƶQ` raGu]c'{82qz\~ר5i&`@!U'_Ȱ &x<O J B~pG)) (_v؋ <6ptV c'i h_"{'_g-׸{EY@&!O5LgBR.ƻ}3幐H(Atwу`MpI w9h>QbUP6w^p:OҴ8w[E0@lALA| h,S %؍k$?˱ $û)Zp$J˓ ]Q!K?ap5x@kp[YC*ۣ= 1KC7RU>!5-i5LDE\DFlDQiDHıB-Aꋻ+87>h +kRT8b!ǃv<3*t+́Jp^Ѓ0@+8a`=216p6R=I@ C\Q]h@DGQH9;p0L(N:(]7H Sa5Y Ȁ15( [$p@En$L1+(\ŃP @aB8Pqd<-pH2xF"K8ԤtQg2jj/aízPQٗS+20Jl8܂Ap2Hb)))ȨVHw8YtZ)&(wF Ap)1BA &hF4sprE:Ё5?'sp=pM8w`3qpHȿY؀PTw@DX?mwPE:J`RuC2XbTR+<]؅K[eeI[nh\@ Յ[NӾ.-0O1uPw' %XQwph0pp=ÀO)ip}:mLŴ Lb-c0rOA eJN(XP#Cp7JH(ȊX $5ɭݕ#&͝Հ % эUc8PQ]Z[(%̳]PI>p> RpTp0կ@VJ4[^A[jR`:=UAcRׄ#H285L$S6ՔL L+`YŃ(&H]rF &Mp%rlBPߛR.#+H;J"CV-`J&;" XYdT.bwI_xZ? 1Q PyHJp(@H=W:h@Qh?cBd>FaA%]a>:dL0"W-` w#wpN Q8e h)BVF ̄xѫk P`*>3X]\@wA8P2=8^lDU(F >qԳشXuew*bLQeR)vo2-)p1('9lAO qQ6$%M>ǘ'}L@Xq.d-i~k1E> Qdj(b9jrUh*B3R>v㲾Nd}aMDOll2w k kNM)>/-[%cNf?[ |3ѓn>&r`QP\Vȍ#>hmkVm[m$oЕ D]i.ֵU&t~N[Ahp$: ' 0f0>ήQnTfoXX>l&d^6pu3m&60EGfy>SJR#Jmel#%Cl T= o6kA^7q+"#_"k5Rxr[) T&<7-l/of=Ni]Tgs:(w@Y'8r$3&rKGtpZ-o.tޞtDhLPMqN}T8R]ߕ/u6ޤp vn@Xb!1uߚuN`aWXDp!6 pP/gQ?gLn?un 8pD#feF:ut`iS;t_~o8okXd_Pw\U&xFw7POl1@HywqʆupD gM1g .A#G^h^h@oWHWHD+.Lyaw=gg4Kٞ$2^GzWzicwzblz6o^p4o+藈 0!}"O$\u P`Xdwxgh> pkwv|rVw ؀χ 8:EȶzwC 榦HsOu2L,YA (Q!B#`t-8 cPƈ&LDPa p(v'РBz ]0`pj@:$ :^(P qJZMV=UW|XeZm\uݕ^}Qy^b1ո*ЇWYhVZk&mM/ơJ_SA}eW%Yf[!]*E!_~ywz'6D0y';y$\5eV"\:\aN8ӡ!ƒ1;rB;w;b26 Z60qPRgPJ;\cՔ[6%f'y)'20,T;I; @h2%]>بV藤T).֭l ԇ'*w/hF؍5К:Js np; P=U)o* -uYxb*C%Fу2xx@S.T_R .[s+^8A \3I0İpJF-TG5bjk32QJ%Y (7rA)Y+K3v%Ӓijklcu#BwJ}"N{%מ/]9MISS4[=,`K/ZFҮqED݊13,v?d s)| w 8 3L15}nkxJ!I.@ @e n8a. PlzX '롺@(6{V4կkB! vSbC@9H#@P4a^]5:~QR&5ޠAwd4 wgq {$ߒ@Is;nkcȀOLv Hl1ea 1>^xЅmx#R1 A(0 X"m$GiHI؅& KJOy "q8i@QI)щ$` +ԅP`%جy?p",0 ePəBI1!`KJJ-0q PS܈R!C,T CB4%8 POHA ;$;s̢6x-n `'8.0  4f-N̪8a7ܡԹ*5vU= z*Xi@gӹԔ`A`W"B2 0$VC ; f  Dcz ` x+pYzJ N`!;jj?P!`E t*p \D"HEp @}Ob x@$K ]N"F :@@ _`%85:@#_5AgxC`C.:Ё&L e.50r8] 1s̴ ,d wzZԦ'#3Dn2S(SO22,sWr\. lf4gIfY>@<ߙ{nsg;́&4O,DыVWե$Ċ.|LdӚn3yNjNF-RԦɌw:jtA)5Ov$`D!;cZ_OETOsmioݶvnmvC/nyw}o}i;pLr G{pG'_xpX@Aq? 7{<-g9OV^<.NNs\<Γ@yё~ }'FҡO} o;Ŧ8)þG=>e>A'˝p;CS|{Qx&}.D7#/y ~򖿼َsǕ` f  `Nzab"` !aaa ! *bRN ""!&b^ɞ$V%%^&n"q'~i(")B^)"*("+Zb&",>+"-,".-"/Yp}OUc/.#|W `] ET3~! AO18N(D\"!l1"6cǁ>f|=&<#5#AN@xc5;0?Z@C6Z>#Gc|%[(|Cf]($NdH>6cI.$1cG$VdʙA#գ4JN@6$NVL?64N <$H& 0eSʬp6Z>MnVޥUcSNǙ!JB_BlcVABf%^VȗEcA1 4K<1BpfhBd"Y@lXRe}Y<ئbڦpAo69f@:Nco]:@-&b&nVgeuf!9`v~ |xagXO0y99fZ ({1!@wZO4'$u'OFe.5@~&%N(pDR wh 6[(-((C`h(hDhhhO[)ON 4iBjirizfiOd@O阖viٞbDĝDĞʩi頢a~a !:A'%jZj6ja%ꨊ*j*jҪ&j!7gB+++ JPMYa+Nj+v}b+븚kVOx@r+ԼDD;kbz].zrҫ2:B.lOFOX,bl^B#(rz>5J^="G&b^ʂl#},&&hͬޔꬄ,gPf.-rz-FmPqɆ(%}JSq쬆hP(O6優&6i֬xFqq]Zs"@2Fgv6 $iZ2;Э;;cC6*8SlZ<;X5=nYOgJJdg#¡m*D>Egeʁ->>ZbFN$ |h֡;6%>dIv^ƭ:\;$bAzo2evoqo vJuLDžAomoevN^fdHcA6:qt10^:0 Q\pN :0]mNp PO1O 1-͎nBAA\=kkqScqqc{Υ\\rr:±\~DZq1q˱ ?0QDN1O) R0O<2F|RrZ2$$W/&O&W'_r(g%|)ru/*,2-+/-S." SٜD 332Y11Y3#1+035;YZ!=;|3988G:39s9s8;{3;sO Ag6E///4Ps te t,E/@@E_A!AGaN\%uG].+ Z@ItHũ,mج$Ks"ŃiXOMo ꯃ⚒|y37Eu DטB/SOhQ";@uiEHUXVPo t5Y>EZZJu]!AK;@ ;Cbdc/?t'2{tLu!e@O/d6@;Pe ]dPеh I^t!A-TO@NZqTL;ww״3pCJ$wP,7/${KwE{w|~wwOKxwCe[&xl;v|7;wS7+@$lR U`7wM@{_H'Έ'btdN{ht"mw}#4y7EOPxo9{I\9PA8׍Ly+@9\9QS5$wQybN,ev4 To5zAϹ9|yN؁Pb48'ܘhߵH?9O5KMW\7~ kyz|#Jjx50o5Q #esٱA#<{;@K3YsW_ :|ŧj L<GsPH˫KЧǿWC.r\7+@߶LLP;{ D;O@8EC7Q$xPs}XGls; 9dk}ŁhPO(>!/;@W }ߣA;oC ;Avm3,)g{6[8l6OO>l>㘊'Sy7;vw ,K#!k6 ;׏6?C9K/?w 4xaB NLv)VxcF1("w@&$\cAJ~pc${, ,(x3  FCK6u39Vz+F8j d5{#1h2RqW̫G ]ʔ $9{,,;& rd'sfg;4 5 GLٌ!x1x}Gd4HBp(}(݄=B7wܠwGLW[ПqzP(]  "<1'|$o&#B[N.%2hp0<62Сމi "6|[mo= }̀ z>4ɪHB~AҒ, 5ժ"=%L| $* $K8sHŌtg)ݬ wT2z>@e+/ʻj,9 #X}LlO)LR,xK3"ƆV]}Xe}*Ժ*T \ĒMlR,55L7]w<4B!f5d *@.h<Y \ w(؂q?̭ t GuKXzS ;b!E,^>;_onߪK /מtu3G/{1FLA Z  * -3"cT/^˗ů~_ 00`ߦd0 @a5ZgazX]c.u Q< l-}@)E.B=W{欎  Zȅ.2h7tx)lVnMmG\]0C>Uҭ6`Z!{,mT>>lh#'zJ>vo eRWCl)mnȘE8qMX@-,V[27޵{w@D>3O4/-0܀w t A& \9"8AFSy˙Ԙ{~qao E e B@RN.. 6 `J. [+bϮ  ao ! _PNEGHLQ/Uq}a \@ >'z ~q3N  a1QO z`,MENNl}h RUUN2 G`&z `6Afր aUABO0r UZ--#tM%;V%s@44 J \] &N m ;/r?a b-4cT.95dFvMA–@h 0 'Uo Ppv9"p `hBvhZHz6݀~aCK,NJ.hSv =е` @ fpl V`Nqm}Vp` `c3ȀB+oPjp םWEv!lK s:s[CWI[0@NPS.['l! >K) +e7quWx!xrC FwA~m D |>D! qpU o{]/v@|QhpJn p_W 5g-f3xAa^BA|FX6*!\bAQA` .m$8{հ?`ۏJM4;}p)Sqj(#h 44 "`a }3*H H@2Vv &X7UΏϏ KGA##>MsR;W6,W7\ 0ǖ fK yM``ؑrTD4u`*@5V"]9 9 yxٞ @`,!L:9Dm;MZA6nH 1 xAQ 5|3RZh"@@99 4 b!LAuzr 4 7A.N tJzGpy3R?d4" fAxvJa8 Fq"b)X9. Ѡ`:T>h.@5@uwK{! J[R]* ^ X)!ۺX@AH |P{Zܡ L`>@Y9@ d:?Μ@G RxD{{AbO[[۾3l@$A!Ǽ 0X al!@!!A@Ȁ@ހ Xa`;Kikk|mcL۩eem;efUll/@/`Z\7ƯA hЗJn:ǟpL+g{rft{vz:`!al ױ JNϩ\MX<Rls +9]|`OQ \| +P`}{ L/ð"< @OqB_ٟ a ۯ?_'@뱖w2im׳Q0 sv}HRaLXo2ܽr+x<ӟأWޱqH )6].F I!ճ}~(@{Zn=׍+}=}ylY->&@n=`@ӻ%6hT" \0[i!Q#`]v`UmS>ww]^jJ~~\{sӥ7ZCb tїz`_\ϓ}i,?9}o}12ZN@5cwh Xb`LNllZ|X#C׽mv7\f|ӟF +{<_l)Rذ! @h $H!ƀ:1D*@pę14kڼ3Ν<#PD(NLz uSXJ(+k0@t0"14rфH'SlDLtڽ7޽||w -*@@ dРANj `A H B ~K"F?YJ8r¯D:5vh9$y6m8wB %K0`PРԢ0bɲFrIYVs7Fۿ&y;; vb1cIFeiƙgtPB 5PDUtQFz르R"M pDE\tdDGu+iw&1pWaYdއl*C+%O7@^G@5XdUvYfu@viNjz"l#v;Nl_;SHb&$D;J7]u>fReBp0V㕗yi'8#*(h4m @uM6܁l.rFXghi|!GFҠ 8N90階=]a;tiAК$yLQ@2D"k [+"exgW[`k&ئ+!x}V "7*  0LO@L1l 9Boz;Q8Wv) uq& `7{!]+I|NU;"q7GΜLg}D/[[wu\^v9@^ 4 ~ 6ٱxgjZۛ-[n=[،1o꼬lvB+$r7-˽ەy]Toog|)Ax_k,6dּ"g#i )/B'hL z+B'.Op 獅_3ZB(`Cw%9O @VǬ ҒUw>`/X~OA^WE0q\G2 *hZq|Q!5ʥ@YaQ>/h :HRob/@;A F i`JTzE°=<F zʚ̨^20ElPRFXU atB,ⰇB3P`r@(Qߪ%kɀ H$ !ĺ6C3450@ u&H3Bajv9 ( {}\BeHFbCpA%\@"PL`H\RЎǶEm.mp1I¸HrX@j77$_, وH5*{Qzɾ ƂnHf ȳ\Y3HZw' i#U'R|[;bxL֍`|{-"2 4>p w3Kh'-W<ϸǡqm>$`w#.Wܿ1Y3ss\8y/l&t$+ӭ.PݿX֯d:]bgQD5{q=L{ w>O|+9dy|y^+osӧ}I_~|5Ml_{}O_|}azG?鱧Kc}_Ͼo}I}tFz~?OvPvn7dthve'vgvigHX( ؀ wvgx:"`;PK6SUOaJaPKFJOEBPS/img/sbydb055.gif"BݽGIF89a倀@@@???첲999rrr000Š ppp```﫫PPP߰///ooo___OOO***UUUGGG|||vvv:::>>>ݻ<<<!,JIIũԝ⃷ )ջn (n | #JHb*BȱǏ 1ɓ(F2˗0cM8 AΛVIѣDHT`-n!")ISOCj5R\JL$ z8(T(@"IN%5?ĵYJdڵr8! TIB4g9mJ dU Dװ}-@IJ<vc|M( >@(a ժB:ة.RK-d❏SYrDGX݄yƕdF@]eӱVAeᆰW$ &bYA%V]r]x<#(uo {zW(؍q٢F?v饗"YUZdZJXe%l $;i@OOlfYIu_*(~+y蠈&zX裐e ]WrhbA&e*)XUjJ"Pi8*꫰Rt ]%0t$*! '^mޙ1nNd(&Ysd(їDUڑ5(S@M\jcw dAEo~dM6Id&nA`.hޒ '•W-'-7jTkr;niWK< "@ej} ~+'t8-*̂T'!qPY.pA!<( .4ԝ|Ӄu>_,V4Ah43Քw{PVvA6}tډ..ְjy靪:=N{옂0#ң/+B#࿃>̏R3"g(7o0ZM--b/>G+dx& ĵV rN}<\ܠ"eU B3N4⊊H-0j‚tPEA* /AԒ8e% bNg>m nCY@LZ_$!E#Kwci`rvM̈4@4MP,nJpC(IrBWټL)s`zuT' ))(|Rbh]!r`7QV3 Rb䔩pO)S$jLY3ЕL*]b5 jrHԠ5lNC u) p!g4̉vvE`;yx>ÇWd󟆱3 ЂD AjBDD ;2DY@64 HGQ\(I]h@Җ(FgJ8)N%T@ jNGӢĦBM*x *C5TaTꔩ:IO UNi:JֲuX݄S dUX犘D^dLի{ ="% fH`c'kX e1B 0 n6جeQ;p-l [r6u%vݬnA5nqq\&UBs\FwŮo]v׹(ՎwyˮW{_׼Uo~ݻ_׾o;`ؿ0{]K0xVm<ov0abp7[×P" U`bD\-!n|:6PBE>r'dDKDd)GYS6D|e%d9 [rf2+gr$=ě'gCyuv3qgByψ,hBZ·sL?7:Ћ.V:nmcivzu",=jLZӧt,Q[ܞֶ[O<ҺUl[Wz~m{bsVnl6[n;mꆗ6m݆`r+XFw;nufw7M pW,`~g)!YZ!ֈ+&N' ì !O>{.()`UNwh0ךk}ܜ9Gyχkµ :1 PG$dHD X"{kqf@ 4Z|E?F`EK @u NbwySDj \pSoȸCpk/MeګY}(,U@fA lOU @!U8~)@򘇾KaTtK#c'j^@zQBoB  Q7%|w hpbbQ2xw>P |h[`5\7ւ7 7oQ-^ %^>_Uwȅ 6hF&ZPHsf.e8Ox^( '~gO،8Ә evwQU.(h wG[}eXbI`Ysbf؅yu X'8 ppЉ g` 0h pgHF+6#@oFf l (Ip+@r Q@jCF (|8%IPViP[vF&fJp`ف{ޢ{xg O}=yZpHJwVlhb(Ѓ L9F}@Pb(9^К@)Yhysva9Xv }AH~F1PAwJ;ZO&Wꯗʘx8gəp) #8/õG胼) -\[I_C(^KZH[ pu%v^ S4[b:Z@؂O@}I~75sP󸞵0Dx~#tH&8e(XvpY( 땀w[8fI``ق~(J `K_YA  ;1`A R^HWe!t v3 W8}*I0^ПXx}-ە` ˭k*Ux8-@Ȋaȅ3 HrJ  ؖO斻ۖ 7KӮ88J(lKrԷagHgdeKdi P 7R ;Q땜W^tX 05gSВxgZZs{}k(l2\-i[{Z?zž0¬blUǖsúiaT)OiWV-:g[#ڼ.AD9ˆ=Xx̊oVhM+P,@誐ɒ<ɔ\ɖQZwF>8Y\©[SZo{ggẇ~\yٚ-)e[Qܖ˷f Ljyf|œ 6ա#V%o^OQl\ݜɆqs<φ7d?[ $I|͍͝L Lz T =Q W:]M_$F}Vx*MMY &,ұZ)M  Ɓp1;,0+ 'Yɼ`s01MPӖ`ZФNӓ= L 3 IyӋ X  &yg /zԞj_ N]*z mi8=Vxd9eZZ9軎p]r M C{=ȍ%E}ԘW}jզ}-(XL!4P!ct*߁K^T9:@,jۮmx~~꽞MTgxĘ% J IN}9M녍p g݉L !k{6Z4*B  .Ɣhރ;h.^\.'U&PL&^U[Ŝ| {^ !.5Fע P? b.~N=t;_}@7e]xܭWh@M> Ŝ^˜ٹꨁ\|mC?Ek Eٙ%NrSq.!Єy<ۗc76&?å[FvL{^? z |s~=8#4@Mt\ϵάکj,tߕ^ g( /eq/JI IJII!%I$I˖Ó$I&ۑԄ 舡۩$J%I ۊ <:yȐ#.+UL(l= X0Hd`L8QJ)͙(hQ*@%4m*D"`pX"ĨOA pEEc[%Np=J;fH202C)7јFq+>4.c8:[6HD"*%k"w/ fnq2hn+s+, $YGկPb9]0 , P_6,hJV]N kpPjc+C|$3߁| / yYM['dJ/-ubހ%iD FĬZ`SDY!% 635H)6)DiH&@%AA5' ( ID[2`HQKiÁJl(g8D(rxMҥ@.7"^| r|#<<.r礔Vj}jM" :߄v$ JȦ+} ks(sU~Re+&=ǘ?Ebl(RmCO~T覫M%++֋.PrDMXZC|J{I GK),i C,ؐ]@l-+2l ^f`əj$5<ϫÁhDm5SvLTyÅ8&@0uG6mop۶ ?<`x|4dКRe̟ڊRYws sgyu砇.zl 6$z kMDdgjViTCӿcan$V͕ PjI'8l)xŽU n4R 0M&QБ 'C!ҽIk  P ,)hBT=s:&!0JG%@ +1ACo GH#d&+@؃$RqeX%""ջё QS!g%gx4  Ҷ|f0 6M&F n-1 }CO$@A0Q +#;&&OD}j`CC-Q AO89%X#xEg#)Ebe Q %2L6Vo9T1!=Ҏ,,dpDRltet^/s0l'[Q("Jytj@ ρಓ Ѵ~wg;FSD=)E a$J 'EcebTfa}Ԟ<zds 3?җEu1:+[]DOhKb s"WDhfֻ0 A $ @Pd,ɏpnY@0a9rԇAa*)h$inyD J~hJy 0|~ BXiZYsHuy0{ \~ 68{pDuw/鋵HwxX08aƕhD[ܧyْ@^Gm0wIyuyGٜWu֏zɜC} jEYDߙlڙ9By$QVY0 o'V7TszkR%Jx@(::i o?~FʞZ1wt7E,ڢ.02:4Z#ji<#g@:ڞ"$=j?|C Q5Ezy 牃)G(yy5`hքF5 J 8x~ DʥtlezFNFA@n@N2JjKTnw:Ei{8Go@N'r 4n <9ZwzZL2IpwL"Ӂvsש~I JzRCt *J!˱Il(0z燦IIjzItЩ ꬸe7Gze |WKJࡴ:խ*z~< ;\iꨡ%b yY. 4{$GC PBpyJyyH0`Xg8{mRv,DyX[>b$ itQLDGzYs7uµi[6(`h,`[h[KhK;h;{;K˺뺢 Kkh(`,˻뻄&K`˫J Kۻ˽뽃ffh{hK0v뛾KKhK۾˿J0{0 |  Ll|<<%'L "13&<`':Å?Ä,ELă` KJQ RLWAGM l0 dl#a\cp|s,DŽk\y|tv<xz,~gw[pJx-Ž<5 ),×LÙl,,ɕɘ|áɣXlŨCIOU Y]L_lS Ƨ,˩\˭ǀJo\Ȅ<\le<Ǭ n<\́|ȝxTs*l+`|΅΄<|l<*`+p]M}=m !=%M" &MmLL(:}?AӘE G-IMԜkMOQԠU Wm?Mʸ`p,4fpc}jmin=Mjt]MJ ?suxw.H_ q_׌o)+jj A"{؞}M]LڗU*X}Q|'2'W:5W ׷{$sۜYa+З緟mMS ,b >A$zh,$ʰq;{é޺Pbi=Gz:wA b9vg͸ ʲ D.,x{"Jw~ 9~Z0G%tt0['.wM_O| $rj7h 1>n~둴tSW5n)$d+O_]`4.Φ hn*e$ȫy8V7zۅI`2價rj[ޱ$>Kem),;=.? me޷Χ}9,듼(0˲ ~[ \ΠCrb"J|HV_v03$?ŭmN]h}4NXKsAج 's$INs nh3nr* طo٣NFp;N ?h䶁MIRlW?y[ L*N|R0M r( z{z)?Doص LNPL:jX\?m(PU/ju4Op5K *@v[Զ F ҆Q@bTIwF C0NH S>uf[m&ߨBugRkG  5Vmt|M8^{So[DoďFϊ"τ*$M4矢vgo`SJI $"J"I ƙIljIӃIڕ䆛II I!IҩՔA-т [L`~I.D X5PĽcȱcq;ɗC4k1dy.$ BYJ,6 J0ԧDZ$#TgNxhA +{(#d0Jj}iU L u FVh\H觠*z:Z=HѪ棗Y$I $t#Wf4b]Kk ''dtЎ JV*{5al$Vfjtkj"$VF۪Ɍ[nZ$ %+ ʫ5 k3@wnF,YOqdw ,$l(A5F8aB^i~x4ۊ麛f"PG-5:.M2eV@AIҜzYPj\+akDܺ< ݭ,gƩm\;]7#mVLO6iv--}(dMYb҅ qSu"= ['c9N"Z+Yvk3ҫ1qS |c"xjW4XEHO?e3|Sq/)C)atC O&qOs:"dlN]gJy~ G Lt6,)Rk_׾j$~CD#8pcW"@ ^}hc=@9|dA ZӠ":F@P jC>\ކB0pM`![``dX fD0sk!'/ %=g"Ji_ 1ҭ H75{3}&A-`u"D`pQAPne(ehҎJpPKO[#hIL.@%-EyKSPXW|&!y&&;HƍD%1%<`$0 H`@$ HY(0l=ܾR P g)M9t*E<{(?H@AQ T఩͚Bd4FJfq)$#x~4X*B%m*RDfQj P=+ jjA`UJe%gS]@UpUA$a@f# 97fBK6U .Ҁ1FI44%X(T*~%bִ,g[d׹%@$hE+^$ 0|m_1¹P|Oet`D}e9 ,vJvWgaZy鸛VR=y#Ƚ%/!0A#x#˰^m$$|س4OB>iT_{ZVP;>ubAj yﴭ*Pƈ(k\[>s=j,+S\pY*ט*“XL22";"Vgp"jl$қ=Gل=:7@-xM@ ij+ v; K٫h 0zV4YKO ?hPJ4J*#$E$"iG!8CB1 |u|-6 @r{S3|9ErWr$9 pp^qgxϻ~(c0#jE\C0mC<#Y,=#-) k;<$hԨ|!D_rW.xT/eg4sM#ɇ[> O`$$r0#J_p ݈ȮC[ _~#;߽w p_Gakq?Ssa>Pv ̴LSIp\t 0VuoX$M%^ĴP(B Ђ.0284X6h-UJWsԃT~IPpL؄N3a\q3r0v $CZ!5URfPUDti_RSPI%OsV07='%7NuEeXQWh0DN$a~X2Wa][x AL`auAMV'S5, TYcu%IdtO}h]WUSTI"H%Of%cH X҈%PxC!L?%~Q[2k!MYB%UI1 SU"8 OW _M3Uv}7Syb 5HXanwŎ 6J&J`Q`Տ`zT*lq\r%myV'0u^ wdEpw`%Rb6U0Vb2\$>9 IPKqfH&"cS 9Ya j~s @ByvDy ZI1ÆiFTsTVQMk% 񸖄iQwWnii6NhG9\6^㕙i@Yy{ s}9 po@ ` {p)N gC WRלxdT@C0ЙuЋW2)ĻA;{ͫ;9~ԫva c˸2૽{% 2&몼`s9Aڹ~P|;+;& ^Z[ $|f+W0Ca!\&LI`0'2{j0!/P/'R8><[:r1?.aǫ,F, $V2!ZZ 2\<2_,2aņ`\i\f<^b dkqL"z" !cZdžPȃ|#CȋȆ<{ ɏJLɓLɗl$cU42&TDʜd˄ʟ,2 ʣʥ ˧,˩L˫2ʯ˱,2I2<2ˆ,Lˬ̄02sl܌wLo,ٌglL, r0}3Q 7  nA^< .,~&#N%~,l 2n/.1>8N)>+>N+es (?KBL%/b;+''ٗ3e 7n03cM2m+V4W2mqag7n ^P+%&pm-C4Qg~uq^($@"+..46MBq0>NIN!P+>(ꏃ)"= 걺<!>?ڱVG=aӾPꕁ Jp`Qz&\am~&.,.0>Q68:o@BD_L~ JL߉+7_9TVOXA?b?d_fh/h^/'2r?t_vxOnBWm?xwgw^}?_;PK#UY'B"BPKFJOEBPS/img/sbydb027.gif45GIF89aCCCZZZ%%%ddd333VVVHHH{ydTTTbbb(((*** EEE DDDkkkNNN### 666lll@@@<<>>pppXXX;;;wwwPPPrrr444RRRvvvMMM]]]hhhmmm---,,,777???JJJ̷555===zzzggguuuxxx...:::nnn^^^iiiƥ888SSStttěÁKKKqqqfffoooQQQ111{{{\\\sssLLLYYYǙAAA_]^534dcc}}}Gmlm||yaaa͸et`dcdUUUIIIkuh|{|ı=;ݘa@c>dJBNH,9aPVQ >i%JR2H`eZQ~ifcW韚pZy"m@>xBbmޛu.w i1iFvt}Гs+Qw\z9tFl>N/Jjʩ.PM=hw-ȪJ+[ vʞk0gj,lj *2>0Fc"jD1.F_˯  7Gܰ0{q ;0R$o1WFɇ ^uY|5smOW'H`/a i ߴeH`: ,Ơ^ s4j@37ȣɣ=\S; H)⪚6:gݚo m/"6qő;}gӽ6oүykfg>.:馣nrg?]֒_'-U5Y7ḮZ8hКS^MQfdE-АIo2Rt hJHѐt/5?Δ1 ];)Ԛ60y qy*%.r7L4̽S+dL3[y!X6h2`spf8[gD5BA44չ+~ `? :tG6\E/Jrt (FyMo0>BX1wcU:=SjK{|c?lꍯ{÷j5{A_g?o~/^~[{??eTm7o_7"w~ۧ#x~wOGtG# xPT"fIvX#F8SH6J#xwA6]"׀KHU,S.E6(Q8B~2X%4hB=x+$G@IxO?$M=OhNQ$ւYTt@dAC\K^'(4'\0#&&yoȆ#!xȆc@`5Zt8l!dJz,jueh(al0_y_0l ahU`#"`_0rhd0Xh:@duglX.!0&qn؍d|Xzhk`y 8x˦*(lluPXideP !%(Ў QP:pnܗ _P%P&HWv:<ٓ>9RveȒHY:  {K#x'YIy[05@FdYfyhjl (`W@XyJV Qx9hl^ !`PИ9Y ~ehqI#'Su`HYAO`YIQ-1`ɚ:/Bb% !09Y T ˹P!gɝ }R$FО9ٞ2九:P#$VٟYУ cp  0ڠ Ȱ {p} `bSx0 ` P [``N$uP5"MgE26=3 8q0tpfk`w]`n0ar~P{ b0xp @*QhФI I:"c㩨 GE * aPW[ڥ_cZgkڦosZw{ڧ𧁪QP?Iip <0"@ zX\`*djhlp*tjx|꧀ Z `!*Dɨ= jJzتڪ :j)}p`K!!  %3Fگ :jʭ*KP;!K$ˬ :jךʪ*J6PBn 8l]ex ' ; %;KS|7ƽZL/p@4-fпe y\ǸRMTmK`T@12`(0]p wX0p]͛lz&U׬G` ((6pZp wC M@ٖʘ} q|lH,ȼQ=}ЪڮP5/PdP 0. P 0 :0R-mq}t z(ݫ=NP 0> Pn.!>]Ǡ=Գ}|I<Ƚ\N}f|]W =~P0L=HDA+IGN0* .=&nsm* -4\JLNW\}MϿ̷ߩ=]4jnrw{nN}⇞z-1>nm^.^䁎=٪M .lǹ߾gos^ɮ|^-zpBp6 㔎旞~ꕽ?nDGϴ>=ڿ>N  N~ .^#p>'{~I/g0޻DZ.8.[N@/BO~Ůe?nTҮܠ⑾[_]_o>* g^7Z߹=!oGn _^gA~/N?/~u `Nr뱏AODJo-/^SA .dC!K‡UATѤK>!HUXilmᕀ! ޽D1jH&QdL6qPF*eTJ+K,Spj-./#0c1$243ANKZ{-ֳv#8[.*砓:'XtIRo> ikk菱f&{) R9ڪ!!3z+++ ;,{,*,:,OH{E`HƐhTOriGG쏹":$C0;kE+J2Ҽ+ӣv2Kn$:mAJ Ő P%'UR'1UmSf$)K`qIGx4uMV2R+$ Z"]˳=zoK´TR$Na[->)A54DAdtGM4Ee]MYy?{GͷTM_fUa5 cpezxJhLL?40`k;U֓ P #E1[:ơa+Miߘ>O稞ekQ:*-͎mc7ƏevVd㜇R2[}ppg&ܛGwg|"zIlNyi ks誮j:nA]kW'Jמ>c=kds] AO}.\8K\x-hzB?A d{'|:}{xq#<~(8 pCFgaI(B?_eX'2hZJC-Ww@_1P#фƞ%x6d`K d,# =H&< p4CA@  h_dǭڠzXJ̖u`"w ~??d|̘cs A"~GH A_f~; u-T2.n=` YC&r|d ;+:{IXjuhN쏷.T`HЂ?,bzp) Z| z,Eea@G -wˡ+oqCym~?^K .ƴvg]mQ wUP2 Q]5@ TPbH0)4R8.:H4 /ءFCZLsj WN2@ 3nAEAd#+Y8]S au!T9%9ٰ^_h/zl}-?` B`뷺6Z׫ŮK+f@5[[я+d *|B-yg^|` lN&ĵ=pH$? D#݈/Fx0YrbyiH4 W B| X##Q 4`чpc6VR G_O=zQ=}9;rR"F `>9 `b *TyH89, 6 HF؇4.Ѕ^Ȅ?aHbGTX!"+؂1;s0 R+$+hl˟IBc" 4.j+p-|.P,L4Є.(d?21JQXA&Š-(B/Jy1y;T BI+h"xÈнlC"K:JK2>+z,RùR0_EPbT')Ȁ A xOH4b4*_k1; KУ( 0_PKlB&:0q"]}h$0YФ1 #CHTd %+l]L.0HXbGXpEylzL$"} 8Ȣ80 h!H:.…] B@2J yDVC3pB0HxVx$2`~"xxpH;.:fQ0t9;@HSl%1|0J4IJJF#˲fCh3`S&xP$E ;5&sQ%rJC%'BpTR)H҅A[8(hfqM2TD`KK1`MMp%x)BЃRW#UN^hh}&8>.Pc7,P=PMP]%BHM`A02K1D\7h,D!O*,!<`P6 NN %]#$X7ϹyR*R+R,R-R.xPTIosMHOl5:ZX[;Hx NlXfa뉄*dQNB26更4$OBxS2˳:]SbO ;84H[Rȁ˭(RXUY*ҳPyT|yʬL0: 8-] U@K8O刂H E];?GL^V`V23:UVfU(TK`!#T7VmWUX[5 s8iI)@z4&(A3 0dH}$`!0 @/UP5XQ &VE9VxE%Q$p(9}Pɑ5gH$ @ȏ-?8y&X ؂[҃- s4= L=KNd$&V< Dث3҉YF[ =嬎g}$;lgʞad}jlߎ08&iCd>iNX*&]d@E㴎xV-0+nBb.+n. S"^+g^z!k>cNN9Y HV8 /خ6i)$H $6 pN] h AM'{p|IN,P/Bq~o-l )xnF}qɮpfWH,`}//0/]#سO'W3U`0nns sp^X0 @%]NH(EJ0O8TT DQ2p6Jh>aTW(ukfڅ?Ф^qY/oPo3xc6u6/_Nnl^Ng2K@*P>_@6=?x^ \?MNR(Iȅ/D@^F/xZO=rkEvAV)Nw%o  $P/TywRYT^y؂ɻFa.0{G_!PȂ.xI5HGpcShVx@-0y 8~vJ6P9,XW.yZSWw7UoT##zN7}6cF6Au0F wY/@FLTD}8 |@U(0<Wqwy5P` KH}%y0 /^@ J !B$Ȋ>$9rɌ*.7d?BbE D&Μ:w'PLĿ\ gM!FT"7T \U*Wlѹ.d+#aF2漱JAC ;C!1#R:<,+̙|m6,6 `i@YD#O.x0†9SQ#G!G#Ǐoz3?4}ŖOfiZGT`Y?[0 Q9op&"grP`D'Oˆ(*PffA$Q&p@DwD@ 9$Ő '`/;mj{$'~D ?um#0 7!pQ0 #Yc|&hA7al 6n7PA X \p1 棔9X`psFz`E:=G^Jgy _x.R]sJÚ\"œY*+Pmb $DRVdɠX@MSD *Jd ] RȜYZؤ#RFP;sæ,gߝBIGLV-̢-Pc`à2\lPp10Xؠ.07a K vـl0~ze5}NҖObnJ?c V3j`$S0?E҆C Mc(,U!{?1@ž[d,-`?P0@CKDd`T?'OyS$J' FqɠnY])TTOʬ@3f"@ %O)^خjqpHeYe@[@TBf=~"H ` j-$QU3h2*\$O&,m" - stl\}x;i~XR7 1ng ̛<,UBaE8ڧ-}pRrX6'X9K1,(8A|\k3=2:F$8!m>O!0DeJكO95,6(!~XεYp,5x<~~ ,b@;PK8D,;44PKFJOEBPS/img/sbydb042.gif5XGIF89a"@@@Ѐۿrrr Ҡppp㰰```ggg???000999PPP;;;Ż>>>}}}vvv333XXXsss 888ĭͯ,,,yyy///̶tttuuu===oooOOO___<<<---nnn:::JJJ(((777iii555qqqhhh666zzzbbbófffQQQxxx444MMM ***{{{DDDFFFjjjVVVZZZddd+++UUU)))cccLLLwww]]]mmmEEEKKKeeeCCCIII^^^...aaaYYYGGG\\\'''AAA111kkkNNNWWW[[[&&&SSSRRR222BBBHHHlll|||!," H*\ȰÇ#Jd(#3jȱǏ CIɓ(STXʗ0cʜI͛8sflQϟ@ JPF*]ʴӧ2BJիX}!BB֯`ÊKٳhӪ]f Ѐ]A24ж߿_X݅(W!#K %@$r (0`C]4x ަ9RTvi>qr+;w5S(7`'hrBh{p0[kJٕ 54(E%y{⇰ ǰ0dt Ҫ(*2&1a(ڰ*̃rIor+Q0+^-R⻡D!uE) IBn&d4#Шƌ\v]@6V1IFs-᱊{Kb'@*WV$G iHJt$9gP &D$_ \1{&pr7S"RȦ6nzsyR”3XNƽ PABU( Lȃt֯$ծJ%6Z b9hC4)JʨC(L"b*+^\-H]&z܍6U[@mo4 ƥm0_Č ҍrVD %p܇R4Xeje.B66uڻj z`:M~%|O, Ƒb)F o\`r.6xr)yzA&p0< C9bT&CX8\8%&,mc =6Ώ cضkn@ P璭8W,̣QIë!+'a3J! -Ԩ>5( ;z泟-@cЅ>"Eͯn 0bU~58\H@P`hD APOX}?*I͘OcFi3lTzi/[@lc#;fbhOڻ&=`; ` \X6f`"ú.\8 pHں³cCͧT MpGiUq3: 7 uIf(V5=};!nIn< dz qc7؀Ixiz LJ  P#| $HqQn~!R!7  `pFG_H$ h'|Q}>a1<51eI8-<;8XxotDNC0B7t ?tIjm` d l'|h~W~~Y~<~'g'xgx_XotfWG~ &p/J`ii0bJpP'00 C{fezI0z`&y%hg~1ȄGiGVZȅ^b8dhglp(CX}wxJWOx78UxY8"`pPP mqXsHu芎tJSч(RXH%A긎xHHd gW6(eҋXǘ،xҨt؊GHȍ 1}Pxɉ(@ƈȌ8B8F}GzȁC'QKCsktG@lDY&H0DДNYJ~8vNȑ(9 y HXחp3 W ~]%(ِ+ eH2y`.ja`B&qAQ[fFFs'ACiECD@jpPU9I"i&),f iYgG Xy$y)ٗȊ1pt%A)M#Ax;@ZC]!IlBٞ5 g jل)ʼnaI|ˉvXg9矖rI!I_)z9-)ٜ :hөMɇ֩K%ϰ2|paGd)!PI%TW gpIBП)w dgyI"ڛ:Ușʜ`wCԹ?$ab5f$]nUn_O ٣ oNHz䰟 Nd:iWʡlڠn `ZjZXo31qEPE f} q0 a 7&}u&5ZrPx<< o@ hJ *zkʠHڪzzڦ {Cvš b ͊xfvkG rp%Q!W p:OP<˳*j|NٔP鈶 [P[\gʯ { ʥ'nYy&9`ƹ[ $A9=EAm`Q"vQ8x]P4p0Xǜ6(b}Ieyѵ z``;TZjk۶ki EdK;"Q;3(Jo0qE lMl "oa!ǸXwyʸm[F @iFpKJд 1 D@rQJW ̋[   bKe0@T P h[evME l nZ! qߗv&ٿ ;[O &=Yu{5^@e ?yL@pM@Év7V"L~а&̻u6F*RHp`Vܹ/I0 pWp tJ@ `Ppsj #HbE!|[vb{Ƌl̿[6  ,Z{p.6?  I :~g Y7 1 Ɓ X LXP 3 P@VJ5 A=B3) ) *@fI ̷fP0 5W@z ;%QlM^@elhk|qJΠ! M  ئ#aʑh`kp0Uu c'MxP*MNҶ 1MK U3ѝU D\u B}UM; M P0Bp_ /\- n Wuƃg# ':Gq8u w 웬V\m@n qZ1 u\Ǝ¸oL,MT12W=۳ Z Q@ r=njXDtţgsPp&P/]˘1M'P GFqp$PWZK@UX9Զ}PBI` {@\] EZX}fr[ӳ#)8G?O \;Z+۽qPܢ\"]ϧmr6 # m7nWI Cꑃi@C?&U~ )\#̆Y X0= ZP F-t> @ӃXf \` #2;בNA4VN<#*${օtfu!شp`*p!^)ޙ=I:J? ;O,3~ ` 0 w"=ߎ@#PPX'  ӼP?_@C] y `Ӄ F0o~i~fI`ٔ8!%0nƲ-n<ٹ76|M /Y{PH/vkMMd 0}b28]`tݔhp YL``Y[Nrp4pu&F . @Pq P,XP@:}AsG!E GNȏVLʒ1eΤ)S\ϟEj%ZtErȁp A X`GD0ab1,P2(xpb :8ⓢy Pܑ&'a!#/fbÇqe̗Lhҥ6xT T9[#gS o6Ԙ& -SP C2ИDU;aĉ/f(JLGuWa-%Ԯ}V R!H",H#4bK$J* ;ɇr!>4D PqE[tqŚV0 *Ԫ*OJ?fK+'`E([& úK0i!6_~ gFsӦ:/=䣯ۏ-JKOq<ӳ*>PB:?&\r.܎LDNlx h‹r(WhQ*+gaCs ǩt\G,!b#z2 8-lW|RL~pD B踃hi6K48 TA; KHrunArШ׈I<4BxTB?65dDS5WSYRS(i:?rKV`6܈ 8 ('6x(`m(?rd--x*\̏ȷR%xcq',{a ;_$ 4&@Jh\oScc~YF֣g%Gia SӤiS.Dȝ-șgFU]HbK(׏'~~6 1B)76D@ l(²7 Mhsެf!)ۊJ 'k,Zܹ$UIț2D$sZ BwCt ;6ÉՅa(Aa<5ϋR*{]~o!)+Η". t0PV+d'Ѕ6lN"PYpY%*@f#b %P,HF$܎@qgH&4 9C` ihC zå V,y-ьhT#8ʑRcM>珁t Y<%rʳ5E5pj&Q$A1%b" ;${Bl<(I6,$pȝ,aռxP\H%O(A>1@MX[ܰ#,e+µRp:-\% '"I1dPZE{=?ЁMBВDthF7QɊe!IFn0B*ȁD#9r gT_ ) a rAcJca wDc i ^ DbD8+^HZ9 7Y[~+_k_'>w<=y>> ;"P;2;; @!^@t Ar,Ll$\@A;RHF']ЅAY0`&544(+OP8+3`\ Je"҈@B Éƶ92CR+EsBk"gF4ٌD3(On0vWaz\>]r ݦ^%"cNE^dFF)~cHJ/qUŬTW`cUZ-^[-eC8ʽaQ؈#0e`QdLJ%ܐ:\AO&NY W&96eTFU\W.uSfի$$`v=>#Xgx&FWqTKYTe)}uf椝:t}mXd%dTHujxgDiAϕギ^y%g5gh6xpFr6ݏ`8ih&j(;)Q Aj.0;KLɂ^iY-_.<@iW^Ax2j X@)L )~8E\jS}iV6q|h@ql$Ŏ^lrŏ0~!XV(P֎dVij%me&Iզ).e찖MDMnj o^l "Pkrޒ\)^$o( X얘v֎Y 0ojAUkѾff0]p0k<H< q@^'^G WqIh #Os_AX ^,3Cn5o_-&qkn1/3&XlneN(8$3?t(rX_,K:UGo80oP`G_ABEtLtNt)y7(G7( Up3߀ZvsPyok?? PV??)#`3r@venZ~h'icMBrf{?YP@*8sx`wx`P@rٞ 튷'~Ewrz'K7x7ԅqpx;mdj^\/"=M Xq ^娧*xׄ[PeOo+z`F%98I0Qh^(T>P.|[oOc{/'d HJݒHK:t;۹uHS((hY8߉}.}k,Gg?SݸƉ)PfD3̏ᰯӊP¾ )C'9BT,P^Ng@1$Tq0@"7~ P‘%{9+p.%1~@ Tbf [bd<Ƚ)mogDR:!qBP8x6( $Wl>Z ~U a dYE,0()>B v'WkA4`iF bWCASpHhƴa*cjyDb1\L% +N#DOBD3*MnDrrYp).իO=Bb >D&UԇI : `}! J@DN2P\ϗ+AVLm2[O q"$\h")A󆚡 V8@љ؈}Z) )ЁJGL:vХ)np٢Bȉ^#XBsČ̓Olh6RacvkszǺE>w9A(U7nxQS=DALdWCO\H\y'gjGWax3x$Br#L8Hgʎ!AV 6W l f>fRu3ܫG ZzMzb}CqoLV1I!3YQy!IGˑ8 eu&aDlDrsg 4X? AxK#f@K?3Om&=+ {Nخ^N*u qݪ/3YߓiHQqi ޺YEW¾̨+701L]XS&a1C)~wːIA|@lp"p>><<<000???}}}vvv󠠠```ppp;;; ~~~PPP,,,˷ƺgggôJJJyyy::: 777XXX[[[zzzsss+++---wwwiiijjj]]]111555444ZZZ///___ooo***^^^UUU888...===222666ddd\\\eeemmmQQQhhhcccuuulllaaatttbbb333nnnfff|||qqqYYYOOOTTT{{{kkkxxx'''&&&(((RRRKKKHHH)))VVVSSSIIINNN CCCDDDFFFMMMGGGWWWLLLBBBEEE###"""$$$ !,\C$`A4.@ .4P!ĊJ!F 3+pD M2DPA] @Ȓ'qL7Shτ pRJFTjՐ #EvlXYm9ژmᾭ\4[Wџ"ljੇ&.l1UC(@d-O|p ~rtO.!"_g ʴgۮ횷۔sޭw߾  2>?g=t+_/9tBOӫ_Ͼ˟OϿ(=U& 6Q Vhfv ($h(b FD4}$\Fn \A C;>ޑJHXj﹡n]/Lh|zGT\1.']7,LjA ^g}*:K/|?oUI)7G/W/=gpQlAMI@2V^s=^#4@_F`1W )|;G dl۫%8((sLdLUԕs,CZO4@ ] BGAj‡^-,͂i+N cm;6}"x> Lzei Qγiˆ@t2lKa-u)=&0>'dNh$N; { x*@ڷ-4sMJEKf6В`D[Xs2!Ng4a.`hbչ`v* `dʼV' `)v$\g쪗Єf;[^@ k%n:w ]݀ q0d EIJx[[͢JxxXQ?O~6D7D Xfuі0 m^ *0&ukСr8 BG% ԧN[}(9漣[p %9 b LHHxϻ=KXBOCa `lh"ϧ]g{_EXbv_{~hO;m'^d+;-ʖB:AK~F/|Ы s`+~*$EaLaO~Pノd*=_)o]^8*|HA 9h&MptMѧz<*hDFZ>  GEwTe n g" }Z~w~"8 %f` xWc'C0cBg #E0zS$ x[觃 BJz KJ/Ьpj)` @ eZ Yzd:?K5Ȫ"%zrJuzx|ګ FJz p\0/Ҋ) v h0j v zSCǮ Iڦq:tjwz}ꫀZIJj`P ˰*K hХP: γ';j+;j{ʫ~گ8kI@+C۰Xum5 z y0Q >Kc:-:5ˤ0%"`nDw 8V` |+~ <몄ʵ`+J6+X `Prpr{xy`з`(k]k03e{;m{[g ں +%Iy֋*;_bK* ˒ڬʾY[*  1 2 ǜ̶S@ w ]FN B;v[ a挮d鼪p˕Zkcx -`M@ G5 BȌk 3k0U $]W-N\K`b=d]_tƝ4^6^#CP;-v|x7=S|pvP˺`MP yP i'.ѥQ0$N ۟ ʊȈ7AJ@䢺 OG.=|X{o=c`Y0枽ii9LmÒ̤TRSfvèmO慎7%[ mP; W|%3 zE* QPAY!uJN)@F`v}J Q R©ξU,{ӎ@RF+/0#HFΩ`NU {Nî1`@ Y7̤PS'Ѭ~)@n0 U @Сܘ"_P N :pޛ̻^\ 3jMT`#T G #KߪLp+ QV/[ϸ /O0|) ovURsP^yy pPd@  " `ݠ@ '  j w0eP0_!.Ĺ ؟ڿ Eo`Z ,ҠӵǴs_B7ucb'@.wTm*A B]:֡bi" `j qBlp>0~5 CbсK"X͑`d%-IIkILn 0&03.Njl!70!xrG$$q,X`L#l x@"RӬD%nq b8E/,a-$ZPG<)_Ȑstp?YχsYD9 .N DO;v )H ɏd)kR YPNtBD(Ӎ*Q?ӎܡ>k  (}Dt (^P=%P`j.Z2N.a8"3AZUaKVOR>U|5'GE*v`\R]*1.))UF%dG`_13d; XIⴐMW)R”c>j˜J & ]W .v nOx* H@=*Rt[ Ր9 (_IQCW g8,ք,5Sx497~ t1`ӗojME=꛰wJB TcV4ugx9V zj2hl%o{MO@G1̡kc&vURp1&7goٸZs4nbDŽrx3o~ȣmfd2`Y%>g@3NΔ>DP0$vycb>֜7_7n:82d_d!a ]ƣ>`BOÐq 4g7GvqOpiӠ8&(π1t=60!ɋض2_vWy.?SV+ c7@.ݫ]~u!hORc?i <<|9샻ӴC C  x;3śL)nl@t8͓s5s[Kk -@> X \$U?|˳+AO\!5=3 >S@>4P(H> q7 4>46,CPPD0?;%c@3b`D+0) 9 'c@\,x8ɳ(EPhH+8@D5@\EFƙ[ Ve(4'у_H\DGX-5Et`ƙcDL(;P?Mjhl_>Pr/ $0|$;b>ڔ)MM0R `ЃG+L$[s@DNK RqIS,ޡO p8Ol  -,OJ$a2(9-"?L5Rq9=x ͖0 أ=s QR# R!R"-R#=R$MR%]R&mR'}"F(R*$R-}R/U.R1-0S32=S54]S7L }S9ҰB:;E?SӗTAMB> TDB=ԘpDD JSKLGNTTTL%Q UOEUPTeDuTX YW>UUZU6IM` 5 acվ3e%Vbb ,UO ktv־VporsVj teu%wnoחWטWz;{M~fEցUh%؃5guVօE؇U؆5xmWxVuXw؋VqXXtX Y|ה] XU}~e٘RnUFtٝ % ڡYZ-ZUڛ0}ZuZک YZڮZZ)Z [5[} Fڷ5ڸٹu[iۻ9[[[ \\-\=\M\]\m\}\ȍ\ɝ\ʭ\˕,V\̭ 5EMYl]n|]]׵ٵ} ޝe5ޥE٤Uަe U^jY}Y]^}7Ue5Z____e!M%ؗH.NF`u_=_ ._```u65-a.>>aHaVfva``!c#&bY^U_u\Ub'F*+nb+pD}.b>c c2@cPt`pc8c12:><^=~>FM@fEBS<d$\F^wmdH6dJζndLdMdNdO5hQn dHۙ7JPthS+V7x30# 0tX0]NP _e3MS[et0fUF#0ci8pNx`eiSj$"HKxF$Xw6hWN\gt0x{~^/mg!ej t\.=l\^=jǎlɞlʮl˾Ee̶10w R);ql:!XBi@QzdԖ,8!X^#x`|n@kbmga&XٶƮE^xhh!#HReCkh$Pvnچ#0pnp"6fVa oX~jg6fG$p6#e! ostXqeb.r\?- "ag # +#H#8 sf@gm30htxtHHo0@-w`m@i%tDifJ*TXuVoU'TJf"QWR0Ȅ@$Tu`K H0 "Hg.i"-Qkvlvh %unM#e$oM ?f&Og.f}v|OF~|/~% 6@0}@/}?qgڏ #m"sŧ:&|kGs/E+xAtlk!:}[`Hml@A;6 cC LS%̘/YS&Μ0 РB-jhP-n,)Ԩ2A)֬Ze@pL  q :d0>2T4.LĊs0Qm$j1? (BeQiH:!FAt:#BM$ ,w>3/nʕ/B8t ͂Ώ自mcG n- YYw%~HK\"7#C8#AmCB:Xy%Yj7@?m!mS{U"mIVp& 4{}'S9 2mRFq\mfbΙu~1 #cV?H`*B5ޘnDj)H. `ޑ@u2+~ƩJ;)&c Ta MVuzwXHEK-b)mpKd 1D7A_.a6(o rF06pbɂݎgyD*pCJo@ٵYZ[ta*CQ/ 0 (lEƸ3>7Tq I,pICMC:4DSo@Xߡ5]Pxsc! tbt yғ56k }BM_f@B`X!X'{P2`W:dATQ/AI&Q/L@x6I'vX?O+Ԝ Ap LӝYz3M']T'" ]( PyEH'G j-X@IOmT*S>r¼BQrM Qoԗ2DPTuǂsW5AV*,`6A0 , [1yC   V٤$A %ղf)9v v˃ꀱg 6<(q^+\ؤ]kU=Pju5-jUK@-V %(Npַ[j\rSsǹ pA J-X pO[%//P>(dz׋h5|Zіm `F.\W\OlFYсWk ËP$dzQ%|!: cr֪ }_$pv2qz\-\$tv0f2{oD Rj>TtfvL۱kd&LN4`*C8Fn=LgXӜ5EMjWX hHs L=@ q5qk\3ͽjL_ {-dEGp% Cq_Czml{ZfU 6;z"=?L{Ӟk![G'/Zn'Mpbyl;pO:U9Ѓ.{u@*< ܑ8?{4~O^|v4,i ׵`yLsszW<0鳎/$uPQן4Nl|-7!s'`XTF}AwgAY>%c4B)z!Ti]:8H:D824A.C1$:":B%@5CP0BC<%TFTN%U Xy! C&+=DYd?f3΋\ՙ(bj)":K X:$P@+:Be-"bM)-[?*@AhlBԀ2diDC4+B b`/(4(Y:PM'tBH)L,$d駁-De%@qBilN(^] [ 45DjC'PA$z\) ,+hT C5C ΚV)5*٪y@УbrUB j 6ܳS ŠX Ȁ t[ \@1Db @ + 3*1WnI$0$72d6i&',H @$1@:dB<28 =5݀ S~,г l42[Bl5$!00++,p(%H6lA$44nBH[]5*P&@(m2R#j65S@-|8Tu*GO *ץ,u&Q7kFd[-nTϚ p3~+ 6 i6d&WskFtO7u7&@ 6qGV? Rn 7ki> sQ@ -01 0̷xOn4v厫hz*9i-fX@}7h8A,|x,'x(x-xA*3Q;…7p{p`z І{K*:Ђ@k8ɂTA$eeZ'/ "-0*gS?‘xAod+{6Rxr @+90LABW*Ke 8QBAw `/G7j@y ESsHR?@/4oG>8rw֢8tk:?;b#6J ;?sy¥U7KlG y'd>˽>M +:~d*L;ԫ>ۺ}Lj &_%T`EW  ;oܷ>4xaB 6t0'Bx#ؐ!C bt„ (b>#@- CLςrƻNFۑ0q[*3@h2?2SL<}fm/G -31$n<42TJm/S)?E'QHD'!^-(z]FtQ"6EU̜V0W54"s[V]r=5A5lY }Yy-s^AU!}5ds T Ym>(fb @AKE6R&~>Ɯ'`gKo 4@D&~{1v'GKT QbR.>ypTU C1 E(B4X XP)L q _LbHҠWx 'XLbVGH A Ѓ^ob"X Ml@@)p 5n," @P 9>?aYT'j|$D|  #e2U0N1$iY%* N+dB& Y&-`S  mjcV@AYO Les@N*/ @ ^ӢF9v!E7孑)Z:R1LiZS9NyS`PZ}ԨIUT>EMT*VYmUU^WYz@Y:n]k\jumkA˽r^Ml\Ƣ,bbXVVA,Xz m\CÖ 5-iWVDe-lTmjq["o}\ND|;J.w}s*R.vknv{dMGzރ E/λ5nq{\׾po򂷻%wL"x fp^6ְ ||k^:u.+g,c˜6kg!7K ǒc#;Cr|$-lge׶YHLڀ;PK=IIPKFJOEBPS/img/sbydb026.gifB3GIF89avrrr{yd555(((]]]bbbRRROOOVVVdT&&&***"""zDDDhhhLLLIIIe[BBB  $$$lll666@@@Т___<<<000PPP```|||999???gggyyy;;;///ppp333,,,vvvzzzoooUUUKKKtttʃFFFeeejjjZZZ111AAA~~~>>>---wwwXXX777Į===...xxx̷ȺuuuïGGGJJJTTTƬ:::QQQqqq^^^nnnȤdddlj888kkk{{{222[[[YYYmmmfffILKLSQRHGGECDiiiyxyttr1/0םZ\[[ssslkkWWW~baapopCCC978`_`>==e~]!,v H*\ȰÇ#[şŋ3jܸ C (Sr4˗0cte~8sɳ'OfJ4 u|*]sPJzF#jʵWpBAفqfۭpkyݻ kDω L*[F8&L*(Ѹgz@GӨSxkVMi?7;'l ueܜKNw؋+>]9v5GN͵.;u{}_xx}gWj! U.Z~2AWDEairXׅ֠(a!H%a4B2B6b3aD&9PKFJD2TSfb%H[.ٟh_٦",b'x1wlِIZĐF47> 0L>X3N,)oT7@p *X:0 >^d)BvJ੩=25*_t&Gi3I%R 0t(M)hzƶps λl>5Տ=$4G,E,B,wÐՊqLlr#$,tp)[4{0 5 N/\^|ARфB$!-_!r& ,rXG`^u Ni'ڜeF l:CN>L`%s = *#Lw?7w{S9tÎ>rîx( 6N6! *3/< a]F"I B !ƅwtCЇ@ X԰x7,UĢ<сk*Kh.z 'j17a$w/: >z|@X5ȤL"ŌuJZ̤&-leؤ(Gyɛ\0Fa)ML7T#r> I\T1!bo"8K *)cؚ7R)n0LS*-%둑|&SqHnqO7rVlg{Λ3]TT1¢-ƚegc:IfHO%姉jgf_0P\ e?t7|h/c0t3+V?=l4G%5SGі*ͻnQӜ]BcFlGC;󦷵ٝaf@M̷T8ɣ#kCQRAA< RGn 60OTj8`xmQy {qxɶTLOE`!qyɀ.t E:"CK&uQ})VSޘR(@ag*;}J`!7>X xޡ yWx#fD/kyG?qT>C pe 1 2Ȋ<, ,[w` V\d \ gx J pkiʡۼLpL͒l͹,RM uPlNzͬH I0*<̼Ό+Nmߎ˼ߕ}ϩ,Ϳ0ƣ|RTڱ=|(#^'+n-]7dݽ @E~s*OQS rpZ\ NOm&UAᐞu,/.͐l;|>۱>.IKN Ԗ-PԿJH]屼r ~ڸlj^ጮHN(x{ݘ>r8ǎ.^>]~ΠGM尬NP]ڭ.p&~wzO9n<%D=T>i H;寜Mґ)+oNGvn.9ymACn.LT>bN&heO~3.n1&_=~Eog߂/݄_i0 .aϒ',5M80~ OKOR~PWO/Mcϟ%F 2t؁#E UW?5nG!?E +.\PyǏR8i%J!XD~$G"Fذ!FL,1 H<)*\!k9"$ ds7\Cǎ?  AW'!,$ ) Cg<|ןHԩU{,Adʕ-}"I 8L3ТF$ej%T\EH~ DC)޺wIDK2iĩOBEӨS^ͺ!¢J+4 / 03 1s 2( 38 4H+S1y1+?4[H͂(-n9|O PP Q Q#=qR[ӽ4LeFl vQ, !t$Vt N W2MJ|K134d!7 |6-vj3B?) BB5o틓}[ꎝE S;'FLomWۗ wf=D]wgy*nj RI  I|֦"E AV,88)(8+\(?p Q-ub=Na=SD/BP?(@tWxpZC!,兀󲥲ue W.Fp]t{? F0jPȟ?1!蘀# H?щd`@(Z%AX"4(5bьhT:VF8At?@=я$! )7wFa 3@AA P$.(`D 1LȂHF4@(pCp@  FHgs A 7HLBwZGh1Ȣ< AE%@_hb?R1HD]"it^zIO{Sg:PY|Eh),PJЀÐ(E jMse!\QKH0`jSTFUS%׽zNJbp `g[)T My?jA>GE|.8g>3G_0WYMH_A| !+ϳ5kk-|׆Ҡw^WX/-F(xUԦVeBG/N@ei %ui3=#q%4y&T}Zva#9I+mYN 2-hqa44u.t+ TZ7<,D(tqX"w-s؄?2rBg}uqqK@J0L4Pv];ɻ=[p W d7,JV)q1 xLK2BbSj-Qs$E&a 7+쁆]ah'huh!j`E $@-۽vd0rIik9U9D {x[C  B!§²K6w'O+K#,8 >~Yh"UȂPbR h Jhy P8H$8ALAv:j%\&cA)*B,B.B0T1$C3|T [0K5Ã*2CžEPں8 3>$208A^ЃpG0\ $[WxÉHC: EO(SLU<WEYZE\E^E`FB42Jp.,zG{G|G}Ǹ1PA0(ʾO9PzP]?(Jh@UX`1Fi ҄0T@HdHpHHJȍȀf!07JJJJJ06@QT03,H>8,>̢Hs@+x7PRi2In8t PTOH˵ܫܫ3K=ɌMZݕ[ms;^=WwX+@ (7ȿZZZZZc4Pʗͪ=}=~YXSU_.b/VIL _ca4VY X%N]&Z _s`8)%,VNdE^mHLH3Q㙕^ .bmB%&;߅c)c-&8،H.h@[e\e]e^6~T}H4ᬱb7;>Cd&-eIUTce*Wab6"ÄiV6=6^8&fn1Bh[8s6e'f](VlVXsygQJΚ sUuVcn[Um0g%W})f8 x`TA>}h-8*Cd~iedfjXiU pn .奶~fcjdZYx# ;iLCPne8.$v3h\dޟ[Sp!0P*0hJ~xɽk~X^3Sh88hއ18C@mV(jVfX>k_䔦 .$x )؅RVp9(;^vo{.Q7/Hx.P96EĈe55.Pr@`ψ1_bȃRx6v9Xgہ+_8 ;rb@$ux +/2^m3w TC=hi8l%+Pr ߂^76 "ۀ7@^^-P38DJa\KSHzy"N ni!MȅHd?ynwpey5NRU6Є_΄zhoo0@K|cc[/^ï )qgAƜ/ TIRh"ƌЂ3Bk,fS栺֫Wof6SKb:ׁ`w0QCP~ll)ԨP=A#)T-/)&tn-HM%LnaCK*R/W j0AD ( &F8eE-&2/k4j.V S (6n$H$+O#3ȥ+BK3oчYR#Ars\:"\nD8q`߿MIܥDʒ9L/dA__(` (d@q V I8AQp;h`!1 %E4p5(B/Px#EH !|#Q tHhpLV(p Bf lI6f Ѕ?+?uP~gs.DJp(<0􃢊,.aW+SjiTRD"J6(,e?+rER)I'pNcZBkfFm` kt )J;-jB +\A3w骻..;/{/cm`&تSj/s&i  jP7.Ayvp Fdet1mGXN͜1jii&vlfgR4EiaspcqP4 )/gB,Wct g~Psw;vN`pO~Չ_ ~m|Qk&8]4 |NGiIPXdmqeϐE3xֆ-Y&uA2B3Y5Dhl)%V/9kEՀU12>}i8L tXd.3,$Όz~݈>BABeVjf87_hm 2l`p*W@2D`4.P.w q %p$6La;r>j@LșOTdd-gɎڳrndj&:Xoȃ$$':I2>i_=@;ք.CYf32ƒVD)kj#n|2e@䲁x Ϧl iDʚ5Ug@\S#<W)`w#l"zJv 96?pi4Db."D":HXW21dCT/aT^UE;PK&G3B3PKFJOEBPS/img/sbydb054.gifQWGIF89a2@@@lll999???666<<<ϫrrr///___Я߲yyyoooPPPUUUKKKzzz׶```FFF"""ppp;;;OOOˠ,,, [[[(((---ZZZ777kkkuuutttjjjeeefffʓAAA '''~~~222111>>> vvv000*** :::wwwXXXsss^^^gggȔiiixxx==={{{mmměGGG\\\888ddd]]]|||)))íɅ### +++JJJQQQqqq555aaacccDDDYYYnnnSSS hhhVVVIII%%%bbb...CCCEEE444TTT333RRRNNNLLL}}}WWWHHH$$$MMMBBB!!!&&&!,2 HÇ#JHa 3jȱǏ CIɓ(S\ɲJ +ʜI3b.sF @ Jѣ?ɴӧPJJ* ʵ+QZٳhӪ]˶[ʝKݻxz$߿mn^̸)L4LyqaĘ3+|rπ7sM:^ͺgа۸sͻo<\=qS_μ0K΃=iw"HpLAXB;F|i#M3tp;^$AHl a`iɩy(}>!nDJ1ϵ8 [ot>+^yY7^ΈW6ZiJt ýVn,gO zNcU: XG\W2Uj "nk w/c|-Pn)(AHz`Am0lD խK §њ &C6,G#~iy?4Z 7"Έ)[⧔(ƕ5{ӠK*LX<5P~o,83(@+)ka@ʩ0|$G,` nlsl#QEqrL%U*K)%Є]_)hHULaJgtP-:rzL&0IM{[LCiVȓC"EL/BeQ&sp'u,Ú, >3L8 s<'2tq;XJ{N=$?A9fTzDjr;Lc6қY?-KQ]GcBa ljf lSrfF-MAB麠ϥDhRIԭf S7YTJU?*.:T0ի*\Iznjh'ɴޒlu[:$&e֨%}hZkGͬFƲUO%:6%fWGΎ4ݩj{pR4gFϵ8'Yg{v}n|p3, ,jZJ- tW|:u):_Bix"%T g+,WMψ4U["7(kߩԷr1ya{휢̴je?A.<|v!pN{#gtv`*6Ml1=N2u86P61)G5Q2uA.392e/z$1krcM+xγQ> MBЈNt 7FP'MiEc*<7ihSXDZ* Hh#<<ґCaXpjH8ЎMj[[ؐF }m/ *uDPSC5^k($ַ{`CM0>H/  b 5a`ā Ҡ kxb @.`/ ] }0gNۜ93@:нpi /C'|(&Q-H *䠁 "p* 9*F3bfF> +&O~-^8'O[ϼ% \a9ebO/>[ xAQ,=@0S|B/Zc 8;¡` ~@Ix,0D|"  x `z0`}Hڇ}շJ2 ؀2pz^zDz|p؁Xz 0 }P| t  gz PA (0J6;6g,1ǁ \@9b9GЅhx$(QHpVgqfsXZ|_3Sg؇l{nduwX|0iZ(Px@iOyX CVFhX'6x}8XxȘʸp(Y҈#ӊ花(U踅x((F}x ȏ]yh\)^9XШ`ؑ&1IȎ*َ!#I h%:1ْ)=YDy NZx }79k؆h\ه^IH6yT)" 6 YqXɓ4ay,Y`2~9Y 8"1wgii)`lPrprtIvـ}i yn ٛ !Y)} Շ熝 0 @Ȑ͹` )9NyǨ@[ Zz iH3٘I p 97 | XZmXva{3Dg0 z8Z 8hr`;pHJLڤNIRPXY+*ia)T,7.0 XhI!'|ڧ~;PplWZʥ́Z  `P:ZzzVXJf )Ѧ*JEW0HQo7qszX `z:Z*; NFXJDZ}0 zڧ: @T\y# r@ `*Z| pJpn:K4Ш ۰I@*Zj抮@:$Kpp *wɮ"!R#*C0*CDa"HD/i"@ZV{ & @a jlq*PPꊕ8;57NPgж[8*pJ[;뛷mq wxQ,ZyPqMۖ :ټΫ[wc ϻo` ,a[j} `ҔNy@nۿ W05;X0*Fzp'p["X+t @5SV",sX*ѢSpQ yBy'˙Xr gC00PyQ0晠٪:r )\z7hƭ'zR8PQU ,@ ؘXkrpQPcڔ#:7j90j&IGX)l2plVJU kM!  l  \y{(ɵZ @Z}T"h*'J:7#:&L}{K+-y0ŬȬu\<&6@xp@[| P Up>\Pypnpy@9{%ثPzT Qp:hl(|U1lXҖ眇Py ҕxϞ  eMѵ` ]μ@ Mp@ fp{ pv}$a1iI9,:b )0N)J+蹆 ȁ{w-چd* g  PPЛr,qP 0 ZS!My#D]y~:}ZX#ʯ;}5 Y]@;UofMyFνԤ}l-` p֗`̌ 0.*x @d Յ 0 =DYjJP,HjYt 1G?$mۗټìŖJLNL֭plٌܑ]6& hmAp m 00 0 % aT!]SUy<;[]N1P` p s@ [ Ѳ]z~(R``znC1_mz҇^LdNNA-* 0P ހ P/^N}* p*pē;.0^&^> ΄̞sZ OkP U02۹A_ZL "?$_& +! sm A R﫡p]?K%Q 1N_zO/8`^OYh\7kQ|{@Ǧ!aI>KKL]ON``_1pOˢN4M! H"iw *|o&)!O9qj/31C@pOl'!H8i!ֹݘ&_,j?OOģ:-vO $X`A-LqC% rL$O E$YI)IW@?,ZͤYf6f:p$ZhD~/PpԩO YUY`$[ ڶ_d*Uy\w"a!>Gg%OVe?r&?״T~!KAM Q*(=P*4(Ay]C^D`sѥO^ݺ +w Ӯ=]TM9 ʷvJv*40P@4kw:R 9 4@K60P!ԛ2³,˔! QDBN;5bk6v2*5Xk5@ A(H~T% JpI Di$@]"*  <`ݞy 0؉vʂIهh;~0~Œuhۢ` 喕[~|HTx *a`~9ѫ to6dWNuf@T hjNm jUAg?5 퇂S sqȂ$#)ro'_=@W5qX )KN-lLC'Kr'b_5g{n#ɝ-^@zmqLJC`{]zh %;eY)#4/6uT<7m`@h44@U 䔼0)Ҝ #6pE,fQ[bE,#1"5 .] ٥6bP<|"POV }`dd#El8⁃h5z+D6|zDLpI H gĄWMl%6 ꇯr?jzHwLhFSӤf5IM0,L'j}!bɉTPTy -Ty!&~D/4r\S e(C/LKS qS'ęǀJb*C\iXN F eבIYI >$fˢrP˄Ѕ>RH$TDɵ*w$*NbmSÐG? " p:/.J}$.Т/"x 0&١q@XӁJuKA*b4d ڻ-)XUAYVy&?[WͅS{7%x>mre;mD ^6԰# KFa69iT0p 5 p WE:~嫝emT<@V sZs ei:ۣ!NhvK a춾L|b%i;_T#KPF7ȩe{ժfw] c#E mV:NB䈱Y$w3ΑlRؙ^捳E`bLxrADR &eG; m ]$mYdͮ?:K3vJ{BC@ن8sxΩ~Z|k`[ؿCSp޵QIhb]E3jмù-JxWMPJC-7L˼~}o|Zf!:V6l:qky.\:wñylKI l-([Eq;|\eOq:H [*G@DW[<`}@*(9-Ő08U( =ӵ#9rTy ̽b9I&H ڙ8ܡ;:A LQcPj33p ; ᦂ ( 薝ȔXt<@8ibB'71xc {@hK0I2qi 'b>?,Oi&#+9v =rYDiD[>X17L!4 =Kqra#LـS.Cz 2! :: 70`¾QK XY籏kLq=X!b#$PnT^j), 'ڇ-c|s 4z;U4Y3WTPڔޠڳEX4}H&a<{38fbFֲZ^d" iHIs <[v:9b%IĭA*'{H!Ƕ5BT i؉ɉZĶ/\5`(=dÎÞ9٫K ۹AFZ,xG,Ťc&Z6.7s)|[dFn|VC}c}H@}7GdOƷbScKe)BdOHeU^eVneW~eXV`RIJe> pYfafY&d]>f1e;Hcd[g4\QXfS9ef?ufm>hk6aq"f.guqg5gE{agOg5HgMhPg$~5T&f`h`hhU67> Li wQx.i6j6s~Jf6kq(j>jNj^jnjM8քcᚾ* k Hi2c`& C*jkzQk~kmknWTENhf䁶k0H`%Į`[lxk.Ah.mhɖgJNmh~`lle`2@mmnn>Йyfm>`vNWnn^>W56`8!p.fH_r"0;PPTo08/[M@rP{X7XȂs{lhlt uDWtFwttItKtMtOvQ'uSG9jhud~oGYo''*,^1/3v6wsys*mfזmeijqTnv|?D_FusJruNR?ucWz_!GW}u/'x`?x5ObO@hxsOmW@7 Ayp/qGHWtto_x<`NkyY_r~)w]uG'_z?P izknzw'Gw{vP'x{OWw[/`{yoTw|pU' zq?Gzǿtyw|OW{_{~|uu7a?}G{l~:hזO|ruwޜ?Or{\xx1x`0^8dC *Pƌ7r1 ,i$ʔ*WDy2gҬi&Μ:wgG~,j(# 9`bE@NdAI# dQLj"zzQ&0 O< n#Ŧ| Ԫ<a`l!ƏEH !\|τj(?Wf;.{.K,.G;NC..?HX)b"X4gl|%-5bN6풛YdmMlpF+,<3mWJ'uZ0w2!rO qv<Ǫ!4k2Ҫ5Ĭ5Gpμ"ga'-7BjǓRMe#L\۽8bf6:m2MJ'j}CzLz" >;~;N"*;|F9js }ОM?K:O? x n&p>髿>b??>?:zT{%)z3Aan|,A0i[Lv­VFL "`-;mrOZރ`$H`Bx2G?b :OtvYqL\(N5$F/k|d;f$7$<|QpvZ_HAeJU'oȏQ1l !Xͩtd!YIBQj& 6=r\M YʘJDJτK.700DWWh r%8)Bs(p\͐Y"wBqӍ\Z&o NpjQ9.s)w6x6 {%@cyQ׌`qYŌ˛CTU=)?`ЕEr#D#+y~|@zK*vKdH{)Leҥ2դ0Gs#EQ0J0yGZ^rBSUH}V!RVӍn|mIVUz+\۪P9t\Y4T WϿ!%eebSoB :Ҫ$̩]ӳ`'Hк,T-r9q (n╸ mX)\n`3(.GZ.?R*[v&t)(q.g?:V+a P]gE$ھw}èPЬ_M]J`}$VMW!JV%bp$5\Ksap5DfV 0\ ȃ@b Lb P(8 cB%_ 1PD p/DZ"ʡ{ ;A+/nGWqaqѬd`6 eO" m%yqAm/я5-qڳi)n-y{7 ׻;B@L_V-qU3 C: S8HEl"[X ~*![ ġ¡ L aGa@.!,N L"%V%^"&f&n"'v$BF ")Q$z"++"%&A-".."//"0Cb)b!W-3>#4F-54^#6b#5(&c? c2. 5f9/n#!#:;7ca;;c>c6#u#={c#@.$4 ($CF/:(A^d $3J$G#? DvH"E#Ab$JF#;dGd?KJ$L<$=LGL,%+F@!cMMG褘.2%Vj) R$P-B@"<0Y%ZZ%[eZNB2%Iz4ʁ)Je-BY%aa$\&e/.%DeVe^&fffn&gR. ^N^"_I3gkf*`@f2e*aoX"?@gTeb$)&!lonabgv'r^rb!ȁ'l'{g) 'p(@r>AJ癀ȁ)g{(^&gp(g~  -0@ewnvZf<0F<4@@?~2s!hBer(V$<hF@*l@0$(6)fJAh~Tl@|&i翽h82"܂ĔV0 !&ĩ)֩)橞Ʃ.HL\l@fB% )6:.KM\6. !n*v~*)Mx@lbM*Fz)(*jAN<*=V\j{^@"4밆]TEg$zcYTr \^?`=eC0@*^b5x)60 $T)^E#߻4?k-hl]Ѓ \%B&4'3U Pn@) ,+r 7 p$@y-!bA7iABH*) L\Bo+2}/mƂh=Bp.lT @CрHA%1 11BI #@ l/8A B%1 Ā.@ -&D.x/!\ r,&@/B'"'"/2#'-l8q/EO1[ k  <@#2)?r'q: ,pjs0&τD )/7&d8q-kK !4 +'3RBL39@%Pr *7{ l3=K3 l*1@| (3AO3:;bl8DrsL2j 7I/O4HtBk; ` tBH4)w5ˁ]jR(?x4LtL;q d4[0r4O"1tj3ROu"k&4j u(Y7 Uu؂ȁ:RQ XS5V/WWADT'15ZqeA45U'Tr͵ص`s\9i vcO5 4r! ]c!|d}hSu%%piKjSu'6@l@muf'춛oS5?6qwR]7rACs?@TK TsgvqqAw?XvxTAycqK ?p#PB|@4}tfK7%d~?RN7H?w#B@z#8=x/(Uc/}3BuBKvsk{cx&4?1 g@U?8vxIlu[C1L}Sˆ+֎@j79#urK98_5 Lx?5;!q"(@W={<ޟB!|G7~=K 2@(#x|K}?7|~E<#$0?$ d+  x>SՓ>B+<g3BͪNn5rb<Ko:p;N$LBI%[Ne)M.*+;C܃O-d l?/@̩(KK50` 7TCEtN)X\ K@ѺM #HSOӍ:MʒkѿV$.T$3*Ϝ0 [+G;lONJI?[V`1BuL TsHs4$m̯0MOQoI=T1؄7g9T4[O~5:CWf|IHe'T?mGWp1\8V״] e3ކ-V{dbݘ暿sCf65RGtRlx1L$4nƎU5ŰݓiMyssW|xf>9zY!{n4kk2öMZl?FjuIdQQe͓W%I-\2& 蹩a%2u~M]m3kŷfnz0օ~']E`hN!VoY Չ>UU6KvCU. A^ҋnYOU7\FC~~tDި !md5Dj qkO PXGx>Naoc F/(`6 Lh`yB+SH .2!=U?CȄ,X9P;Dz ~. @h$b1~#B˄D XGGAWPY 4 iF"PX 9 ~ #/Q-`mBXDb>  ipB.}`!n`@8m,dЀ"Lp시Jk cWx x@!yHD-ATz0BW$X6C@PrJ 5g4dWiV|5PP8?:7d E#X`qC$HCc@K /&VאO 9 !DsQ0 ~PE?3Dʢ 85hNuP8  A4h&`KO@[ Ҝ)?! RܔNMC _"ڿCJe*0UC"D+p5od0HahT͉YHE?(Al[q7<@iIEN~I"X7*e%E [ƈf;kȢ5KXj#1 &K8Rpo,Fl{б~w&u%V4ب]-тZ(f_!Ehahpmw\b脗{/?8?Ϟ7= J HƷ>,ݺ*[~H LL-&QWu ɄHc@,I4lݯ*H\d3c2#IX,\A ^B Tx Q)T@'-`q~۫ N 9f6(*$>P>&: Nt0H T1Qs8dNFRrは`oCX8d,-Z[f%h#>Dž?5}Lո @^{9QvT rYq wݮȒapān-J_sW:S)~̀ˀ!PռxZu|} ^ <'.'CBeB v4*pҬKC/`Ԩ3 <7+i["3P# `jAR 1iy+>pG\>r: )fDCyGcab5 :j-s!*;!n3@34sބFᒮ$\ {NܺkQS>B?T4|0n>!FDBGB5/F&kAG ^D4@7@h>Ϋ F@TxbtDgTkjq 9 B@~JMHEf@HN}ퟘTKY ~aJ3@ 6a|Г|Jaed.`MM,LyHTnOy,AY r޴Da "_`dA `E. 8A$ *X>oORPD4I"͚/YGNE!+! 0<5j!, $iXrp!OCXVoջrs QOJT(Y"6 ! rh  .AVj o qG_I ^UD'Q{IH 4n h kN_qveY\vL5.fLu_9e@ txV+6 S? A=D 2p 1cm ^_Ҕ%A 4m n#@ Z6 8 (a^@4P(">|A`@Wms@&rursE'_Q/I< tuR227ے[ 2`~ aj`J$w1az7y#ky3DWs?fYB<@7ېcQJR ;P@A&>@ *!֠f!t\]m AvA^a @hZ]9E`ebG@/WivI XmFJWnqlKsx1T`{sw@T8 `i批-'tOS a6sm9cj֘F_N5tS鎋l8EԀ>:`_p0(4fVG%W@):ضPW6Ui8a RY\<`{`i͍G @Q+rmFtlXfvskA[`*CDyj8gN=Y9euO9H 6 qsx%و(y[րԳ%kAZr+TEَ,$ \Yy'[2`# y yOY3y ` 9V 3ۚ@ z8CZ @jA]-8{A{:ͺQ|{<ϪW{!\:I[Jv`!t ٪k[X{!Zûmg!#8[aS adٹIΠd!"`U4|ÿ%a"An[PI ;q|@j\@#YF"0f iJa!6l Ny\aqA.9 :z< `;{E T8WŽ@ <1 `e@5a-*t a !uS lӽ :  6! ` ,#M=b ATo}L{}cLa=Ёٝ#@ڧ}"&H֗ v]Ml % >!q2`M8 (9 D?1y,֤ @}8 ;PKJVWQWPKFJOEBPS/img/sbydb025.gif6}GIF89agggSSS>>hhh|||vvvNNN???ˇ888:::sssħƭQQQ777zzz̶OOO{{{iiiqqqǬŴ^^^...EEE}}}xxxzTfc`NKKe}]`]\GEF)%&cP~~|kih_]]611{zy]ZXZXX[ZYE?=caaJEC|nfdcURQyyw]\[JHHECD.**ytiUUUmkj;65v{uп!, HA#fz(\ȰÇHŋ3jȑ C:4Sɓ(S\ɲ%J3| I͛8m0ǥϟ@3>*ѣ7}ӧPN,BQXjʕ F[ O]Ӫ:ٷp x˷o^Th}K!˸^L >ϠCU?SGѰc{.cO?ɪs&ߐײΌz!UKLzٙ7A3_/|; =~}g`w iHY FJ`W!abلڅ~ouX> \$/x2H^<'%(թA" +XbT%Rfez- $_e]&EVz&`pOigFr HjZ'兀d &3 dGA0z 0`(S^ 7&(>0M)m*Av ">4ꎿy*\1H>5L@!EcB$␏;4<[߸_ rJgns:nr:x#tV!+v2/YvMdwƃ ŝ"oM!do܁9I,%׏*8]1,$k%tqFPU`=|cXUL`#S!d-cWMMum>z׭!m}*(p\wH|so7 ! P8PO 5xͭ$^M8< D"<1C=f"ݣoH"$X8PC7d{s{Zh6  |B/ a8x'xcNXU].s?3CX:AnvpSNnwc`Ct-yϋ^?]/{7>o"Ǿ 2ۗ=y97I"&PCBY7Ȟ."#3 F&dp: tG>jяW#80 ᕰ,gIWkK,P^4p[!SEX f1f3b3MAd4b<624A.UGm3+$o:u*^>'<_ӄz힚VW\;WDheęCw@?6|,FQj%-K4iZ`JRJ5)N}M>R*唨/Z .զMLK}jT!U0UlU]%Wg*^f}*U)UQq+P WuieZ]Z.p9L[*@e bŢX2֋hA";Y=cfi6v*Uhh8wʹmJjZJvăml2|ֶN3uۖmlŋr$wl&q޾p \R$'vפ]rV=wYWMy(Uo{2ŗLxؖ8WXF|_8#fߤvE2fq0PհvVjS[AsڪJ&oswݘ0RNuyd6(EzVidXP LmH7pݳ$=pYSl?4lIN[2LFd[ &,P[ҖU  (@n9M@!ݍ\A šDA)B,b]/n۰K;./ @"S')+!Ϻ u >z_[^Z;D`ps`d=ߴR}u]p׉ⳆZ1v7kQq L=ݒ:=O?5żZ4 D!JWw_ '.8?p;+>Slc\s`AxYփzЗY6ߓ}7y}ާj5#FEu{ts`wXEP0Ee&`fq6'y]|v7t}{;~}XG[8Y:HуeEb=0r uqw|yJCE(48YH@zny5^Ws䂅I[hU]W`.FSF_j&T@nolzRaxEOs65=rW|10Ga<~P~熳GZq!eE:+=Wߴ{padVG&pa3r!Thw m]u4`rA0g=18N0qpJuMeP '5Y R`h7H7[~Jx{p}nr+p&ypa ySVB3dfftA|VE0Qτ_ mӈFƉw03ᒈ`1 m0_iL7Wьؕr=Vu=~XSC{ap5FscҨf9{02t!qepwSy!P~)_ҙIUc%2 8CctgTyp4>`aQLgGzpCuq6hng_oy{%xHo] }" Wߙ[6Y\[I!ɞJ}𹞧՞9ɒbc9YY!z5eu i"yOzzT9)/]e.¢Y1^& M4T6z&T;*T=75Db:J9="++- B"jDe5R_?ڤY*J%>Ƥ|ɥHF EnzOb#rJu Nw 6# So_JzjjwbAdDTGbMw in&i>cZhƋ"RL0( *&8AgUwz Z&"(! r꺮ڮʮO@lFz93T0r:0VkbhU[ˮA #R(7I` {+:V$!"%7T w8O p_PY 隳Hw0ƪK!cnR;T[V{XRbcf#I;+x2PdƊu z|۷~@O`p۸#Џ@[#`*G!{p?0[{Ƀl; V/2J GK`,%{țNs "o0++=ˠƫ[˼A1`p۾rֻ!'[Wk;K p<\g m [bcJ E`G0qI0 y0P = p 'P9  @(`.@*Rкo=#0Z[ H!<%|)-1<5|9#?C\G*pAAY ]"KȾ;.`e "L&*. 2L6:> BLFJ|ȼ("L{@Ƥpgjm p~P _>InpMNm03d0'-jU> @I_~ +ѡ=NrNjH %JԺ(l>pm[@¾rO>>0p *0` {WO$&~-l>W4NoN׽UPJnh` :%L&̘b&r@d~lB,R$Bȓ'u{%I?1eΤYM9o//Wh%:t AljUQč~h$H7)6!D-bԸG,!$r$-_A $$EgKEBTУIy0CRLEt҈$fB4PXpA@??RT R5K>:*֬V3̚5G)S Nx1ƎC,y2W^_>O@5T)S*j:N; ;s . /C0S1 20ӌ3@4PS5`6p#qg-39l@А:c“0B#D"$TG4L~ jJ*I|@'Hp 20IÔbT4;,{,*,:,J;-Z{-jQxSt(3($9nn;*kJ R=/ s%IabQfKS?6{SVi*:ܵAO-/)C6DUWDT=QR+mS7SC͑TOQ3Yu#Z&mu(=#.=1[Qv]qzvMo9AAIJB@wr =t;VtDL4EJYEMeFPquGS} `3.`X v~2W)yWrdi%#tv[kӿ.d;SVϖ;fAx{v}Fq-u19Eձۅ:H8IɭkņyX/>֟CipVܻ۾# q㢹.HQ qzߤ-iUГZw*~u=byme; xBvD+/=^F\v~9Q >+ёOkwP> }3Vڒ)Y۴B?i`  x9 d!g gQN_KÜ=jjũn[A|^K_^²YbGpDuPZ#S;ě'Ds5!F#}=5n^DܽV}1-s"ץiTBdVUSh=-i:8@CR(kNxDRP`"YE \j#)8@* #  YMA $ ` BA#^ NX})8|ZcYgY\Q>H `"[#EH@s _8E>؃$3=&|X!haC4B  h0%0@yƕ(b]`o}j\$ pu (k'\ gX0 bwIӄ@=ט, >̀1s*aU S V4$`p0?U  xC)2H/,l6m0 +hƚ8˙vPЂvE0H$cm }K*y_LHX9%>z QRߥ  f8A𝵺7 q&4ۑ2/f@j_UE,Aw!|9{đû=o\7yൾa(Cf>jXX6皽_Ǫ"p`$U*0:{{@8AGd@0,0;a7a |{/yoA <6C c肖*C]f`g9 2h]$Rn 7" |VeTg h@" 6@'>?~w 嗱/x  @sjF`b=L禄?0\(8 T}#w dsGUA`{|;?Wk2Fp-;;L@\@\ 0P/8Sd? ڬ.+*( E (G ˏ ,?Ux @ p*+4A 0A8sԺl@0 C1'ԯ !R&'كZ#؂MG3҅X-8AzGA'RRPW:Ax9dG `Cb >)c./CQŖ렗;C/B&*P&CI^# Bj%rڝzĹ1U6;" Ug|FhFiFjFk R .$0V42(4[Ś0D:*_|aEbU~=H N8ȃ<7 Xc٠ `PPK@N H$"Fg)U(xA`1"ljRbZEv q)ɵr4'!z!F@;J :h(8~X B`&hCH`h\`YW0)`4H LBFGͲIO&s%ݪEX]1L,F=JL:|$X̘xJ~}(R]xz83SSH&l@@K2[ { Wr(L4 3~7SPJdXXh2ȃ?LEx00M7$hxr̂N6NS$8\2x M:Xv  Pͮʰ,4KTKĄ˹˻J=ЕT| pBk¼C0Z7@90`0##U:?ŕ:VR7L#MRR& 3)R->-P'\ ,B,kADMTE]B5T*իF5'X1U¬ %Q#HMGR09xQ!YR¨' ϳK)44T8Q-#TeVBE0([5]U>e"@ERLW|@fl=^sTw *0׾Q9kY0(Y˿pWhC=%b(|ۃ~[@U@00WpX(*H$.@uB(ZVZIE[ `2s $ >{ɝ\ʭ\˽\\\ 7@ژSFpcp V# T`o`c HՁ 8K)[3 ]EݰL5׍)fU7^-˛}I_]_m_}__M_ !u.8 C]zzP TX7dX$%^,]L]7ZX(uk0F`. 3_¹,!y _aa_pgb)PUtEH9^ #SðB%_?@Ǵ2``<8IE('$VbabtI)*bƋ<'aSt&4$j*GU ,/4`w !$8tEkPVXL#6x.cJ!KLe @s-R^ff>HTdVOzE-~᪡IJY{ͨ$YhKKff~RvfらU6BɘEZ޾~no#p$cydts&f~hPVfxh眀悮|F}+֑ش%poA^TxģyLhʚr;Dw&cTiNT>KW_ v#.fsf[8 i6qBk<*gM$mjބhVNk^knk~k.&(렾Ane*{T(P`^g_&gLX(#0ɁDP=Hllmm..)L\\zFhqLhN#*8lIqoji|Lg(#x(h&qqqq&pn8P׃44é gO16q.ض6Bg/"P!Op77g%= (vgb.e!^G.n"`n=tLtMtNtOtPtp쉘 %0?W.(CrD7qfz$G5f(\2#dOve_vfovgvhd7}PV/rk07(#p0%=]u`/r2bSӼnmw@mr950}X>iAwnt`GgBх @#h~7M%߸I{m&wZ-X0`x<\epE_z? y#XTY([LWGjAZ1Ѓuurg<ȅbr=ȃe &H#"(]hIO羚g[`zox~moy7gVMz8Tvjc`MP%{{TtuXKς;/ksy|08yvDT0Z ͗2TEyN0IxS@Yh]0k fo𕏴xɿ=,%:t AljUQč~hXg 0kL.lL1„(P,Yb_6m! )40g 1pk)ԨRRj5?M@HDyo =_=lKvN N1v=;f@㬔=a^%Shѥ\Lq$;baD3jq 5#KAf0eҴs'/?5( R4b/n8" ܄P'VqcǏ!WD3k̹tR"3@cAP&L@ W`0H?RQ" S!>5>Lz@K 2m~(A 8@+q d&; z/b 9ȁ Ơ5\)@%5 0 HD()(# sz-D P-D(B$^I3W%HA @zB 'vCMR@Pz΅҉ |C@zS7=g %t/1B* =)JS*/42S YҝJHK}L2N}*T*@KS̠038BS*X*VqƮG_; b&μX%,c‚W5f` TU;A~F2:@! /TOU 8%Ik>V>Xt,hD% [[,AeU1z2PUDW9(8d(J%Rjto)A/[`_k|_8;`r>>}}}۱;;;___ooo///봴ʹǺƷgggvvvyyyOOO¼<<zuשwƾbÃ'=E"ӛO~y×Ϟ~{뻇|ǟ}؟!B6߃E.azda^n^|XىYmu 4h8<-(h2iH&LdwMHڌQViXfYi`)dihlp)tib@c 硈&z$B(tDEj)0FOv) 4Rűi< A, QJR@*Z~EFFc ʊ)njb O{rʆI$1m&kJjT!DZi[F [,:эscA X*Rȅ R4x0,@[#-IE2d0M6Rtd(A IQ4e*QIU4;YR"d$.o\q%/mLL2f:J  j*) a=DZ1'7p* Mhqzn:TҩI? =63*gh ;3I \*@/zs* eCeEPQ "CM;@}#L"ă?0)a B5t!Kի%5)Z 7u4h@D"! BT2UTu5 NxгGQQ`-HJ4 hfGxElfYH p)*kY@*ek@$ T$i\ VEk<&zm[ QkTgr6T(`?n>_2(4Ȩ?_F7Fװ?8¢ .MhW:5lw"o~@"X @|"HNr+AǑ@d%{EfHI    'K6 wAf qMsiH0;HHFh*ѐ5%T!@|'l2kh0 nw-jI!RE3hmk\ԼN}mi$9"&1Zik; )9A`tTQ/+>_Ѳz*mMNi֕vU0{+(w̃'yVmCJ-ѹJhv>$ ȶ̏p| y/*dZVVRpXU3DXG2~6QYz;x]^3fxH[? ~G Zi{A>bN'wz POn=MTwC;G;UjZ$Uoz mbfn wdr UfmKUS%TFTERUTLhTs3z7&@ YY|y(   SJ%v Quu : t@iNuG]P b(jBIF% @b%fir#6y8AWN4`k$ J[pEGorIJfQY Z@wzyUSdUtH#gY!?4pkn i`ڰ @P@ `F P0`PfIY IrZCWB~49)@plTPiv`U@,YYyd(HƹdT`鹞9t29PZEO7c`k p) `+)96z8:8o>H#z&2Ut$O&&Q'@ǠfisMFiB %z B`yY]TС|ڧ~= ?Vi@ jzmqLHv4`PyTZ-JZt s`)^T@`ak>ar0B03iHp*.t0 j)OQ9)Ǡګ zX$EY@4XQة`u ,$0z H@dF`adef)v ZP%`ڨlڞn ʢsJzNJ)9 ۀ$[$~@[ {(3WAJ8Pp r_G D { `+ \૞j7:'9Q˳X ym+iokY\{~+kثkދ !|BPL@t0d0.L 5ZV%Ĭ{[ܽߛT\5f&4k;@h){Pn\X@ k { |gz=7;ă̼ LOR EY ;ʼ;ɜܟ< :L͆ P\b6ʁ,ˁKG|{W\ `DgǼ,9G<ʠmjBBk \ȶUL  ]& j Gm , ZЦ!=#mMȵķȿ\!l'[PR=T-ՃSu 07$9-{FlIιPS\VHJ@M*]@/Սm:u,(Va> ]ˊC̹ H[y{ =x=+±ܜ<*Z֝9L;t7j) _ @2  Vjm^yҡݟ 2 .;Wt]{@"PP5@K<t %~.PF--n=)3NMm@vΣ8;gm= &lÈ: m_ )İ Tij` MpW U RTKZBsޱ(:g[ЦMUޝr]Vm~-`k8i;`kخ9b%.I2f'^@ e PR 8N ŋwɍx`Ä >l!B B4hB=6IebL*[B3xNJ5T B ENJnK ^B)&m TQ)`E @) $- o;/hID ["3F@(l0Ft4 +0C8ABC;Q(/M hPFy +; l @.R%=JM /$`A8I#Pv*31fUW ETQjQw)Jw*#DSN $A] xRp(QrV_R@/ Dʼn%W&lMc 1 "$/62j㎹doE.qMH2L 8 x-x~ e JžOGZEQ<_iA^*i)D GL8#>X;({vɦ+M*  +:Spg xx|@-4F ecI%x7/Y`C>6 PTu7v F&mkC`=e1@i ( +q $ q`e(\ X~A4Jhq)$ 2sp L@"Bg=ن:aP:@BhD# ., KlCvO;apB2#qaW&"p7@,.LA7ՂBK\B-'M!֋J]j[7ђTv\#rxԱ("PA|"Mh #ZeDa b0jh0 , L I@kYՃtl l;p!d`V)[K(9Ιy)`]Dԑ*& J/]~JBjE+L5QM!7u8Y'-G_0%ݖUS3{}g,eт׹]oO[JAł.ƹ/] P&ߞxz$z ]!mFZ0vG`˻<Њhl@S b(R\ ó?y1w"c5%;p)I7Www^ 94YCzJ59X{s\FM+T:Yˇ07W̾#32KTkwu ,VsG;5A;\9KXZֳ/ŌH[p$.̼c4_wI?f#LV&PЭz;?gYBܭDq^ T`+ a w@_}-4zGlY:M/3 ͟KIp@i=m{瞞;WoG[댽 D^:t ? 'DpWQۏb 0|҆d};9JsBC x:i]eR#n*!+8@-8C"F 8?d9/ " C0;;<?;Bxʂ0A8̸s\;{xK-,@$ &"47#x@1;ck>d=hcgx.lk@ 4:!@ 2C@Z-,%|A3HVe%eUguM~R-L>#O _ hb=VeUVQhVgUh݄i݊m-.F?5]] HH*r:?t -X-0l1֢؂=-e[jXނ {|-}0ԕ 05x}(p5%YY} ̓剔\Չ~ڝxڝZڜZ!2Z [M hl[x([`.۠ۿZ[5 Í \h\}ܝŵ\ɝ\Pɍ۝\ -\=ݜH uݿ]]5E]֍\- Ε$U)܉]^ h^xޜ^ ^^u^x^^^ˉ^h_}__ ]^_]^(J___ ``V`5ޜP_>^ F2R Y $`S\]Y> >/=a;cJ}>$ؾ0G nz56X^0^` 6.!bK&v'_b(b,bb/F>h-21&0c4Nc82n5Vc47 7n-:c8=cc68c=d>56>DFcED. EhFޖG^d2xKvdFNOdJQL6TN2uehYZY~e\eZ[^a]vbc`VfFefH\fYxfWA 30anjqi.8gmfgsVtwu#hNfh~ffeg}~ecgi&FVvf{hznopFkhw葶hr.Vi=@@A6d?Ή&隦C雎BFjT.eRNMSΉH~njVUMkj갞&0^c~kkkk kkH2.l 6nl6`0`vlˮe2lN2` l.YlX6mئΘ3Nڟn%2Xb0 8F nnωl1x0 X1`_4Ή4֞8o > ho}mlI'l( g*莇0H`6484 m4`h͉3 noqBI žmx`383 4Ѿf* !nAm^m3V@3(r `ffbpr(s) . 6(s.mx(x~nʞn4I7sHG~ɮl08$%>8X mC' PGtYPt~oX6P1xmFE0Ⱦx@lc d׉x`2ukFnvn2" PnB^'wu7.):_wx($"6x_nz_p|wG9pw7 _ oJ&'GeH\x߷6xWy!GWwyYF\yYfIyz x0zWgwzh|6h}n'Oym y7yz'GW{d7{wy7'Gy,z?O_o7v|6gw'G|o}{5'|ط}_}7G&~|&+x0nΨrwniSn~7a/G{mF8Ԩg0~ ^nɮvI,h „ 2l!Ĉ'R7r#Ȑ"F3D49%̘2g"&Μ:w,ɀx!Ƅ9a~M8gŒ /)PyrաM_ǒ-KɔaB\(t gD`2 2I L %di0a3n8aI˄;0^2„I U Z. 5Ԫ.^5 xz<6 nƻ/I.s2Ϡa3gܺ9p uwe/HhͿ%Q]:wz`Pfe[o6P^{W`uW3!_uTaPEO*-EP@%UV%5Ћ(҄3Յ޸ct5cL9f$X$p`7dQ"vUV$`%^Q%ayؗcy&1&m њo9qylݹ'XgBj'd pPj>HP>OMZ)F:z1駒r jAj*jjBj<jAJFAbkA+Ak [kΪl@D$J .DC,ZKPO[{민+ppFCpNlP^[q,r1A $l2(ǣr,lP-:z3]F:o?r;mKyt65|ВM>9(ѐHH=QH(1M5tJp3$AD<(VDBݰݸHda"0v0p̡R -$8/Q\HN,g76*:Њ8ax : d4^ ea #niC` Ó0:qJ6K٥EId H:toZH%W搬9 C\&7+Y~L!t4۹KXMj)ALI1e!C%ALq3&լC.o^,7:Lys PɄ=a"I3uKFahwG1C`'НD%ZEK0rE(4 < B+CP+؍7Ci&V3>!2y/Ɯ<\4 Y(B= W3 3dkyXDaπ~D- Dɓt1/[d4 MA{![y !pnCBY.f샟8 2y3Oht}w0~68\A҅*T@Rãym#SS1LAW"`};;> }=MC` auaoK2tcx Bx`[fěLV #d<p-D TX6sxiP2 1o3wp$cmQCBBoƆ| T:ǃN T;ٛ;Do(Bsx kPyl /Bǻ9ChPe9A7d^/s8D}{W$pqx} b;r)"yx=7Dl~|_jzc˿>'RZ|CVLanj$p[σ{phd<_C->1ِZaOG ` 5_yA`)͕!>Qdq`LdiWxɐv}UDV Q<  C0|!LH(_2 !p VO-|}]˰ۍV!K1ĀS`aG!ALWZݽdx)D VAU;Ջ)1D:5_(t]+B@aEN"ٱ -B̀B_%JT NE)"0 d;@C.R!L "8Bb#a6@BS*6j Q+\D>ijcPi#(n<gx) | H$ 1DC"((4HAi( } rI%j6PB1x+@6$0`aNРW@VfSƒl ***@h@l@@ 0B)¨֧B:Ķ @R+>*)n$@2 ؑL X&Hx<%P߿*dSt,<@jhVfv6F봖(hq'd:,2 @A ( F-NrJ@Es͌DUBKL&2|c-F( |,ٚ-ꘪ홲þRbrǂlގ,쟢lDfmhA ..+@&7~( y0A<|@xC8h :ذ!A-&L V,yB<$tIQMV,Ym7paN,iDJ+["  )]sdc `wp~Z;6`pөW~:H#FODapm'PD"U)TTb+",R-.ҋ/0HJl-L2 (2lLۑK HH@ oj**:+8[pk lK,>4 &D$> X<-Z{-j-.]8UqGR W^T^fvXF8"޸$xhu XZkw;s4Z36?:S@= nHjE/~a .qF|& U׹E>3`~/\^4 A oxPC;.؀b xf0 xz/^jmb܊Xٍ `o p(+pc2m-Ẁ!@p`XMǧ X<H/-ҶW5Bb S "W7^Zl[ Wծ< 0A. & Pnm0\ņo| *TE9$efiC cM:fB\f3iV[Xls 'x2̄ 7 MhCw$>-rIօqv9H +]y]eg@C"%Jv Q A %&(E/laSzIhӆދ1<Aȝ=Ӂ PPЄ;'"֟Hh\r:ڹ'I x ӆ}5}E*>x_ajA*}lns/YQ+@ ȴa<¶-Go[G`d&uzhb%\s+C1h '> cD#0+æv"4`9u26*. f %ZM:G~m.;iZMw %8 W , ;ť8 mlgw^@qD: Z˜Ż Gsf`CRl]B $®y.^=MK^oN4@=v% h`|Xs" 0&6pJZ /JA C \6)"(ZX*?o@8^ƼmkP _:`龤jh؎n/ZB~~( r/)6p;ZA @e΃Jrz #'ˬa"2%^   `A~ ba6A a TA~,1t@TRn - Of y Y" +`~o ! Xk QeP=pM M2  @ἠxd `j6`AANad7꘰KNFQ70q%p$ UְٰHj@`k- Sh› [V*:ڀ8ppl  x` $!fꠒ>`6@@"V f.[k##S AFD1H' @$ l0IF`(A2S33 A &'H vY*'r%M'jJZ))D j!|cŨjh+{@I |a,I^8G//5rʦ }QB1`'x ix`%`2ų2㜃:&?kA?d@<! t 4 /8BH NePx m`gԑ1 x,`*s0 a}A^ʯHa ! @:, y/ 7~ S'A~@ =K 22 MANN5APt@8!۸H`V` C-:7CKCaDC:Q 2aE}! 6d4\A C,@!:*Trg `2RsJ0E6j%${5BZ,"`r ڨæ /.% 04 -G 6S ђ  "| Ȁ ^|  _xpb*A,!6@ 7D 41ÜI/0JS`GR>} εZj]]G @_dRIM "7iY5`7U55`Sw ,@: 6 D$!% F ^h`I_##nJsV&7JqNjMb&KdL=ބzN~.].Cn01^fsq`;4ZiB0' [>!ugyhqKOr$s w&̱qI?tv]Av'^ &0Rf0W0JqxqBXW%7y8} 8qs rah뙞 MAy_g@4%cb]k'{K}y|/4@Sg7;Jk;[ iYx[eL'%U"pTYqs@ I ~ :u,evidsm5/mP]o9~W8w9e" ƱtƏW"eW1wq {ԀR+ۆz+r0:oK-a@`'X5 {1/|;ثIj5w1ycbޮ=8qY$ z ۰ ߜ '[cwL.Y6S-EشӸOEBr8fYo7ovwaB%x z; Ŵ'$Ǔ7!9tvg;Xa0 c7|0SY+7ocײ]Ƶm0E75t!z|S;[7%g=ڙm}+Ӈsq19rT`ޏAz.d/b$űg`q.C{IۡۛƩ)zdv  oO>M T ؼ.N A]=}A["í 7͵cz`äya~w?  @&>:u|BQ|}I8{.5}a_Cf:W>Ӂ0$p#aZ _] Z*` __x!$q`*@2KQ?H>%Lm0~"D.4hСdž Jh1a TXb;^0a#F$K<9xAqA»lpCBQ%KatbKʑlL!F{9Os$Am꒔:Ԩf5OjU֠ek֩u_D%!6I=dV=lh[ǦvlP7Ք mo7mtiwimo|ӻ$~o{;&I{G0+^['3S\H>|+/9Kcx*O90l{:}[t!^σ'KGtG ĥ^[[z׳~|29Yns/{njO;v}r:K#d?' n)71xC$o<%oyT>曏<=/yO^|EtgWYzc^m_{~^G}{^_"Q5曯ZΗ>>OOOggg999͹ķ}}}±۽ZZZvvv@@@<<<XXXJJJ˭ppp=== 000yyy,,,PPP888``` sss:::***ddd777uuu666---tttmmmnnniiizzzYYY]]]^^^KKK...(((lll444QQQ cccqqq))){{{kkkUUUfffhhh555jjjbbbVVVeeeDDD[[[ FFFGGG\\\+++xxxLLLaaa|||111III&&&CCC222HHHwwwMMMNNNSSS'''WWWRRR333EEETTT~~~###$$$BBB!!!AAA%%%"""!,| 8@Ѽ/#8\qs歾iKrz3W9ѹNuӝd;Nz k{c&")H Pw!y,Vƅ&$p@ *QPa(<.ІbtYD=ь~T'hJCJҁKSxtY5ir Su6iB~ST.ELTB j&* 0 ,u )Y ցyVJֵ5v+So_7]T^paa8<Xhld~PX  !/vxś: w+v7"bQ83xz2 pP;!.Yˢq=Z^oϯ6m `rXXHT 2mXqvK_~OpKe* _8cm*K"@ 8Wm 9w7Ӓ.fޞ b}>ps1E ]VYpvIe.1>&*Z@LuxI69E76 n{*d~#1yǚz/[`}Yߔ#X^I?'xY'r=oRu@*`'罚F #_Rם',J)!;(h\\| D^dc0tpB0`pz6p†%rFyI>P} DH7]a)bbp[ )aFg2qjVZnUvg)چn'饒}ǚkc>P 0Y,pWz> 0&*:0[@|ة;;B@SPaPDap*ij^j8[V)Q |!DW6 "gvkUb@ hc<PeﰐU` c| Sym8 a@:Ч~BZ * "gBJWed2tpz'ʦb3i&H6S> rc*cZIjX-e_j֊S m&1gzZmB*a[`:pb|r&W&( ":a('|Y,Bp ˧SZ6NB ɞ@kI78(&+b #{a ){6Y,j7ˮNeRJF乮A :f6w&.Y'&8`0O;BrF', cP 1*:o$NK'm0թec'pYȑCV5}X6]{&/'KHO;kcSZp 72vKk={bz>9&PjV97qz ([ ?ƼFȒf'D' '/%eڷAU2Dm*Y+K tVB%d襆">~;0 J&/EԴOK 5/Kڶ>[|cf0^~^C0Ŏ*ϐen{gR&v|h!F>0MN Mc-00@/0!` %@c ` Z G r0y<hΧQg#ݒ8`6qp:YO'('*報[pѝ} 68.ڤC^G%OS^A@ atӼ=Ԛ7e< \漎  Ti` Rs.$cI`3יhˈ '_2_՛'E0]G+j@ S npޕߗ.DnHP. @DHp4^>)rJ`Eh~0 PC `~]]F:s黕`o(ߞϮ0U Htj` Ln_nLp0 PPhXkn&jg >` Ϯ&p R^p$.3g22j_:Rz*lm0 { F`>^W/-ot YPـ}}n jgȟʿ̟6@ro৑Z,p BgA&gf|t/8dl(-Ÿ[󩋬Z,j@\PF#XAA0`+h`3`x1"Jt&$($I@*G8 $Z(8N*Sذa1a! 1Ԯe#g ᅇ:d u8\B;7GD@`k8hD twgaV\mlocJ->L OP &w.C)ZĨG"IDK2iyH*2=Q@wAA,J*+&32A0K.;CfI: ;, ?pL5T@l@@<4!cm\0 L 2؂)K/R|؏_,LNk:29b k衈&袌6裐F*餔Vj饘f馜Bwx*b$,AOb`IL_PDZkkkp ^{LXt#+X X* 8#U2I^pB'kXA" Ab!Ç6 T@' )$I٥+: M7N< 5o e/$4 u4/xcd:%W[hbV[[q;wfֺ*"d9jbMIUm[p "xH0DԢB T2^{)7wp<3Ho mݔk fɔWvY K_߹s[mh>h$[˶d9o2!H8$.{d[8N+{`,OP ]QQ"=PTtT2SEdO^Y$` x@VbJ7ӽ0b],vײ? \󝴀'5|(ħ$~> r Pp nh~eg@hw#ΰ+Q#ZG "t {GH)\a Pmқ S+`rw#0aԗSr,f?XS)L[ 01"L]cy Pq( ^[ӸIBp*T$#_<譓n$vDq̓{y30a+Ĕh  ,' @[ QZ jC@ 0K~!\Mq[/f ișs.d IvRϝE#%bRE#:5P ?hrU֫`Dec"(ޚxծC*n?/`YS:Ұ9bQ7]%aQ=!*uD"PY~{AYZ6*kC8 xE @@eo[[KGט7,9؉.;TN3H %?TS S,PPX>, !w=pcX;1!n*$a#(a9mAx&n!Q`s3,ݤ=xTPL-%@E &@V< VY@cj@F|Eɩ d:>+kJo4eM S'=3pf̟'Jz*NC<3VU@DC }w#шX~ G?(b%-jFҨtpCiN.:+joP]ٽQ;`AS>b 8,Ss>]JMv[KK+'`wL``=\P#vT4CN;2@]jͭ.fZ_BWlGek A]Lt#0_6pLA0vA{nW_xG1P#yr;'|4*līIi aH)ys 3'|Ba :cd?\n ,+&< x &{nzOsYXmw3?P*P\(ePI(> H6@7U`$Wj>Pw >5{5)l0uaU*} 5? B)T 3*?d;Pa;??"9o%0@ 0;@x'ЃAxa@'&Bww\T8$A0@DtX,J\>IŸ<<'ѻN2/l]qÂ)2)£22@ hC0Px@xNd4/$P@@3\'4+a@Y*7 #0n4(@8?t/%(H|>M(Ȑ!U@G9[N脴 5A17#BDq =(BC- * ;Vpb)a9"I 4+',k0-+)QS? 0-I,jHp^X` VPQDLx@E:1?>C?k?+H&`ҎQJELj{fyh 9bdLp >r>wHRR;2CYGuQ x(aլ758xX7U `_SW]paqU 0);a<;u)MՖ#՗3U[;J0 @Iu:@Mt{{*X`],uAWfݪ2-[Y)1 IY | 2tY`= &+3w0 ;;"&p> ,V275bmXӰڃ,  UO@ kOp֮:@Tj Z+ۧ[{ٴYyp3!\Q5\Y=z]U`Kt1՟'}l<{bue\Sx 8ځ<]3x 1^z%^0УU y4FxX, 2P0 H0a'XMFEM) NPN$5-H%&?@>b %`ʈ hb(9CM(S`B F6v"- `ξ`owxwIxKނxcpcx"0w UxA@Ax)0wCPPQxRw{U7M`hcLXOp^}M]K٪`(UcE A 9;Hc`c^(i9&Q-~I_|:CE& Dު <@dAxE`G X9PBSgE6 Pe;]f+O`1AWۮ:f.V%<XeVR! O`T^ d\Ng^Qy_a9w:whwX|n(Thx5@XXd<\Ef!ͳQP̓xMhϔf^#ѰMX%[[ˎQ̆H\ -FFU8m9F,̢NցKULgDN`؃=6jHGj hQx44L>hVx)6/@kpuASXf,FiI$@~ G f5Aua;81`&j+P(E;]8B؅lH0N%mZk}4-F4H (a6/؋O~n4ЂϬ/lW.Nx8o`y eO@Zųv3򣥰MhuI6E]*0+3ҠUb /Xs"Po HC^x&C@8K 2):kL;.eT:xB0 e? QP53pr쬳R'K\,rr0G(1'p3ߏS\(L'W x7/4 ( :hs+ԂgP ,+sۻn7 # \Dba7A2V+-YS" 8 ףk3אtUwP㋄nG+ibu.`  eAB_cf5v'Ԫ2؄d}P\HxxJ: n_? yv4+#VHv1+<~_⛟Zvߗ1 p$)*i$zz?љw5  -#^{y{8x @lj x\O<>~WB8O|vx/ gܰٱWUsg/Ϸ L0HP$%H0"e+TiREƻ,2(#'ѱ vac$;N4 $E("PDR; .%t"8pɀpA?ޑ-N$!_ֲm;W@ ,B; V0/= @Ã=PϨR0!ʅ .jX4hh;|0#G$HbĈ%!BXP@G %JXЁ)*T@ J0k ǀ ZY R}Ǘ $hB!JhFs1^*tĂv! BG(uL(>`csRPIEUXe5"%Xb|b]Y *1B8 BA -=w;V@I*$a!$Ad VvYfuYhvZjZlv[n[pw\r5Hx ,ƝwGx`G{uB =D]F5 1C `O?e xTz8UUW+(Br gDDE 0W]xQz^,5eYfyhjlنn)q!sAׄ!8~& h߹^i"h U^AA*ߤY_~-O.g* fQbI'3HSlB+-X &@d:.#Ad d\ vi/ɯ)0py6,,I'@y$ۢ'r|W}6x; ;@_6I%Y􇹊4% xu!CК0-Z[{;:(CtޮYe_+efkqVp3!,]u1Be r\(1F}Q|(eK/ @:AhRv>O <J @;b2hZpyHq $F4"s*0$$nY]t0L: N7H4 n@kZx#BjP21=*s4Y*(E&Lf{@thLE)Z_ËA-I!BEwa)^Xx7qokSaQ 5HtE,sGXM.= \q);EI5T)qޢ%# V<,dI"-a\LI)I)2lb+F>- }^I)@,&`x_L$swdfGJd`1ޡks0<F;Ȫ G*r" >PCF0 M DPsMV $j5'^F{  p @5H?*p_v.m}a*UafPW3[JzGǁc#\I5'PBK:@V5z$ 5,fYMyRZ8'[N0*]k*bmVtʷEzkvna:irc[SX`:Nc,@nx 2@L;$lF[EkZ-ʥ EN "^ZGB0B~sZSST+`Mc 988YNV=NP r3g/ƊqtR;|h^c݃u[Q!lNQ23! '@;z/IGQpC0F)ȝ1;R j@;' X1ԀistjHKнһX e~fD w9.LX&Cef!PAO ENWLiS-}s[ ub! Ǣ\]&Q |ǚ6(ގ|[8&?SǓhu5`ed%@}D^ьp%P8]fF^Mr[3&mn`QJfX 02sIT1a]S~`rQTw5f$7֞lzp%P-WAZAw,CL{5zy٥6-kÇv RXHt#f=p>PpA/(k5-Y0/-\7Pw#.@B" `3~ D6,F7E(] ##̍!qLA2C({%4b`tAZTYcc ,xY00Y6AL~(ȁ$A!X($XcH,:$ Id5@ B&H7YA.h%a,IquQR`Zl`(4<3I89 #0lv`YB6#pe4%pd h#T)%Yi6Cj:jAkzl&(B!$.GDmYLmV-^zwEDؖ~DْقuI---ۊmmݚmުm ߖH8u.(n~V+-Ab||.nz~nvꖮ.<욮Үn.. /GnG */2oG8oBH/34O43s22F3?BGs@1;@#tAKA@B3B tCS45[3H3|GH?3>Is>?4 8{frG,ÝT^WwH`dx,*yt2-<ā0@\9y[@;A;āAyya۸YTqÁ9< zGc9:]1`\:Te2-ck>{+>W~_g~c}Cu'>]>ue;``*Ś׿vл3rt+ D,JyuG؀̜2ŨL!I+x5h@N? e  '3hAx8lKpb * H"  vdH#I4yeJ+Y|'%wbִyEx LР* `pfQ(8(؀m$T Scɖ5{-ȗidA@`.Q DE':F-](jAB ; {sf*x!%-gn6m僑 .G'~σ:O7~|(g4r#El m4%&L]e=k16M~5>%L`2ܲA]Ҡ3AĸOl 1x0q$C S4QJ\MI NX^L)v>)hɲahkg P } (1TTi([cUH-k.,2pgÂX |q[ > HHB!` DrL ^@XB v8Ft p w@\.│q N_hp1;.,&  a SQG;x\°8A7}PacG>nI|ԚH4F~r$Uh=M$ A 80*!ǼܥOQA ¹zrS 54`*`;0E\@Іmei )Dw\9pkD@Nwq tC)!wΐT1H@#%萀w:J9BEs'AW$611HrZ&A0t9#Cg, [N4V %3@Q>u ' r0$)u: auӖ"dXwXgRJeV@A9L"U$C\Z3C]Xw$@ zM 18aܤv|lB9]xK6A([ + #zPCѾ6!jNn)PuzA ":02eVH_" JZ{1ŵzրM;.@u㾃j1T`r-IQ;B H9V:ls~n$]R̒LWDլ{ZRYf*{YCr=ɹu#N1H&(hA ht~Q$³YN 8nCL*$Ó,'#NcPckǦy)!:O3^9m:"Y*4& 8pf$}|G Ccec`Gf302Ți All*:ʢ`W^@),7CgA)qa;Y4M.u-l#4y{XNˊ 9eM)UpJ*Ձ[O b0qI@ˠt+5EPJLRsNf*T^MpzoDF@Ȃ ҍ%09&9ەC)~k% Rdl7 @X ulIs UK~%uB MkA)h3P$:GlP$1F:'pb; iVzF%`Om; CXw:~G@lpG:;rrXXm.X p [P9Na $A9pWB/ċiF>_8ܝ $=EZL? 9ϣZ]%:/ {`@`ap|! € @  J| < FKOKpڀ 6:"gfc>⵴D'/@ /%oPfHF  ab!D\a 'NhϝB0Ki ^ȋʀ%[."BF\湒c,J ԀZ_/0 G ,@2:RL P % O'`Z4.0@`)J q'l[;!T`($, L$$t ,Jc @؈ ,-H ߡ@ oKq 0W_1g p w6`オ $%@`d z~ > Ca@@>/:c/ r^'H#7tGwJޡ[7l6 vmbwTcicgoZ]!϶p{r',aFSC@{BKlOz`p˗JaK$IL`? jb8p;L@ EvI-SQYA^;a3f @NԑX;r$%I(rW`vXb͠JFsD&PIfuYhvZjZl#fnpWeőn grIg'$ ,Qgvq7PX J'hHm"|%DiOHA08TQG-ȔSPILxY>`!,F!gG﨑H-(a&B CALhfjl m|8}̵mLp#'gwaDp7 |1LJpDUqII Q*ʝJ`{a( p;Hf"rd@+(ۈ^P㵈 ;NQTr' 0f.[c9B "U v. (Q~7Px? (GQE$Ngr,z~0Ma%Ya hL;^t`8Bb6RB7N1#`;D mߒm6fq AXe^V7L8gӡM/F{,*p($s,,;sS1=nvC *w!sFܥe[!K NA{h`I `p"t x̂<< C;2V@eHY:aY+H爯%@Rԃ>x+g/ J4AKҼ QxFs1r\:$ a-A*xA8D1%/LZB F8BJ3(4U y %U4dPf^@ @#.`AHCJ`K#8 E Ё x@eY43gYpp |i4d+]<đ܎73x` mCPt2P`@(XJ,s_d? /K2fc&4!L/9*.|@4D&BLK,A M C!aDKxvRI]W2%4HBE,bqIBE&AOpЩ&Gщ AI jPCHLpQ\ A%9)h@ILf(3%iȈMK`ꔧ$A2%55D]QԦk1EFDW.:m~>Jw?@@W`&@: ep4Њy#ʩB6,N˲lcUS>V@)a30&npZ.!Mkjkޜ-mۂքRroܸo^_zuK`pJPB';_%8*v! (@{^7(DP}kXwxK;ڠ,8~ޑi:YSq,>uFkm[H0\!c$8P %A fTr$'D) M;te>LsAhBD9J\V i :.0f.N0n@#'LP":="qp$ZY-W:έĒ>>U\.[ <0w*k.XgP.jA E@K lK쬰!v C(pw4pœ0N;5zE75M0._ wđqS\_o#@62;!9yHN\tR@I9 |9ܾ #P Jp>;̝ ӣ&(D!)z&Me_ bG &~{>(AƧ)~o~'"*P_j쒟|r^YQJMvb38{  t ;0pN 'u' P A0 px P|av"ivqwt}1}*0]'(h"+ߧwdj4s d R U Հ@ _aX c @FpjXk -Jçwb.y5$#dpfaa3+C`4ɢ @=& ̡hv!hG?|'wA ,p>W 'e(H`` Z XT 15 c ` X' l 'sr9)XyX{ c IC Y K:> V` I0)"R|` Al-p& )oՂ|Eb82pyA+ƶwM㋁5 ;w"4W "r(qHJTrH Oo`xJ0YLqKQASZ9E`=eZ?L5TZTLUaN#fhpk*i\4|ȕ+%w8A)DiGI6)NE%&Et[啰eFKcye i1`0`kYZ MriTt[w#5"P*#y||h-IXPIxe$!$U5&!5R%p!_"7.1 T[pSqYTMvTǙ՗.(˗5iw.Y Pc=G81:) p%0uh^c3WYyYi_e>8ʥ t 0 zp G` u r M jp׹a9&p(vɒ-!(`q5[L@K/jkZF#[@_ga `;/`tf,u0, x=dc@V֜~ ֦l'p6Aħ9#6A 3> 7 Ь1) >9IdE*8p`&v÷gꨏYyei*E|` 9 F1@ p!P 90oz@z= I4%  P z=j VPʂhǫI%{rJ`860b@`c@zq@؊շ{W}K4?` +c = ұе5磪chSlq;  M`,z #;\d ЎK+;++6+q@ h;;:.[q  760>jJPIH_DN6|)d$P4,dAYk{+m prK10 T]F gQk1X | 2f$3 .\+Q+!}/օep2NJ0Yцu@ SBEf<# I4D2nn{ vt$aYGN& w&ppp'SYmLքV ^ >imQm߮!%+Z]Q4h -` 79 )FHnw hR 1u5A.-e*4C@%>=a}[n3io:la-aey f Bc⾃j14;9HMXzǃ 8p`,0f|OH%M$b ,0#BXPD )*T4 A D IFp}躂'^ŚUV X$&DpE+h0 xs' 1sI"#@ :XIF =&ȡ wnHhң ,Њ8PZ $q){«W,z'O2`Q`.9 = dM4pppW!x)M\9\G6d;0@t'*\d9 0C Ej@%\!,b-./H C +&2d =`  H@0@2+xH:ЍĶ2 . .'[lQ;*`"l"?rǁ(Mڀ ecBdX⨅R1`!#B>3TQM"wNd,j뭸뮼c,lMs 2 $DwH Y%*ߩFX]K/SZ̈́\kTތs X?l ajGf:`ePt&E-(3zb 8TLEa%-Uc]VϔF6W[%@$^pPy Jb!aK[2,Mw]ndWܹ0g @kfJKx BkᛁeOUYuqO1eɈ'c%fy1`#q64z~[@y˹ۑUZr̙QO jw&V3trI| x ?%Ќw x2ȱ=x؅݀9\i} C&$c*dƅ$A_-!C U F-|-C`D "1Ѕ*Tp$R(p,!ˁA*VQT !xca3lhU<% D4`b7,a igz6~ iP8 |@`"aZCR$$DHB`8l#E9#V`aZBRSd,YHB2P '4$ ^@,`3@0HTs chd@'0 `zDg:K 7h3`izC+tӛD (Ik9cjm+h@_i@Nf?G#:Rb+ Xg?[g-) H9jP:ԠtDEjRٝ&5iB:UVժVvի_jV:Vb5kZպVuTkTH2u$t]E׆ƒzk\K v+bXxR(c YHv?eYhmc#+ʒ6,jC;Ѳ=-lS+ %mrk[H|[%LE.jHW#ans+&$uu+ծtkn+B{ _}%_w%/Ƿ=p~`W-[ܑH$ps#< _IHH'F1bU(1_>> [[[hhhMMM^^^ǕȾ)))---DDDŃ͋QQQʈ†aaaEEE...KKK&&&***AAACCCWWWbbb+++RRRLLLTTTYYYdddSSSVVVeeefffHHHUUUcccIIIFFF GGG$$$"""!,O H*@{HE!i@Ǐ CIɓ(S\ɲ˗0cʜIs&CCHdzgO!< JTϣ| 5JJիXj#G$4!۷pʍ `AUt@׿ L&2',4p0˘ a&>}9ӨSɠᑌp\A >z6 mͼ5ɍ:OC#5HVdktC|ZPa1&V G4֖ܰ Dꬸ(Jr4l.;5Ao,\,Sjl @"p+Фn{q(䢼<}(l064 40E C0 $bX@_  PKsI$ӯFWO @3l85ęW7G8Ο֢:+>},xR,sU[aց}5;P*\zsꠓqeȸN ؝3jp\QS,>bn@׸?7}_H8@G7F16x5`aڷ>HN؂~ţ￲; B0!IC:[&80̠h$qj0< 0`x8B0 gH8a@f5it`HL <<Dž:H*Zъ<,~ DnV2Bh鈅 +pgő@3yR|f 64Dž>h"F:򑐌$'IJZ̤&7Ȟ$E Wx07 W %.` Zz$h'UEp0AHDZXIL,Ag,Vfr$c&tҁ 6r5l-8ma2Ča66gjdcjςZ&p`))M} eR S &O0F25T M->zğ2DGjjndGCRjϤ 1H7Rvv{i< &S6mN?X9bNs(*MZRr~[-X5U Ӫ4XVgzԝrU^H)ic  2Ռ,ZӰշ4 /.0zgFJla IT9f'@Ͷg L"ɮ(iAtEjʔmg(@ Ow;i :x%R+[ğ}CX`  dbNs(]Vu+y&]-9Om)u+`5@s _6;`8ݐs^ZQ aC HL.aapyK>>>&:;[\&ϣqQsX*]} . @;HA,^2y̓cHϛ\eXSkŽC6ɼOyGUpt\bt :_9}1Aɴ$USD62  zhB`ЀDQs`*?M(+Imj`|8Yj Yz,`Pk[K:52/ l4 {H籷lA[`ԥv0@9PB < Y_Dpַ[7`F(OnwMxp@O#~DK:&A ;/k9qՓ_Q?kEMA 0A7KB  *g3~0'ppOzNq)i]ty=K \P O `ɬr3WP: @h3׿߶߀@lQŧ5x{= ,n8(E` W`QhWwfhln؋rYǘ،Xט88!I'(9e*ْ,Ɋ! WqdH"x淆>YH i I8H#% ꘒH^`Ybi gcz Qٙ`Py`Y2hћ}G[ ^ ٘B$Uaiv5 ϙ}}1X6ͤ'ɝ5 )cgI1֙ٹ9[XFsncRe%q^PZ :J q)P/G^z}0JY蹠&[= z)ؙd&d>qМ-!Rn^O1&\fp%23KR[3L'Y♁+-j >  87Z5Z8ZIV*@ڜ)BzDSjM*w0=[%1rAQ{9(A\##᩠ZIqc)}Qklm5: W{ [""K%= 頮#l;cYg3O-@750KZCf3Of@ȩH\Š;"S4D4j+.ق H3)앬blB Z} ~Zѧ ^Z`J*TU6?QD+03^5 VJc ep#7tGM31KأJS:b*^<`|yE(,?KPgɲMMU^Ks"1;3'm: )l̪vA@jV9jUЭ](>KΤԅ =5   )&Jz(`%08QD7#;]MaoYB 펜f$"t*X @ڣ{WQ@ g&3*-3QDH<=#kΰ9h=b؎`%]t9%+:ʨ:@Z*zuĹ1!ؤ҆N0֘rR _H@ #W|(PzOj$Mjo !z@[xGt,nG0{.%&m{- m4 [pJ  mj0p0@;Po4`=p o0 rkb}mpM1@jFn .@.iג9^=50ZbSiI/<˳CK=q'K^a!Qw5@ @Cu` 0mI%(tzwyP{CP| _3rNvz#.K^ٿ%v7R'D "8rsC49^{JkڮS@>ot~pXPk[=d|_Wpsst.~n/ ;` f=P d E|>w.پ(nIHJ>ݧ';#K*$Jbq#NŻK 8Z@ilpapf3z'p96} rR_UX쾅0'<:5W%A<$Z W_o6~z4*[>sxTz>oc_h" l~^;.G ~*A?~1*z"_4S\%Y>++$GQ$K0+<CqDK41&ktB[hDl5`E 3!~6tͷNȋtH! n<2# Ճ.+C6˾!J@ AQAzH-&R.1c"&3 ?tH+u42utRq4;Au6un 7 vIKBU1,.bP QpMϩ3`*HJO@\f+3dtXz!Y SI El\,zBd@Ȉ"vbzZuI~K:/Z h!*I@@Y %S)ZB:b)c4 *` I29ivxoL2cxz6m!k X%%*Ml`(J)Z8KW> w!Li)tx!Cr20ʼnsB683em1!B:hZwqBPht<)N)D~tٳ b}mv+I5Qr4NQXQ$}NT}| C֝$40 "aToR&A#FE g}w8|Єsj.V $S!H>B| z!aXw iA:8Kc;@RLVH'>*4cXTE*! 9ץϑk[74PC!Ra.'v6 Ǿ"3e3!%XQ9&V=wzf{˔ ~:+3 n9KZfk4_ut|xiQ1!vS1Ca㺂m s?A.çl/SJ vj5H! XK6p\$OG 2T}H/.қS^Tz+&43[0 3ܚh#$ G8p=5yc5=4A:gr x:Bo@̣;ON׽؇-KE(ʐZ/?e@std%$lWYp2>dIߵ]` ) lKy_w8+<@\=Xؑ@ ӛib@r:@ט #9Yی&6,DZ,]3 `PE;<6a26R$2ARI?*,XB%T;{?+"$@4LC 2@LSApC )ؽkr"#@,x9qJ% @""2J>QȆ1~ƛK؄: \D(t0&6!0OeTEЃt{u$Ȩ&T7@ ЍЅm5S]TU}:YE$5Y]퀔-0fg EV^K>  tډQ-(;(A9"؅Z*FHeץgH.B$^]}]"*W-M ׳׆p=Ti 9{-RSX]}eՉ-نUȥ=ʽYYҞeVEh2) `[^."@z&`/>0`e#.(y7^ ͙QpʯeʊS{W }\RN c.c.H`t010փ'Pc.j#x2㱝 PPa{"'' 0ãs0ؽdPuQU5b b!@b%[ߓ}_Ybp̥ⅰb@KP_e8cО_43@f`NaBN|fbquQRFM\T^\UnbWX>IY]6`E[yM SmJtD!!HcmDg !F,nao.D">btNbuTU)'~:z\G|tЬ .HJŁ)(1ӺZb(~|5j brShviw'.X>iz^Vb@i${S+]  D4h(ЄMȂVj콉覞hبF\Xb%_&i1iqܰ\|.F6!xy9/띎Sgs=,t3 vMifzqjOFe>ghebVY~Yf0@kx*V1*R;/2(2 `""QT Ɣ潏nx#XH*50o,Rќ >rJI&Oz/,+nz!Nqr6bvljܯ)NZ^TWT ?,`p:Upo ]Є;2r[(x0 tδ$|j p,LAlh ĸLᱞW!6pn[[En>t~u^qZ ]}gʌ˜e'fdBB8Q4O: Y'kul@Z4h.s탲"NJ0dm%϶*=W S ceZbvgh:"^lRSfnxjyMNgvT  (IQ&7L3܉4.gFar0JNՂ@{1=-AXz h6O"GwՆghhGhHWqf呾ʎql{wi(xGxpU͓~ȧxx a'vl-HnMGs>'О͈QDwCO_Vt<Lwedt4q$qX'*o'M xD^`( 6 & >}^YDowot__|mN||(zl|:Mzr/Qv/{%Pں!TJ,h@!Ĉp8ᢅ6.X`@X!F5( 2(D`Aˆ@0p`cf@Fܤat% 2DKdR)BN|nJII`j $TBD!!@ X]V:3M:A)٢*CBS1勭4`,P3P7wM/n8ʋ Hׂ,n}&~fW`! uo?2ZX#H$M"^5W5ݔkd5fH)ŔSPIQUWYZmeP\suW^{C6XaQFq&g%hj~5kxmynI9%֥ Ca"GC:38bIܖz@%YFAynuۭBO8w;!Ac9BlMBO[rüiw| X<(&X@/l@᧋)x" peΨN"6.b AM0-NO D:CPE:dٲAVLN)6j FNV9ݓ+:C K Xk `@ 'X D8!,\>'hbTլ@Bmfa5/A4Cl#LhA4B7]6BD !BB#'0=I:DQ'KZdBMT! .f!f/[5""b%2YNAEAcz<  @AlrdrQmqz@@33&AT:8DxA @::@$C\lD:. G %|2G2 A9($я*"$ P:L8uC A$dK qQ`&|bd @dJ(d #0@Abd)uiZfBf lfg.I*x\ @PpF,AmAPZ %De(et@CpUJI D@pS:X'A|nY^%p0B)(0c]WTBA &PPB\1%< @c:I 4gqIhvG8BA"GDyQz\(Nja~@-D%x`ߤxRPD0UDT@ z{J SnBPA )Bx㛚X_HUBā4@=F>n@ *h\ ȩD DS݂d t-LWcV2Tr:I0f $@*2g+zDi,fh@ș-T@檶j&jìd r*}A\ @A Asd zA9>7*}>eWR4i%BiDT8e '^1@¤--؇}X8m@Ph`6IŤW[C0橢hA:ĩ :@:ޏP`*fRFDY-V"+@kHQlmm~ |A)pAhKKǘ_'B0F\{>A :9C8,'XI"Jh@tA,E-8@pBޛ^䮺"C3d-H!iu힢rk~ -$@P|"ZF#@)AA^(J%D*.B:P. $ (@@TΪKTPt0P,j)J/2&4/h/bUK=(ob}|K~$+|y @{v2A+@@V@ D7SyJF/||A\% !0 z*P`0(ҰԊbamlb5S! "+ kD QtgDoɜg leA.SjyקQ-qR0*xB7@4 _Cn 7 ~d"$! B+0 cp5|d+9$z'Go!sx38j9s+L41*r"N+oT@,ioP噆D5FYE!D@.6(j3j٩#Tv BdzCKaoB0rB!N`PEJGPV{xB#4|JE L7Lf3BLVM|Q(\s]s *P!iZ_VA\s:mn5S FxbY': AP P0i4D"q&J^ c"@ )ydyrnmn]E^ gwv"#o (kRAU7zz7{{7|Ƿ|w ) { {K n(DG Ql'L."Ƶj(@Pt%(q݂f]Y (d6PtB$BD%evM:h@ ހxy$dN49eJj(Sy(\d9N~sv~yy 9䁜'9! 9瀠] ,ZL:Zz)&V,<@FbO#nH ʀ0*:*,2 -r 뮼+k&6F+OHNZ!!|HG;39-݌!HG%4An.ՓRM5QB[2OD0 Q: C8QWHg QUEXb-ց'Q9OYOv}(B44v8,VؒqAVΣ0EJLӤdL ULХ3L L襇*XO POo8 Q 8:E!ʔH ȪtPTjX @T: KH:`ҠdYȀG pP 8]ua^_]aKwؖBhl ‚ Ӭg 9~{J QG>7 JP%h5k&6·U V"N("YZ5]? "2y[K5͟ uE0W䕞oM,BBA. 06̈;|SBzGQ2FR g0Qg#|GB%%bkPpPtz]PVYEl& wO M\|-0.DLjXd _ O( 0@(`΀xaޑ^\a m!`@/J@b V1>4Qc:t@D9rc{Ĩ 37 ODIP@dW.%p.mp@ /dW r/ k4P"' + q%LrEQn1 - ,Ё.F1`r ,A, v`$2  ֢:5>*J'QI/rr/Dk%)Ð))+0a*s6,+~8] .ybhelhӊz"81Q1?1EB 0l$'sTrY3&cEY&p3BS''3 5 YS]1D6p67)Z*A,'wB;a1$s<1̓S-=1?4>gR>=oFS0 U^ܢ55/D@P@6 BԧetOFFc?u4@02tTHPwc4PV@ v V C$3@A=IL[  FhTLAl>fA4M FqN(cGT rpZPY 'P :4%a $ʌ`NKO:|@nPMDL#7@Vg# n4g4iWWNG6) է@aa;9r!~4 @[[o M2] ҡ e!}J!x]A]ӡ^הftWSW_6v6 4`* `vFӉЬ{)r U!kU1)-F 4KAcOR PDdKdQ] ecvfl^c4gT_y_}w(Ghh(i}jF f `e˔:LƬ;Rqtu\7);w#vJElcQBlvKM@nB\Ko=?O6eߓWUe6u s gKSgqG(NH#`P6rPzz)m<|@vg8m<>)vFd7B1e"8r|cOw-w`Ɂsk$ ŒecѶ[sr "l5nW3$ZUuzm (Ҷ_'7(gǗG˗@Ϸ%W}zrPw~;O7>8p;@݂@ݶStw9H7`-:XI@JaIcO8D S4)Ul >[o_g|X6ug ! _7`^AƠ6}!J}6zu)dBer 7;(y#un~=FeSt:Ceٜт"H "(ϐS+%SU@Bi@ 6a#a3{oFwr +!9 @ ҁ dh87  X.zA927ck=N4SQ;tM)|`k=z~nw6圧ZҹGoZ؟un禞mW1|P`@BD !a vaA\ tL@72`{r#=Ŧ'C!kÙeF;)Q6H{}7R~_R`[))nۧ2$sC%);%E^K.Z$!5!x@T"<!a pL:A!>ҡ**A2}Guq;|.{:)dcnW\9:l#~d7/kc95cgŽI1 q 2D{D[==;` ^a%>#?']D!<`8ڣ_`vRN"! ః! D l q@4{3)(Χ3e`xP(j8g)H("r:сo{Ȍ(?|':5)52Q8λƇ@ u6n{ Q~@?Zp#˵A!H:O!8Dt!VlTAXA4au@ 4JM] -"%sko 3u@`!`3*! ׻绾%l!`*r䩚aW^k)JCK~^6; {k3]td :I耮@``- z{Avn9An`EV!P!WZB12>H1+\gh@` gGpTST[t3" ,fs(WN2E "A7n͏r_"@:u1`PPH hXń +1$@$K<2ʕ,[| 3̙4kr )2 P * B.866XjtSp=>ۻXrM5v,ڲE1T|1%vmP/6qD$`ŒaFPU#t^W`vXb5XdUvYfAЙQTim0Zlv[nm -q{q N蠃:GD:C\NA&@:`vÍDe~ h'DЇ(F)U#YPA␎8@xVȰm8D.u]8.Q *b:b1#(Z-OmS UFQ c\(:<󣝍FH?c֑u'3`jT ׸$S5LUgUmuf%֞ACkBA?̀.c Y5FVQVoDʫ`,ϐ5X5If:@46mm#$a :@PPQ>ZFjnuk]t+0knG~ٱ*ZghDZתwB@0\݇/ pMP[g /x`GHnL ro~ $- vU2ҌgkV 61x}hXf6p\;BA l9) Ovd;AȲI_''\yj5k|_MpGw޵\ټn;&]q~Fuk|\Z'܀ сq`O/9%ISꐧcnU.đ*0߸&<HG BVy9a^B!(n#j53Z?q 'm҄~p2Pʂ1 vmcWĬ~xQv;Wk #3Ȋ /zѧ zԓD O`} W7 w9^ֹ!B:q >k:з~C gw/$Wz}٦pjgvGX{Y ~U xŗr@p Krtɥ )PyS٤C fI[ʛBJa c| P S jx'"@` UX{/ a H|d4PSq:Qʖ@jJaRjRZJ]ڙ`G'` Y` J-mg@tT d { n Py50aEҘ\S6c$ډȪ *;j.KYIS*Z۳y @^0 P ic T p /%/%a-kb& 5J(iPlg SE1x ]` wb[[U\0@ spL `0IpI+ :˸;+w @[&2+` +~@~0Dvni 25`2=@MPfe6" (q0x{ "PwXJ*jB+f@B S r|o(qk, &@_PCA0 19" ,%pIiM\i&e7`p7&,(| Cp 0 g Y| " ?P<<ps`|bd PP w1QQ6AVN>viCd}KTil^d" `E b@# u%\P ~]N4x;n6JdQ @S;Cq:WzNpb.eNƾUnvdSznlp R sXF[U W U;怞*do,{y1^/B 8˯<, }(B`N@__ '5j$Z`PBa u"]pnyyϪ>prn6=P/pJ 8YPR; BL0; E;I ]I)cA& Ъ^78#0NQ>KΠ*A p u,XvuKwQ?k XN [ e/J9/KO|}B 2zK.S0)ٽcO`gp/ -`X@_AD Mt'Boϰ|wrTSIĸ /NcBP|0hu+})N@LR  QD-^ĘQF M}RH%MDRJ-AHͅ5męSN=}P8@(tP\> $QKH2 TêRU>80?ݾGWu޽pXFLxQ:h2Bbb:F)ʉX.fҥMWh֭]=@,NtD G6F6͝ɨJխ_Nq6tMv"$ݩ)r%`IW3n\VI>$ЭِC / 7(74@E% %d,+ߊ/EY _1FA^Q1vjtKYB,$`S(H%)XBt.9CF<@F~$8\2M5;0 ? ,hb=@Oi!2 H& $dj"hϐt%x2>,P-\:LWU*HV[[k:pA#A " WcLL@C<;qY_f[jZk9lEڳAN{#xr!f.lguoC8A: 4u.7)NrÆaf+YO( ` 0lˆp,50Ă0~`Y L.$CmMiR$,$$!Kg9N/%U%$^I1 S =@60LC 981y,SC(j1*U!4$"_xLFWաTh5U'!r'G1G =cHcdD7+*h"=c \H [oJ”@(ٔ?;P:*1 le:~ Ǟ M}agL~Jj78 |@ 9wHiCԵ.v]eϷC`tm x^j LD:x=ÓV:/@dUetb`F*-!K-p$-re\;8HS8ájSo-Ot󬳉'$ =67t 0":VnUϚ!-r/_]z3uydba\@x%+80P,_vnH8a[ S"*,)[ȋi@-,I M(F\ * lh@kk۞1o| /PU.Db#ag9HYֹp[hTjr|e% f:f(NOÜ`m ҡ/0&E2lHO.𐕦@ K+/]LM-n:rJתm5Sd +]Ǹ:4>Nr2 m銽Nv=P"ȅ TA =Ֆmnt2&1 LUH4BrCn1byRkX[Tq[Ŝn1^Ap WC@ SH  rψ>"G&_c^H@GNC6|e偎"D:a;< bCفk蔵1aHG!jtb5EM[A;@I aHʎ+}a` vo;ݡ?ӷN/G}̏- pC9&Q//齡Ӷڃ?dA0f^5B);jS4F>8Ѿ`.&('(K&`@(1fYhL{k+8Dœ8=I-벁5`@j@=#2`` uú:tk9.:iKɓ,O!IH@Al l?yL@$J*K9Q"BU0J-)";n2QCcC#CL:8PMbL3 =0AXIETF7!t+BJbٱ"B4h1O$i"d3Q x5Y {>ZE]C(P?bycdLF?!ɒ(Ic `1G`<HkFmno7tJ's =dB$DbjrDd»u a"2e{ԄtR*)QHT"H 2MЋYZAľ^_T  F`Loqb=g@"PIlIEAFd?pĸK\ Ǣ<'ub\)!g 9J  D:\|:#x̦(8E| Ӟn󞂼 >̺tH]C^HL$рBO;22T9;:L̜Dĝn,͟$$ x2<-0+lKʦ*&P2tS$ԜO`&0ϠeRʞ,L)xDtCH_TO |/OOy P5P;LlPFЌPA uD6V(֌*ᚸ/Y+;Q8e.*&Mפ0"]NacR@b7h3%"U/H(}҄D|C:ˉK.eOt0$`V84]6}SSS PqP$ T֔uʱFݱd5"CJ `eeJBNL+0<Ҷ'DUG$]X;)~XG*ż|H, -b%/}O1U,SgESheSiP8VmlSFpBqA-T&fB.5] =Mv׿ t@Q% HU@3A80ȁbLD[Pdˁ.5KX$Xw4@\ĝ*`=}\I\P\5\ ̕- \-]]9P;`]:p]̓%Mڭ]BA](Ḿ5 @pD VHr$^qb2v= hՁ8w]-`1 =~c P؛@(X%#10.hU,\ ` NEi`л͠B<F#. SK*jF ֐fnNk^W6TdZV%P-H1ƁY fՈH\~ fzM`z}LЁ!; nJhX` hssi5Xf4{  P)Pd)^g1怘i)P)x[eh楂[)guH|g >s%'p=@8l }Kّe$ @DIABTh;ށ0kFtv9~ i_&'ȖttiΞ+P 0pj1)h~+hjjx |+AKW?mz mF֙nÓ ώ~N~g_nunzv jg+V.9tʃ,%f iH9 `0a-p`cCӈ衜CdŶ &txylf~NjN-PFGvIvûx(&`np9" $p@2biMu6~ju`in`OVH~q&-%'osoOI0x%p2TDwxîq*W]5I<# P5DERGEµRV_*x"=.G3߈Xv~g7wl9gl0hN~s׆B/c EoTe Xxd&E(ʦE 9JTZZr݄"2zhfa"B-MwŎƹN-K4ÁT\i?EA30B A [,`U!CX 8m`A ,ɖCłnVfv<+tΗ뮽*D{2lv٨>ZyX@E:S=ܚSR{è霻.Ԡ@$…5r[s:cD$B (-m ,8WwN=@ chY-L#A/qqAWVɵk,\D\pB 0pl }m!`z {؀Y];ئ:.;;n+ ezX(o>i-^P<%.1(7Sc{ɌV(6'RsT-tg#!eC5/ϋ5pM>v2ؽյ`B6ߕ~kB0 Gr% L!a/dhF`B”`JS+Sr!Q"@/qzo{ bH"3 %<Ou.lGCVxxA%Rcdy;H}/Z"nԲCHfξpYCCQMk?[YY7`U rtzK`_j  pNSIā,lƁL 6™BJ 57ROexEN!bn'#\>, <t9C@9X5dh;Ă uE6{r7C~^3+| 4p2Un%&IˀgbS4G=9ʇ@+gyyfH &D _ΜY @~PcfL\̒66AɃL8_8'A(pBvҡ0̸a2^) Gf!tet];E#w< 7aTc& ˛ݸ̈́G ȚQ U: sY˾yWs?0!@ |s;"qb )O+ X#D* 1G +:!v93d "h;ASU ^PBL3vu֔\z*/_oP0B0>nApC_끵&)0! E]X ־R#dzy{y~jvH20 l_/ѩet1`)UhU-̀XWMY-Om՟,_y݁Bu tLC2`<S?Oe$^BDAUT4iU@hA!AdUkbIJAe %[A|VP}u~9YSZe[RzY#T2ʟAcҒT&Dex%Q`ehA $@`Xex#*^&jWPmƝs`)&q^^%}qNBTtmf&P>AZ%bbd/USrPgB@U!㥃'$gg&DKB: @{d&Ei6VHAjFRfL%L˂:^ ( lVBip/$A%0,ڌEWv&A:pAȅg[@F),*s8U<&aGeT({^J:'t|.8]|LC:~d) *h|КzZ qVKZh A3$|ZEaA5B 5/T(xg<_"~X2P"pTG~ \ݐn{GArʧ@}n5ЀҔ$g'uV%!Ae*Ѐ&' x@))jz89pARFWxZJ3ٌhx'oѰB[zZXAl / d(( Bȋk ΦA`e8,T%@>i@A>fB:5VV Tl-k$jK>*T˨(,L)PO+|jk±LMCP*8AT00 eyPB:`A gՂ|2W:A (˒@*P—N<Ьj@m1"eC ю_++F%BSO|2Cxljhe 1A(N0Cz%Tg9O/0 f&Qh?%2D®V@<Z"͖oLa* N2~6-JbR?nC Į.Y"4@ PL#8!@0FV4QT34G2:dU`oL00ApA< 8. Ϯ/ү:m門 o5 Ch*@ӟ%zz@Z&te1|&. #J# / 0 }n,ooB%7†(@P@)A:Ȣ)q)P / 3Me!!'"P B$Ss%ې{AԘf tIf&XBL$ܺ1V&3:/ !W!X)s13GT45{-&Cqcis: {s`ff'Yfz;'J;[ U1_%# F3%OV3@D6o2< t ZɦCBC"TFV'8CPtF F+024#/I7.4J3K( K7@ 0HUdޒ~&3`x*z% uE7u0uaSG<3R=7r<2$wV%546& A#Tk 8wAI]ߵikP.^.`#vpbTsU/3VIs{5V3f5LqgZh~ڰ r$ /l#>B=˱z7qw xbotut<3cr3sk3OvJWJ%W5Lkl tDu]*77#!||Y@88`0P"B L\x_4#yqtN";c3mICsOxWWW_xKgx&hfo_.m|`*TB yR/+q3HOc_5dcd>Gw~yXߗOq*9oV9V_8|c( yp:M zrHzVtAJsUYvS&CXw69v:qǶ 9:y cHz#Wy_g9CwKepfofw} \zofsn"(֠g{Ltzc=Gx>':ek{@@C @9{}k&@ ͑'< |K#ϺUC{{Ńy_7krǃ{@ɿ9z9S)[{bHG%0&O'G!R,]0 p%T~1$ya YSY/WR$Tk5$|̬H0Ku`Qi_1F8 $,tD"cI" `U]$آ3{wύ$2atRA`"Qj@q4`04c1Ϝ5s8k[-È}ٕ1I8He^\۟=CfCۙ@;5#{*t4+⋿&HG WpDf[ >< >@s tT"tjQ@2 .` F?z&p@7`y ~B?thؤtЁ x섧+=q:03P9)?T Mb:P$} @xƑ% J7#`@HA P@MD t #Pb "vfB;߫Mpg P6C`}8F- @``V ) \/Xt8@tMqң6]UIk %R)h@Cְ3_W-Qtws gH2{NC8!Dl&(͊Hcd:svq:+>38$NiKg$,@2?T)XdA',0TڠFl&9 ݊FW+5DBz bF4߂e}ѭSe@bYLxxdLGjg{=LKJ}ePPl-X᳤g§.~:n\Ǯ@04~axjɂ iaf!0s ?j-ڤԁ> :T6dh ` HY>(LMТ4`h`H /L $ ,*rR@L  ա , $z*,6n=` !X L@( p ibԢ)@zhתoDKta B$q "aj1,p.ZF+\q !1݀Vϣ   1bsLK q,:Kَ  "۬ϠpX ڀ&15R@K-o-D@V (w!!Q*!qlp~."2$G&"$ҡRB$q$i2d* rpQ! |2(((} r) ))a**2+++r,ɒ,ҝ`-22&KDd@&@&A&&U 0j#1j20 S$&(_ 3)4 #d@#␑d)^OLҐk46C6`H"Nl674D 4V@4>@\H8HJLY` r:U/0 0s11#2'2/243=47X4;4!M5W5E*b6?7u7}8s843 3i&3BQȔ0S11p_3?g3l?w@S@8 8#lz3ABapBE@.a2JC;]12C2D;s=PE4]45S6B?iFs?{3@g 8 Y 4HCB.3 IyI D` JC44FtFߴF64GtGt@}TO:!9@  5Q Q}Dm>; J%UK+<1255=;3?u4YMQ>I5TSNsU{U4VA83kz5Xcp5dr@դ(;U1'CY)3S1Z;SCTUT5Ku[e[sUwUU{8e5B8%`WuIUˀudA^m$>`CUYKYVL VZZKSaaaM6N#['6\+v\1,ax^7]MJvj?$- XK]D/5fI`fW4gtaeaFNG Tԕi4j7jCWZC`tf9fSaZwvm}mSGN .֐Jjo7t=$pOfR_6l7Llg[Tr״gibUUhubK A Pj@tUWR7zWuM|evETfmDm6wvw_ww6x/hn/y_(@zizC ZDAdfkwSquZ7[˗[G9a}wad@7=CĀu{ՀGggݖbnA..4#:8C nCDil |C5m'a+@a ,FDv!`P.^/|x鸎8x9y 8` ./@,K!,y.8a>zaazB*|K4@:yhmq9uyy}9h#`jxg` ^2̉^b@ 19yٹy `)@!R$$ZBb!  $NdS2&ٝ-1:59)3ƴ3) FY>U3CC=ңa:ezimq:uzy}zj7"Ze,l,Ȩ " :a0:r DZf,  ګ=DbP:Jӡzbl s`J:Ju ԡ {Kz,j#/ ([{Ft@.@ Qr[v;O:*  `3`ȺF{ r@ hZۦ.`"ա! ``?|m b;׺3``|"zDBN[ | K{"˄/`[\Z@TMT<|z $u@U` <ަWݭF;5 "<@} 񽩤mу}]+1|ڜ,ފZe0ă`Ł@q/=//s Şzs!v~lҐܼ h9=P.Y|ȉ:aaLDp V{_,ɢl bܺ  zAITrK?U, =-,"ojWeb?Dސ\mg:ڡ۷1ݥK.;򼿭{ >[o* =Ȯ]=[]|'ѫ+qj|n _|??f|D& H@:!H@]t H.A: YD݀BD0ȓ(S\ɲ˗0cʜI͛8sɳϟ@ aŋG0. A2iC)(Ҡ4ѳhӷ]˶۷pi"F sa 7r0`5ѭ!'y˘3k̹gu2i,!0V9RKN G@d#A NC߽Hi &avN<*C][ENӫG|]*fqϿ(hz;PKP]|ڭPKFJOEBPS/img/sbydb023.gif5xGIF89av555]\]HHHdddSSS???EEEeYdV&&&UTU ### 666@@@lll൵<<<```ؠ000ppp___ ;;;PPP999333yyy---///zzz777(((GGGuuuVVV|||[[[fffQQQvvvLLLkkk222AAA===XXX888{{{sssCCC,,,www^^^***+++JJJgggtttqqqnnn:::OOO)))iii...rrrǞKKKoooccchhhIJ͌aaaZZZBBBjjjxxxNNNFFF111bbb}||ıMMM}}}YYYWWWe~]YXYB@A}{fPOPqppwvvHGGGihhdSIIIA@A><=ӆ~^hgg_^_quoP!,v H*\ȰÇ# l⯢ŋ3j(`ď CƓ(7N0˗0cpfP8ss'Td sH3ӧPB_1jʵ׬cdEٳ3۷[5<ݻx"Ѕ$ L0`(iq 'A0L`Y븳4h0ӨS>E1ϰ#B۸OI9 Ck֋+G8ۂys^N@ġkGKN^9йW{>ᄌz wk}W`^BfSFwUaihbp'J%%(cCNa8hP#L:ZC١HT$G62)HO"-R \[ ilxfӭ9e!#,l"'9gi!xp#}xN>a 6쓋> ޠ~5 ((,>CЕYZC ܭY,"F:v+_dP>y1:BFP"(< mឩ Ъ)/CA@qTofZ?X 7 CR/4[?@ !/xR$Lq%VH_^QVw/tq[4\eф!iEAHG Xz /Vf(hvL?¢n[oW :הO;@Ix\| 9t38.7;sz駧~>ﭿ쵻?wU=]s t<MJ\ƴhY@s+xg~FX( }=0!TfCh1 $# C0\P$mWVC.D8h"ȁ`$gh>z%صPL"耪2DCJZ򒘤dU8u! e%BGHFed,S')iNnPeT FyGAT/D($!,sD-oITs',na>S'N2kEf:ř. 90<Rzs(D'f`К 6w$fπ| @ *΁> BڒFԜh˺I M:CAʓv$GIJMAT&=iD>vM)Sд"+eH҈ƴ )PwӼtGEjBTLTGBUXWdVݹդִ":W W5eHWրUoh\2Wwg^ 5aQ WR# |FYS,e3؞R?(G+01$j-iΞk>{V!_AJ[,.֠M("Dླq;/Rִu{f32]VK^JbwHmyUZnnBN6I:cn> IFը}) O)S-E tSlC$˱sM7x{O F0ٖ-v1bS@ruPc 1̱*&;Pr R$PK..{#~ieW+ PfQHL:xγ>g`)q٬⸞%(> Tioyh'3IEك i0$ :$qL&Hu?pD[map;] !@ [Lɬ7plH9edM늾 *x @; 0 XiȒ܌ЄP:YΝW3\E=ʵ@P%HA,d@ir ӚQ[\Tm~ą+B_َ'_ڸNkJ"nЂwa`}h_m泮sLM ;p$u:A35Nu~L 56ׯ] >hD7~c^낿uA0);(V0e6?>xd%Ё]kq59UB1;r[i?Vzl` @@[3&ڇn=bO ˗ϱɿ]܂T|GLƷ/(gl''\= Z64vh7jdg\g`1Uu¶CBw2MY)j%W#xa0v₂121WG.kAuyxfkAhVg{:ło4c؁TjWW 1VrVڗa`lzg&hHfjxu2TO;u 7bG׃Amje\>VjOw*7{@J;CQ(?1 QW n:qM!kWSAwqtx6ԁsS B6g*E1g!&iegpVmH7M`qg: gsf׍PTeR5n1mAghv7eFz(np8tH0Ȅ4`Lh yaRх'V&npA}&'@~~qi,Ò9 1ydX {+#(Cr^Ew3V6c5(4dz>i|ygEo|W`Cwq[WVLIafytU{P)QiYG9ٙ  š嚷iYiJ9!W IEɜϩD)StYrq:ĝٜ3Bee㩞ɞ8[%CŸRXC"HE[>=oà jY J\"*S4^R'ա9eJiWc':dâ-*Z_f"E#Y!?) /Ck)nv>w@ Jd}>k^响zkU%J @`ePpZ@tJUr:aPn_jPtU0cV ~X*%gMZt Wpکp@ M@eJ,@om*t`WZJP0p-'kPjʺ ZrUʬܺJ:kbz蚮꺮ڮbJmT}0`%ЭPz}>H?X̚ 4}"AȰ۱ ba7 HMt, PD[F{HJLkb:{̪j{k"4[X;tT!M۶nKGd{zrR"xjzp۴r+7 ۩W9# :k6ik,[{ ˹i"?EKЫ@{l[, c @   :p oPl`r uhp Z\ g0b0|`@pK Vۻ{k"&aK9`PKWK[p ;+)$]0vfpkdx}cMqorPh1Pzgb`sk ;{f #a+Ĝ0JK1 <|!<%|)-1<5|9L \kJ\A"PsLj 1 U L "L&*. 2L60R1Ǵ /`"<pA+ȄʼnŌŏƒLƕ|ƘƛFʒ{ R{Ax[\`3ګPb-D#F^hҐmҕ1>8P7`+p m^{[ 3cΰ4Un6 <Ϳ }@pdi䄾P~."= koJ9[W@ @.-.nj60K 0Wc@JV `y೰CF=샮}OT>OJu0 홪ﵚN[KE@D`b wP}4KJp01po::W`qr0P5O .}QI'pA Up eP 74o8;O>_ .Hz Ȁ'Qpe04ao _ >.蹍ފy 2&`*z}j ؏_@ @)(R0N>P ꜯd`„WR&C6XUqԨ(I# RFѯ_"E 5jt(Q‰Yw*'V!b/R ѡ;m\YE2{e&yxFN4~b 1x@!|_y4nܰ!BĒ'O$I  PO&CH.# Rt)(trF4dɕ/gw?Çi(x d%wXt7#Θ6H${.Ĩ;Vn@#6Tb%d&*/0z***:+z+KTT9Kll.cq> mҲ\bKMa Ҧ!\UEA:'2)5O+MR=׸Tô䯒A;T4pd0 Ű VrjDHOTEK<(S91OoUR{D% gc1\Vƞ,vuѰXb2>0Q2Cs6e٢-PN\OO P Ir}DIS;TFOm 5Gb3_Ue՟R)g;Ʉm]׆[r}xKpjg9|T p չHQ4S=zԳݍߜjO.󞮞.ޮk*!.Ov/Yb}v8v弳}ng<\D yq}qh5Gc<̃{}:Xtk-=;Zu[l7V펕GiSږm[1۷j6%ypv-[4&n]?;(/* i;IAt,VF(WkԒ /&?kmc젻e|^$sDБ"ZgEJf{\^ʓdd06_1L%h&$dz>Oh2jb"C9LMPr|c%Ef' Ai{ ] kc\~_r*TcvK1zwE4VAތ b$BA_x(@0tp7 44 *rag` G8`sP-7Qm\180b? RM $)G<#h[@g4C܂\^Nt1i6!\&yαBvG5~3{ўv= bl[ EeP7xϻ}9jaEr\3lJ'H6'I`(B1\ABP#2`6WԢ%z Xߘ6(NpXZ:0|tX TG0.u Wz-<]9+\NsG^2)#2o YU D_@r Qju̟@|A9ëG"z@xMZ1yG(m^v jB(gh];HU6R8{e=%AKK[?h?5X;; k/؅W+RPk=`@1A B!B",B#C;/@9x$@:@h+ŝ6c7x|EÄܜn~c =kB4 B*+T>ȸ/ 1,3LD=.IDIlLbDXRH1a6i@B8fhm  ]L<J=b&l< `[*:b*@C@D,(p pK((^ȁch3UXDx@ j 3YPVAЄu=TjUPMpXZ}\T5) }p_PXChX.@eXRpXxbJD #V8g-\͕Y] FhZ=]cPݎ j]5F%"p^5Plmn}X0^\h3@a=.}(#]94KU^͈EWR\"(^n_ ,@ @I8*!@B?X]`hLȂ8GSZVHR ` N H8vaa)b!&8GHX&~ n(~c{h:N*"Ҁ~]jN( cK heR.eS>eTNeR N^ JhNh^h^hGTW&rRZL QGZ=fSfM0/voiiki4_(6fzЯPyyℒdbd6NTZP*hS$>kNk//ĭф(e>,$6d|w>hH4ikj̮fi)V xI0Sil>hIk(}KDlJgkvlX.Jl6fK^~n2H Vk^n>hG Tpkmqn\^C #푾mmn4Iήo0H@(&&OB.`8&m Lvfrq>GЁpqq/q ؀^\8Kk`dZftjwof^dpD_vSA`m_Wצ[h_캅 qHar r&dDx P#(+)n+/GG7(G>NsZA%?C'^@Xh P%ȁ`g FGOܚЂ( (lJT8ΟHK@Q\NsGdZpBM0uHqVzj{jX_}\'oJK4hXHl&rL)ϧr?;t8_/(E&4u~^|GfrE6#!|5U^|WpMh XYp8#4 Vxw,WRz ~~PtçX)r@Bʈ?Q`e +0Y#Ȑ"G,i$ʓP:T/\9Ti'P8$'ДTUAP$;N C&T'D!CVE ^ rĈ "TȰGCT¡+/!?lxT1"J6}u*?LXG΂Hm… eQ2߀wjr*C @!6I(6ņQL^r#1TVjزgӦX{01N˴{X0 ĤB?bA*=VdYUX/hƙg7-\rmhAD~zUCum Qdo%1T80^/PU0u4/SUuUV[uXdZ9)BҔ2 b&C_EH4JZ&@ P 5ՃIhJ7X`XETsJi47HMAXASA G*ZiZP!T||JR bIE^@Ȑp)' ІZUA`r(.4D"e0ZeTc*Fi~+lk+E(l$UtB\{zm6P<@n Q DbQl'#!OEVh-f? @'$ 41QcL4Й qC/?Fс!h'P)dDb̃ IXA@ob+ώCTd=)oc^L 3 2S IA[`>4?:n #;h.R!? yӆ="d|ZљTz(0XV(a $f`@ R  ,Mcx)L7[<#) QaUa?vF<"K ,@gYag4bXEmq:Ȁ| ` I<#Ө6nLV0MMяU '+YUk|$$#)IR$&3Mr$(C)Jp|UH2%IB?a I3!%mx bGXTё&"ݴB4.?$TE LH)ʛ&)et&yM` }'c[S&o>`M2D )ĵʟH06,=MlĊU |Ea;K8 \M.u(D?bS[Sd:VM@IS_ij٬(d*"_昸D\f#eS5U67),`1@EG ΜbE_@2T#~׽zuehU>Z|xc3u^vS͙LV}^7?`"l(מlEۍH99: ;f9SX+rEZ.9 L3}\ɵhYI"srqp@d[yHo~@ҾfWn~c PwG,vg}AB&c0m| gUVv{"#Z>>ʦňjjjUUUFFFZZZKKKeee~~~111wwwsss===rrr888XXXuuuqqq---:::[[[zzzxxx777nnn{{{<<?͸zynVxwxz{zzYGFFGFG||y!,v H*\ȰÇ#ŋ3jܸA C r(SrB˗0cܰ P8ss!"d  =* PJj0|>hʵׯ[-t0ٳ` ۷\mzݻ 5d!@ L0`,}x1 H30Lr`? ls̹TMӨIڻسkHMiH7$ l ͚qctȣK/;xŧKW~~]{{s7?{g/}|vq9_WSi1xׁ`EYrυ8҆"zhT!rH0>"*8ThXa<>r"Z]H@&I$K"!AXXeWvr)_lf8VX>trgVݚq..V2}xwd0g6!t>TcO HM4x"O;;l(xFʚuVziv)v ېjj',syg{g>4hZ6퇠J 2!AkXoMPlT8 +ֽRSZ VI91|f_!Uil,oM ^Teͅ!v&@_Y]tXgmŵO-P~}d-Ս6׻ 9G |5SHh y3(wy裗p뷿n(]^;NI}.7'q9=Y&h fɠ{?S>yyY Wm1 BtPX9ԝvhVov< HD}KCw&7~x$~X(iB(6jXG;`b p̣ ܄dl^nBL" 3:&d|X$'iH*8H2&d8CZ, I_$` SHB)Q'JLr(N>@1fǂ^҉TN>5*'&O™ϼb4IH+9qC\2\ŐYKy.ŗ|I09MzӖ >ْ}Ę:Dd(: P:!BDJJT%J уvmhH2R4'B?zѕ6.M);*ӊ26UNsӉU C3E:B`5)OӃG ӭ¯*X*>լ D+?ժTթYJW|i`NU1\!hAN^ R`&`mc-Y%U\X5-RS ʳ|mle[TѶ3uك K.."Eaʍڄ7/]gsG%՟V l% n +ޒwJ4p0jSVdo{u]"ADEtQLH0x_;2ĭyFL(NWQ؈5JS+0bԪ@L!CA!pZXEL!Esn]r~`X8F`.2C.s?5t\R5isHe:K$1`f<^b &H&}0` `KD_D90;@C"!63 $ @A|" DS0tJ=Zת%jXǺ˳&P ,$ U}5Fc[dYvgЁ(l: ±DldզDg:ֶ,̗ 'lp i7=u6 (@ޜY%&%kPx ݵa D ?u@@ .8g{C E=j-Q|-D"[ߏ7tuM+Z{z/a_菓Nא矝4CRwcdwVuSVUiv!o lvhJ"@`0sFFcYpxGQ8g8]IA~,d;wxVFxWu|=60cP0qxjtwAH FUw1FpujkhoO!ADZR|`MvpN) 8[e,']}&q6 /8e.:eOCT` 0sP<^HUPgxm%_m8(wⶉApJ lv@306id8E4fPhHb7UO7S'/ 8!wOPkZaO|_##qxktRquLXQy_11U1LDv`ms7qsH'|cj3`nE~ґُJX"0 ,rg3pT U{ HPsTCVY`{jlTEYұqrїl$hAdtE_iE O٘i`LIMtQᘖi4T9]IF ɚI Y]IDiYXY+ɛIDB)iEljq̉ICUcU!)%e"yA)I$牞ٜԞ9;hce%2`eS`1ŸT<Yc< ڠIC1*ɹ6"JUr2##5(B ,ơTPU{'psZho*ً({UPXeXPepXPXpQu28jZ\1IJL$N fW\ v`:Z`ve1Z@:,P`#`j`aXU4Z"ufe`&Щ::n `Y0"Ky^Zjep ^|Q ":ZzZhh^Pjj&0bbq:Zt@;[{KP)1:Ū\G֭6"Yj%,۲.02;,;)!|*>+% [/* ?zuɡ4R;1{0k;+JjHq`\[jeॡ&PKn2k-!=kxZ"e;jˍmh۸/+#q\ #}!w{e ˶- @ Ő@ P `} 0^a@z.+"|k!^kvj˲u.)&$0j `@dgh`pmD`]wPt UPsX{ @WpX{k^'# p+eK[ۿ\ \a–@0`"Ru.4 K˿ L  LK-ZxP"QŀW--+5\8;>ADLG|J|dle/p %"U 1a<6l9jΦ&kEP:nG &@5מ,0M ˧eJz[A $^0  df^}m8^.J.p  XR  @9pD!ဍbP.*`0`PU0 sDFn>m n+a?O"<jT@g` ;&H4 tx~_o?>`Ğmf_P!&=9P-:t1BYc$^HÅ0L#1B bP! 4Vi.q#J9dE@0 (\I0!D.eS 5ۇE 2lĈ!,@ą O?~L89$H #FN!Cc $HzР_%Eq +Z$(?&&]ڴ []jcaUbVZ>2{n {1&X:(BYD1jH&QdL6qPF'=?ө*J6BK-܂K.K/L0 CL1L2,L3 ;SqER[^M,lKKv"8[碛2ȟx껉*(:(J:)Zz)j)z):J"XtsJ+KJkފkK8  k&63c73uEִʲ7tG SHȌ '[3)ɳ,㲽/s2C3]YNAsA>3BAS-p1)Sh-S=jPkCU-N ]e"';2$cXU4d”OuW9 dp 24Cq!%qfWd7yA^RuT~SV$8VgEփFcDOtƤ%:3el@'$Tfp5LCFA|tDI;lv!:uhَ Ri>.WjnIkbc9f{Y~͹=nԻenC7psuNDhQ\iޘUNNj稖jgX4:}xla/>؍VٜޙncX/Kȅágh_Mz}sBWѝt;AJ~؂e1KcjK֬ (uVW-[ W!.]! ~`@B:aTHh$5ٰbe#V҆Y!bX-{sY&:f;6Z"hA|yq_" F>3Jr"F^E,lC<ގ@i/tB E!82ySd$$YKMURe'hQL&T!4C* Za–VRo_ Y;M8QENt3?O=HBe‚?(># \͞F>R>xi0 g/C?MQD9Hpt'C;N>ܣ, [ P XZA.VPrbࠅ`0&@ѡX`h'ӊtS%6"7P @P E("w1HZCZ o*ȉFRi;WiS֑v{ʵ)A**zhXIA)$喀v?%Ї(J@E\e"iU,$nB,8:8@z Q 7_jg?w]Жc?P:<"AA!IG ""W 8@|X]GB00xj=6A$>GC!iL"WC(q8"d @'a @@6]h I}]`Xғ pl Ö!B @b3 q]P$ 0 HSQ р|@D?h&??l %!E#PIrAxt?\@tł }Cr;um*|a]Gz,Ѓ Td=Hqg5W?(hwk0@!\:ֵE\4M-! XoȲG$ aIOm<ЀCCP dwq>+*U" ;" èD"`* OLB p# CP @ H@+ A@#FZJpiXpB,h^2m( Mh&l~"@(. OCxA~_g P ~=Vϩ 2J<J^x/bxG℮?*NPdн4 h*S0/6;3X >%N?$LB%\B&) ?Ӂ!"'Hp SM[@Ke("5GXXR؁H(+4@0"`+ " iR(O4 ̐ 0H6aXDzFP0Xhˢ)hK rO0BukBVlEW "9(CbEj+OP>=-&NO*#!7i[P'I{El C@Y $BcR$CJ`F FKQٞme'4j5*(,HTo偢5ɒ Kc2iƕzƖR;\P(D8X7[b0Ld]T(cUYh\1̰ڰ@LDd}P3Aɂ@i[ )/VxK>8Rz$4\  8B7(4bX @Rbp8f2ɘK(')Xd'L7KB0Nf(Z66X̅8 턴4 G@*G~(庪+r@2'r/ IN)ml2K. b +@""84\HS=S Qa-=A0=!+6$؆h Uh Y0TRJH'R(AZAX!,5W/ 0I1iF@TZ)rhœtdE".g)Fy!IP"L9 ZX~$ZilZ>heJhXxed"eɔIёr~_9\^k-ȚfnekeV"n(dEu~ꌢiǿdgv}t%_1lllll?H_$kkffilNgMh^V_$ST6Nn^nnn~>`\''ٜE^KNI\@sƞm1q$H]HJnHloCPnH=(F8FjAZmre~EJޢyi{mVM0gTp~qq18.؂-@؂F ;Em9qen6h mfBq0FWLwjV. j1o2/V؂ oXFKI"hHF[gJ'(pr+.gb*tKt>PR(j6w<軞$WiKf !x( `mq.4 .1(avb/vc?vdOve_vaXQRpk\! uZ_[̋ntт!=Xqwywzw{w|w}*؂sVVG:wBu)?rrb^VijvTUn"rSp$/hUo@$x81ph7.D|dtQ9Kǁ-0y"x - S3AԄy=PERM=|WWaUYiE2ŗ*Zw ƄdaPaSjVՇֈfȖ$eE%`C_At?qЁ!I\K;+H? 9nT"Ĩ"%.|D‰uxq3: /hfzm{sWߞ%v-*BNӅDeԆmV ~:X$H 'md!SU`QTqQh16P3lP! ӹq 4Ѕi nẑ zo'uַջz*%x]N@r}'( f -X _p{"VlT?ⱁKAx XrG N8X8d+k`4H g=~<5 -p7,2)j4r쓟Cq &JD ʥms=/zӫwA'AG2$(BEHG"#%%$/4_~ACdtɶwAJё&,%٩d@0e2Px!2;<+/ tDKc BVɖ/nB40`DJ1K. h -9 BX kQ0[9` qz#! DH+A1fGD}Y8I$ƳZ1,lX ɰ]u(UKJG*s@GL"(H Y!•nD+8hI*`R <5%uškL˂V:Z@V!Yenh4fee&C-LX@Rm43on$FA8M-P~F̀-,4*u(/jӬ#ZqxvFFQY9dVgG:c0k EXsV:IWdQ0E4"I@:ZrO#ybA 4Yk.A#9ƚȖ=JI|K3z,‡R8w]%*l?"/)#\엤m*Mrň' ;1={&Ì\6xu(: b Z%A 0Z^o6̺ ٺ:`W H\w^}R zeGrڢ{I! l@FMBMN_qFZ% آD[D _ AdǵU~E^AYʕ_Zu&]) F&U%IyT`_)K[ \i\ UBW`q@h@FA񉡔y[aVMѡq*u@ ˒D@;PK鍊|7w7PKFJOEBPS/img/sbydb058.gif\kGIF89acۯ𙙙@@@Ԁֵ000ѳ<<<```ggg yyyPPPppp;;;ZZZvvv---rrriiiȈKKK999,,, XXX***888qqqxxxƨJJJUUUddduuuǽLLLwwwʪlll:::GGGŸkkk777ttt___666nnn)))+++zzzsssMMM ///===NNNQQQ444{{{555VVV~~~(((DDD^^^]]]...FFFmmmOOOoooRRR|||bbb'''hhh}}}333aaa[[[jjjfff???CCCSSSAAA\\\WWWHHHeeeEEEYYYBBB>>>&&& III TTT!!!ccc!,c H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜI͔x Jэ[JLDcRA#ad GÊBt9Y etm#Vu-J\J߿/6G_w ,*u.'P*2<#<:z͊`-c}E\AH[gd>(^K9^μ9ǥ~uJq/r6ROWZ}*\K:$G Io5_p]]ePxgUjE( !B !n`eR<(~on%\XBVPK T@ ?dZ9,b B"yYQZkyE]oݷ*~yGRFU݁ڔfDۙRUe]G'YZR 楘UR]w@|ũfr* U`YzGhg[UGX馀l*'fjC%_Sr*P)tҩ?Ztqs'XȭPUt%"vkh:+"3UTvW}N~ D7s_[D0Pi%_}D1Pw8@m T4hrXmaf:HR+0p ݙ-EDGS_K[>2+TpTg1@epjŃ $8^+uIaGG0U `]@}R7ByCRYym=nUn]?&o-4=R箻T|/R3SG/oUWbwRHE-^>d[iDADI@2_H@/KVR3qDbV/A4 Bz8KT 38Hd?$,CXnD dσ8!5G 1=*"ԣ)l{q '9g`hZ dž@@F9@u5Ԭlgb[NI#XA˶o2Hv-l)XY7=n {L0B~c h ^f׻ps$G5`x<>x49KotHA0?"c|NysVn& !@wt`;:y{[# AzEzҗsڞR~;<~ b{~ j_{_.ۯw!aR<ܝyXۯ:Ax^W|Xۯ鑏܁Ay/Xϸ31 (x" KHpdlns&NI`0 &`[(9؁^ae@H5aEl=@AphbHF&eXSb p/ "0\T7Q [c0!hhHX!5`a eHpЇ+f\H T` `*p(h؁c؋b(˜؆Hɸ8# L7 0@,0P @ X8؅TsHHkȌyI ɐ IIYz)+I.1ُY ِYHnД& QSy(48ٕ; >9AiYkT~q)suْwi8Yi[^ɓad)gɑFI)(61ƈW5y\_ٓb e9yH`w(iY0y{})ym`O əYͩi 集y و#1XY闹ٛ)T Pax)y)IhYىg*s*[GHɟɗٙʞzlف "c$Z+i2j !z ygh ӉY؉igz TBZ ԙYMږ=e?ڦ'.zZ𙘨yLȦڥjyvJ7x }g:$QZ1u:6ʤږL*iih\r 3j}iZ&tū+JjHwکځpZ 5ڪJxف}Pj#Z(cWwgڒХ|JbZD U $0 'Zʆ Ō0pEP)'P|[Jur@ q0qYʒ$ xcp  R`|Kq ӰG@QM%h @ V г xX GG[IkE#  KxS`[۵` I  _ d@*O(F;PqP[[ O_73Y i@id9d fx`X`EK;R u OK% țo ۵ K\@ٛk@ns;9f "<$\+UR.U۫0u<̛;@I,`d0>+f*Vj,1Z`vzfMڭ*`3m׌ z9ڰ\[T`0 O., 0 KAr@^sN[8 p,N0dhP&7p!X\ ` Vc۽p k}@o(*[# } ͐ `Fs H&83 q  D)GO_ K[P' @ָbж5%P  !>w_5_ 0Pp ЊP 0֝/'Og Hh//օ٬- ,@7 69 0R )L6t_׾//w_]u$XA .dC%NXq4j `G!E,1I)OTK1e~2iIAng4Qκ)ox{5]}}SԌ 6+)*##304 "=tL#'JZJhb DSZtE%&`@Q; !N>r32$Ȋy":tCJTdF."{I 9QL&{";"T4tHkBB*lSHt`*KBG/UtQŒL/Й 0A)q):.LK5|l'8 !]UBsEPF{KGa"s$&%&,5+#E +m6;G"d- Y]uWtӵ/ؗ {wޘU^|c^~=|x}5`ڌZсvXxb~bb;Cy=6YbGVO %@SHky ЖWY]~驼J2.PziNh$#ӵ{ju$&J$@'"sV{m׎A ,(l@:k{zԖ59W|qI‰96B pݻo̿ܯ <O+C 7c3LJtuW,XO ʰL y.[QLϭ0~{?1*gz]E$t~~ ' ^8}/# 3`$P d`@FHGP? I0-$Q@Fz1A\BP3a m(Cm `07$b `|)d"cVD(FQSbzC,nAL(6QiyxF*V!Hb$,s H2Q{CxF@.. :Q?!$!d\<K\d'}HMRaj %M6'`g4'] PEHOysw|K`S+ɓX2$.OA>f5yMl *}Sԅ1 (AQw.4 }h>#*Q420C)<?h;AQ%IQjFv TE_*<!dhjP9m%Opt@:p\T F=*Ht 1pj:Q*WOJŠvC#iβN E) PcCXFV+]{ջj2{݀ $tU~@h|A58lb: SejFqZ`I]jJ╁8K"^IRzMn{8`rD(V1Aq7sWFnv]*̻mxw wDy†28!g ۤ A3Id! /tK1D^,+^<@A Hp/tش Ip(QxELbF׵cpÊS1Ȁ @GB@1pGPZ6qC "@ 2鼽:{::KF?16s9> s-0p@{L@›> ۾;K;X(u@%K%Ę&L:(•P@@þ#;ýk+;824@` $Q5l6=BӾ@E830u8$ѻPt`F̗Gヺ9 ;??N?I;&S|\ETWLXPIE)D?EC@/ l+&Xd4DCcPgCx1l>m,Կ.D@D;b8SDfLwGGz(G+EM~BO DDŽHH[HEtpȇFݢCF G`A?Bɛ488Ȑdő$.1ILI. S&Ɗ?(>@X`FPtɞLʉs>9*PtxǛ%6(t |0HF09 K$˲lo*J:J>Xx%A;3XH4t˼V8(*EEH@IB4̟D0dL;Ā>p$y8,HhkhQͺI6 2E#WHCI#^MKl ,NAԛ@DPx˸ 7@^[#L=0.HtuK4rN+2,HOݔ7<pܘO2CNzS0txK l"$(PW;thjHZKKX2 MHLtPbQ3-Q] MQU1H0tK%Hl K^3RD#OKxF܌R*+U,t>CH,P001 5; P5}]}7 E4 t;қ73?ɈI ԡT-UYUZU[U\U[eP< C7"K0QJyӺ!@4X*3<U׊]VZ*PUV5 W%TD@0N052Q[;LWI4"pMuK^>B=POy+0$Tr-W8WteLEC KHJGG?eX،-ʍmJ}_t G$nuuHp@y$$6P!pńXb&VG-]Zmp_e%?FydaB6u@BEnGvƀ#N@< 89!H6e}`,aNG`_ uf傘a~`bFcdNGfT?N[ Xc!b0S.,i[][M (n߃xg#\$nzg~^}N5&q>}`ata 89 g'fhM.hfONhFYoNci.i8iYLuXiYti:C c f  e@~gd0tH*nIL&ݧٛ>hE;OHn8S F>é&j^F⮞ǯa`"j@^E(_&kgHKH->_f[;DPĻkPl"<^.F>>&lͶ"*Xbiθ2ʼn`~nF#ǝM~kbPU VaFd2J*%hʃthx>q.f~o*@tbdk^..mRhH-o~pv'4V$=|6kf!DHVfݓ])TMw:VMp|$b;6bSq.R(ok$'qT`(h*OG|cWs^S~)2{55}x~9$}""(RyUW!p|їN7XnDFPfr&$M:$Q6MLbX,a\9Œa(GL 1b0 $M^改`%!tډgSgu Je\E',) d䢍6)N(ӑE"٧Ew$| Ez7N٫/ruIQGFIEEp1lu۩3GBGihP;]Iŷע"h4:uF:ӥSj!餫NsIѾPPбI-_A ֞pe;NWA\kitQu๫NłEt1ױZ[mнi|TA:IEtc \|Lk!Q0"EAm"uI#g\:APq6:_}Cfurꘐ6 Q\|Q-1;-REr ĦCoyTGPH]Ҕ4>1푫SxU R%[^ W|%ɁV:)$WޚˉI x5͕;]tNFCl-"Wm;5U}V  ȬyjS c+C7dY\4q h릒$h! ZPCh9QhB笐_:_鈡*RxPa!xW\wӡá.[L8(U _B!BTr{HH 4lfD7;IVIN|lII-heR-2{ `y7 S6fVARȲ`!:j} 4r7 <%4K#ȷ&;"!ʘ[3 *^etq|=b%^+Y(vmc/Nh`WBְ=R*TB,jc7ֵ/-^a+ݎj\q[(QT;PU-rX2}.vBVטݕsw5o9+~Dk]׽y^p /,>03N#_ꗝ03Z0/ތ8&>7Kl.>·6&cN@41l1N]~,%3Y(.-dtШM2Y*7h,dT3VKs1<)+EC=5v "P~C\:3h2O3lR.l㡍46eo~6-iS־6ms~}o>7Mn, h[-yӻ7@ 4`[-@_f/?bxB>#N_ &I8T&B)T k sC )h9t` җ<է)!ܓYlIHn;.ӽv;wגC"{ 3<+!1"1"s` _ K) n: V!%!-aZ!*_F `aaaD_ơ!ja!a! ڡ"!&" Fƞ*J $! Vb$ ALZ:8t$H$Nd `;NXJD^Ez >^FA(@N6MXcE40 $"V` dEt`SX;@dDeRRRXM*TNAPr VF r(W2%]fS*eZ2ba8VcX&fd ^pc%&` LAE dj$ AEZ*Z"["fj&A*@Te&%(#$o.gAJk6hʦc"d& bsnNf:'f&w@RwNlTmm&'}ƀk@lx&}' A:(ta~fb~~ҟiAno'?grg n(Zh=5AhnC0_$(s@<tbbug:''x''$_:@h L(,F5y@:nv*wN  LRvJA!ߐ*.'^^*h**,_EZ聩:fV*fi:"h#`d_E)fAiKAΥX*+m8u2j% tbkj+rkAxkd~Obc:(:廦'Xߩ@ +&MA|B&k`N_:l*$dAz_FtlrlA*k "k,Q:te@ǒ.ZfBj@t9BErboCĀѦõ&m*Am* gb, 8DȭfDvĖ l i^췆k(A֭* n: 1JwB)|.⦃2m1Bl,(ce4xԀ-7 L|/BEA"fYB*D&.ެr+j@ @,4Hnn:dC7PV2Z:-o 8@oEW.w*@́ /,'4..R84@H9l$wdE CX0OG4pzw pA#BR:GrATZ<-# n :nư @d@` l3\!A:ҤHkЊdB:HTD$q 'z62:Nұ1C`B2jF3BF$NƀHB"AYV+& D$q%o:pBqkΎW(1Ѐx:062*ffX#% \r$O/' kmqo(33C3:p@ 46485PB&8 2[2sjp+(߳3C4@  A<KkKGA) D@ 89K2%%& ,u,ss44CH 4,JKGMMN@OB3C C'E3^°Fwt4SuHtIC |<@4 8GL@ HNOs9CPs0#;sR{rSSuTӀ>StI@`a#bc;6dKvYuZPo̾p]gtiGHt@`a'6,vc?vddO_96D{D{a1io92ױiKU5kkClO7mWmcwn't9w/ApWp5Ew3^rsvtvm[dv[vPC+q:u~RC)S,i#8Tj[ukwlK7uu5O~fC1o2^t_37` 6S8v[xe5fk8[5x3F7jO{_5|?wK}8 7ZxCw[8˵+{#|x}xSvg8q'C'.9rv8G8}O}˸YB/A&2x#w7xsy_Cyw8A"$zR!;z=wjkW9k:wz:'¨8Κ::^:#c:;Gyϭ:;':~87߮/$zqru{z :ϭ6CzGǻ9/95QG4.9 38w:紸?|zQ/mGqryonޛoS8}{~:wϭ,=Fps=O:Ǿ;}޳8-cqc~{#~?y;f{l fo_+='y|,-,4E:,@waB 6dx"]\lؠAC vd< 2ΝKÃ74A@& B$@a ^a‚ 8P@8~[ĤCcbf@6ֵun\sֵ{w@(t[QQ#G E<2 )^ʤiN> %AQJ_45ujիYfIG``b `٫!đ0B)ZDǐ#KL˘3k̩ngϟA=tiӧQS[Ūk3Ljw@kַܼDy~\8,#[1lʨ83D#4Ԩ25\C 8 .mLP$n.*P1D"$Tb%,.363R)j늉s10<`>ے.!4lĒc![.N3: ʐIk-d̲8@PM NH%J-tj"8\GvN /tBZmU^}+hb46KRA3H ¤0|JC?;t88\L@FqMv}^uشekd3TQN #N:2<%kč!ކn_%-0d Tƞ}S2i =S=}I@ enxљmnw^d<^PӗG~$UU,e(y^-kSO6`GS4vm>:gNCPc NhRG ( @^U),Fy*6Vk[ꈫ<1YkwxPH9N l!$V@wo[x뮗B1"&5y#p~]i^6'bqUP$ANI{O 9./^f9XA' M/0"PfI珑сua3Uұ vі! 2 jV:V!b`3y"3,@.1y8q@t@:a@(XHD0tDi ӵA~YѨH ,!MX1$) 1 ?Du@ x5b Ǩ AT ,^@t4Bq*.Ҍ]W;Y^Ҹ^ `HRt$FJ-KN`1 !`)xb$ҕJVQ¢Y`E]_LL, /1Xΐ. )p.JR I#.t@H``A ~xҁfz(K. (ZQ^hE'A/&F%`AґNWl&u찇(#|@.c i]Y6T6g0YM-rq yVJQmn? 5*4#@E:4(̓ AM .]!(Np0CWQHP2J,0B20S&\42ign\{{k @2(J,,RŊc1@*qFUժê w,_UL8Qt!T˶ +Mmy(DHH@WQ B#wPl 8nC`(^:DH,LAzAvQ2X*!y6hQAB)H,\uXK-%\4"~#H7 xHLx \H@ axH/)H)Gu1`!PĮPh'7Fix!O0  #Ņ]t4 ʪ(={,D .WL4֡qfH%xs\sE!x$? WH O'W0t" I1 lK*rXP웎,ĠE> N&6BLg4lB<0a B0lhpxg:,1H!|IHqi1ۡA PSj [&FkLG ^` 6`: O2BhzA\fwMsM, 0W)jsQe`^Í~E,"hVbf-ġH1Hfv* :;C|bA~q̺k ZK(38! EIj-KX"e/v@D4Psr_ pӱB<+^vg{,7}Wɮ\f"|2|:J!}_Gʗw=Z73'MWj_[ϦG{( =fe(|;~,X/ 蔯Fz(F`I<-Ko, B !Bc`u(lR,NO)zyP!| PPhXpT{ (j0Po . msnmĭObgc0!cPT kq0=p/6p b e#b~% /O O 'Lr7kB_nH&0V\1$ԴNƢ" kHZl/5P@b PQh0 Qo貰8q!F Q߰ndbecpvg/ONO.옱11 ?qcx Kql R .@q"p"#ב# $א'$/z&%[_!,hE'cOEB|WQAT[M""D/ 0 uܜrMq*G|B`TRb.1,/ G1'r1tO]Ԯ((+"6b!R0g>R3@`(2-,b3 !$ 2oZB3$Gr*"q5//r7r$S;Y8)1933rՓ--H@#2[&==?Gs28*s>]r:2;{4s/Ns" %sΑS84 uZ3srR< tEEEs'AtFHsQGG7::T4A?M7&EI75Yw4P[-!gW CyZ['[Vh 4A5?4]OA`>@^5~LMCE\Z_[5`[cE`t-,ZaU1`ac9>@q_A_5eKse#>^VccvR1H  sp6*vg%SWCA hi[M !7 !9d^ h`n(eJ@`I6=ls]Ԗm@00-4n;>VIMP)7o Ap_@h/5Ur3e+1' 6 `ss4tT= DJiOW`v lhm?mqwIu蘠q{Wnǖul[l rTWz?w.V-d UuUux[WD WpQasS|7Evuq)}'7rM s`fnwhn+6:\/{WuMeV&b.\{$Vp) tcXwpi8a餕L'ߏlal.R.XI+x8! a bN4H; d dؐa،l`xy @?yx{8vT 9Y !Rt@ ΃_;`(,a` @`sA9 } F`PA` liW( AwIbqB=ِyV9!> Z !P 2z `F A~A $[6WbJa~ aPS3 ja:XaMK@V(ΠH#o6HKQY c›}yfL +J:ɚ\!`HIT S}!JT8"*`F[Jc)`(DXs-[!:ﺪ @³?`L[(RZ-B&xV3d4H':Tb{ض;`@5N;2k"w[;ϛ|D̿#Ly\/|!<1eC;5(E6OI5 @z <ōv9 Mǩ$gX@,BB}uɟ9v@ b t` -"˃!@ \!\,8o| @ !ȼLł<ə< \zO ͕`N N"[=0<̭@\,  >] qwq <YP}Ǣ??ɼ(] p} (}Ǚ t p ̃ ٍЍKا Ӂҧ|̗xg =ڙ yANoС=!f}bޙ=!u u^i=u@};]Ţ=W毀M> ɧcʯq!p>ؔã "^z=Yם p] >?9߇_ޟ b K9 x U%Ot?y";0n%L=QV=aveQjq`UtzhuMuGA4W{Yo :!:M,A:,Tqh8j#Tw%mCǙh_%[:F(!HEnIRiDeEriV:O8ydfNލfnU^wݔFMQqS9M":_1NiVi\aVIcCVC\S:W$eU*qrZ2:\/(6Tpf M&l¦ɓOo.,Rq9gMKڴKfK;#<*h䖋LȪfγN.Myo2[:Lp). )/ q_f~ LqTw.Lx *,. b̙QLsf`y#̳R!纱B]B#tQDZ=OMTH Mom3qth@@AsrRS OVc"hvP"`-6'@xx/x?yO Gsq=z袏N:g@8z뮿{N{Ԝ{|.||"?}w_=3_~'-~c= {~N{>c@ݏj N hJp/Hu p=+ p$,/'~v  _p4 oA })hdaRa "'O KP6qnLn\r/ `d Wɰ-3 hR#2fhs7 ps gxLdfR4O9 xʓ9ˣ(ۉ]Rie>9K v䧳9ЄN mh G:tߺ'E)ZPGu(C;:Ќjt(#?jtA)iJҗs,GeϘ┖4Kw@u=eO@"ՉEQ?BMSJ?bՀUU>]5WNJ@鬩QκV5++?J5:5+2KX 63*-6s,&!KYM6ֳ,!1m6,AKZ63mQޭ6saK6³-q5m[vSuʭq+6u ]8%׺ӫ.wk߅wfW轘5YB_}+~e.3<+x n6ߣ4  / u x$.Ox,n_ c>(g x<cኾq5F'nE2z,ec6Ͳ,Ŭ>2KF3]6̃u_:7^gyo7> wȊ7?/LX&2qPzԤ.q%JkxլnvZ7~oھ.ޡ6&`{M(#;HFCn鳧]MlغQ-o _rFw{=vc7ɂ\z]~8wEqY.דն#kUGr LnGz.߅o|/wW̃;ּ_vΕsfݜ?'nЗ5=Gu=GydJ}vWm۔tv__}ؕdUcv=ogm3w/' %+~cy~w=uOmvUY_vƟOvK劏d|G/G:=Yo8ـצA6?4_ڶw@&|Pay/F8m}!8@AxwApQigM_)@PtfTCA@ g'H@q6_5h7x8Xgmf@eTvm@f{H'{IvߑȶNwvi7ZWOQkYvMxe\^i`hv[x7'eFGalvVX؆6yk]/x{jl(Fhiw?l8hxmX~X)@Ȋ芯(HhH 苿(hLjɨȌ(Hh׈٨ȍ荚 MV Px|5⸍B+Dn"@ 9q3 P㈎Q9 S&D&I5I+@+ ܣ &@+Y81ɐibɞ8 I9@9D+ ]y򨒵:?q0ɔ 9P㨐I*#ڏ$ZQ9p GI# !AʏP&z 霁) 099@qY¹#Yx Y:[ڥ \C x s:) 4z 4 pI6vڣgJ+90~z  َ $*79 6ygyCC@Ii?jJiIIiUIq B**y6٦Ix!I!z@(2)DAB@xڬ"Z Gɏbɑ:CQ*(Zzz@o۬tj(ZƚE IA+$y+!I )k <jZU2'*1کBJ{E?A:G)+DD鰎X6$3B3IUk "Cy?G0ɑ);JFˑji)xZVy V`˯1KJJ PIKA196 Rk4]  }k˓Z)P;BP㪔ҦXvy:+PZzjJ99 Kٞ+Kط쪲g K'j۹@TۼL+ͩY[90KQY^i*?AP ˱Gi G9٦) i;ڑכ!i9ܢ1]XB) 1oAQD!NOJ<̭ۑ2L  3 99AL:ha|AC0Ø9,9I(Q3  LS+mڭi P~jL+CДh ʓV 0B7)ʏ@PɴȑLB)B爭I:yA7ٕ< ټ, )7+ʮ<t˻ȱwjχ#YʜE }ɜE\;k=.+̢u+& .*«f%O',Gob+PӅɗflɜ[GݙȚ㨬8=R'͘iJڗu܍07쳡zJAJ4+j :ՄtI+11ٶc2h˓Nٸ0*2:ܪMZJFڟIjiɫy ڬȷ _yK(@ۘxkk;*J+LFTژz\ĩ[ɏ z^)!K\ WGaϋ=5)IyoM|O몸y.[@Ҥz ʷ+o( [>I#yuɭJ *|z[+Ω Kͫld<ޣK|[{h9Y8ZƸN? Vl+@ lĪ zܬ+6(/yʒ ]Y̲Lь:C.9<8i+iz\=}:b9=]ȱ.;PKWak\kPKFJOEBPS/img/sbydb049.gifGIF89a~@@@rrr䫫999٠000``` ΰpppyyyPPP<<<>>>}}}mmmvvv;;;333,,,͸÷XXXJJJggg555jjj888---+++111777444666 ...222ZZZ]]]UUUiii^^^***WWW___\\\VVVhhheeeYYYsssdddccc[[[nnnqqqQQQllluuu///kkkbbbfffaaa tttwwwOOOxxxRRR:::((()))&&&HHH'''SSS???IIIoooMMMTTTLLL{{{KKKNNNzzz###GGGFFFBBBCCC"""DDDEEEAAA|||~~~ !!!$$$!,~ H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜI͛8s;C @ JѣHIӧPJJҟUjʵׯKٳh[M˶۷pٮKݻxq9pA޿ LÈ+^̸ǐ#KL˘3k̹sBQ!vT݊%`܃!D`C >:PP7hMu삧Srxtv[(>ck%@!οA0wPε!]A P'l4-TAry`>xN Q8C88vߒyi2t@@;QqpkP&n뵣#x@0 v߀^ցN[St5we Љ_ ʎq'– T6r^i@^[!Кr}i"xL:jZ9zUAM}?*\uF!0@9n2pr:A;p0 xPHBBڻn?r%йc ^IБE-}lM DU$H bMoO|+׎QT1ʏBBZwkf(QN}tClN NnC=Ipמ`^Nw@Tų-gkC^Ʀ ~ED#A(֠%N7+Ԟ(^hGp7ԡǚhQk~dK gx-jCfQd:Ć8 :A5,wb͸.)d>ך5hU)%q2封;Dn uk]e}Ԡ4fx`]vtya-pY&#i{IQi`-AAߍ %eH"$Hݟ"Qx ( rFHLͧK^=DƊI6܈"ޑLJԄK XS, gQJթ4X꒮ծzu3\Xh= ֶp\J׺xͫ^׾{5+`KؕMlH^]^a,d/'䧓͊d3K,BKXR/`H9+Ͳ62юwĚ0M4cؤJj!@_뒵? V,Z :*2CI=րsڵu;Mlx]MBNF%g-ջugh$ cp n+RK&|]; B[ 8L} a$ɿ{-L⬶eR,+ 9mܔY$1H$>f`H+>)gj %S-A A @W| ;F}S09xK2lvqm7sV P,M :pGgE4EiB{3>`[i'OD* zP*b(O1nsS[I\lqDlXh}f/fî"kJ:k=putmQϪɵ_gK%ZJv T`ENu~3QpMF(0;0$Z#: 4&繠EѠ9GС:ڡ@P!J:  ?;JLڤN;? H!iDNZIdJ#Z>?PAcsZ$@vzxJOG`'#`XjZ:". A1 "jfTjNh%SP 0Y`'Xr*)#\|4/4B1r>0OJSP=:)?0 *WlZѪ!6R\|96.NuÕc h>˺O:Zp U0zJUH/fҚ 2B!Ctvf%534>zL@rY`NJ:Uaw2iȇ9im{|ɡS @ #@AMT:bTa50-TM))u`Y#a>JKkJ)Jd}J!a{y~`v3.`r ˶@[@O,GKkzv  ptf0v vy4Q˶p"@ pr0t񲫔YfN5r7Fz˶Sk«кKea @4pK[2᫴@ Qоd;L;Kܡ+Y`L@L"B b"B@zk@Lwۼt `kP%,a^F4:fG=a! Be`!b@0D̫ У)+i8)A2i=#W:\DnûW3m+NM{IPİ 궭a R O+kJka-qR9æOnZF㱰Lv$Уp\6P8j$ЧӡK0qaH;'/ј`ȉ+)( cK)bɢɮ lPCwj/,ʄVŴ3'0/ypC1lIZ\ܡtllL@ 0p QpG;p/Ǥȣ*@. 2m I, =ldv$ H_1`t~= ULe`ى-14زm ஖ YPO;PY`.}ֿ0Qm]ܦV-k-m/ 8>ͭ;ij K1-Mm݂1Q2!S ~(>]߭|@~ٽC-0@ ! pԑn#i[ @)p-AN} 0t^v~x^@1ܑv~S|A0P 4=g 5PM>CE P0^P p o<'p(&`gnM@oi-%~؞ھ|~^پ.q,觎Mc ^;: o@ 3nȮ.K@./ >`  00 P*0>~ɞ̆_|d"A>+NJXF.M0b?`fop d@l0 0/ _VoZ ")-1>tv4 !!K @AoK|_,0r_ol.qzLX[?`o*/oǯ 4>~LծJpcp1?+ڵNǃ X:uPР 2Lu4,XpB H *xB'N@aD-ZĈ   Ő84$!B#NhFC$iJ.aʤi3Ξ? %jRN@&\aĉ pcȑ%O\JX~HСE&-3c8&L낥emܹuݛ.lU"E7v+ɔ+[9ͷ<}ZhҥMF #UƹZ<,Οz[: .^ 6z@ :2IpB L 6es /#CC7[C/+k,kҢpA;ă/F#$Кn-# 3 ,qM `Gs  (v(@;L%@kMD0EH? 1\Nv 6E SPCu"m@ 8\tϬ/H2\&WqʯJZH/ s13ӼZLeȀB`vV`:`m#ډ -v}w _{ Xn[NlNQM;TD 4b<3mC&_V70dU5>.r?1Kҩ!NAӀD=C$,Kr}hg6aTvj蠝B~ͅ^"VaƵ9 pnܸ _gp lbO,|6c *ٽe[Y̧l6g'199ZomLLGuv1iű5`ADh~ٱy7- O>^Ozt v> GIPgb'6'7>SU#⑲XV4?):aJs 2t@p֎o+q /TO2P ͧUk7 0uiCgW@}X"v(A' vJ:",#krPw `+B`G v\6Uz([Ad0>p}+FW6ċ`5#D|TXuSңE6Ct5GiѬ\8c^Fms3`oQ/#;Y"z r̜fM@Yps݄M]x :g%(A Vc<9H)?SZl Q?deQRd% K&i&;2l{9jͥF`(3 A  =NX&W)0i;zR &T>mlg#j;p@@+̅6ÙT0ɁR 1r }B_%@.B􍢋-4hƏՋt ]K 6+@TMTD6F0V]ѫT8k>6bz9l b9sĥ҆(՗PkG}#7-V4,V%f\b57LfU`! Gݍfyt%T'&P эAbu!fDhˣ-XJhjp[(0ֵvulÁ77jŰVC 1 Dg 6beX |{_! UIo(,eo-XwU;RW5Y5s!M/lSRYss|OHl_F:&xDnaJ>Ё~W66bT~MNVrT`@@Hkk8 8xvh@5u(= D=k."(A" C ɦ!A wr?LT!D$%l'L uɻ#L$.t! RӅ N;tR+t< v82v0N0 DH x6B0pAxGT`/F9qܹWDd#vF!@|B!9lr Qtc9ir|&7ByҰb}&, 4)?*̰HMÜt4Ӵ"@/gV`9G0rsJZزF$˱T "x)x* C?BžT rED%0HXQ #A |B 0(t] R'e3+RXe6/uH؀$؆m`D)D`PcCp =7g -0%`X$>d6GP"fA8+!K{XG"N61v= l5Iܜ0-@dn0!AGsF%2MVU۩,EgzHİGgQ,Q!2%r>mfnbggv Phϲh͌*F81h x,L~RYi]-hu@hVi- gؽiIi<jGkkkkMO!خkk7ɱ?HjXr(k\Y鬶\ꗶ2 hkIJVkQgh(>EH@*=4<ȃ?AXUHJF!xk6>vmH4KC0ٮIhD*#Qj֯>kjFGĭ_lF:ў831U,,7@@B)3K$ R"nJo7)`&(i&(Mg`^͞ozͶ汮鲾@eeJoʮg$ S G)0Spxq$ T !ǂ"%Xwr>NiOQq6pɆΝffosɠف+r&čc`&0WP# ^U ; /pE?pb'o`wO3j4ol^6xqEVDSe>o] 8gu.2/Mu2]~<|u]YZf\'kum_0 aLLd7u5[hUsFsV< n? ~ sg>s^vnkbXzg{׀uwOnxqg,>b*NxT_x Y `DvYׅA`cXx_0vV*.@vJ9Oez 0xd`:^6s']@ .N_.rq?0vtWdgZqk5zd= OqJ@F@ '~η魯_Ǽ=R(SOWGv'{vc=H#\mygw|dD |Oűol|"|2n1OQx{5[XO׷ZşsۏM>: hI} ik!~2Z~y!1puPР 2Lu4,XpB H *xB'N@aD-ZĈ  Ä Dk׮v6X`@@&\D/fcȑ%Odf̙5o3]BX0j.޼z/݀Š3{'eg91~GXØ|%)~2YgxF);?uMUUm!НV\obeZ-;@z`r`7B]aVYWY)U1e0Ex%%]F!Y`i!WX J]Hdx%")54Pie^7Zfdvv )b♘Lt!0G0kz_[`zט(`!YZ5hS$!?yII"_̢U<u8)${bgP-0H"(H J+^Z/Jk+ێ2b2T {'xGnLr:OKBD)-(cxw#91Ey;CZ@9_IK@ V\[3Eg@\ 11e`@ :8P +m&mL(P7Csd%«9ij_@ h6iqkx #١u%7 @.2affu ',D%prc &4ag8n<8tz@..F|Ӡ}q] p0 Af";І0:u$ $3KLΐ')I 0j h/(HA %#ZI\$u@ 7qA @M $*fQA*i 48㩾Y2` TdH%c C1\# bh6d%)֙H"p iN g87y:WH,L?τ20@u3L<ÅjyyG 4] 9RtJjR}*)C[?2vOːS9QIM LJ1KOSZգEuIwb@YժW{մ ( e+֊Wqp=\3X0]JѢ*}=_M 3P@HXuEj#2lfOYZuG{lD[&*ƴJ5Z/v=-":Q4mnU[β˅p}Kɥs%Bt%DZAnz^ZEwKuw*uY{]޾Wʽ SwKGH .S%VQI`w0!HVT3ΰ[*mzA\m_z2 Ƌܧ7V]!cK6,[ޤ9Bcz5KOeD`V9˃qeZ !t2KXϖ|qf+ ; ? =>-q i0O6h95Г ?]6Q4+Y4rsT. a%?䕓эrwwu}柶9nY?OIXyBpv:g b4Z}g7dPaOz'9#)e9ގ:$Yw Oz%Ow@ OiyW;B\nua{o=[yck|dzco!} 0ԠPA|'ԯ.' Bpz?Oz \U 29@FN: @eՀ\jZqNQFڽh A؟uZ[Y [UtAJ &hEL `Tha\_њye,!!6uh@aɭa` J@R&"<ᩁ]N$E鵃dQ@h D" ^Z@ t<""6"ۥܙ!ʊt"S*;Ԁ \ @4b ,ު%g9^lbaNI449@ܵC4a (@sm#F7Z e`pF#D. (3&FP<=VN$aE];d`apc%``CF$MյC JRddՀ5G~$>>I? h#A~!T]ԤV"g@pg4H t$9}@4Z^5űJZKNKE#"n%``CSP)b4$n@Q b tI+b]&Y^B^fL&j A |f9.&oJ`WSjX٦f9Мfo>:&p J mn-,rBN%UQY_B'jkJA@Y5 &b;@Fe}Gv>xr edyjS6IE!}Cu~*Qbfgau(VF&LVg]DQ)B)rFb(h'>#j Tfy5^'mR2XJhhC ЁhMN+Dk&Afd !FF݄ś@NG8w'5Í\}œ2XVgN #c4 &eY I @#\SaFS@CR@ hXi('C Cb*/ꁘhg<Evȁk,_PEaDjGnibB%ym5Z)f>5 /B" P+;µ:]ij j;b:ZF'ş@ɛu5@F2؛F++諲>@';d j"DO$ty)g@4Z)v"]{ʛZ?}캖kIhaʡ2X#VTiEͶ@!8e(N "V]_ffQFҢ&蔵gEš@u@~"*FX-!k֭k, ` B֠e $ArD*,&,PRlJj ۶m̾ ,@kFT<*he6.<dC+Ђ2,Ax-;`Bo+f.E s,B0AiUl* I/@ak}KͭgdL xA$D6| @8(K /c7P.W*&V1wSnJj/t\M ! ``ʒDh1bX!q ;հNo T@Dt'2(';@ RU*'o"{%QB.!al?= Æ$0%N\G@p2+?(92^24_'^<]Xl)6řmXhSʀ5rH311G`2q3c3>@P2 Ys>C+3rf!zgm&gI:2+.$0DMM&۳33;  @*J]]8Z,a6YZhESoh-xpsts|^39o<@{90.!|а|R|>2@Tי΃Z :y|kwگ=۷ڿC;. 0B =$A{B[{XcKQh>ꧾ>뷾>нf4KϏ`\~'l }`wO^>GO?ωkv}>C{d)B;?C{'Y_+KU?; 4xaB5tbD)VxcƆfx@ 0P 4!C \N .\ BܴzkVXID@Xbmp kٶm`[sֵ{v[źWt88obŋ7v1G E4R%K0eҴS'O@5T)ӧVq{,Z%' C+wp-}/ &xtөWw+cȑ%O\e̙5̹ϠC&8tiS֫]#nv/PE x!2O"FxN -Ìl˼,3/Hc4TneF0#+w!Ì Hl6h" (2;̾L< 3=cE$c 6v ˆ@`؁h;lH50#= =J(6β2>;O4JkC>?r0xS ;XSԬ3U\u8(Q+9TK+05EL?J/I$ <]ͥVjB}z5 CJLO$3 Tu:e.Ppܸ❸t  .(ޘcVCapR.ED17MӁ vEŠA$ ~U͵X]碍zP-CKLMS3W ޚ뮽Zf+Xؒ bhj";ŒdWj j ρ ? 9 (6+HmV}PzX|K~~^ٖrj(A0  _t>5f `G| jX&0*  @.(Pw $+!*h:-~`<(s B&Y! aZ Kbj7O\;Ρ=Xh (qF o0QH7/: &!,lKRG5*daHG^8uH~shHPe Q*@t%,aC.kO cqpZC Q@ DM1a CNQNS : $DE8?O~`O`@QЂc]%AB x@2v 8B%%0B4xg@#*˘_UFfАH IyyZD>u:=k`Ka0KLH1Z$QP N(`a)aҞK S}0) 2CVoJ~yO+y4*] hOuToGSB$n,lEY 0eneAgYRį7ĢCOAP[85mdk4wխY8E^`jo{kFlrc\8'TP[#v SN2v6bAOz)50o pI|(|ߌi\f =yca,pA ><x!GV2]"ўC 8J6eva-h\ ;Eӭo{׵ PHG:"1/ sdFxb c @W ~`k`:s@YCwЅ> Pp,k9sڋ#bƷ4 p; h:-0Ou֛ttk+е,Hg1 ?+قWj622k~ V@ ..|naăo5k1\!]( 2u~)?4phvq`Ԁ@ X^xhaxF0t7$Z"?t ~hu&^f%@"" 40FȰ`[2"0>uIaѭ Ѯmv4BT`[nAPzӃ W=' Q3܃2'y 1GF*? xaX\.8Kم6tOPm|>@~i]` A DO{  @($4j!,}/"p%` |$ԡ$$!gB@Me(2D KpWPl:^aq+/{x~P:0y o r8 F\p 3 ΰP  ni. 1s1H/.Qup+ gh)n?NB18NqJXD{%cHf.OnrQ3d !QsvQQ9Hqqw;c-ϑ8Bqn#[21h1 C ! p2WR"R"} #L#7RBg*d$9&$#IRrcV`%'&'F&_"kn2^r2w'y'(@)B F`)e((( rMp-I(bB +#c*ϥ*+*r:BZ2#b.B/:@B"r1\2 Β. V:00F 2j3V`0bFDځD ,R(/. b-::@*) :S+E PA)a29!-0ddr. sW3 F@7 R/3 *Ւ/G@b/F@0W73S1SW3& <7}9ۡrM3Bsn=SK@eS/C@k8 7:32a2K1 1.O<[3>2cF!.ۡA+&)/TDIDk:EU:/}0 !V 9;)sF8CK@TSrHs@gJ 9I#C١+,%4ʔ!]XهT Ip`2Y`Z^u^ | ` D@\-\ Yg] Nײ ^aV BKC5`=g``y, a!dK^I` @ F\D5;`):s-c+db4I, DdVh5bSA!:7C0"!RX).-!Vӕ@ܜ` Vl$vVbBMs,e@4SjaW˒6Qg;3jf"gu8 VqlQbt!:G0>i.,0n7o;B rgϫ. uq_Wh:q71O959Bsw`B"8[V". npUvWh`vk7rry7xww5H]yB|Wk8ÖzdwRbmm{3:#wx|ByA7S KV/ biVv{|1xC cpy2V`V/DCk@ b}\[^$] Eonn2,}`OMfD "mK^ xb4iy3-w`]k؍`wʌ2YkV@P얚!d" .9}@x쎛@ X 0X:8?Ay:@˒!7X"I[ٕ_K-U!TՖ %jp%;{-.=K4EsB&Nbnix5P€nwo65M#B/$ٙD 0 +/uI=]~Ygءuz-LaqU?7+0Ē3/74I3+s|a4U1W/nR9j׈C"Dm~4cK4LM7Wy vT` D zrkZX>?bT4]spכ7;7/s8TښY\";׀O,g'd-zrGŧ`򸨃6|[^`c9 nB bNCikBiրQY{7RZ:٨ءMm hw%"Hu" bI@  /;=ۚ4#3 {ZY6T;?Y{-iQ37'#€ "Rd  dZ@em{ :xw=4/sY48ңVW;Q]/.G7>{  "AWw P:Vz[$|$$ FQ6 {1!o863FXouWs9[?ySat|"z3òPze>h!S)+s<+'Zs*Q{O+R@ @Zx \lz9@ףb8[<,VQ.\Jȡad1} ulb Z bHԳ R]A,rcڌ]A!(&p@BtA U}ߵYv B=ۭ\0-DT_c0ƀg݃ݝ<`D|R P`R |Ⓞd:A `0愁>,>^ߞZ~ޭc}~W9M) V` ͊فNg%wf+,0_ ߽ΠƋXY0^ Bž)>mEm?E7?fv ?~ϭ lnkŅ08@'P7ß"E s0… tƋv+Z1ƍ;z2ȑ$K<v[| vXtev<ى(3СDO!,X`@(Ph &L@ \!$$x B  աGa~]DN6O@}Hv֞k6m~ Xiق B%Id*cf3IAXRJv"{|gn֟o8(XAfnCh@AN8ezrtPYInNMi#"hJUkF_mݖn_pWq>P>tu 4J}( ŠhXN"zb:kLb. nJպ4S_Q쾋QWJ▖4= p.wXh+ 5<"1 u:LF1Fi`rZcpMU{)=ki!)Ag{pBϦ=4k:;lmt{W tիz 8]O i `)p@ m`PЕ:z}Xf6uiFpir)y[RP>] <@d@̘gt)ǘȌxeyP%P9=™B"  q'wsTW .H% Y!II" Y=R `12P$ 1  J9D#EAaL*ҡD%N$ʢÒ pq/D957ʣ:A:[;+J35I*XFHʤpQ*SNPJbYZC[jXʥœΩS`:kkz!':^:j&ҦuJ!p*rtvjz|~*d*;x>xʨZjVZ1:l@ ;.ʪj9! 9!**@d4Śks퐬~*QI:ZcȬ݊ʭ j%!8嚮*zA/Q:0 <1 r)qK!ѰI81; r?4(*+[! Pz5./ 9)y?+,02[4+&I:<{>˴0qT'Nsqf*S˲U{ajX qgsKRk* ,iqڲ[#G:0@`aPF8fK&<H$5$ x*hzàs 8oTWKq>d$[l_g>A{0P+ + p+ًw˷[ D;q5GvvֽKv+4^ =k^/绿 >k’fOP^$ eZN@ɻ$8P ?P>0٬ P^G/al 2 Ge <Ok5 k!0,=SL2n ?;0MRASPLW<0\\'-;p<2u \;cS( # :@POY-$PM6mMf>zs>oU_|q f4l~OݫRn ׍O օ- 퀸<`h k87? ю \5ݫv+rFȃz+hPMm 0 k1< ===ބ["=B `;PF +k7BA<ީ$@0mYp ]Kumy}|gԠ])n02֟~;݅;ܭۖkvDS#d-WY8.OLj7 M%|hN3"XD᷈ E+"p`{^,='Up8>[}ۅ]ÌQlt = R_ ,8lm.+0`0  ^"p-Pj.~N-N:+qn$@r Ĭ\q|ja䠽KX댾z#zANpSxܹ=7]%r%<Q>Q3@POZc`t\Ȱ1]٢*a!PS#P"L!D["NQ8}1<1\?z<b<ڡ\OA]!Q];v"nv%,Á00PF=~RH%CIv6INL5męSNScGJ*dv:P$TDv0:4Q`bj`ԇaYN*nEuśW^v4<`gSbƍqM $ 5hMCT-8aҥMkDB/4&!vE `'vG Av|@sKztS?5 \xL |ZzOm}^$![S b$ 0Zk:v`ଃvj`Pj> /l'Jbg#Q`.ָ-7  ƒ2<hnvz{rDH4λv{HhdB0J+I3$a2J$1~ib  ZBШ.J: / W(\rb2ʼn*؁^`1܊:B;ԺѨ@+vTRγ:Ur.P]wպ#/ DEv&GŠ7,;(,Xo?  c)Y2wxk aJ/E5A#3!Dm.*`"`kUj5br}7R[76S5VBGuvަܠwRhݮۘR !8 =F'P2ԕ RvbY#2>zk8m9pa9NXnM ɂ]ӂky:jhpsj7̹Dj˻/gs%9h *ovEvZ XH^v0T*lλr(jaJv/^#pAT,(zn߽?qw̿;g*hv0&aZ=gL7S袧/|\ȧb3V >@SS dG;!fPB"@/a eh + `LP8@ Sx20[Eb~qߛZ8E$s7̡:p 07 fB‹-?ĨM(!6Qяu9HBҐ$Cj]3"@!vPF qSA!-)hHG !KhB8KXoXI$)Ѐ` ,B'YA2-Ә0>1G)@*J1:-Ź1ÜDg:չNtn cT#s]cE$)C 8ӟ?P4I'|LAZԢCDo15@Q"D>JPK"=y d pJ8}CNCNm!9'@Aم6թciTڑrӪWm;1,dKa DZs֟o` GM*BTcSР8R\iK_SSX.pDY@TP׻"U) ZkllXUvL .p_MXBV,f5~6+^Oֺ_eĖE=KV㱑le/2׳-i.|]`];6Ұ] oXK]ns ]Vm_ uw$Ei;ƚ׸M.{9Kok_ؿqq1(*XG<W]s9mג'=JŻ)^{LWu9e6gf{UbZV0eC8&miz'y"fT9$ 2p"nq:=otc;CCf|dK8Ӛ.O} ( 5a5.:2"oOKиowP9OU rpe:,^2 i@ƶ }W'ܳs{m2s4:=1B\uLdYξs} y?.ps{ F[!ۻV1S7ǹ n= 7;p At-]ktSX>g Zc8pO|yMfK{C!j)+Io ,o_nnL6 G{]l+=n7] x/fyoM|T;2wz ||$*^]x}f?54ηy/z |X+{e] 0`տ{V=]x^||C_O2wH=pc ?&۴kss>{;Gū[?u7:848= l,қ6w̾V;:>sCA#u*؁ DA :  7k4;6>5p0:@4)ٓD+*#@vx9;%ߋlB6BBGCs'`¨cCtCS22 '`'xG a SB*.d[x9 @L .B 4ED9[でB>OsD*H?$mc,`OlōXCCAd<7%Z;Gx ' :Fo 1cv{6rG&LDpɥPH8sDNOA(Ժ0wb)FQRǥCRI|ɘ,h]:Cʎ`¼;Ɠ|LԿhYH|Olr<Q!pK~>rPdЕm7C`Gy@r3PJ8R*<3S0H{ .wj/J pDP|Rі;<>@<؀kjc 8}(P8ȂLtWjHA=92- : 5%43لN9EeJ -?ChnK`bDU?e|TF&L1%:N%53.w6F7]'UQS(I@]U#DLTFU VD#/īdUVFcVr00X>RCDdDluP]Ĺ Soi@\ JQkuOdX/H QW3Rmju½c@lCw%$;<EPGaDTSUԘ?u_]`=SxH$TWOYMImmͱ0#T<Êa4Zt-أG*RJE1P"(><,Ze*w+%XUՃ;S1DԜ,ķ\M'\LTsa ȽB>H\&=\>v(hS%ݯ}CQͰ%"ǜt,%[MZR(sS.D:F) ܭ1Ľ*w(Ճ[ۥtU[L4b$^<ڢ 6BCV'w""`dQʵ<-T[#ISx~u[ ~smd v)f]50 ijmpetr"ȍخeG5^Jc`Z]O =(.euIM>5PHUo- Po*sv][T [v.I D^}f|nR}gkֿ9eECh*_Pe(2pb(=L(D0cHQ`Vp=HQeg`fUmgI(>BX\uteKv9(! N hj Z-ܮM6M0]n QhLF EQ(H{B$k\䜃@H4ʸ, ۉk-zhl~j@<4fiHj!#Iq9_3EH*R(eY\q-RcLf&c:vΞR RP`5(>4WX*F|mbJq-E f&^P5HODG\COObg_5 p& Ѓ `7*w&W?(p zZbm!T˅ȕ˯yuaSbV'f>hIvufȷİ.u7k2νG~#E(hɟ% X؄ \QgwdJ`v'XM7k p PΉ(qEn."v? )r$ɒ&OLr%˖._ŒQ0HO!`7`:;Ȕæ(,X`@(Ph &L@ v: ,p!B$HH WDtBguٱ' _&yAiC;'B( P Gڂ9(MGޕ^K*$@bMW% W(t ,k 6[Q\z$ݥRDuש BmMޚ@t ꁱHh뢼eÇHDI,b閡 .;GL䭉++١j̪^vAhi /sK Q8̗G`#гG!s&̪e@*$Z[ Nl5WpV `eՁ2Tš +c"J~Fm^ᇋY"p/ u+qV(;Аs޹盳SK ^zA+TbHƅԁ<B "eCj2X&)FmleJԦ+DTO $v@KةJjD@l(0ӧB5..,Ѐ #*F@SJJֶJB0+]j׻x+_׿G,a kX U],cB6,e+kb6H,g;ς6-iKkӢ%,'S–-mkk[-oÔ7ok"$M.s;PKхSukPKFJOEBPS/img/sbydb032.gifJaGIF89a2@@@999lll???666<<>>OOO˰000,,,(((---ќƬ777[[[tttkkkZZZjjjuuu222Γeee111fff '''~~~AAAvvv ***}}}:::wwwXXX mmm===sssĸGGG+++^^^í{{{|||iiigggxxxddd333555888444...QQQ### ]]]aaaJJJccc)))YYY\\\ SSShhh%%%qqqEEEIIInnnDDDTTTVVVCCCbbbWWWLLLNNNRRRMMM$$$HHHBBB!!!&&&!,2 HÇ#JH! 3jȱǏ CIɓ(S\ɲI +ʜI3" .sAN@ Jѣ?lɴӧPJJjS ʵ+( hӪ]˶۷iKݻxX߿۴oÈ&̸qU&LpLr^É3k^l9%f͠sLH} @3ͺuϡc+v]6sͻzhQ;qڨU_μ$nKNG?~.EB/~@ÅAx0mXE!hTN_YbȻ'Yߪf%:vZ{ꇴJ/ޫ^ǯV|w0njj"Ŵq=nL`~,Kl,&O2X -lXGE3s\g tTSkH&t2 i)G,i|m9-k>nD vo,k8lN<{g+vqt̲ d.hZO*FmD=<#֢x3yPhF bWH;Ej Fq 0%pzT!wr\ ?*n%ţyn{ɈQjt 'H:pBsJ6HR[X*rXE}#EslYՐnz& 2=iK90/QHD`$f4IMRf@13ggP stKPyBH);W?ma(HCъ"#- S9҅^8o8ZP,fN SJ.~1%iSʈ) Jґv$yԂPK(Tzӱ“bO#g]gԯ*p5k^W3u<'9R\&w@GJ&yd(U~ЌljTѮīX'KZ5VvukE5;ԳϔgZi}PYumQc ͭrs[:ӷWn\E2VDP] 4m(" ݕVn*yP:'|I>תz{-^ئ;_l)N*XޒTpP$f}lzu^焯˙XU$<]~)O8M1E0pj?͉i udp;.\X:|QkiU21K6`Nԧ6L)3f7FՌ9{NsdY+NQ``@'MJ[Ҙt?WF`дGMjM *)0w1C6Y8ՔNو@7B9X#ЕgXɇ~gIUkixo"1[ibdIfyKI=ؖ #(٘ɘP)rtvIF4 !4`ٗ999Y iv YyșʹY  !hg KK`~Bpoaa3I*xF9)0 ɜI]i !h9P Р:0 p8ɒ q 9X BKnBw{QN9!aؘmB:ji ȡ10 @0TZVzXZJ\  0dJљޙОc678: LJi17:/ࠧpmbZez"K Pک:JVcjڒɦu4 @U4{7}:zB JڥE ]vcڠ~P :䚨Z Р0*A[`KX qYJqz*1T>y$K :嚱K:P Ю+& p0 p@ +@aXa-3 *3Pی{9)"b;ʬ!& a,Kv{x@A+AP)xqȗY3|4ɵ;y+О p=۟{ĠnA gj9p}vh  iBۻ˜˰QA7i_ʛ`Ы@ 9@K ;wi` ݛ께t0 ,;J~@•]Ǜ@o W;B 8V{p1w1k{-M1qR. uH;ujf8A!w -'<0{U+y{NĪz5 a+[ |03Y+I,ij3:f|{P\v{ \>E|&PQU %,pǞy%xkk[P4oʕ-JJ7ɞ &D,JyL{pmazU +M1`  o Křwo0,.tТdp{ f(!(yu%0 3^yM?0Ҫ] A2. 0!.ߐ9@  QQa+殡hh##)tA$`#"]܅Pի00.yG0г ҭ}=A,Ǫ}+Q->+Ppݔ ۰ -{k  n =[ls9z,^ ~Oag:;_ﳫ; Z}\68:<_MJ q BD _ haq1]4N=?9///AߪL8 ;t >Vo В&POF!^ ! [Ez_15/N? M6IN*?xߕ^33@q/.K`OO{/wj zrj[d $XA .d8~+E5n#WI)UD1ec 3f9LoATh"Q=iƤa U ;`% Ŏ%hRiRiyU)]ed8hV;I7-` \VA(̹ЋFQfYl͘E*`ԩ-nϱernZP-J%FvI LYAP9:u++ŏ'_y @`R"E&ۦ[ nָI (iB0im& S@; +B 3̉6Pɴ3#€sE[" ?$h8'9.`&@J-"N 9 rDVY < L"C%:齿Nt3#̔iJr $X&k*${/NSNJ,D7;(œ4Ӡ* 7' J>u@v X=$#71Kzג ٠ 8Xp4c֒$Ò0-J,_B%6=U7NrC%H0Ҁ?$@|@@ RՖã '"m׾ ق*Q]7AEIԂJ}%TM#'x:6et$h7K t+KWR%y@$(K, '8 r8 k~U@ dGf8wt1~ݏ~8>2xh&shA_5l} \(H{|mٶX75Nc(#hc:O%yɬ:ll.2h& qn-('`{$+ (hR6OwpxEGmSMlĐ+X" ;vi 5%[[n&ge D[_|tO ! Rs<yϋl%\$ t'6ÅX+·+q&98q`Bk-_ h$>XqKEƵSM h@F8Qsc؊Ȧ 3V&[, dNeA 3#9@`_BT~@S҇>ZaGTRs#JI(HHj"\ T@^EHOՑb$IqA߮X@I]k@A[ Y=Y@+8|'=Վ*})e;NxS< ǂr}q?h1sn/aAJ+哥X; IВhQ)Ycb3ɎB')=*6HSl3K 'U XC|a)@/?(KSC ɕ,H8@A\YC$!S_!zBH-!K^ó9Ȗ1: P!s;!K::qʨؓEF CCSCK6+;L“>|h2a(5:ąy>L;" ;"Ɣk#D$Q^$b59 `EՓg; ]"rD5\ "1=$ (F~̰k ?FFآqY; HPGCD c! 4㽋(`44j)dx4C 0IȪ#KE拵jȕ.Hb* *B5Ñ}ɺ4< 5ɫ< $n%5+1˳'YG\vø3A0̰߳L\䪳 F0ڙ~.bXc-R 9 *\ `NNĄ|M?̸I08 0[ z+4 P-EL /CTjA'X|:NHU$8ΰĿ/Ip1IWj=  -ݗKLAB2I «ϒcr~{|̍#MyPMQB.E.@)5. 3.; C'gRBBp+B}(7R KҸ41l4( @KLTMTNTOLE=+Z)TWMsBM=8UR]eTU)7;$HUI= ԠX_])x]V#YUVqe Hi-6FptRJVXVČ(Vea*ߍ8_؛u_L݇]b"&/y֌`MX >/#a0Cbab0c1V Ӈ]B\~a+>$/ ,6:\)>2H1.dC&Ȇ0da$ aᬕ9:.G}$6ZrS'0c䬕d}䑵dpL& Nߪ4 (@&e$祁Ve`use\bFvY" iOn^~hP\h#T~S.geVR䉐8w~gxJkzƍN.дgaNbVcN|F f8hhhhh7^vgg6fːGhNihqn6rna+sihhZuif> vpnF{iSCd !Yzi_韶j炶R6,0v[h8NUjj6ϠjMjJɀNsPx%!m <-Ȃnune5h^ll~|gƞ&Q6ht6 ?Fd^` A%0 0PhZ kh{蕾mF鍆lVemnjE#jJ]e` ֯ ȓ@!kjX,xpO&0(vkE-N]6 o ֆ&oB,~`XIFzHp_popppY1.Eopdospqop76 h 0nvG, _!lrCN$ ?R p%`f_Vr)c"G 0l@,!@.#- m$)os-rngʞwv% 0 ;oɦs@6~`s7?5I 5I]0p^ h 8K-u&o *tDJm>>{^uSmT&nuQG"5uM/H`vavb/vc?vC1~UGkW&_'O ^?_Gvmvn_"]Ov-6؄7h/dOr7wt?7<w0w}wHH\ ?xp$`%pxx8xJAFkIH 3@@. :<8096X`@x42&$P 0 W;ijGkKpz}@ 9z/3>{# `x<7h)h=?? fXmHKǏ/OG}{{{B(-He@~m_r/ӇtOY2߇|ɧ|o||}7}W}/@p.!Ĉ'FtAC?(r#ȇ0B">(1"Õ3^h :a94&C=HS9BÐZ? ذbǒ-k,ZW-ܸr%BܼzOߣF 䫁GRPL#gfM^ӧ@@جxJHiGԃ K %KGa%/"ġ[/ }3g ? 8 r *HB]d]FS qhfjl!dUI$`K(c?3$5:d0?CsnIaL2axSN;&PEyNAU(beH-8& &i&&5X B&eqagai刯 d^9&BD׏2fF,O{IN]AݔAUYLiTfWq 癣+*8烥ڹYhf("<m?;&Q?V*DHZ=靔JޕJɚ~ f<0|0 +lZm0Z [|1 #FJR煙Aӂ8jז82ѷapYĈbEsqNִj?kynikaQK=X[}5y]{ aX!$f"|(ˊ.YH n?,s.E !+zK*7ci,$` .cwuE>sE- ٬Wxn۞m 4%h;~@`w:oL*}2^,>C#6Ɣm~KVQ $•p,!*%0Kb 4GkFZ*a3 ^.d*%T &*:dϲf!jeۖ`t5 Z_/J{hLĐ=qab ل@o#")=muw2U21oudy$=.eLh2M pXrs$ 6؅Z,NJ8D%E@ 0Qod)嘽Y1pz%/w5K\҉.é+_(~08Ic[.\&n-H4N#@H4XN~`7К3e 9nћ:4syIgHN3$eG3n@# dR"N3X#/pXͰ05pfѮ8rtr4рf=+ZӪֵU4)\8v+^պcΊgLG;.$I0 )d=ͨn$FXѷP `AKL4wuթx)|@TnSv0#Gsr-Cӯ{c͏KWnTYץƽgJ2Z:@=aagt\{}x_Mpsc޶ݒqŨN*}mߖlM.:v{ 84taQ2ȿLr]1Ot "G0)_ KhM:;\tIw_tQcg~ ݂\) Ĉw{xIs]}97)o{Ώ=en],􉜾qv0 aZþ9WyA1Uډ}{q՚Wi MnA@CĈ`daAy˖AIR^~t`XY0ᯈ`ݑٚ !D9BsiρL` 9t RT`]`&z *| 2* ʆBt]>,!aC b(!!H& R[Z iZmd\pV-#ڨ!,b ab''"K}b1LB)fZqI=.R$,@%A&A4A2̀1A&t495 6x$B.B!4̂#;<؁3<4#/E/tHa.4R B7zc@ C9#$A.ԁ<#8c?C8 }@$NN$OOdhm̤$BA%_($(2%TFT @zXM%VfVn%W_ڡRERe^0e0v%ZZzn]Z%\_%Ye#d\Z"ÌT"_&Z&_B ]ڥbY" &aFfV&Y]&fffAQb.&h^Of&jT @h 4 P73'DC*1A%0\>l"g&u>h l@h"A+!Lt#8l-/$@'A 4A lbtl€ hx $C7D\ |@8k^ؙtV'uSpvvx%0A6CC3 6'rb>4kJ ( TyN-,C7,A/`*\ Cf\}hu:aEc lhP*'+$(p)$#t&}] 4H;$*#A$P<8,,1؃!AB4HgRX')j1JA¤JC^3<:p*=ꨖ6B[J$dZW.!BīfDiSĴNV+[Vko)"jhn+2V+FV-!,&.,6@$L+hkĽ>,v~lFBɞ,ʦʮ,˶˾,CHleZz+l,Оl-"b .&֫ʜ&-V.Mn-b4ņ-GDmj-מmz-ɢ-RF ؊"VKѶ-ۦN-bMlR..6m-نBJe- V.-$F.͖,.F@!l%ᮮݶ:@..(Ю.砮B@$<8N/V^/foV4CJ*rҁCj/No%nˆfC /0_@1d\if 3_0g0+h&U4p*B0 O/"?0TnQ>0Fĸ`1\ 0o p 00\H k0W1A _@r?Hm)? [1q;J@ WA1!a@)1!13H GPTACq0Bq2(ǯ'o%<,2D #+p@8@hHײ- ,pG@\hq,o(&& \-/s-+1 Grp8*l37w738839os1iGP@5%nu3=3>s1LHP+3@;c AA4B'B/4C4:DL3%;shqCo4GwtG[L@N4V7 E-F(J0TJ+fKTpMM^lVT7 P@@S?+uhnPcf+I3h2A39 r2O4rk1P_<?l YDsT%= x$P#P$:,+p5EKuŚSU[*%,؂)"(B+8?Q g"L?X3JRve4j17p@%?Tj#?v)$Br/wb7&aMw[S'p`/xv('_<'@ԝ;,# 9?/?zA_ZC>WDx>ۂ>g˽{,]C @-؁ql?-?~ waB 6tbD)VxcƌB}dH#I4yeJlɠfLofN;/fbJCE sjTSs-AVZ}lXc*DCQk"CYckޜ{B ??/R5|8*?#Xpqy)W|Yiw ?p:0Xi3g _v )7U-C~,yuparl9LB&z J~('~nsP|xɇw;޾QtK>20+IǍr[Щ@=*ЃRCGB}2Ĝ Yq`GAsE`/}"HóA \9#3~~*QF`0NLoJ4}`@( 5 E:<7|a>, J $ ;Mn;\Ga"HxrҵTt*~IRH\cLJM0g.TWP+TTSsUVVY%5^ݶ4Wf$ۈM+XVܡN}Ц|=A~Z~nev ~(޵X⧗; ݃ZN];k8y3Ziaq fV!d&j@5(y!hc$WsYzK6y~80̑`V9fA IB`9~Qe'.$샌U 2qZm0J*6&aDgkD𞜢k)8g8s "/o~Sm^uc D(`x,A^0f d!@\ϑHfB! Mԋ!o@>c#Np֓L,å凛v8x Z~O~07~Ad sd~h }@=ɭxA8!O08:/?-1ZOU×hh[?txAa` ͘E 3@u2p@12 &X"?8 hCw@6Pa&G`X/ JpAEuB$"I@+@ox)4qh&9p,7Ghc v -rĚQ "|e !#.K8ZriAf j"dHD6 A{#rAܡ\NN0(H+)pLJ<3> b4@cp Pt(.NwSH#QeH@"kCAPlj"\*~xNw ?hҹv: 0t (@ 0I" QЀB5(Bʆ~/h8婡RԨR6jU 0b\JVU-ee6c:2uӛqr`C [Qyν`M}jTM'ku)eyJ`D IG#Ez:r-leK[V-d҅ҋq:ͥi3z_鶶ץv]6%o`A۽WPA .@u:׾}]~_"` ,޶2 1n! >^QgƼַхt3 c+ٗj1| kHC~UC(fmG0_U3Lx 咛dHTz~aj8`{´ P `ݓcgfϬݯ2*TԽ3fk_{Y4G#ꌹ 6pBv#,e*qS/l2bvE jgxeNB w}ϸC'c?:.tuMo^Wb:bOvg; GeEmN`s+k@&2]^Kx:cvSǴyO۲g?a l杈%Z(mo tJ3i9mPg]v8 ~a w!b P4[^DAȠ g5n8Qo{.\~6(?6!=_}_%B҃"I/q'<_EQEp:8stB`~/Ω@˞*/x+@/ԪD PQ B0ɀNPpA$ Zp^b0A@PWAhbo, ! *a/t>r b> H4,kd J*AAA}@|jVCA*ag PRz!> "a H4bmlC0 A>f@ A`ӆVAx`ʽDƍ(LO 0& Fr J?ƐGl 0@K܃ok`ΪBT!f:hsnzB )D@P ~ 4 `ӌ^b葜L !r 'BA!!5`P28#q$KVX%p{@آLʜk sa܁( R )/M`5 6_뵨+!`>bF /QN.cq#;!`0jH SnA  #&304@D<( `Z4̞Sj@V7$ Q29dRӷ$|;Dvi<4쀔R #6HpM*S?HIF@ H% '%NM`*! >"> taV @4̲&RD K4.Jh6@*A A M &atAj`!Ha62H7UԆHT2&@I!CnHn઎mmAM=S,TAV$@%m SpYZF!&w`A3f  RN[bZnNZ ~,QkH!@@~kG?{[nv  oY]@Rrq`O.awO;%v3]/claK{Ѯ yɒ/kQu.ϭUVuVaF/1VƖv65#}mGco Vϡvq~Vc.A< \8؟l؟V}o>Xoթ@,M?% ٽ|ԍm܍P}a_Rbڀo ^>ܽX ԩd$JDÐHM]@)B=pS=d= <;NYa a@G l#bǷ{ 7ێZx !_^~ C}^S[}^ 9pR1:bl#A<J9ֳ@ yA[_c_g#_U܇?wbxsi pha R*(4@L,m9@~( 8$#cm>0@ '=xOQ~RL`g~1>C?] Ch񻰉r1?jڼ3Ν.vȐ"Dd0a~xp :@7:7 U1Y- l~'|#V… #EA7m?" \GZQU0ed'ۻTVjXfѪe\re^z`fb1d(HFeiƙ!!ha&UlvI& pv!,ar&0t!A 3h@ bӀ&4RL"[&`0eZn|SUuUV[uUXcuVZkV\suW^_ Va-cMVemBpNhJ[U'n+ș'<@*( xؐ $ |JP "L"++i &%\qBYLRT* Oyc^-Q^}dwfjp8'v.|FgbQdoBj"V}k&inVmAss&їx6'EyM \0@+TPAIWۂiߘk&qX `R腛E)tJesZw5pwŚ#+(PUT (@OLkr҂>%Ҳ587[U5_ZKq;\ltg\5IS NxHM$S z exNl Ly9!ff ?f|Ϗ蓖E\V7:kb<{&=&XMt M7~ll@&ЏlPc+Nh=a>,CƁff9xO^r % t``FGo`CXݰr;4D?5 8 P%߈4!_:^CƑk犜tFL}E$8.n!"ߣ~{P?=aQt5ml@k1cAM.P2rp G2_K@2Qf{Yq69B4!EQeM̀WyIe҉ < HP6ƊSeCnhRP@ A= ˦A~H -N7r2/à:pС`3@/oZ3&s 0׮X @Qg1 ?=P#@j?*Ӡ4$jLQÌ(E%]è33 ~E,`U48 $ li`zNδ|5eRe @h,DgCU@.8Vb8+i,& JT͡aX(M |l1?vB(^PӭPAoIcF]W)?8p'l+בն7]QDnwL+ P{En LJ H(,1'5-}W_l7^.0N$(51&Q\7|%_s(&V(8rP@15 1\1 <֝ h" JOHA jPq$Fs'Lb( s}:KNuI:8EtB_/`i5q38a@ltMX= h+.%nm'.pHw=,b@lBp+| oxJUu@A"z!]PC&$>.6$GہH4V"(Hn<'$ Y!@yAqeXcE87X Q}d/ώv";G5 }d `@%g9xl^1'4!)A``6;(Wa{':Wslbp c($A& r^Lko/AD8hA BL3;Ƹ@Cl "@,pjk(]42;ҷ@(Ͻ~Ʈ1z{@0':(gkA0V!(WU;PKC~OaJaPKFJOEBPS/troubleshooting.htm Troubleshooting Data Guard

A Troubleshooting Data Guard

This appendix provides help troubleshooting a standby database. This appendix contains the following sections:

A.1 Common Problems

If you encounter a problem when using a standby database, it is probably because of one of the following reasons:

A.1.1 Renaming Datafiles with the ALTER DATABASE Statement

You cannot rename the datafile on the standby site when the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO. When you set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO, use of the following SQL statements is not allowed:

  • ALTER DATABASE RENAME

  • ALTER DATABASE ADD/DROP LOGFILE

  • ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER

  • ALTER DATABASE CREATE DATAFILE AS

If you attempt to use any of these statements on the standby database, an error is returned. For example:

SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy';

alter database rename file '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy' 
* 
ERROR at line 1: 
ORA-01511: error in renaming log/datafiles 
ORA-01270: RENAME operation is not allowed if STANDBY_FILE_MANAGEMENT is auto

See Section 9.3.1 to learn how to add datafiles to a physical standby database.

A.1.2 Standby Database Does Not Receive Redo Data from the Primary Database

If the standby site is not receiving redo data, query the V$ARCHIVE_DEST view and check for error messages. For example, enter the following query:

SQL> SELECT DEST_ID "ID", -
> STATUS "DB_status", -
> DESTINATION "Archive_dest", -
> ERROR "Error" -
> FROM V$ARCHIVE_DEST WHERE DEST_ID <=5;

ID DB_status Archive_dest                   Error   
-- --------- ------------------------------ ------------------------------------
 1  VALID    /vobs/oracle/work/arc_dest/arc                          
 2  ERROR    standby1                       ORA-16012: Archivelog standby database identifier mismatch  
 3  INACTIVE                            
 4  INACTIVE                    
 5  INACTIVE                                           
5 rows selected.

If the output of the query does not help you, check the following list of possible issues. If any of the following conditions exist, redo transport services will fail to transmit redo data to the standby database:

  • The service name for the standby instance is not configured correctly in the tnsnames.ora file for the primary database.

  • The Oracle Net service name specified by the LOG_ARCHIVE_DEST_n parameter for the primary database is incorrect.

  • The LOG_ARCHIVE_DEST_STATE_n parameter for the standby database is not set to the value ENABLE.

  • The listener.ora file has not been configured correctly for the standby database.

  • The listener is not started at the standby site.

  • The standby instance is not started.

  • You have added a standby archiving destination to the primary SPFILE or text initialization parameter file, but have not yet enabled the change.

  • Redo transport authentication has not been configured properly. See section 3.1.2 for redo transport authentication configuration requirements.

  • You used an invalid backup as the basis for the standby database (for example, you used a backup from the wrong database, or did not create the standby control file using the correct method).

A.1.3 You Cannot Mount the Physical Standby Database

You cannot mount the standby database if the standby control file was not created with the ALTER DATABASE CREATE [LOGICAL] STANDBY CONTROLFILE ... statement or RMAN command. You cannot use the following types of control file backups:

  • An operating system-created backup

  • A backup created using an ALTER DATABASE statement without the PHYSICAL STANDBY or LOGICAL STANDBY option

A.2 Log File Destination Failures

If you specify REOPEN for a MANDATORY destination, redo transport services stall the primary database when redo data cannot be successfully transmitted.

The REOPEN attribute is required when you use the MAX_FAILURE attribute. Example A-1 shows how to set a retry time of 5 seconds and limit retries to 3 times.

Example A-1 Setting a Retry Time and Limit

LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'

Use the ALTERNATE attribute of the LOG_ARCHIVE_DEST_n parameter to specify alternate archive destinations. An alternate archiving destination can be used when the transmission of redo data to a standby database fails. If transmission fails and the REOPEN attribute was not specified or the MAX_FAILURE attribute threshold was exceeded, redo transport services attempts to transmit redo data to the alternate destination on the next archival operation.

Use the NOALTERNATE attribute to prevent the original archive destination from automatically changing to an alternate archive destination when the original archive destination fails.

Example A-2 shows how to set the initialization parameters so that a single, mandatory, local destination will automatically fail over to a different destination if any error occurs.

Example A-2 Specifying an Alternate Destination

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

If the LOG_ARCHIVE_DEST_1 destination fails, the archiving process will automatically switch to the LOG_ARCHIVE_DEST_2 destination at the next log file switch on the primary database.

A.3 Handling Logical Standby Database Failures

An important tool for handling logical standby database failures is the DBMS_LOGSTDBY.SKIP_ERROR procedure. Depending on how important a table is, you might want to do one of the following:

  • Ignore failures for a table or specific DDL

  • Associate a stored procedure with a filter so at runtime a determination can be made about skipping the statement, executing this statement, or executing a replacement statement

Taking one of these actions prevents SQL Apply from stopping. Later, you can query the DBA_LOGSTDBY_EVENTS view to find and correct any problems that exist. See Oracle Database PL/SQL Packages and Types Reference for more information about using the DBMS_LOGSTDBY package with PL/SQL callout procedures.

A.4 Problems Switching Over to a Physical Standby Database

In most cases, following the steps described in Chapter 8 will result in a successful switchover. However, if the switchover is unsuccessful, the following sections may help you to resolve the problem:

A.4.1 Switchover Fails Because Redo Data Was Not Transmitted

If the switchover does not complete successfully, you can query the SEQUENCE# column in the V$ARCHIVED_LOG view to see if the last redo data transmitted from the original primary database was applied on the standby database. If the last redo data was not transmitted to the standby database, you can manually copy the archived redo log file containing the redo data from the original primary database to the old standby database and register it with the SQL ALTER DATABASE REGISTER LOGFILE file_specification statement. If you then start apply services, the archived redo log file will be applied automatically. Query the SWITCHOVER_STATUS column in the V$DATABASE view. A switchover to the primary role is now possible if the SWITCHOVER_STATUS column returns TO PRIMARY or SESSIONS ACTIVE.

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS 
----------------- 
TO PRIMARY 
1 row selected 

See Chapter 17 for information about other valid values for the SWITCHOVER_STATUS column of the V$DATABASE view.

To continue with the switchover, follow the instructions in Section 8.2.1 for physical standby databases or Section 8.3.1 for logical standby databases, and try again to switch the target standby database to the primary role.

A.4.2 Switchover Fails Because SQL Sessions Are Still Active

If you do not include the WITH SESSION SHUTDOWN clause as a part of the ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY statement, active SQL sessions might prevent a switchover from being processed. Active SQL sessions can include other Oracle Database processes.

When sessions are active, an attempt to switch over fails with the following error message:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
 
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY * 
ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

Action: Query the V$SESSION view to determine which processes are causing the error. For example:

SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION -   
> WHERE TYPE = 'USER' -
>  AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT);

SID        PROCESS   PROGRAM 
---------  --------  ------------------------------------------------ 
        7      3537  oracle@nhclone2 (CJQ0)
       10
       14
       16
       19
       21
 6 rows selected.

In the previous example, the JOB_QUEUE_PROCESSES parameter corresponds to the CJQ0 process entry. Because the job queue process is a user process, it is counted as a SQL session that prevents switchover from taking place. The entries with no process or program information are threads started by the job queue controller.

Verify the JOB_QUEUE_PROCESSES parameter is set using the following SQL statement:

SQL> SHOW PARAMETER JOB_QUEUE_PROCESSES; 

NAME                           TYPE      VALUE
------------------------------ -------   -------------------- 
job_queue_processes            integer   5

Then, set the parameter to 0. For example:

SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; 
Statement processed.

Because JOB_QUEUE_PROCESSES is a dynamic parameter, you can change the value and have the change take effect immediately without having to restart the instance. You can now retry the switchover procedure.

Do not modify the parameter in your initialization parameter file. After you shut down the instance and restart it after the switchover completes, the parameter will be reset to the original value. This applies to both primary and physical standby databases.

Table A-1 summarizes the common processes that prevent switchover and what corrective action you need to take.

Table A-1 Common Processes That Prevent Switchover

Type of ProcessProcess DescriptionCorrective Action

CJQ0

Job Queue Scheduler Process

Change the JOB_QUEUE_PROCESSES dynamic parameter to the value 0. The change will take effect immediately without having to restart the instance.

QMN0

Advanced Queue Time Manager

Change the AQ_TM_PROCESSES dynamic parameter to the value 0. The change will take effect immediately without having to restart the instance.

DBSNMP

Oracle Enterprise Manager Management Agent

Issue the emctl stop agent command from the operating system prompt.


A.4.3 Switchover Fails with the ORA-01102 Error

Suppose the standby database and the primary database reside on the same site. After both the ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY and the ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY statements are successfully executed, shut down and restart the physical standby database and the primary database.


Note:

It is not necessary to shut down and restart the physical standby database if it has not been opened read-only since the instance was started.

However, the startup of the second database fails with ORA-01102 error "cannot mount database in EXCLUSIVE mode."

This could happen during the switchover if you did not set the DB_UNIQUE_NAME parameter in the initialization parameter file that is used by the standby database (that is, the original primary database). If the DB_UNIQUE_NAME parameter of the standby database is not set, the standby and the primary databases both use the same mount lock and cause the ORA-01102 error during the startup of the second database.

Action: Add DB_UNIQUE_NAME=unique_database_name to the initialization parameter file used by the standby database, and shut down and restart the standby and primary databases.

A.4.4 Redo Data Is Not Applied After Switchover

The archived redo log files are not applied to the new standby database after the switchover.

This might happen because some environment or initialization parameters were not properly set after the switchover.

Action:

  • Check the tnsnames.ora file at the new primary site and the listener.ora file at the new standby site. There should be entries for a listener at the standby site and a corresponding service name at the primary site.

  • Start the listener at the standby site if it has not been started.

  • Check if the LOG_ARCHIVE_DEST_n initialization parameter was set to properly transmit redo data from the primary site to the standby site. For example, query the V$ARCHIVE_DEST fixed view at the primary site as follows:

    SQL> SELECT DEST_ID, STATUS, DESTINATION FROM V$ARCHIVE_DEST;
    

    If you do not see an entry corresponding to the standby site, you need to set LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n initialization parameters.

  • Set the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters correctly at the standby site so that the archived redo log files are applied to the desired location. (Note that the STANDBY_ARCHIVE_DEST parameter has been deprecated and is supported for backward compatibility only.)

  • At the standby site, set the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters. Set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO if you want the standby site to automatically add new datafiles that are created at the primary site.

A.4.5 Roll Back After Unsuccessful Switchover and Start Over

For physical standby databases in situations where an error occurred and it is not possible to continue with the switchover, it might still be possible to revert the new physical standby database back to the primary role by using the following steps. (This functionality is available starting with Oracle Database 11g Release 2 (11.2.0.2).)

  1. Shut down and mount the new standby database (old primary).

  2. Start Redo Apply on the new standby database.

  3. Verify that the new standby database is ready to be switched back to the primary role. Query the SWITCHOVER_STATUS column of the V$DATABASE view on the new standby database. For example:

    SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
     
    SWITCHOVER_STATUS 
    ----------------- 
    TO_PRIMARY 
    1 row selected
    

    A value of TO PRIMARY or SESSIONS ACTIVE indicates that the new standby database is ready to be switched to the primary role. Continue to query this column until the value returned is either TO PRIMARY or SESSIONS ACTIVE.

  4. Issue the following statement to convert the new standby database back to the primary role:

    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
    

    If this statement is successful, the database will be running in the primary database role, and you do not need to perform any more steps.

    If this statement is unsuccessful, then continue with Step 5.

  5. When the switchover to change the role from primary to physical standby was initiated, a trace file was written in the log directory. This trace file contains the SQL statements required to re-create the original primary control file. Locate the trace file and extract the SQL statements into a temporary file. Execute the temporary file from SQL*Plus. This will revert the new standby database back to the primary role.

  6. Shut down the original physical standby database.

  7. Create a new standby control file. This is necessary to resynchronize the primary database and physical standby database. Copy the physical standby control file to the original physical standby system. Section 3.2.2 describes how to create a physical standby control file.

  8. Restart the original physical standby instance.

    If this procedure is successful and archive gap management is enabled, the FAL processes will start and re-archive any missing archived redo log files to the physical standby database. Force a log switch on the primary database and examine the alert logs on both the primary database and physical standby database to ensure the archived redo log file sequence numbers are correct.

    See Section 6.4.3.1 for information about archive gap management and Appendix F for information about locating the trace files.

  9. Try the switchover again.

    At this point, the Data Guard configuration has been rolled back to its initial state, and you can try the switchover operation again (after correcting any problems that might have led to the initial unsuccessful switchover).

A.5 Problems Switching Over to a Logical Standby Database

A switchover operation involving a logical standby database usually consists of two phases: preparing and committing. The exceptions to this are for rolling upgrades of Oracle software using a logical standby database or if you are using Data Guard broker. If you experience failures in the context of doing a rolling upgrade using a logical standby database or during a switchover operation initiated by Data Guard broker, you should go directly to Section A.5.2.


Note:

Oracle recommends that Flashback Database be enabled for all databases in a Data Guard configuration. The steps in this section assume that you have Flashback Database enabled on all databases in your Data Guard configuration.

A.5.1 Failures During the Prepare Phase of a Switchover Operation

If a failure occurs during the preparation phase of a switchover operation, you should cancel the switchover and retry the switchover operation from the very beginning.

A.5.1.1 Failure While Preparing the Primary Database

If you encounter failure while executing the ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY statement, you can cancel the prepare phase of a switchover by issuing the following SQL statement at the primary database:

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;

You can now retry the switchover operation from the beginning.

A.5.1.2 Failure While Preparing the Logical Standby Database

If you encounter failure while executing the ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY statement, you will need to cancel the prepare operation at the primary database and at the target standby database. Take the following steps:

  1. At the primary database, cancel the statement you had issued to prepare for the switchover:

    SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;
    
  2. At the logical standby database that was the target of the switchover, cancel the statement you had issued to prepare to switch over:

    SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY CANCEL;
    

    You can now retry the switchover operation from the beginning.

A.5.2 Failures During the Commit Phase of a Switchover Operation

Although committing to a switchover involves a single SQL statement, internally a number of operations are performed. The corrective actions that you need to take depend on the state of the commit to switchover operation when the error was encountered.

A.5.2.1 Failure to Convert the Original Primary Database

If you encounter failures while executing the ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY statement, you can take the following steps:

  1. Check the DATABASE_ROLE column of the V$DATABASE fixed view on the original primary database:

    SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
    
    • If the column contains a value of LOGICAL STANDBY, the switchover operation has completed, but has failed during a post-switchover task. In this situation, Oracle recommends that you shut down and reopen the database.

    • If the column contains a value of PRIMARY, proceed to Step 2.

  2. Perform the following query on the original primary:

    SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS -
    > WHERE NAME = 'END_PRIMARY';
    
    • If the query returns a 0, the primary is in a state identical to that it was in before the commit to switchover command was issued. You do not need to take any corrective action. You can proceed with the commit to switchover operation or cancel the switchover operation as outlined in Section A.5.1.2.

    • If the query returns a 1, the primary is in an inconsistent state, and you need to proceed to Step 3.

  3. Take corrective action at the original primary database to maintain its ability to be protected by existing or newly instantiated logical standby databases.

    You can either fix the underlying cause of the error raised during the commit to switchover operation and reissue the SQL statement (ALTER DTABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY) or you can take the following steps:

    1. From the alert log of the instance where you initiated the commit to switchover command, determine the SCN needed to flash back to the original primary. This information is displayed after the ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY SQL statement:

      LOGSTDBY: Preparing the COMMIT TO SWITCHOVER TO LOGICAL STANDBY DDL at scn [flashback_scn].
      
    2. Shut down all instances of the primary database:

      SQL> SHUTDOWN IMMEDIATE;
      
    3. Mount the primary database in exclusive mode:

      SQL> STARTUP MOUNT;
      
    4. Flash back the database to the SCN taken from the alert log:

      SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;
      
    5. Open the primary database:

      SQL> STARTUP;
      
    6. Lower the database guard at the original primary database:

      SQL> ALTER DATABASE GUARD NONE;
      

    At this point the primary is in a state identical to that it was in before the commit switchover command was issued. You do not need to take any corrective action. you can proceed with the commit to switchover operation or cancel the switchover operation as outlined in Section A.5.1.1.

A.5.2.2 Failure to Convert the Target Logical Standby Database

If you encounter failures while executing the ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY statement, take the following steps:

  1. Check the DATABASE_ROLE column of the V$DATABASE fixed view on the target standby database:

    SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
    
    • If the column contains a value PRIMARY, the switchover operation has completed, but has failed during a post-switchover task. In this situation, you must perform the following steps:

      1. Shut down and reopen the database.

      2. Issue an ALTER DATABASE GUARD NONE command to remove write restrictions to the database.

    • If the column contains a value of LOGICAL STANDBY, proceed to Step 2.

  2. Perform the following query on the target logical standby:

    SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS -
    > WHERE NAME = 'BEGIN_PRIMARY';
    
    • If the query returns a 0, the logical standby is in a state identical to that it was in before the commit to switchover command was issued. You do not need to take any corrective action. You can proceed with the commit to switchover operations or cancel the switchover operation as outlined in Section A.5.1.2.

    • If the query returns a 1, the logical standby is in an inconsistent state, and you should proceed to Step 3.

  3. Take corrective action at the logical standby to maintain its ability to either become the new primary or become a bystander to a different new primary.

    You can either fix the underlying cause of the error raised during the commit to switchover operation and reissue the SQL statement (ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY) or you can take the following steps to flash back the logical standby database to a point of consistency just prior to the commit to switchover attempt:

    1. From the alert log of the instance where you initiated the commit to switchover command, determine the SCN needed to flash back to the logical standby. This information is displayed after the ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY SQL statement:

      LOGSTDBY: Preparing the COMMIT TO SWITCHOVER TO PRIMARY DDL at scn [flashback_scn].
      
    2. Shut down all instances of the target standby database:

      SQL> SHUTDOWN IMMEDIATE;
      
    3. Mount the target logical standby database:

      SQL> STARTUP MOUNT;
      
    4. Flash back the target logical standby to the desired SCN:

      SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;
      
    5. Open the database (in case of an Oracle RAC, open all instances);

      SQL> STARTUP OPEN;
      

At this point the target standby is in a state identical to that it was in before the commit to switchover command was issued. You do not need to take any further corrective action. You can proceed with the commit to switchover operation.

A.6 What to Do If SQL Apply Stops

Apply services cannot apply unsupported DML statements, DDL statements, and Oracle supplied packages to a logical standby database running SQL Apply.

When an unsupported statement or package is encountered, SQL Apply stops. You can take the actions described in Table A-2 to correct the situation and start SQL Apply on the logical standby database again.

Table A-2 Fixing Typical SQL Apply Errors

If...Then...

You suspect an unsupported statement or Oracle supplied package was encountered

Find the last statement in the DBA_LOGSTDBY_EVENTS view. This will indicate the statement and error that caused SQL Apply to fail. If an incorrect SQL statement caused SQL Apply to fail, transaction information, as well as the statement and error information, can be viewed. The transaction information can be used with LogMiner tools to understand the cause of the problem.

An error requiring database management occurred, such as running out of space in a particular tablespace

Fix the problem and resume SQL Apply using the ALTER DATABASE START LOGICAL STANDBY APPLY statement.

An error occurred because a SQL statement was entered incorrectly, such as an incorrect standby database filename being entered in a tablespace statement

Enter the correct SQL statement and use the DBMS_LOGSTDBY.SKIP_TRANSACTION procedure to ensure the incorrect statement is ignored the next time SQL Apply is run. Then, restart SQL Apply using the ALTER DATABASE START LOGICAL STANDBY APPLY statement.

An error occurred because skip parameters were incorrectly set up, such as specifying that all DML for a given table be skipped but CREATE, ALTER, and DROP TABLE statements were not specified to be skipped

Issue the DBMS_LOGSTDBY.SKIP('TABLE','schema_name','table_name',null) procedure, then restart SQL Apply.


See Chapter 17 for information about querying the DBA_LOGSTDBY_EVENTS view to determine the cause of failures.

A.7 Network Tuning for Redo Data Transmission

For optimal performance, set the Oracle Net SDU parameter to 32 kilobytes in each Oracle Net connect descriptor used by redo transport services.

The following example shows a database initialization parameter file segment that defines a remote destination netserv:

LOG_ARCHIVE_DEST_3='SERVICE=netserv'

The following example shows the definition of that service name in the tnsnames.ora file:

netserv=(DESCRIPTION=(SDU=32768)(ADDRESS=(PROTOCOL=tcp)(HOST=host) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=srvc)))

The following example shows the definition in the listener.ora file:

LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)
(HOST=host)(PORT=1521))))

SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SDU=32768)(SID_NAME=sid)
(GLOBALDBNAME=srvc)(ORACLE_HOME=/oracle)))

If you archive to a remote site using a high-latency or high-bandwidth network link, you can improve performance by using the SQLNET.SEND_BUF_SIZE and SQLNET.RECV_BUF_SIZE Oracle Net profile parameters to increase the size of the network send and receive I/O buffers.

See Oracle Database Net Services Administrator's Guide for information about other ways to change the Oracle NET SDU parameter.

A.8 Slow Disk Performance on Standby Databases

If asynchronous I/O on the file system itself is showing performance problems, try mounting the file system using the Direct I/O option or setting the FILESYSTEMIO_OPTIONS=SETALL initialization parameter. The maximum I/O size setting is 1 MB.

A.9 Log Files Must Match to Avoid Primary Database Shutdown

If you have configured a standby redo log on one or more standby databases in the configuration, ensure the size of the standby redo log files on each standby database exactly matches the size of the online redo log files on the primary database.

At log switch time, if there are no available standby redo log files that match the size of the new current online redo log file on the primary database:

  • The primary database will shut down if it is operating in maximum protection mode,

    or

  • The RFS process on the standby database will create an archived redo log file on the standby database and write the following message in the alert log:

    No standby log files of size <#> blocks available.
    

For example, if the primary database uses two online redo log groups whose log files are 100K, then the standby database should have 3 standby redo log groups with log file sizes of 100K.

Also, whenever you add a redo log group to the primary database, you must add a corresponding standby redo log group to the standby database. This reduces the probability that the primary database will be adversely affected because a standby redo log file of the required size is not available at log switch time.

A.10 Troubleshooting a Logical Standby Database

This section contains the following topics:

A.10.1 Recovering from Errors

Logical standby databases maintain user tables, sequences, and jobs. To maintain other objects, you must reissue the DDL statements seen in the redo data stream.

If SQL Apply fails, an error is recorded in the DBA_LOGSTDBY_EVENTS table. The following sections demonstrate how to recover from two such errors.

A.10.1.1 DDL Transactions Containing File Specifications

DDL statements are executed the same way on the primary database and the logical standby database. If the underlying file structure is the same on both databases, the DDL will execute on the standby database as expected.

If an error was caused by a DDL transaction containing a file specification that did not match in the logical standby database environment, perform the following steps to fix the problem:

  1. Use the ALTER SESSION DISABLE GUARD statement to bypass the database guard so you can make modifications to the logical standby database:

    SQL> ALTER SESSION DISABLE GUARD;
    
  2. Execute the DDL statement, using the correct file specification, and then reenable the database guard. For example:

    SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 100M REUSE;
    SQL> ALTER SESSION ENABLE GUARD;
    
  3. Start SQL Apply on the logical standby database and skip the failed transaction.

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE -
    > SKIP FAILED TRANSACTION;
    

In some situations, the problem that caused the transaction to fail can be corrected and SQL Apply restarted without skipping the transaction. An example of this might be when available space is exhausted. (Do not let the primary and logical standby databases diverge when skipping DDL transactions. If possible, you should manually execute a compensating transaction in place of the skipped transaction.)

The following example shows SQL Apply stopping, the error being corrected, and then restarting SQL Apply:

SQL> SET LONG 1000
SQL> ALTER SESSION SET NLS_DATE_FORMAT  = 'DD-MON-YY HH24:MI:SS';

Session altered.

SQL> SELECT EVENT_TIME, COMMIT_SCN, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS;

EVENT_TIME              COMMIT_SCN
------------------ ---------------
EVENT
-------------------------------------------------------------------------------
STATUS
-------------------------------------------------------------------------------
22-OCT-03 15:47:58

ORA-16111: log mining and apply setting up

22-OCT-03 15:48:04          209627
insert into "SCOTT"."EMP"
values
   "EMPNO" = 7900,
   "ENAME" = 'ADAMS',
   "JOB" = 'CLERK',
   "MGR" IS NULL,
   "HIREDATE" = TO_DATE('22-OCT-03', 'DD-MON-RR'),
   "SAL" = 950,
   "COMM" IS NULL,
   "DEPTNO" IS NULL
ORA-01653: unable to extend table SCOTT.EMP by %200 bytes in tablespace T_TABLE

In the example, the ORA-01653 message indicates that the tablespace was full and unable to extend itself. To correct the problem, add a new datafile to the tablespace. For example:

SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 60M;
Tablespace altered.

Then, restart SQL Apply:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

When SQL Apply restarts, the transaction that failed will be reexecuted and applied to the logical standby database.

A.10.1.2 Recovering from DML Failures

Do not use the SKIP_TRANSACTION procedure to filter DML failures. Not only is the DML that is seen in the events table skipped, but so is all the DML associated with the transaction. This will cause multiple tables.

DML failures usually indicate a problem with a specific table. For example, assume the failure is an out-of-storage error that you cannot resolve immediately. The following steps demonstrate one way to respond to this problem.

  1. Bypass the table, but not the transaction, by adding the table to the skip list:

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','SCOTT','EMP');
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    

    From this point on, DML activity for the SCOTT.EMP table is not applied. After you correct the storage problem, you can fix the table, provided you set up a database link to the primary database that has administrator privileges to run procedures in the DBMS_LOGSTDBY package.

  2. Using the database link to the primary database, drop the local SCOTT.EMP table and then re-create it, and pull the data over to the standby database.

    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCOTT','EMP','PRIMARYDB');
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    
  3. To ensure a consistent view across the newly instantiated table and the rest of the database, wait for SQL Apply to catch up with the primary database before querying this table. Refer to Section 10.5.5, "Adding or Re-Creating Tables On a Logical Standby Database" for a detailed example.

A.10.2 Troubleshooting SQL*Loader Sessions

Oracle SQL*Loader provides a method of loading data from different sources into the Oracle Database. This section analyzes some of the features of the SQL*Loader utility as it pertains to SQL Apply.

Regardless of the method of data load chosen, the SQL*Loader control files contain an instruction on what to do to the current contents of the Oracle table into which the new data is to be loaded, via the keywords of APPEND and REPLACE. The following examples show how to use these keywords on a table named LOAD_STOK:

  • When using the APPEND keyword, the new data to be loaded is appended to the contents of the LOAD_STOK table:

    LOAD DATA
    INTO TABLE LOAD_STOK APPEND
    
  • When using the REPLACE keyword, the contents of the LOAD_STOK table are deleted prior to loading new data. Oracle SQL*Loader uses the DELETE statement to purge the contents of the table, in a single transaction:

    LOAD DATA
    INTO TABLE LOAD_STOK REPLACE
    

Rather than using the REPLACE keyword in the SQL*Loader script, Oracle recommends that prior to loading the data, issue the SQL*Plus TRUNCATE TABLE command against the table on the primary database. This will have the same effect of purging both the primary and standby databases copy of the table in a manner that is both fast and efficient because the TRUNCATE TABLE command is recorded in the online redo log files and is issued by SQL Apply on the logical standby database.

The SQL*Loader script may continue to contain the REPLACE keyword, but it will now attempt to DELETE zero rows from the object on the primary database. Because no rows were deleted from the primary database, there will be no redo recorded in the redo log files. Therefore, no DELETE statement will be issued against the logical standby database.

Issuing the REPLACE keyword without the SQL statement TRUNCATE TABLE provides the following potential problems for SQL Apply when the transaction needs to be applied to the logical standby database.

  • If the table currently contains a significant number of rows, then these rows need to be deleted from the standby database. Because SQL Apply is not able to determine the original syntax of the statement, SQL Apply must issue a DELETE statement for each row purged from the primary database.

    For example, if the table on the primary database originally had 10,000 rows, then Oracle SQL*Loader will issue a single DELETE statement to purge the 10,000 rows. On the standby database, SQL Apply does not know that all rows are to be purged, and instead must issue 10,000 individual DELETE statements, with each statement purging a single row.

  • If the table on the standby database does not contain an index that can be used by SQL Apply, then the DELETE statement will issue a Full Table Scan to purge the information.

    Continuing with the previous example, because SQL Apply has issued 10,000 individual DELETE statements, this could result in 10,000 Full Table Scans being issued against the standby database.

A.10.3 Troubleshooting Long-Running Transactions

One of the primary causes for long-running transactions in a SQL Apply environment is because of Full Table Scans. Additionally, long-running transactions could be the result of SQL statements being replicated to the standby database, such as when creating or rebuilding an index.

Identifying Long-Running Transactions

If SQL Apply is executing a single SQL statement for a long period of time, then a warning message similar to the following is reported in the alert log of the SQL Apply instance:

Mon Feb 17 14:40:15 2003
WARNING: the following transaction makes no progress
WARNING: in the last 30 seconds for the given message!
WARNING: xid =
0x0016.007.000017b6 cscn = 1550349, message# = 28, slavid = 1
knacrb: no offending session found (not ITL pressure)

Note the following about the warning message:

  • This warning is similar to the warning message returned for interested transaction list (ITL) pressure, with the exception being the last line that begins with knacrb. The final line indicates:

    • A Full Table Scan may be occurring

    • This issue has nothing to do with interested transaction list (ITL) pressure

  • This warning message is reported only if a single statement takes more than 30 seconds to execute.

It may not be possible to determine the SQL statement being executed by the long-running statement, but the following SQL statement may help in identifying the database objects on which SQL Apply is operating:

SQL> SELECT SAS.SERVER_ID -
>  , SS.OWNER -
>  , SS.OBJECT_NAME -
>  , SS.STATISTIC_NAME -
>  , SS.VALUE -
>  FROM V$SEGMENT_STATISTICS SS -
>  , V$LOCK L -
>  , V$STREAMS_APPLY_SERVER SAS -
>  WHERE SAS.SERVER_ID = &SLAVE_ID -
>  AND L.SID = SAS.SID -
>  AND L.TYPE = 'TM' -
>  AND SS.OBJ# = L.ID1;

Additionally, you can issue the following SQL statement to identify the SQL statement that has resulted in a large number of disk reads being issued per execution:

SQL> SELECT SUBSTR(SQL_TEXT,1,40) -
>  , DISK_READS -
>  , EXECUTIONS -
>  , DISK_READS/EXECUTIONS -
>  , HASH_VALUE -
>  , ADDRESS -
>  FROM V$SQLAREA -
>  WHERE DISK_READS/GREATEST(EXECUTIONS,1) > 1 -
>  AND ROWNUM < 10 -
>  ORDER BY DISK_READS/GREATEST(EXECUTIONS,1) DESC;

Oracle recommends that all tables have primary key constraints defined, which automatically means that the column is defined as NOT NULL. For any table where a primary-key constraint cannot be defined, an index should be defined on an appropriate column that is defined as NOT NULL. If a suitable column does not exist on the table, then the table should be reviewed and, if possible, skipped by SQL Apply. The following steps describe how to skip all DML statements issued against the FTS table on the SCOTT schema:

  1. Stop SQL Apply:

    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    Database altered
    
  2. Configure the skip procedure for the SCOTT.FTS table for all DML transactions:

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML' , -
    >  schema_name => 'SCOTT' , -
    >  object_name => 'FTS');
    PL/SQL procedure successfully completed
    
  3. Start SQL Apply:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    Database altered
    

Troubleshooting ITL Pressure

Interested transaction list (ITL) pressure is reported in the alert log of the SQL Apply instance. Example A-3 shows an example of the warning messages.

Example A-3 Warning Messages Reported for ITL Pressure

Tue Apr 22 15:50:42 2003
WARNING: the following transaction makes no progress
WARNING: in the last 30 seconds for the given message!
WARNING: xid =
0x0006.005.000029fa cscn = 2152982, message# = 2, slavid = 17

Real-Time Analysis

The messages shown in Example A-3 indicate that the SQL Apply process (slavid) #17 has not made any progress in the last 30 seconds. To determine the SQL statement being issued by the Apply process, issue the following query:

SQL> SELECT SA.SQL_TEXT -
>  FROM V$SQLAREA SA -
  >  , V$SESSION S -
  >  , V$STREAMS_APPLY_SERVER SAS -
  >  WHERE SAS.SERVER_ID = &SLAVEID -
  >  AND S.SID = SAS.SID -
  >  AND SA.ADDRESS = S.SQL_ADDRESS

SQL_TEXT
------------------------------------------------------------
insert into "APP"."LOAD_TAB_1" p("PK","TEXT")values(:1,:2)

An alternative method to identifying ITL pressure is to query the V$LOCK view, as shown in the following example. Any session that has a request value of 4 on a TX lock, is waiting for an ITL to become available.

SQL> SELECT SID,TYPE,ID1,ID2,LMODE,REQUEST -
> FROM V$LOCK -
> WHERE TYPE = 'TX'

SID        TY ID1        ID2        LMODE      REQUEST
---------- -- ---------- ---------- ---------- ----------
         8 TX     327688         48          6          0
        10 TX     327688         48          0          4

In this example, SID 10 is waiting for the TX lock held by SID 8.

Post-Incident Review

Pressure for a segment's ITL is unlikely to last for an extended period of time. In addition, ITL pressure that lasts for less than 30 seconds will not be reported in the standby databases alert log. Therefore, to determine which objects have been subjected to ITL pressure, issue the following statement:

SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE -
>  FROM V$SEGMENT_STATISTICS -
>  WHERE STATISTIC_NAME = 'ITL waits' -
>  AND VALUE > 0 -
>  ORDER BY VALUE;

This statement reports all database segments that have had ITL pressure at some time since the instance was last started.


Note:

This SQL statement is not limited to a logical standby databases in the Data Guard environment. It is applicable to any Oracle database.

Resolving ITL Pressure

To increase the INITRANS integer for a particular database object, it is necessary to first stop SQL Apply.


See Also:

Oracle Database SQL Language Reference for more information about specifying the INITRANS integer, which it the initial number of concurrent transaction entries allocated within each data block allocated to the database object

The following example shows the necessary steps to increase the INITRANS for table load_tab_1 in the schema app.

  1. Stop SQL Apply:

    SQL> ALTER DATABASE STOP LOGICAL{ STANDBY APPLY;
    Database altered.
    
  2. Temporarily bypass the database guard:

    SQL> ALTER SESSION DISABLE GUARD;
    Session altered.
    
  3. Increase the INITRANS on the standby database. For example:

    SQL> ALTER TABLE APP.LOAD_TAB_1 INITRANS 30;
    Table altered
    
  4. Reenable the database guard:

    SQL> ALTER SESSION ENABLE GUARD;
    Session altered
    
  5. Start SQL Apply:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    Database altered.
    

Also, consider modifying the database object on the primary database, so in the event of a switchover, the error should not occur on the new standby database.

A.10.4 Troubleshooting ORA-1403 Errors with Flashback Transactions

If SQL Apply returns the ORA-1403: No Data Found error, then it may be possible to use Flashback Transaction to reconstruct the missing data. This is reliant upon the UNDO_RETENTION initialization parameter specified on the standby database instance.

Under normal circumstances, the ORA-1403 error should not be seen in a logical standby database environment. The error occurs when data in a table that is being managed by SQL Apply is modified directly on the standby database and then the same data is modified on the primary database. When the modified data is updated on the primary database and is subsequently received on the logical standby database, SQL Apply verifies the original version of the data is present on the standby database before updating the record. When this verification fails, the ORA-1403: No Data Found error is returned.

The Initial Error

When SQL Apply verification fails, the error message is reported in the alert log of the logical standby database and a record is inserted in the DBA_LOGSTDBY_EVENTS view.The information in the alert log is truncated, while the error is reported in it's entirety in the database view. For example:

LOGSTDBY stmt: UPDATE "SCOTT"."MASTER"
  SET
    "NAME" = 'john'
  WHERE 
    "PK" = 1 and 
    "NAME" = 'andrew' and 
    ROWID = 'AAAAAAAAEAAAAAPAAA'
LOGSTDBY status: ORA-01403: no data found
LOGSTDBY PID 1006, oracle@staco03 (P004)
LOGSTDBY XID 0x0006.00e.00000417, Thread 1, RBA 0x02dd.00002221.10

The Investigation

The first step is to analyze the historical data of the table that caused the error. This can be achieved using the VERSIONS clause of the SELECT statement. For example, you can issue the following query on the primary database:

SELECT VERSIONS_XID
      , VERSIONS_STARTSCN
      , VERSIONS_ENDSCN
      , VERSIONS_OPERATION
      , PK
      , NAME
   FROM SCOTT.MASTER
        VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE
  WHERE PK = 1
  ORDER BY NVL(VERSIONS_STARTSCN,0);

VERSIONS_XID     VERSIONS_STARTSCN VERSIONS_ENDSCN V  PK NAME
---------------- ----------------- --------------- - --- -------
03001900EE070000           3492279         3492290 I   1 andrew
02000D00E4070000           3492290                 D   1 andrew

Depending upon the amount of undo retention that the database is configured to retain (UNDO_RETENTION) and the activity on the table, the information returned might be extensive and you may need to change the versions between syntax to restrict the amount of information returned.From the information returned, it can be seen that the record was first inserted at SCN 3492279 and then was deleted at SCN 3492290 as part of transaction ID 02000D00E4070000.Using the transaction ID, the database should be queried to find the scope of the transaction. This is achieved by querying the FLASHBACK_TRANSACTION_QUERY view.

SELECT OPERATION
     , UNDO_SQL
  FROM FLASHBACK_TRANSACTION_QUERY
 WHERE XID = HEXTORAW('02000D00E4070000');

OPERATION  UNDO_SQL
---------- ------------------------------------------------
DELETE     insert into "SCOTT"."MASTER"("PK","NAME") values
           ('1','andrew');
BEGIN

Note that there is always one row returned representing the start of the transaction. In this transaction, only one row was deleted in the master table. The UNDO_SQL column when executed will restore the original data into the table.

SQL> INSERT INTO "SCOTT"."MASTER"("PK","NAME") VALUES ('1','ANDREW');SQL> COMMIT;

When you restart SQL Apply, the transaction will be applied to the standby database:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
PKS-{PKFJOEBPS/content.opf 6 Oracle® Data Guard Concepts and Administration, 11g Release 2 (11.2) en-US E41134-03 Oracle Corporation Oracle Corporation Oracle® Data Guard Concepts and Administration, 11g Release 2 (11.2) 2014-02-25T08:43:00Z Provides a comprehensive overview of Oracle Data Guard concepts and describes how to configure and implement standby databases that can take over production operations if your production database becomes unusable. This guide includes several database scenarios such as creating, recovering, failing over, switching over, configuring, and backing up standby and primary databases. PK PKFJOEBPS/rcmbackp.htmdL Creating a Standby Database with Recovery Manager

E Creating a Standby Database with Recovery Manager

This appendix describes how to use Oracle Recovery Manager to create a standby database. This appendix contains the following topics:

E.1 Prerequisites

This appendix assumes that you have read the chapter on database duplication in Oracle Database Backup and Recovery User's Guide. Because you use the DUPLICATE command to create a standby database with RMAN, you should familiarize yourself with the DUPLICATE command entry in Oracle Database Backup and Recovery Reference.

Familiarize yourself with how to create a standby database in Chapter 3, "Creating a Physical Standby Database" and Chapter 4, "Creating a Logical Standby Database" before you attempt the RMAN creation procedures described in this chapter.

E.2 Overview of Standby Database Creation with RMAN

This section explains the purpose and basic concepts involved in standby database creation with RMAN.

E.2.1 Purpose of Standby Database Creation with RMAN

You can use either manual techniques or the RMAN DUPLICATE command to create a standby database from backups of your primary database. Creating a standby database with RMAN has the following advantages over manual techniques:

  • RMAN can create a standby database by copying the files currently in use by the primary database. No backups are required.

  • RMAN can create a standby database by restoring backups of the primary database to the standby site. Thus, the primary database is not affected during the creation of the standby database.

  • RMAN automates renaming of files, including Oracle Managed Files (OMF) and directory structures.

  • RMAN restores archived redo log files from backups and performs media recovery so that the standby and primary databases are synchronized.

E.2.2 Basic Concepts of Standby Creation with RMAN

The procedure for creating a standby database with RMAN is almost the same as for creating a duplicate database. You need to amend the duplication procedures described in Oracle Database Backup and Recovery User's Guide to account for issues specific to a standby database.

To create a standby database with the DUPLICATE command you must connect as target to the primary database and specify the FOR STANDBY option. You cannot connect to a standby database and create an additional standby database. RMAN creates the standby database by restoring and mounting a control file. RMAN can use an existing backup of the primary database control file, so you do not need to create a control file backup especially for the standby database.

A standby database, unlike a duplicate database created by DUPLICATE without the FOR STANDBY OPTION, does not get a new DBID. Thus, you should not register the standby database with your recovery catalog.

E.2.2.1 Active Database and Backup-Based Duplication

You must choose between active and backup-based duplication. If you specify FROM ACTIVE DATABASE, then RMAN copies the datafiles directly from the primary database to the standby database. The primary database must be mounted or open.

If you not specify FROM ACTIVE DATABASE, then RMAN performs backup-based duplication. RMAN restores backups of the primary datafiles to the standby database. All backups and archived redo log files needed for creating and recovering the standby database must be accessible by the server session on the standby host. RMAN restores the most recent datafiles unless you execute the SET UNTIL command.

E.2.2.2 DB_UNIQUE_NAME Values in an RMAN Environment

A standby database, unlike a duplicate database created by DUPLICATE without the FOR STANDBY option, does not get a new DBID. When using RMAN in a Data Guard environment, you should always connect it to a recovery catalog. The recovery catalog can store the metadata for all primary and standby databases in the environment. You should not explicitly register the standby database in the recovery catalog.

A database in a Data Guard environment is uniquely identified by means of the DB_UNIQUE_NAME parameter in the initialization parameter file. The DB_UNIQUE_NAME must be unique across all the databases with the same DBID for RMAN to work correctly in a Data Guard environment.


See Also:

Oracle Database Backup and Recovery User's Guide for a conceptual overview of RMAN operation in a Data Guard environment

E.2.2.3 Recovery of a Standby Database

By default, RMAN does not recover the standby database after creating it. RMAN leaves the standby database mounted, but does not place the standby database in manual or managed recovery mode. RMAN disconnects and does not perform media recovery of the standby database.

If you want RMAN to recover the standby database after creating it, then the standby control file must be usable for the recovery. The following conditions must be met:

  • The end recovery time of the standby database must be greater than or equal to the checkpoint SCN of the standby control file.

  • An archived redo log file containing the checkpoint SCN of the standby control file must be available at the standby site for recovery.

One way to ensure these conditions are met is to issue the ALTER SYSTEM ARCHIVE LOG CURRENT statement after backing up the control file on the primary database. This statement archives the online redo log files of the primary database. Then, either back up the most recent archived redo log file with RMAN or move the archived redo log file to the standby site.

Use the DORECOVER option of the DUPLICATE command to specify that RMAN should recover the standby database. RMAN performs the following steps after creating the standby database files:

  1. RMAN begins media recovery. If recovery requires archived redo log files, and if the log files are not already on disk, then RMAN attempts to restore backups.

  2. RMAN recovers the standby database to the specified time, system change number (SCN), or log file sequence number, or to the latest archived redo log file generated if none of the preceding are specified.

  3. RMAN leaves the standby database mounted after media recovery is complete, but does not place the standby database in manual or managed recovery mode.

E.2.2.4 Standby Database Redo Log Files

RMAN automatically creates the standby redo log files on the standby database. After the log files are created, the standby database maintains and archives them according to the normal rules for log files.

If you use backup-based duplication, then the only option when naming the standby redo log files on the standby database is the file names for the log files, as specified in the standby control file. If the log file names on the standby must be different from the primary file names, then one option is to specify file names for the standby redo logs by setting LOG_FILE_NAME_CONVERT in the standby initialization parameter file.

Note the following restrictions when specifying file names for the standby redo log files on the standby database:

  • You must use the LOG_FILE_NAME_CONVERT parameter to name the standby redo log files if the primary and standby databases use different naming conventions for the log files.

  • You cannot use the SET NEWNAME or CONFIGURE AUXNAME commands to rename the standby redo log files.

  • You cannot use the LOGFILE clause of the DUPLICATE command to specify file names for the standby redo log files.

  • If you want the standby redo log file names on the standby database to be the same as the primary redo log file names, then you must specify the NOFILENAMECHECK clause of the DUPLICATE command. Otherwise, RMAN signals an error even if the standby database is created on a different host.

E.2.2.5 Password Files for the Standby Database

If you are using active database duplication, then RMAN always copies the password file to the standby host because the password file on the standby database must be an exact copy of the password file on the target database. In this case, the PASSWORD FILE clause is not necessary. RMAN overwrites any existing password file for the auxiliary instance. With backup-based duplication you must copy the password file used on the primary to the standby, for Data Guard to ship logs.

E.3 Using the DUPLICATE Command to Create a Standby Database

The procedure for creating a standby database is basically identical to the duplication procedure described in Oracle Database Backup and Recovery User's Guide.

E.3.1 Creating a Standby Database with Active Database Duplication

To create a standby database from files that are active in the primary database, specify both FOR STANDBY and FROM ACTIVE DATABASE. Optionally, specify the DORECOVER option to recover the database after standby creation.

This scenario assumes that the standby host and primary database host have the same directory structure.

To create a standby database from active database files:

  1. Prepare the auxiliary database instance as explained in Oracle Database Backup and Recovery User's Guide.

    Because you are using active database duplication, you must create a password file for the auxiliary instance and establish Oracle Net connectivity. This is a temporary password file as it will be overwritten during the duplicate operation.

  2. Decide how to provide names for the standby control files, datafiles, online redo logs, and tempfiles. This step is explained in Oracle Database Backup and Recovery User's Guide.

    In this scenario, the standby database files will be named the same as the primary database files.

  3. Start and configure RMAN as explained in Oracle Database Backup and Recovery User's Guide.

  4. Execute the DUPLICATE command.

    The following example illustrates how to use DUPLICATE for active duplication. This example requires the NOFILENAMECHECK option because the primary database files have the same names as the standby database files. The SET clauses for SPFILE are required for log shipping to work properly. The db_unique_name must be set to ensure that the catalog and Data Guard can identify this database as being different from the primary.

    DUPLICATE TARGET DATABASE
      FOR STANDBY
      FROM ACTIVE DATABASE
      DORECOVER
      SPFILE
        SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
        SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
         VALID_FOR=(online_logfile,primary_role)"
        SET FAL_SERVER="inst1" COMMENT "Is primary"
      NOFILENAMECHECK;
    

    RMAN automatically copies the server parameter file to the standby host, starts the auxiliary instance with the server parameter file, restores a backup control file, and copies all necessary database files and archived redo logs over the network to the standby host. RMAN recovers the standby database, but does not place it in manual or managed recovery mode.

E.3.2 Creating a Standby Database with Backup-Based Duplication

To create a standby database from backups, specify FOR STANDBY but do not specify FROM ACTIVE DATABASE. Optionally, specify the DORECOVER option to recover the database after standby creation.

This scenario assumes that the standby host and primary database host have the same directory structure.

To create a standby database from backups:

  1. Make database backups and archived redo logs available to the auxiliary instance on the duplicate host as explained in Oracle Database Backup and Recovery User's Guide.

  2. Prepare the auxiliary database instance as explained in Oracle Database Backup and Recovery User's Guide.

  3. Decide how to provide names for the standby control files, datafiles, online redo logs, and tempfiles. This step is explained in Oracle Database Backup and Recovery User's Guide.

    In this scenario, the standby database files will be named the same as the primary database files.

  4. Start and configure RMAN as explained in Oracle Database Backup and Recovery User's Guide.

  5. Execute the DUPLICATE command.

    The following example illustrates how to use DUPLICATE for backup-based duplication. This example requires the NOFILENAMECHECK option because the primary database files have the same names as the standby database files.

    DUPLICATE TARGET DATABASE
      FOR STANDBY
      DORECOVER
      SPFILE
        SET "db_unique_name"="foou" COMMENT ''Is a duplicate''
        SET LOG_ARCHIVE_DEST_2="service=inst3 ASYNC REGISTER
         VALID_FOR=(online_logfile,primary_role)"
        SET FAL_SERVER="inst1" COMMENT "Is primary"
      NOFILENAMECHECK;
    

    RMAN automatically copies the server parameter file to the standby host, starts the auxiliary instance with the server parameter file, and restores all necessary database files and archived redo logs to the standby host. RMAN recovers the standby database, but does not place it in manual or managed recovery mode.

PK5iLdLPKFJOEBPS/log_transport.htm Redo Transport Services

6 Redo Transport Services

This chapter describes how to configure and monitor Oracle redo transport services. The following topics are discussed:

6.1 Introduction to Redo Transport Services

Redo transport services performs the automated transfer of redo data between Oracle databases. The following redo transport destinations are supported:

  • Oracle Data Guard standby databases

    This guide describes how to create and manage standby databases.

  • Archive Log repository

    This destination type is used for temporary offsite storage of archived redo log files. An archive log repository consists of an Oracle database instance and a physical standby control file. An archive log repository does not contain datafiles, so it cannot support role transitions.

    The procedure used to create an archive log repository is identical to the procedure used to create a physical standby database, except for the copying of datafiles.

  • Oracle Streams downstream capture databases

    See Oracle Streams Concepts and Administration for more information about Oracle Streams downstream capture databases.

  • Oracle Change Data Capture staging databases

    See Oracle Warehouse Builder Sources and Targets Guide for more information about Oracle Change Data Capture staging databases.

An Oracle database can send redo data to up to thirty redo transport destinations. Each redo transport destination is individually configured to receive redo data via one of two redo transport modes:

  • Synchronous

    The synchronous redo transport mode transmits redo data synchronously with respect to transaction commitment. A transaction cannot commit until all redo generated by that transaction has been successfully sent to every enabled redo transport destination that uses the synchronous redo transport mode.

    Note that although there is no limit on the distance between a primary database and a SYNC redo transport destination, transaction commit latency increases as network latency increases between a primary database and a SYNC redo transport destination.

    This transport mode is used by the Maximum Protection and Maximum Availability data protection modes described in Chapter 5, "Data Guard Protection Modes".

  • Asynchronous

    The asynchronous redo transport mode transmits redo data asynchronously with respect to transaction commitment. A transaction can commit without waiting for the redo generated by that transaction to be successfully sent to any redo transport destination that uses the asynchronous redo transport mode.

    This transport mode is used by the Maximum Performance data protection mode described in Chapter 5, "Data Guard Protection Modes".

6.2 Configuring Redo Transport Services

This section describes how to configure redo transport services. The following topics are discussed:

The section is written at a level of detail that assumes that the reader has a thorough understanding of the following topics, which are described in the Oracle Database Administrator's Guide, Oracle Database Backup and Recovery User's Guide, and Oracle Database Net Services Administrator's Guide:

  • Database administrator authentication

  • Database initialization parameters

  • Managing a redo log

  • Managing archived redo logs

  • Fast recovery areas

  • Oracle Net Configuration

6.2.1 Redo Transport Security

Redo transport uses Oracle Net sessions to transport redo data. These redo transport sessions are authenticated using either the Secure Socket Layer (SSL) protocol or a remote login password file.

6.2.1.1 Redo Transport Authentication Using SSL

Secure Sockets Layer (SSL) is an industry standard protocol for securing network connections. SSL uses RSA public key cryptography and symmetric key cryptography to provide authentication, encryption, and data integrity. SSL is automatically used for redo transport authentication between two Oracle databases if:

  • The databases are members of the same Oracle Internet Directory (OID) enterprise domain and that domain allows the use of current user database links.

  • The LOG_ARCHIVE_DEST_n, and FAL_SERVER database initialization parameters that correspond to the databases use Oracle Net connect descriptors configured for SSL.

  • Each database has an Oracle wallet or a supported hardware security module that contains a user certificate with a distinguished name (DN) that matches the DN in the OID entry for the database.


See Also:


6.2.1.2 Redo Transport Authentication Using a Password File

If the SSL authentication requirements are not met, each database must use a remote login password file. In a Data Guard configuration, all physical and snapshot standby databases must use a copy of the password file from the primary database, and that copy must be refreshed whenever the SYSOPER or SYSDBA privilege is granted or revoked, and after the password of any user with these privileges is changed.

When a password file is used for redo transport authentication, the password of the user account used for redo transport authentication is compared between the database initiating a redo transport session and the target database. The password must be the same at both databases to create a redo transport session.

By default, the password of the SYS user is used to authenticate redo transport sessions when a password file is used. The REDO_TRANSPORT_USER database initialization parameter can be used to select a different user password for redo transport authentication by setting this parameter to the name of any user who has been granted the SYSOPER privilege. For administrative ease, Oracle recommends that the REDO_TRANSPORT_USER parameter be set to the same value on the redo source database and at each redo transport destination.


See Also:

Oracle Database Administrator's Guide for more information creating and maintaining remote login password files

6.2.2 Configuring an Oracle Database to Send Redo Data

This section describes how to configure an Oracle database to send redo data to a redo transport destination.

The LOG_ARCHIVE_DEST_n database initialization parameter (where n is an integer from 1 to 31) is used to specify the location of a local archive redo log or to specify a redo transport destination. This section describes the latter use of this parameter.

There is a LOG_ARCHIVE_DEST_STATE_n database initialization parameter (where n is an integer from 1 to 31) that corresponds to each LOG_ARCHIVE_DEST_n parameter. This parameter is used to enable or disable the corresponding redo destination. Table 6-1 shows the valid values that can be assigned to this parameter.

Table 6-1 LOG_ARCHIVE_DEST_STATE_n Initialization Parameter Values

ValueDescription

ENABLE

Redo transport services can transmit redo data to this destination. This is the default.

DEFER

Redo transport services will not transmit redo data to this destination.

ALTERNATE

This destination will become enabled if communication to its associated destination fails.


A redo transport destination is configured by setting the LOG_ARCHIVE_DEST_n parameter to a character string that includes one or more attributes. This section briefly describes the most commonly used attributes. See Chapter 15 for a full description of all LOG_ARCHIVE_DEST_n parameter attributes.

The SERVICE attribute, which is a mandatory attribute for a redo transport destination, must be the first attribute specified in the attribute list. The SERVICE attribute is used to specify the Oracle Net service name used to connect to the redo transport destination. The service name must be resolvable through an Oracle Net naming method to an Oracle Net connect descriptor that matches the Oracle Net listener(s) at the redo transport destination. The connect descriptor must specify that a dedicated server connection be used, unless that is the default connection type for the redo transport destination.


See Also:

Oracle Database Net Services Administrator's Guide for information about Oracle Net service names, connect descriptors, listeners, and network security

The SYNC attribute is used to specify that the synchronous redo transport mode be used to send redo data to a redo transport destination.

The ASYNC attribute is used to specify that the asynchronous redo transport mode be used to send redo data to a redo transport destination. The asynchronous redo transport mode will be used if neither the SYNC nor the ASYNC attribute is specified.

The NET_TIMEOUT attribute is used to specify how long the LGWR process will block waiting for an acknowledgement that redo data has been successfully received by a destination that uses the synchronous redo transport mode. If an acknowledgement is not received within NET_TIMEOUT seconds, the redo transport connection is terminated and an error is logged.

Oracle recommends that the NET_TIMEOUT attribute be specified whenever the synchronous redo transport mode is used, so that the maximum duration of a redo source database stall caused by a redo transport fault can be precisely controlled. See Section 6.4.2 for information about monitoring synchronous redo transport mode response time.

The AFFIRM attribute is used to specify that redo received from a redo source database is not acknowledged until it has been written to the standby redo log. The NOAFFIRM attribute is used to specify that received redo is acknowledged without waiting for received redo to be written to the standby redo log.

The DB_UNIQUE_NAME attribute is used to specify the DB_UNIQUE_NAME of a redo transport destination. The DB_UNIQUE_NAME attribute must be specified if the LOG_ARCHIVE_CONFIG database initialization parameter has been defined and its value includes a DG_CONFIG list.

If the DB_UNIQUE_NAME attribute is specified, its value must match one of the DB_UNIQUE_NAME values in the DG_CONFIG list. It must also match the value of the DB_UNIQUE_NAME database initialization parameter at the redo transport destination. If either match fails, an error is logged and redo transport will not be possible to that destination.

The VALID_FOR attribute is used to specify when redo transport services transmits redo data to a redo transport destination. Oracle recommends that the VALID_FOR attribute be specified for each redo transport destination at every site in a Data Guard configuration so that redo transport services will continue to send redo data to all standby databases after a role transition, regardless of which standby database assumes the primary role.

The REOPEN attribute is used to specify the minimum number of seconds between automatic reconnect attempts to a redo transport destination that is inactive because of a previous error.

The COMPRESSION attribute is used to specify that redo data is transmitted to a redo transport destination in compressed form. Redo transport compression can significantly improve redo transport performance on network links with low bandwidth and high latency.

Redo transport compression is a feature of the Oracle Advanced Compression option. You must purchase a license for this option before using the redo transport compression feature.

The following example uses all of the LOG_ARCHIVE_DEST_n attributes described in this section. A DB_UNIQUE_NAME has been specified for both destinations, as has the use of compression. If a redo transport fault occurs at either destination, redo transport will attempt to reconnect to that destination, but not more frequently than once every 60 seconds.

DB_UNIQUE_NAME=BOSTON
LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)' 
LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE, 
PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE  DB_UNIQUE_NAME=CHICAGO' 
LOG_ARCHIVE_DEST_STATE_2='ENABLE' 
LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30 
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE   
DB_UNIQUE_NAME=HARTFORD' 
LOG_ARCHIVE_DEST_STATE_3='ENABLE'

6.2.2.1 Viewing Attributes With V$ARCHIVE_DEST

The V$ARCHIVE_DEST view can be queried to see the current settings and status for each redo transport destination.

6.2.3 Configuring an Oracle Database to Receive Redo Data

This section describes how to configure a redo transport destination to receive and to archive redo data from a redo source database.

The following topics are discussed:

6.2.3.1 Creating and Managing a Standby Redo Log

The synchronous and asynchronous redo transport modes require that a redo transport destination have a standby redo log. A standby redo log is used to store redo received from another Oracle database. Standby redo logs are structurally identical to redo logs, and are created and managed using the same SQL statements used to create and manage redo logs.

Redo received from another Oracle database via redo transport is written to the current standby redo log group by an RFS foreground process. When a log switch occurs on the redo source database, incoming redo is then written to the next standby redo log group, and the previously used standby redo log group is archived by an ARCn foreground process.

The process of sequentially filling and then archiving redo log file groups at a redo source database is mirrored at each redo transport destination by the sequential filling and archiving of standby redo log groups.

Each standby redo log file must be at least as large as the largest redo log file in the redo log of the redo source database. For administrative ease, Oracle recommends that all redo log files in the redo log at the redo source database and the standby redo log at a redo transport destination be of the same size.

The standby redo log must have at least one more redo log group than the redo log at the redo source database, for each redo thread at the redo source database. At the redo source database, query the V$LOG view to determine how many redo log groups are in the redo log at the redo source database and query the V$THREAD view to determine how many redo threads exist at the redo source database.

Perform the following query on a redo source database to determine the size of each log file and the number of log groups in the redo log:

SQL> SELECT GROUP#, BYTES FROM V$LOG;

Perform the following query on a redo destination database to determine the size of each log file and the number of log groups in the standby redo log:

SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;

Oracle recommends that a standby redo log be created on the primary database in a Data Guard configuration so that it is immediately ready to receive redo data following a switchover to the standby role.

The ALTER DATABASE ADD STANDBY LOGFILE SQL statement is used to create a standby redo log and to add standby redo log groups to an existing standby redo log.

For example, assume that the redo log on the redo source database has two redo log groups and that each of those contain one 500 MB redo log file. In this case, the standby redo log should have at least 3 standby redo log groups to satisfy the requirement that a standby redo log must have at least one more redo log group than the redo log at the redo source database.

The following SQL statements might be used to create a standby redo log that is appropriate for the previous scenario:

SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog1.rdo') SIZE 500M;
 
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog2.rdo') SIZE 500M;
 
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog3.rdo') SIZE 500M;

If the redo source database is an Oracle Real Applications Cluster (Oracle RAC) or Oracle One Node database, query the V$LOG view at the redo source database to determine how many redo threads exist and specify the corresponding thread numbers when adding redo log groups to the standby redo log.

For example, the following SQL statements might be used to create a standby redo log at a database that is to receive redo from a redo source database that has two redo threads:

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 500M;

Caution:

Whenever a redo log group is added to a primary database, a log group must also be added to the standby redo log of each standby database in the configuration. Otherwise, the standby database may become unsynchronized after a primary log switch, which could temporarily prevent a zero data loss failover or cause a primary database operating in maximum protection mode to shut down.

6.2.3.2 Configuring Standby Redo Log Archival

This section describes how to configure standby redo log archival.


See Also:


6.2.3.2.1 Enable Archiving

If archiving is not enabled, issue the following statements to put the database in ARCHIVELOG mode and to enable automatic archiving:

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;

Note that the database must be in ARCHIVELOG mode for standby redo log archival to be performed.

6.2.3.2.2 Standby Redo Log Archival to a fast recovery area

Take the following steps to set up standby redo log archival to a fast recovery area:

  1. Set the LOCATION attribute of a LOG_ARCHIVE_DEST_n parameter to USE_DB_RECOVERY_FILE_DEST.

  2. Set the VALID_FOR attribute of the same LOG_ARCHIVE_DEST_n parameter to a value that allows standby redo log archival.

The following are some sample parameter values that might be used to configure a physical standby database to archive its standby redo log to the fast recovery area:

LOG_ARCHIVE_DEST_2 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

Oracle recommends the use of a fast recovery area, because it simplifies the management of archived redo log files.

6.2.3.2.3 Standby Redo Log Archival to a Local FIle System Location

Take the following steps to set up standby redo log archival to a local file system location:

  1. Set the LOCATION attribute of a LOG_ARCHIVE_DEST_n parameter to a valid pathname.

  2. Set the VALID_FOR attribute of the same LOG_ARCHIVE_DEST_n parameter to a value that allows standby redo log archival.

The following are some sample parameter values that might be used to configure a physical standby database to archive its standby redo log to a local file system location:

LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive
VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

6.2.3.3 Cases Where Redo Is Written Directly To an Archived Redo Log File

Redo received by a standby database is written directly to an archived redo log file if a standby redo log group is not available or if the redo was sent to resolve a redo gap. When this occurs, redo is written to the location specified by the LOCATION attribute of one LOG_ARCHIVE_DEST_n parameter that is valid for archiving redo received from another database. The LOG_ARCHIVE_DEST_n parameter that is used for this purpose is determined when the standby database is mounted, and this choice is reevaluated each time a LOG_ARCHIVE_DEST_n parameter is modified.

6.3 Cascaded Redo Transport Destinations


Note:

To use the Oracle Data Guard cascading redo transport destination feature described in this section, you should be using Oracle Database 11g Release 2 (11.2.0.2) or higher. Releases prior to 1]k1.2.0.2 have several limitations for this feature that are not present in release 11.2.0.2 and higher.

A cascaded redo transport destination receives primary database redo indirectly from a standby database rather than directly from a primary database.

A standby database that cascades primary database redo to one or more cascaded destinations is known as a cascading standby database.

Cascading offloads the overhead associated with performing redo transport from a primary database to a cascading standby database.

A cascading standby database can cascade primary database redo to up to 30 cascaded destinations, each of which can be a physical, logical, or snapshot standby database.

Primary database redo is written to the standby redo log as it is received at a cascading standby database. The redo is not immediately cascaded however. It is cascaded after the standby redo log file that it was written to has been archived locally. A cascaded destination will therefore always have a greater redo transport lag, with respect to the primary database, than the cascading standby database.

Cascading has the following restrictions:

  • A physical standby database is the only standby database type that can cascade redo

  • The Data Guard broker does not support cascaded destinations

The rest of this section contains the following information:

6.3.1 Configuring a Cascaded Destination

Perform the following steps to configure a cascaded destination:

  1. Select a physical standby database to configure as a cascading standby database.

  2. On the cascading standby database, configure the FAL_SERVER attribute with the Oracle Net alias of the primary database or of a standby database that receives redo directly from the primary database.

  3. On the cascading standby database, configure a LOG_ARCHIVE_DEST_n database initialization parameter for the cascaded destination. Configure the SERVICE attribute of this destination with the Oracle Net alias of the cascaded destination, and the VALID attribute to be valid for archival of the standby redo log while in the standby role.

    If the SYNC or ASYNC redo transport attributes are specified, they are ignored.

  4. At the cascaded destination, configure the FAL_SERVER database initialization parameter with the Oracle Net alias of the cascading standby database or of another standby database that is directly connected to the primary database. Although it is also possible to specify the primary database, this would defeat the purpose of cascading, which is to reduce the redo transport overhead on the primary database.

  5. Example 6-1 shows some of the database initialization parameters used by the members of a Data Guard configuration that includes a primary database named boston that sends redo to a local physical standby database named boston2, which then cascades primary database redo to a remote physical standby database named denver.

    Note that a LOG_ARCHIVE_DEST_n database initialization parameter could also be configured on database boston that is valid for standby redo log archival to database denver when database boston is in the standby role. This would allow redo cascading to database denver to continue if a switchover is performed between database boston and database boston2.

Example 6-1 Some of the Initialization Parameters Used When Cascading Redo

Primary Database

DB_UNIQUE_NAME=boston
 
FAL_SERVER=boston2
 
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'
 
LOG_ARCHIVE_DEST_2='SERVICE=boston2 SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston2'

Cascading Physical Standby Database

DB_UNIQUE_NAME=boston2
 
FAL_SERVER=boston
 
LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(boston,boston2,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston2'
 
LOG_ARCHIVE_DEST_2= 'SERVICE=denver
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
 

Cascaded Physical Standby Database

DB_UNIQUE_NAME=denver
 
FAL_SERVER=boston2
 
LOG_ARCHIVE_CONFIG='DG_CONFIG=(boston,boston2,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'

6.3.2 Data Protection Considerations

Oracle recommends that a standby database primarily intended for disaster recovery purposes receive redo data directly from the primary database. This will result in the highest level of data protection. A cascaded standby database can be used as a second line of defense, but by definition it will always have received less primary database redo than a standby database that is receiving redo directly from the primary.

6.3.3 Cascading Scenarios

This section describes two typical cascading scenarios

6.3.3.1 Cascading to a Physical Standby

In this scenario, you have a mission-critical primary database. This database has stringent performance and data protection requirements, so you have decided to deploy a local physical standby database to provide zero data loss protection and a remote, cascaded physical standby database to protect against regional disasters at the primary and local standby database sites.

You can achieve the objectives described above by performing the following steps:

  1. Create a physical standby database at a local site.

  2. Create a physical standby database at a site that is sufficiently remote to provide protection against a regional disasters at the primary and local standby database sites.

  3. Configure the local standby database as a SYNC redo transport destination of the primary database.

  4. Configure the remote physical standby database as a cascaded destination of the local standby database.

6.3.3.2 Cascading to Multiple Physical Standbys

In this scenario, you have a primary database in North America and you wish to deploy three replicas of this database in Europe to support read-only reporting applications. For cost and performance reasons, you do not wish to maintain network links from North America to each of your European sites.

You can achieve the objectives described above by performing the following steps:

  1. Create a network link between your North American site and one of your European sites.

  2. Create a physical standby database at each of your European sites.

  3. Open your physical standby databases in real-time query mode, as described in Section 9.2.

  4. Configure the physical standby database at the European endpoint of your transatlantic network link to cascade redo to your other European standby databases.

  5. Configure the physical standby database at the European endpoint of your transatlantic network link as a cascaded destination of your primary database.

6.4 Monitoring Redo Transport Services

This section discusses the following topics:

6.4.1 Monitoring Redo Transport Status

This section describes the steps used to monitor redo transport status on a redo source database.

Step 1   Determine the most recently archived redo log file.

Perform the following query on the redo source database to determine the most recently archived sequence number for each thread:

SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG -
> WHERE RESETLOGS_CHANGE# = (SELECT MAX(RESETLOGS_CHANGE#) FROM V$ARCHIVED_LOG) -
> GROUP BY THREAD#;
Step 2   Determine the most recently archived redo log file at each redo transport destination.

Perform the following query on the redo source database to determine the most recently archived redo log file at each redo transport destination:

SQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ# -
> FROM V$ARCHIVE_DEST_STATUS -
> WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE';
 
DESTINATION         STATUS  ARCHIVED_THREAD#  ARCHIVED_SEQ#
------------------  ------  ----------------  -------------
/private1/prmy/lad   VALID                 1            947
standby1             VALID                 1            947

The most recently archived redo log file should be the same for each destination. If it is not, a status other than VALID may identify an error encountered during the archival operation to that destination.

Step 3   Find out if archived redo log files have been received at a redo transport destination.

A query can be performed at a redo source database to find out if an archived redo log file has been received at a particular redo transport destination. Each destination has an ID number associated with it. You can query the DEST_ID column of the V$ARCHIVE_DEST view on a database to identify each destination's ID number.

Assume that destination 1 points to the local archived redo log and that destination 2 points to a redo transport destination. Perform the following query at the redo source database to find out if any log files are missing at the redo transport destination:

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM -
> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) -
> LOCAL WHERE -
> LOCAL.SEQUENCE# NOT IN -
> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND -
> THREAD# = LOCAL.THREAD#);
 
THREAD#    SEQUENCE#
---------  ---------
  1        12
  1        13
  1        14
Step 4   Trace the progression of redo transmitted to a redo transport destination.

Set the LOG_ARCHIVE_TRACE database initialization parameter at a redo source database and at each redo transport destination to trace redo transport progress. See Appendix F for complete details and examples.

6.4.2 Monitoring Synchronous Redo Transport Response Time

The V$REDO_DEST_RESP_HISTOGRAM view contains response time data for each redo transport destination. This response time data is maintained for redo transport messages sent via the synchronous redo transport mode.

The data for each destination consists of a series of rows, with one row for each response time. To simplify record keeping, response times are rounded up to the nearest whole second for response times less than 300 seconds. Response times greater than 300 seconds are round up to 600, 1200, 2400, 4800, or 9600 seconds.

Each row contains four columns: FREQUENCY, DURATION, DEST_ID, and TIME.

The FREQUENCY column contains the number of times that a given response time has been observed. The DURATION column corresponds to the response time. The DEST_ID column identifies the destination. The TIME column contains a timestamp taken when the row was last updated.

The response time data in this view is useful for identifying synchronous redo transport mode performance issues that can affect transaction throughput on a redo source database. It is also useful for tuning the NET_TIMEOUT attribute.

The next three examples show example queries for destination 2, which corresponds to the LOG_ARCHIVE_DEST_2 parameter. To display response time data for a different destination, simply change the DEST_ID in the query.

Perform the following query on a redo source database to display the response time histogram for destination 2:

SQL> SELECT FREQUENCY, DURATION FROM -
> V$REDO_DEST_RESP_HISTOGRAM WHERE DEST_ID=2 AND FREQUENCY>1;

Perform the following query on a redo source database to display the slowest response time for destination 2:

SQL> SELECT max(DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM -
> WHERE DEST_ID=2 AND FREQUENCY>1;

Perform the following query on a redo source database to display the fastest response time for destination 2:

SQL> SELECT min( DURATION) FROM V$REDO_DEST_RESP_HISTOGRAM -
> WHERE DEST_ID=2 AND FREQUENCY>1;

Note:

The highest observed response time for a destination cannot exceed the highest specified NET_TIMEOUT value specified for that destination, because synchronous redo transport mode sessions are terminated if a redo transport destination does not respond to a redo transport message within NET_TIMEOUT seconds.

6.4.3 Redo Gap Detection and Resolution

A redo gap occurs whenever redo transmission is interrupted. When redo transmission resumes, redo transport services automatically detects the redo gap and resolves it by sending the missing redo to the destination.

The time needed to resolve a redo gap is directly proportional to the size of the gap and inversely proportional to the effective throughput of the network link between the redo source database and the redo transport destination. Redo transport services has two options that may reduce redo gap resolution time when low performance network links are used:

  • Redo Transport Compression

    The COMPRESSION attribute of the LOG_ARCHIVE_DEST_n parameter is used to specify that redo data be compressed before transmission to the destination.

  • Parallel Redo Transport Network Sessions

    The MAX_CONNECTIONS attribute of the LOG_ARCHIVE_DEST_n parameter can be used to specify that more than one network session be used to send the redo needed to resolve a redo gap.

See Chapter 15, "LOG_ARCHIVE_DEST_n Parameter Attributes" for more information about the COMPRESSION and MAX_CONNECTIONS attributes.

6.4.3.1 Manual Gap Resolution

In some situations, gap resolution cannot be performed automatically and it must be performed manually. For example, redo gap resolution must be performed manually on a logical standby database if the primary database is unavailable.

Perform the following query at the physical standby database to determine if there is redo gap on a physical standby database:

SQL> SELECT * FROM V$ARCHIVE_GAP;

    THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
-----------  -------------  --------------
          1              7              10

The output from the previous example indicates that the physical standby database is currently missing log files from sequence 7 to sequence 10 for thread 1.

Perform the following query on the primary database to locate the archived redo log files on the primary database (assuming the local archive destination on the primary database is LOG_ARCHIVE_DEST_1):

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND -
> DEST_ID=1 AND SEQUENCE# BETWEEN 7 AND 10;

NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc 
/primary/thread1_dest/arcr_1_8.arc 
/primary/thread1_dest/arcr_1_9.arc

Note:

This query may return consecutive sequences for a given thread. In that case, there is no actual gap, but the associated thread was disabled and enabled within the time period of generating these two archived logs. The query also does not identify the gap that may exist at the tail end for a given thread. For instance, if the primary database has generated archived logs up to sequence 100 for thread 1, and the latest archived log that the logical standby database has received for the given thread is the one associated with sequence 77, this query will not return any rows, although we have a gap for the archived logs associated with sequences 78 to 100.

Copy these log files to the physical standby database and register them using the ALTER DATABASE REGISTER LOGFILE. For example:

SQL> ALTER DATABASE REGISTER LOGFILE -
> '/physical_standby1/thread1_dest/arcr_1_7.arc';

SQL> ALTER DATABASE REGISTER LOGFILE -
> '/physical_standby1/thread1_dest/arcr_1_8.arc';

SQL> ALTER DATABASE REGISTER LOGFILE -
> '/physical_standby1/thread1_dest/arcr_1_9.arc';

Note:

The V$ARCHIVE_GAP view on a physical standby database only returns the gap that is currently blocking Redo Apply from continuing. After resolving the gap, query the V$ARCHIVE_GAP view again on the physical standby database to determine if there is another gap sequence. Repeat this process until there are no more gaps.

To determine if there is a redo gap on a logical standby database, query the DBA_LOGSTDBY_LOG view on the logical standby database. For example, the following query indicates there is a gap in the sequence of archived redo log files because it displays two files for THREAD 1 on the logical standby database. (If there are no gaps, the query will show only one file for each thread.) The output shows that the highest registered file is sequence number 10, but there is a gap at the file shown as sequence number 6:

SQL> COLUMN FILE_NAME FORMAT a55
SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L -
> WHERE NEXT_CHANGE# NOT IN -
> (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) -
> ORDER BY THREAD#, SEQUENCE#;
 
   THREAD#  SEQUENCE# FILE_NAME
---------- ---------- -----------------------------------------------
         1          6 /disk1/oracle/dbs/log-1292880008_6.arc
         1         10 /disk1/oracle/dbs/log-1292880008_10.arc

Copy the missing log files, with sequence numbers 7, 8, and 9, to the logical standby system and register them using the ALTER DATABASE REGISTER LOGICAL LOGFILE statement. For example:

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE -
> '/disk1/oracle/dbs/log-1292880008_7.arc'; 

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE -
> '/disk1/oracle/dbs/log-1292880008_8.arc';

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE -
> '/disk1/oracle/dbs/log-1292880008_9.arc';

Note:

A query based on the DBA_LOGSTDBY_LOG view on a logical standby database, as specified above, only returns the gap that is currently blocking SQL Apply from continuing. After resolving the gap, query the DBA_LOGSTDBY_LOG view again on the logical standby database to determine if there is another gap sequence. Repeat this process until there are no more gaps.

6.4.4 Redo Transport Services Wait Events

Table 6-2 lists several of the Oracle wait events used to track redo transport wait time on a redo source database. These wait events are found in the V$SYSTEM_EVENT dynamic performance view.

For a complete list of the Oracle wait events used by redo transport, see the Oracle Data Guard Redo Transport and Network Best Practices white paper on the Oracle Maximum Availability Architecture (MAA) home page at:

http://www.oracle.com/goto/maa

Table 6-2 Redo Transport Wait Events

Wait EventDescription

LNS wait on ATTACH

Total time spent waiting for redo transport sessions to be established to all ASYNC and SYNC redo transport destinations

LNS wait on SENDREQ

Total time spent waiting for redo data to be written to all ASYNC and SYNC redo transport destinations

LNS wait on DETACH

Total time spent waiting for redo transport connections to be terminated to all ASYNC and SYNC redo transport destinations


6.5 Tuning Redo Transport

The Oracle Data Guard Redo Transport and Network Configuration Best Practices white paper describes how to optimize redo transport for best performance. This paper is available on the Oracle Maximum Availability Architecture (MAA) home page at:

http://www.oracle.com/goto/maa

PK%1g]PKFJOEBPS/partpage2.htms Reference

Part II

Reference

This part provides reference material to be used in conjunction with the Oracle Data Guard standby database features. For more complete reference material, refer to the Oracle Database 10g documentation set.

This part contains the following chapters:

PKxsPKFJ OEBPS/loe.htm , List of Examples PKix PKFJOEBPS/dcommon/blafdoc.cssc@charset "utf-8"; /* Copyright 2002, 2011, Oracle and/or its affiliates. All rights reserved. Author: Robert Crews Version: 2011.8.12 */ body { font-family: Tahoma, sans-serif; /* line-height: 125%; */ color: black; background-color: white; font-size: small; } * html body { /* http://www.info.com.ph/~etan/w3pantheon/style/modifiedsbmh.html */ font-size: x-small; /* for IE5.x/win */ f\ont-size: small; /* for other IE versions */ } h1 { font-size: 165%; font-weight: bold; border-bottom: 1px solid #ddd; width: 100%; text-align: left; } h2 { font-size: 152%; font-weight: bold; text-align: left; } h3 { font-size: 139%; font-weight: bold; text-align: left; } h4 { font-size: 126%; font-weight: bold; text-align: left; } h5 { font-size: 113%; font-weight: bold; display: inline; text-align: left; } h6 { font-size: 100%; font-weight: bold; font-style: italic; display: inline; text-align: left; } a:link { color: #039; background: inherit; } a:visited { color: #72007C; background: inherit; } a:hover { text-decoration: underline; } a img, img[usemap] { border-style: none; } code, pre, samp, tt { font-family: monospace; font-size: 110%; } caption { text-align: center; font-weight: bold; width: auto; } dt { font-weight: bold; } table { font-size: small; /* for ICEBrowser */ } td { vertical-align: top; } th { font-weight: bold; text-align: left; vertical-align: bottom; } li { text-align: left; } dd { text-align: left; } ol ol { list-style-type: lower-alpha; } ol ol ol { list-style-type: lower-roman; } td p:first-child, td pre:first-child { margin-top: 0px; margin-bottom: 0px; } table.table-border { border-collapse: collapse; border-top: 1px solid #ccc; border-left: 1px solid #ccc; } table.table-border th { padding: 0.5ex 0.25em; color: black; background-color: #f7f7ea; border-right: 1px solid #ccc; border-bottom: 1px solid #ccc; } table.table-border td { padding: 0.5ex 0.25em; border-right: 1px solid #ccc; border-bottom: 1px solid #ccc; } span.gui-object, span.gui-object-action { font-weight: bold; } span.gui-object-title { } p.horizontal-rule { width: 100%; border: solid #cc9; border-width: 0px 0px 1px 0px; margin-bottom: 4ex; } div.zz-skip-header { display: none; } td.zz-nav-header-cell { text-align: left; font-size: 95%; width: 99%; color: black; background: inherit; font-weight: normal; vertical-align: top; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-header-link { font-size: 95%; } td.zz-nav-button-cell { white-space: nowrap; text-align: center; width: 1%; vertical-align: top; padding-left: 4px; padding-right: 4px; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-button-link { font-size: 90%; } div.zz-nav-footer-menu { width: 100%; text-align: center; margin-top: 2ex; margin-bottom: 4ex; } p.zz-legal-notice, a.zz-legal-notice-link { font-size: 85%; /* display: none; */ /* Uncomment to hide legal notice */ } /*************************************/ /* Begin DARB Formats */ /*************************************/ .bold, .codeinlinebold, .syntaxinlinebold, .term, .glossterm, .seghead, .glossaryterm, .keyword, .msg, .msgexplankw, .msgactionkw, .notep1, .xreftitlebold { font-weight: bold; } .italic, .codeinlineitalic, .syntaxinlineitalic, .variable, .xreftitleitalic { font-style: italic; } .bolditalic, .codeinlineboldital, .syntaxinlineboldital, .titleinfigure, .titleinexample, .titleintable, .titleinequation, .xreftitleboldital { font-weight: bold; font-style: italic; } .itemizedlisttitle, .orderedlisttitle, .segmentedlisttitle, .variablelisttitle { font-weight: bold; } .bridgehead, .titleinrefsubsect3 { font-weight: bold; } .titleinrefsubsect { font-size: 126%; font-weight: bold; } .titleinrefsubsect2 { font-size: 113%; font-weight: bold; } .subhead1 { display: block; font-size: 139%; font-weight: bold; } .subhead2 { display: block; font-weight: bold; } .subhead3 { font-weight: bold; } .underline { text-decoration: underline; } .superscript { vertical-align: super; } .subscript { vertical-align: sub; } .listofeft { border: none; } .betadraft, .alphabetanotice, .revenuerecognitionnotice { color: #f00; background: inherit; } .betadraftsubtitle { text-align: center; font-weight: bold; color: #f00; background: inherit; } .comment { color: #080; background: inherit; font-weight: bold; } .copyrightlogo { text-align: center; font-size: 85%; } .tocsubheader { list-style-type: none; } table.icons td { padding-left: 6px; padding-right: 6px; } .l1ix dd, dd dl.l2ix, dd dl.l3ix { margin-top: 0ex; margin-bottom: 0ex; } div.infoboxnote, div.infoboxnotewarn, div.infoboxnotealso { margin-top: 4ex; margin-right: 10%; margin-left: 10%; margin-bottom: 4ex; padding: 0.25em; border-top: 1pt solid gray; border-bottom: 1pt solid gray; } p.notep1 { margin-top: 0px; margin-bottom: 0px; } .tahiti-highlight-example { background: #ff9; text-decoration: inherit; } .tahiti-highlight-search { background: #9cf; text-decoration: inherit; } .tahiti-sidebar-heading { font-size: 110%; margin-bottom: 0px; padding-bottom: 0px; } /*************************************/ /* End DARB Formats */ /*************************************/ @media all { /* * * { line-height: 120%; } */ dd { margin-bottom: 2ex; } dl:first-child { margin-top: 2ex; } } @media print { body { font-size: 11pt; padding: 0px !important; } a:link, a:visited { color: black; background: inherit; } code, pre, samp, tt { font-size: 10pt; } #nav, #search_this_book, #comment_form, #comment_announcement, #flipNav, .noprint { display: none !important; } body#left-nav-present { overflow: visible !important; } } PKr.hcPKFJOEBPS/dcommon/oracle-logo.jpgm JFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222'7" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQE!KEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEzE7V%ȣOΏ9??:a"\fSrğjAsKJ:nOzO=}E1-I)3(QEQEQEQEQEQEQE֝Hza<["2"pO#f8M[RL(,?g93QSZ uy"lx4h`O!LŏʨXZvq& c՚]+: ǵ@+J]tQ]~[[eϸ (]6A&>ܫ~+כzmZ^(<57KsHf妬Ϧmnẁ&F!:-`b\/(tF*Bֳ ~V{WxxfCnMvF=;5_,6%S>}cQQjsOO5=)Ot [W9 /{^tyNg#ЄGsֿ1-4ooTZ?K Gc+oyڙoNuh^iSo5{\ܹ3Yos}$.nQ-~n,-zr~-|K4R"8a{]^;I<ȤL5"EԤP7_j>OoK;*U.at*K[fym3ii^#wcC'IIkIp$󿉵|CtĈpW¹l{9>⪦׺*ͯj.LfGߍԁw] |WW18>w.ӯ! VӃ :#1~ +މ=;5c__b@W@ +^]ևՃ7 n&g2I8Lw7uҭ$"&"b eZ":8)D'%{}5{; w]iu;_dLʳ4R-,2H6>½HLKܹR ~foZKZ࿷1[oZ7׫Z7R¢?«'y?A}C_iG5s_~^ J5?œ tp]X/c'r%eܺA|4ծ-Ե+ْe1M38Ǯ `|Kյ OVڅu;"d56, X5kYR<̭CiطXԮ];Oy)OcWj֩}=܅s۸QZ*<~%뺃ȶp f~Bðzb\ݳzW*y{=[ C/Ak oXCkt_s}{'y?AmCjޓ{ WRV7r. g~Q"7&͹+c<=,dJ1V߁=T)TR՜*N4 ^Bڥ%B+=@fE5ka}ędܤFH^i1k\Sgdk> ֤aOM\_\T)8靠㡮3ģR: jj,pk/K!t,=ϯZ6(((((((49 xn_kLk&f9sK`zx{{y8H 8b4>ÇНE|7v(z/]k7IxM}8!ycZRQ pKVr(RPEr?^}'ðh{x+ՀLW154cK@Ng C)rr9+c:׹b Жf*s^ fKS7^} *{zq_@8# pF~ [VPe(nw0MW=3#kȵz晨cy PpG#W:%drMh]3HH<\]ԁ|_W HHҡb}P>k {ZErxMX@8C&qskLۙOnO^sCk7ql2XCw5VG.S~H8=(s1~cV5z %v|U2QF=NoW]ո?<`~׮}=ӬfԵ,=;"~Iy7K#g{ñJ?5$y` zz@-~m7mG宝Gٱ>G&K#]؃y1$$t>wqjstX.b̐{Wej)Dxfc:8)=$y|L`xV8ߙ~E)HkwW$J0uʟk>6Sgp~;4֌W+חc"=|ř9bc5> *rg {~cj1rnI#G|8v4wĿhFb><^ pJLm[Dl1;Vx5IZ:1*p)إ1ZbAK(1ׅ|S&5{^ KG^5r>;X׻K^? s fk^8O/"J)3K]N)iL?5!ƾq:G_=X- i,vi2N3 |03Qas ! 7}kZU781M,->e;@Qz T(GK(ah(((((((Y[×j2F}o־oYYq $+]%$ v^rϭ`nax,ZEuWSܽ,g%~"MrsrY~Ҿ"Fت;8{ѰxYEfP^;WPwqbB:c?zp<7;SBfZ)dϛ; 7s^>}⍱x?Bix^#hf,*P9S{w[]GF?1Z_nG~]kk)9Sc5Ո<<6J-ϛ}xUi>ux#ţc'{ᛲq?Oo?x&mѱ'#^t)ϲbb0 F«kIVmVsv@}kҡ!ˍUTtxO̧]ORb|2yԵk܊{sPIc_?ħ:Ig)=Z~' "\M2VSSMyLsl⺿U~"C7\hz_ Rs$~? TAi<lO*>U}+'f>7_K N s8g1^CeКÿE ;{+Y\ O5|Y{/o+ LVcO;7Zx-Ek&dpzbӱ+TaB0gNy׭ 3^c T\$⫫?F33?t._Q~Nln:U/Ceb1-im WʸQM+VpafR3d׫é|Aү-q*I P7:y&]hX^Fbtpܩ?|Wu󭏤ʫxJ3ߴm"(uqA}j.+?S wV ~ [B&<^U?rϜ_OH\'.;|.%pw/ZZG'1j(#0UT` Wzw}>_*9m>󑓀F?EL3"zpubzΕ$+0܉&3zڶ+jyr1QE ( ( ( ( ( ( ( (UIdC0EZm+]Y6^![ ԯsmܶ捆?+me+ZE29)B[;я*wGxsK7;5w)}gH~.Ɣx?X\ߚ}A@tQ(:ͧ|Iq(CT?v[sKG+*רqҍck <#Ljα5݈`8cXP6T5i.K!xX*p&ќZǓϘ7 *oƽ:wlຈ:Q5yIEA/2*2jAҐe}k%K$N9R2?7ýKMV!{W9\PA+c4w` Wx=Ze\X{}yXI Ү!aOÎ{]Qx)#D@9E:*NJ}b|Z>_k7:d$z >&Vv󃏽WlR:RqJfGإd9Tm(ҝEtO}1O[xxEYt8,3v bFF )ǙrPNE8=O#V*Cc𹾾&l&cmCh<.P{ʦ&ۣY+Gxs~k5$> ӥPquŽўZt~Tl>Q.g> %k#ú:Kn'&{[yWQGqF}AЅ׮/}<;VYZa$wQg!$;_ $NKS}“_{MY|w7G!"\JtRy+贾d|o/;5jz_6fHwk<ѰJ#]kAȎ J =YNu%dxRwwbEQEQEQEQEQEQEQEQEQE'fLQZ(1F)hQ@X1KEQE-Q@ 1KE3h=iPb(((1GjZ(-ʹRPbR@ 1KE7`bڒyS0(-&)P+ ڎԴP11F)h&:LRmQ@Q@Š(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((?l:ϊw "{{-3j3%{sj~2= 7 ~MڅKrHb|P3 r=Ҁ +Ş/$iu7=q2dԂxn⸷9$l]H #WI񯄴;\[ݚD8C3p&0U9^AnK vI+!I8>5(zqj03Y.X ,@85ߛ8>pq8=} hQEQ^GxZs[V(HM޹;*Axg]d3k{Hܣ 9+,rr{= |8Yk 9o+4d)%XۖP'qj03Y.X ,@84r*z66h)[ELrɜ/$wr}gYywx4r@c ~5OM.5ӪhnV 2Bq}jQEe]m.mR-oM}>-!~eր5(zn6q+i-fYT6*H8NŞ/$iu7=q2d&êC˨Z&2oѦQ+O hgA}>3;vmwgulQQ<6\K0DF dOk :+xxM]>&fžQ0GOo^@=rcgyawݬ4 H8a~} 闒YJ8rRr2?lQUo;8,.໵;&A"6  88 ¬PEPEPEPEPEPEPEPEPEPEPEPEP_§FװWf_|68`SgI*m$עw?P7fIF 3(%E##lxjmGeow%1GswB9W sT|绒K6z!eAۆe% Ӝg>%6kWТ;dV*9vXNxyW-%׷o2>h>_Ny5E|?R}C:O(Etqw73CK} ?ϷyQOg-<~wm˝wǺԓtI" *fLnIN.F33lZwl%BrpH ``zA7'-٧iFR/)D7x[KÍoK5;͍6qj ʹzN8 3V|ZEsnݳzۜ 8hW?O'UZ(Nys먵sI:GL6< O}zGu×z>u͖Pg|uS+'^O{ۏ&K'uض-@/@72]IMzEjqC)#|Or#rt9Ҁ8{_:$:>xJӻ9ntΪXnpq4~O4 #,T v?{ǫZygLg*b`gx_5Ŭ{''Dx#W7 8;PY' m5RGaoo[ifU>v?,xOZ7j:]fH7@F} yf DxG:bylLKG G?G@Co?/; }_>i3),洊W)~eA.p8p&K$NR$,TiXqة [φnQBf":3X2X?1m9fYíwn GO3&B0 䩑vB8  x*Rү4x$cP̀uSu?#<.Kquy$H6j",|},돳Ow4Vo)V9$EtZY{(׻q('8l.#<|dsJ o^@?.k>_xJkzo)V$Rbt,ܜ^gwnx[îchد%Jd䜒! 0:?Nѷeo"!"DyfpGC9ph9 KF'Bٗך' /KѴrۋb[D6b|8I}Z}SxJx\r@={:/㿇&t_[5M S%m.w p^Ο$:tRk N!V9 H$gi sXWu{qqi$W+paW|@ޤѴOޜ}8 5(3W VP-'oŕhXRQg ,h7'7bJ|=N\as@$a}3rYZZk}P3cd-@(x|zqo%b#]BFx$81צ_|RU&br*X-Fq^A_rz|Zmמ1 @h ,r|txEҼ0#{4tVa2O!Xr#mmⷷ8`GjQ@W7^U4H'fFxd 7g]EsHѼ> k:}BeRI`wH%=k?BK9HȂY!At9ֻ(?FiaXAej;!Ln Vl9'Т(((((((((((((/oOoi$& K&bm:aFSgIv >ӭĸuЛ[5p mb~a/ǚ]whS& 4V#8ei22Nƿ ᆈ|[jV: U&Dg@mPݷ(L[񥾟|cui݋}U)ٕwcPQ^?J oX~Ew-%/glkC8]W9IW)}ڔMwepoq#ieck$94=qhλk7Eۍ=밯jEE\Ʊ3CէZkH{7SˈA4=(!g_^xºk=16VUz7*)1g7-8;P'Gu\G.nog9]x$P**5o'ǿu#^+C4-4aM.!;pߍu/ ]A^{.)HzW?ῃ{,Ԃ%<%M*x^ (89Sۘ6oimu*"?ZE1(D02\F>R>_ 3j]ޥ4۵-ԈFS\>\,!I&2 k`TBIڋ '`30h+]K~4-&[ԷeFe Q#k)Pw?u[o?t]Bdz0[R@!Tpr1_*Jd7g̟lzy~^%8wgq> 'Ɵ>_}[}ϙ(ݿwzm?wߌ |߄|GiX^]ZؓC@{?|'`? +/x~̟ڥG)Rm̎?iW~'}H\GpY<8Q^? {{Z.el<,R,)'5]׿h>ZE1(D02\F>R>G ? z׵[]OMw8QjW8<^!WX\]MIG?lqڀ:()M_Eȶ2)S=ϟo_K}uvZXI$02*:F2/$~iEK@\ߍlW}C;M?P Ktŵ(*zv$OxzZkui-ˉ!)B `++C'C?IWPEx^m|[vWZ+7P#Hڡ2'W~ 𮣩x/\ԄbALn-0bURUY*CQ^KIoQ%zQEQEQEQEQEQEQEQEQExŹ,𖿩gxx=,(RN jF~v4Wvr.eሧu8dND(#pwW=$:Du騷%Lc~BQ]NJ|7g]wOkꣵW' *E-y|'`?M'MFѬtv6QBp{i<Ӽa,cP6FQR$a9t#@:JIaY?TU+Zoi.{YUڪ1hjEEG|Y`Z<7z4^=Kp NmU޴Yx+M:6uʍש=O'xW_)%$B(M[MYѯ`F]J2~ݟ|9iI<< r@C²訫|C4KPwI#Y|d`H f<Ax+M6w455ӫ0bUF0aσQy5֓_O/5Ŕ 9V I <瓐4߇߃z|IeҮ&Y۾xs)R2_ .%"F [rI'5x_௄<-& Wwq:}*yUUPO PF~ xellb.`tf$2 &[fd~S+F W<='CGפx{º,ͮAe}򀗓Y$8U;/i><|agPξPP#Q9'$*E5s_Wii:5p,[ѐ+RFA5O-4; '~ǝsHucڀ.YnquoeZ\h.cevF9R0}\3A_[@x$O*ZM[MYѯ`F]J2+q`<7kV$PFC#xZo4htR{`n]Ueܬ1=('u^^? k5]~hs}7ۼ3n=sڀ8?j>]V+b'qc,q+21An{O';RjVZZW uwOoDҾxVJU~h.guɌ ym`FX2My4_^]$zO[RQ|cx#p$`_Ht/x҉++eMqyoȲFchF2*yK:PEPEPEPEPEPEPEPEPEPEy_F|'cS}^Kvi!GRۢT'r=~6OAv ѵ3}#Lp@:q=q_G}a鲬7nYd2J]QEWZ7}.]Btxf1#mS8n@}k((((((MgTƟaiho1)1#óĨ( Ex~_{5۽+^#HGDm8$ҽClCj%2A+$ AETl g4qj[ٗq!Tg=iEs~-u;J#rP0 \ߊkj>#5lRk<"B|>_PH৊ux6\]z¯$xAd ν" +Sg|9wk+C@nuP"A \j~ $.y}nvKI=(b(;%7]7x $uS 3 }GA5kj}GYI' A3Vw5d}KDrmA RpZ0ܺ60ȭ!aX0Wkjro$ 䒠0uڧ [Wφ|U4o-q kFy-XGw ?>l3bn]_,<{'|)o|'%uI]RhLw.0p/ Y})|ʮ%eTb0>pc#x+^6Ѡc|$q0B6iV:Oo!\w;~ϾtKRoryG >x';'=(/SϷ#۱_&H~Iv{tQ[Tz`3WgWV|TfT)$r$` 1^ x#Lm"GxP* a?\+׎femm;EnH,1yκbO΄4^G(J|^MZ]cq"@ \Ff=r(jEE^^?8(j4?-~F<Uhx_9^6NUGCنOAp״6?ĽfOGc+', df  :}{tisOr(WnZ{Xw,*Ć ]2C`KX?Tmoź:m:%>rvfe<I%ŢYCh&0\rpw(l0r:5m>.^ynRD^XG^OQ@_~̗Z=n @>'I?'aŬ^Okm)}l3Y P02I (Jk}sRu]|r0SʞX4k 8[XSq;Q@ 2y8uP^Gsx^'DtOhYhTE9g8\<?럔~#=M2VV~\0Y(?ዏx-'[ҥKF}ܶY P|Qc ZkFD+0K6zd`O?ꑈ53=Z]'yuLG*)g^!8C?-6(29K"Ĩ0Яl;U+K9^u2,@@ (\Ȱ Ë $P`lj 8x I$4H *(@͉0dа8tA  DсSP v"TUH PhP"Y1bxDǕ̧_=$I /& .)+ 60D)bB~=0#'& *D+l1MG CL1&+D`.1qVG ( "D2QL,p.;u. |r$p+5qBNl<TzB"\9e0u )@D,¹ 2@C~KU 'L6a9 /;<`P!D#Tal6XTYhn[p]݅ 7}B a&AƮe{EɲƮiEp#G}D#xTIzGFǂEc^q}) Y# (tۮNeGL*@/%UB:&k0{ &SdDnBQ^("@q #` @1B4i@ aNȅ@[\B >e007V[N(vpyFe Gb/&|aHZj@""~ӎ)t ? $ EQ.սJ$C,l]A `8A o B C?8cyA @Nz|`:`~7-G|yQ AqA6OzPbZ`>~#8=./edGA2nrBYR@ W h'j4p'!k 00 MT RNF6̙ m` (7%ꑀ;PKl-OJPKFJOEBPS/dcommon/doccd_epub.jsM /* Copyright 2006, 2012, Oracle and/or its affiliates. All rights reserved. Author: Robert Crews Version: 2012.3.17 */ function addLoadEvent(func) { var oldOnload = window.onload; if (typeof(window.onload) != "function") window.onload = func; else window.onload = function() { oldOnload(); func(); } } function compactLists() { var lists = []; var ul = document.getElementsByTagName("ul"); for (var i = 0; i < ul.length; i++) lists.push(ul[i]); var ol = document.getElementsByTagName("ol"); for (var i = 0; i < ol.length; i++) lists.push(ol[i]); for (var i = 0; i < lists.length; i++) { var collapsible = true, c = []; var li = lists[i].getElementsByTagName("li"); for (var j = 0; j < li.length; j++) { var p = li[j].getElementsByTagName("p"); if (p.length > 1) collapsible = false; for (var k = 0; k < p.length; k++) { if ( getTextContent(p[k]).split(" ").length > 12 ) collapsible = false; c.push(p[k]); } } if (collapsible) { for (var j = 0; j < c.length; j++) { c[j].style.margin = "0"; } } } function getTextContent(e) { if (e.textContent) return e.textContent; if (e.innerText) return e.innerText; } } addLoadEvent(compactLists); function processIndex() { try { if (!/\/index.htm(?:|#.*)$/.test(window.location.href)) return false; } catch(e) {} var shortcut = []; lastPrefix = ""; var dd = document.getElementsByTagName("dd"); for (var i = 0; i < dd.length; i++) { if (dd[i].className != 'l1ix') continue; var prefix = getTextContent(dd[i]).substring(0, 2).toUpperCase(); if (!prefix.match(/^([A-Z0-9]{2})/)) continue; if (prefix == lastPrefix) continue; dd[i].id = prefix; var s = document.createElement("a"); s.href = "#" + prefix; s.appendChild(document.createTextNode(prefix)); shortcut.push(s); lastPrefix = prefix; } var h2 = document.getElementsByTagName("h2"); for (var i = 0; i < h2.length; i++) { var nav = document.createElement("div"); nav.style.position = "relative"; nav.style.top = "-1.5ex"; nav.style.left = "1.5em"; nav.style.width = "90%"; while (shortcut[0] && shortcut[0].toString().charAt(shortcut[0].toString().length - 2) == getTextContent(h2[i])) { nav.appendChild(shortcut.shift()); nav.appendChild(document.createTextNode("\u00A0 ")); } h2[i].parentNode.insertBefore(nav, h2[i].nextSibling); } function getTextContent(e) { if (e.textContent) return e.textContent; if (e.innerText) return e.innerText; } } addLoadEvent(processIndex); PKo"nR M PKFJOEBPS/dcommon/cpyr.htmd Oracle Legal Notices

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Alpha and Beta Draft Documentation Notice

If this document is in private preproduction status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Oracle Logo

PKKPKFJOEBPS/preface.htmN Preface

Preface

Oracle Data Guard is the most effective solution available today to protect the core asset of any enterprise—its data, and make it available on a 24x7 basis even in the face of disasters and other calamities. This guide describes Oracle Data Guard technology and concepts, and helps you configure and implement standby databases.

Audience

Oracle Data Guard Concepts and Administration is intended for database administrators (DBAs) who administer the backup, restoration, and recovery operations of an Oracle database system.

To use this document, you should be familiar with relational database concepts and basic backup and recovery administration. You should also be familiar with the operating system environment under which you are running Oracle software.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

Readers of Oracle Data Guard Concepts and Administration should also read:

  • The beginning of Oracle Database Concepts, that provides an overview of the concepts and terminology related to the Oracle database and serves as a foundation for the more detailed information in this guide.

  • The chapters in the Oracle Database Administrator's Guide that deal with managing the control files, online redo log files, and archived redo log files.

  • The chapter in the Oracle Database Utilities that discusses LogMiner technology.

  • Oracle Data Guard Broker that describes the graphical user interface and command-line interface for automating and centralizing the creation, maintenance, and monitoring of Oracle Data Guard configurations.

  • Oracle Database High Availability Overview for information about how Oracle Data Guard is used as a key component in high availability and disaster recovery environments.

  • Oracle Enterprise Manager online Help system

Conventions

The following text conventions are used in this document:

ConventionMeaning
boldfaceBoldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.
italicItalic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.
monospaceMonospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

PKPKFJOEBPS/views.htmV Views Relevant to Oracle Data Guard

17 Views Relevant to Oracle Data Guard

This chapter describes the views that are especially useful when monitoring a Data Guard environment. The view described in this chapter are a subset of the views that are available for Oracle databases.

Table 17-1 describes the views and indicates if a view applies to physical standby databases, logical standby databases, snapshot standby databases, or primary databases. See Oracle Database Reference for complete information about views.

Table 17-1 Views That Are Pertinent to Data Guard Configurations

ViewDatabaseDescription

DBA_LOGSTDBY_EVENTS

Logical only

Contains information about the activity of a logical standby database. It can be used to determine the cause of failures that occur when SQL Apply is applying redo to a logical standby database.

DBA_LOGSTDBY_HISTORY

Logical only

Displays the history of switchovers and failovers for logical standby databases in a Data Guard configuration. It does this by showing the complete sequence of redo log streams processed or created on the local system, across all role transitions. (After a role transition, a new log stream is started and the log stream sequence number is incremented by the new primary database.)

DBA_LOGSTDBY_LOG

Logical only

Shows the log files registered for logical standby databases.

DBA_LOGSTDBY_NOT_UNIQUE

Logical only

Identifies tables that have no primary and no non-null unique indexes.

DBA_LOGSTDBY_PARAMETERS

Logical only

Contains the list of parameters used by SQL Apply.

DBA_LOGSTDBY_SKIP

Logical only

Lists the tables that will be skipped by SQL Apply.

DBA_LOGSTDBY_SKIP_TRANSACTION

Logical only

Lists the skip settings chosen.

DBA_LOGSTDBY_UNSUPPORTED

Logical only

Identifies the schemas and tables (and columns in those tables) that contain unsupported data types. Use this view when you are preparing to create a logical standby database.

V$ARCHIVE_DEST

Primary, physical, snapshot, and logical

Describes all of the destinations in the Data Guard configuration, including each destination's current value, mode, and status.

Note: The information in this view does not persist across an instance shutdown.

V$ARCHIVE_DEST_STATUS

Primary, physical, snapshot, and logical

Displays runtime and configuration information for the archived redo log destinations.

Note: The information in this view does not persist across an instance shutdown.

V$ARCHIVE_GAP

Physical, snapshot, and logical

Displays information to help you identify a gap in the archived redo log files.

V$ARCHIVED_LOG

Primary, physical, snapshot, and logical

Displays archive redo log information from the control file, including names of the archived redo log files.

V$DATABASE

Primary, physical, snapshot, and logical

Provides database information from the control file. Includes information about fast-start failover (available only with the Data Guard broker).

V$DATABASE_INCARNATION

Primary, physical, snapshot, and logical

Displays information about all database incarnations. Oracle Database creates a new incarnation whenever a database is opened with the RESETLOGS option. Records about the current and the previous incarnation are also contained in the V$DATABASE view.

V$DATAFILE

Primary, physical, snapshot, and logical

Provides datafile information from the control file.

V$DATAGUARD_CONFIG

Primary, physical, snapshot, and logical

Lists the unique database names defined with the DB_UNIQUE_NAME and LOG_ARCHIVE_CONFIG initialization parameters.

V$DATAGUARD_STATS

Primary, physical, snapshot, and logical

Displays various Data Guard statistics, including apply lag and transport lag. This view can be queried on any instance of a standby database. No rows are returned if queried on a primary database. See also Section 8.1.2 for an example and more information.

V$DATAGUARD_STATUS

Primary, physical, snapshot, and logical

Displays and records events that would typically be triggered by any message to the alert log or server process trace files.

V$FS_FAILOVER_STATS

Primary

Displays statistics about fast-start failover occurring on the system.

V$LOG

Primary, physical, snapshot, and logical

Contains log file information from the online redo log files.

V$LOGFILE

Primary, physical, snapshot, and logical

Contains information about the online redo log files and standby redo log files.

V$LOG_HISTORY

Primary, physical, snapshot, and logical

Contains log history information from the control file.

V$LOGSTDBY_PROCESS

Logical only

Provides dynamic information about what is happening with SQL Apply. This view is very helpful when you are diagnosing performance problems during SQL Apply on the logical standby database, and it can be helpful for other problems.

V$LOGSTDBY_PROGRESS

Logical only

Displays the progress of SQL Apply on the logical standby database.

V$LOGSTDBY_STATE

Logical only

Consolidates information from the V$LOGSTDBY_PROCESS and V$LOGSTDBY_STATS views about the running state of SQL Apply and the logical standby database.

V$LOGSTDBY_STATS

Logical only

Displays LogMiner statistics, current state, and status information for a logical standby database during SQL Apply. If SQL Apply is not running, the values for the statistics are cleared.

V$LOGSTDBY_TRANSACTION

Logical only

Displays information about all active transactions being processed by SQL Apply on the logical standby database.

V$MANAGED_STANDBY

Physical and snapshot

Displays current status information for Oracle database processes related to physical standby databases.

Note: The information in this view does not persist across an instance shutdown.

V$REDO_DEST_RESP_HISTOGRAM

Primary

Contains the response time information for destinations that are configured for SYNC transport.

Note: The information in this view does not persist across an instance shutdown.

V$STANDBY_EVENT_HISTOGRAM

Physical

Contains a histogram of apply lag values for the physical standby. An entry is made in the corresponding apply lag bucket by the Redo Apply process every second. (This view returns rows only on a physical standby database that has been open in real-time query mode.)

Note: The information in this view does not persist across an instance shutdown.

V$STANDBY_LOG

Physical, snapshot, and logical

Contains log file information from the standby redo log files.


PK VVPKFJOEBPS/sql_stmts.htm\y SQL Statements Relevant to Data Guard

16 SQL Statements Relevant to Data Guard

This chapter summarizes the SQL and SQL*Plus statements that are useful for performing operations on standby databases in a Data Guard environment. This chapter includes the following topics:

This chapter contains only the syntax and a brief summary of particular SQL statements. You must refer to the Oracle Database SQL Language Reference for complete syntax and descriptions about these and other SQL statements.

See Chapter 14 for a list of initialization parameters that you can set and dynamically update using the ALTER SYSTEM SET statement.

16.1 ALTER DATABASE Statements

Table 16-1 describes ALTER DATABASE statements that are relevant to Data Guard.

Table 16-1 ALTER DATABASE Statements Used in Data Guard Environments

ALTER DATABASE StatementDescription

ADD [STANDBY] LOGFILE [THREAD integer] [GROUP integer] filespec

Adds one or more online redo log file groups or standby redo log file groups to the specified thread, making the log files available to the instance to which the thread is assigned.

See Section 9.3.5 for an example of this statement.

ADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE] TO logfile-descriptor

Adds new members to existing online redo log file groups or standby redo log file groups.

[ADD|DROP] SUPPLEMENTAL LOG DATA {PRIMARY KEY|UNIQUE INDEX} COLUMNS

This statement is for logical standby databases only.

Use it to enable full supplemental logging before you create a logical standby database. This is necessary because supplemental logging is the source of change to a logical standby database. To implement full supplemental logging, you must specify either the PRIMARY KEY COLUMNS or the UNIQUE INDEX COLUMNS keyword on this statement.

See Oracle Database SQL Language Reference for more information.

COMMIT TO SWITCHOVER

Performs a switchover to:

  • Change the current primary database to the standby database role

  • Change one standby database to the primary database role.

Note: On logical standby databases, you issue the ALTER DATABASE PREPARE TO SWITCHOVER statement to prepare the database for the switchover before you issue the ALTER DATABASE COMMIT TO SWITCHOVER statement.

See Section 8.2.1 and Section 8.3.1 for examples of this statement. Also see Oracle Database SQL Language Reference for information about the complete syntax for this statement.

CONVERT TO [[PHYSICAL|SNAPSHOT] STANDBY] DATABASE

Converts a physical standby database into a snapshot standby database and vice versa.

CREATE [PHYSICAL|LOGICAL] STANDBY CONTROLFILE AS 'filename' [REUSE]

Creates a control file to be used to maintain a physical or a logical standby database. Issue this statement on the primary database.

See Section 3.2.2 for an example of this statement.

DROP [STANDBY] LOGFILE logfile_descriptor

Drops all members of an online redo log file group or standby redo log file group.

See Section 9.3.5 for an example of this statement.

DROP [STANDBY] LOGFILE MEMBER 'filename'

Drops one or more online redo log file members or standby redo log file members.

[NO]FORCE LOGGING

Controls whether or not the Oracle database logs all changes in the database except for changes to temporary tablespaces and temporary segments. The [NO]FORCE LOGGING clause is required to prevent inconsistent standby databases.:

The primary database must at least be mounted (and it can also be open) when you issue this statement. See Section 3.1.1 for an example of this statement.

GUARD

Controls user access to tables in a logical standby database. Possible values are ALL, STANDBY, and NONE. See Section 10.2 for more information.

MOUNT [STANDBY DATABASE]

Mounts a standby database, allowing the standby instance to receive redo data from the primary instance.

OPEN

Opens a previously started and mounted database:

  • Physical standby databases are opened in read-only mode, restricting users to read-only transactions and preventing the generating of redo data.

  • Logical standby database are opened in read/write mode.

PREPARE TO SWITCHOVER

This statement is for logical standby databases only.

It prepares the primary database and the logical standby database for a switchover by building the LogMiner dictionary before the switchover takes place. After the dictionary build has completed, issue the ALTER DATABASE COMMIT TO SWITCHOVER statement to switch the roles of the primary and logical standby databases.

See Section 8.3.1 for examples of this statement. Also see Oracle Database SQL Language Reference for information about the complete syntax for this statement.

RECOVER MANAGED STANDBY DATABASE [ { DISCONNECT [FROM SESSION] | USING CURRENT LOGFILE | NODELAY | UNTIL CHANGE integer }...]

This statement starts and controls Redo Apply on physical standby databases. You can use the RECOVER MANAGED STANDBY DATABASE clause on a physical standby database that is mounted, open, or closed. See Step 4 in Section 3.2.6 and Section 7.3 for examples.

Note: Several clauses and keywords were deprecated and are supported for backward compatibility only. See Oracle Database SQL Language Reference for more information about these clauses.

RECOVER MANAGED STANDBY DATABASE CANCEL

The CANCEL clause cancels Redo Apply on a physical standby database after applying the current archived redo log file.

Note: Several clauses and keywords were deprecated and are supported for backward compatibility only. See Oracle Database SQL Language Reference for more information about these clauses.

RECOVER MANAGED STANDBY DATABASE FINISH

The FINISH clause initiates failover on the target physical standby database and recovers the current standby redo log files. Use the FINISH clause only in the event of the failure of the primary database. This clause overrides any delay intervals specified.

See Step 4 in Section 8.2.2 for examples.

Note: Several clauses and keywords were deprecated and are supported for backward compatibility only. See Oracle Database SQL Language Reference for more information about these clauses.

REGISTER [OR REPLACE] [PHYSICAL|LOGICAL] LOGFILE filespec

Allows the registration of manually copied archived redo log files.

Note: This command should be issued only after manually copying the corresponding archived redo log file to the standby database. Issuing this command while the log file is in the process of being copied or when the log file does not exist may result in errors on the standby database at a later time.

RECOVER TO LOGICAL STANDBY new_database_name

Instructs apply services to continue applying changes to the physical standby database until you issue the command to convert the database to a logical standby database. See Section 4.2.4.1 for more information.

RESET DATABASE TO INCARNATION integer

Resets the target recovery incarnation for the database from the current incarnation to a different incarnation.

SET STANDBY DATABASE TO MAXIMIZE {PROTECTION|AVAILABILITY|PERFORMANCE}

Use this clause to specify the level of protection for the data in your Data Guard configuration. You specify this clause from the primary database, which must be mounted but not open.

START LOGICAL STANDBY APPLY INITIAL [scn-value] ] [NEW PRIMARY dblink]

This statement is for logical standby databases only.It starts SQL Apply on a logical standby database. See Section 7.4.1 for examples of this statement.

{STOP|ABORT} LOGICAL STANDBY APPLY

This statement is for logical standby databases only.Use the STOP clause to stop SQL Apply on a logical standby database in an orderly fashion. Use the ABORT clause to stop SQL Apply abruptly. See Section 8.3.2 for an example of this statement.

ACTIVATE [PHYSICAL|LOGICAL] STANDBY DATABASE FINISH APPLY]

Performs a failover. The standby database must be mounted before it can be activated with this statement.

Note: Do not use the ALTER DATABASE ACTIVATE STANDBY DATABASE statement to failover because it causes data loss. Instead, use the following best practices:

  • For physical standby databases, use the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement with the FINISH keyword to perform the role transition as quickly as possible with little or no data loss and without rendering other standby databases unusable.

  • For logical standby databases, use the ALTER DATABASE PREPARE TO SWITCHOVER and ALTER DATABASE COMMIT TO SWITCHOVER statements.


16.2 ALTER SESSION Statements

Table 16-2 describes the ALTER SESSION statements that are relevant to Data Guard.

Table 16-2 ALTER SESSION Statements Used in Data Guard Environments

ALTER SESSION StatementDescription

ALTER SESSION [ENABLE|DISABLE] GUARD

This statement is for logical standby databases only.

This statement allows privileged users to turn the database guard on and off for the current session.

See Section 10.5.4 for more information.

ALTER SESSION SYNC WITH PRIMARY

This statement is for physical standby databases only.

This statement synchronizes a physical standby database with the primary database, by blocking until all redo data received by the physical standby at the time of statement invocation has been applied.

See Section 9.2.1.3 for more information.


16.3 ALTER SYSTEM Statements

Table 16-3 describes the ALTER SYSTEM statements that are relevant to Data Guard.

Table 16-3 ALTER SYSTEM Statements Used in Data Guard Environments

ALTER SYSTEM StatementDescription

ALTER SYSTEM FLUSH REDO TO target_db_name [[NO] CONFIRM APPLY]

This statement flushes redo data from a primary database to a standby database and optionally waits for the flushed redo data to be applied to a physical or logical standby database.

This statement must be issued on a mounted, but not open, primary database.


PK1+B\\PKFJOEBPS/upgrades.htm+NԱ Upgrading and Downgrading Databases in a Data Guard Configuration

B Upgrading and Downgrading Databases in a Data Guard Configuration

The procedures in this appendix describe how to upgrade and downgrade an Oracle database when a physical or logical standby database is present in the Data Guard configuration.

This appendix contains the following topics:

B.1 Before You Upgrade the Oracle Database Software

Consider the following points before beginning to upgrade your Oracle Database software:

  • If you are using the Data Guard broker to manage your configuration, follow the instructions in the Oracle Data Guard Broker manual for information about removing or disabling the broker configuration.

  • The procedures in this appendix are to be used in conjunction with the ones contained in the Oracle Database Upgrade Guide for 11g Release 2 (11.2).

  • Check for nologging operations. If nologging operations have been performed then you must update the standby database. See Section 13.4, "Recovering After the NOLOGGING Clause Is Specified" for details.

  • Make note of any tablespaces or datafiles that need recovery due to OFFLINE IMMEDIATE. Tablespaces or datafiles should be recovered and either online or offline prior to upgrading.

B.2 Upgrading Oracle Database with a Physical Standby Database in Place

Perform the following steps to upgrade to Oracle Database 11g Release 2 (11.2) when a physical standby database is present in the configuration:

  1. Review and perform the steps listed in the "Preparing to Upgrade" chapter of the Oracle Database Upgrade Guide.

  2. Install the new release of the Oracle software into a new Oracle home on the physical standby database and primary database systems, as described in the Oracle Database Upgrade Guide.

  3. Shut down the primary database.

  4. Shut down the physical standby database(s).

  5. Stop all listeners, agents, and other processes running in the Oracle homes that are to be upgraded. Perform this step on all nodes in an Oracle Real Application Clusters (Oracle RAC) environment.

  6. If Oracle Automatic Storage Management (Oracle ASM) is in use, shut down all databases that use Oracle ASM, and then shut down all Oracle ASM instance(s).

  7. In the new Oracle home, restart all listeners, agents, and other processes that were stopped in step 5.

  8. Mount the physical standby database(s) on the new Oracle home (upgraded version). See Section 3.2.6 for information on how to start a physical standby database.


    Note:

    The standby database(s) should not be opened until the primary database upgrade is completed.

  9. Start Redo Apply on the physical standby database(s). See Section 3.2.6 for information on how to start Redo Apply.

  10. Upgrade the primary database as described in the Oracle Database Upgrade Guide. Note that the physical standby database(s) will be upgraded when the redo generated by the primary database as it is upgraded is applied.

  11. Open the upgraded primary database.

  12. If Active Data Guard was being used prior to the upgrade, then refer to Section 9.2.1 for information about how to reenable it after upgrading.

  13. Optionally, modify the COMPATIBLE initialization parameter, following the procedure described in Section B.4.

B.3 Upgrading Oracle Database with a Logical Standby Database in Place


Note:

This appendix describes the traditional method for upgrading your Oracle Database software with a logical standby database in place. A second method in Chapter 12, "Using SQL Apply to Upgrade the Oracle Database" describes how to upgrade with a logical standby database in place in a rolling fashion to minimize downtime. Use the steps from only one method to perform the complete upgrade. Do not attempt to use both methods or to combine the steps from the two methods as you perform the upgrade process.

The procedure described in this section assumes that the primary database is running in MAXIMUM PERFORMANCE data protection mode.


Perform the following steps to upgrade to Oracle Database 11g Release 2 (11.2) when a logical standby database is present in the configuration:

  1. Review and perform the steps listed in the "Preparing to Upgrade" chapter of the Oracle Database Upgrade Guide.

  2. Set the data protection mode to MAXIMUM PERFORMANCE at the primary database, if needed:

    SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
    
  3. On the primary database, stop all user activity and defer the remote archival destination associated with the logical standby database (for this procedure, it is assumed that LOG_ARCHIVE_DEST_2 is associated with the logical standby database):

    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=BOTH;
    SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
    
  4. Stop SQL Apply on the logical standby database:

    SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
    
  5. On the primary database install the newer release of the Oracle software as described in the Oracle Database Upgrade Guide.

  6. On the logical standby database, install the newer release of the Oracle software as described in Oracle Database Upgrade Guide.


    Note:

    Steps 5 and 6 can be performed concurrently (in other words, the primary and the standby databases can be upgraded concurrently) to reduce downtime during the upgrade procedure.

  7. On the upgraded logical standby database, restart SQL Apply. If you are using Oracle RAC, start up the other standby database instances:

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    
  8. Open the upgraded primary database and allow users to connect. If you are using Oracle RAC, start up the other primary database instances.

    Also, enable archiving to the upgraded logical standby database, as follows:

    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
    
  9. Optionally, reset to the original data protection mode if you changed it in Step 2.

  10. Optionally, modify the COMPATIBLE initialization parameter, following the procedure described in Section B.4.

B.4 Modifying the COMPATIBLE Initialization Parameter After Upgrading

When you upgrade to a new release of Oracle Database, certain new features might make your database incompatible with your previous release. Oracle Database enables you to control the compatibility of your database with the COMPATIBLE initialization parameter.

After the upgrade is complete, you can increase the setting of the COMPATIBLE initialization parameter to the maximum level for the new Oracle Database release. When you are certain that you no longer need the ability to downgrade your database back to its original version, set the COMPATIBLE initialization parameter based on the compatibility level you want for your new database.

In a Data Guard configuration, if you decide to increase the setting of the COMPATIBLE initialization parameter after upgrading, then it is important that you perform the following steps in the order shown (note that the standby database should have a COMPATIBLE setting equal to, or higher than, the primary):

  1. Increase the value of the COMPATIBLE initialization parameter on all standby databases in the configuration first, as follows:

    1. Ensure that apply is current on the standby database(s).

    2. On one instance of each standby database, execute the following SQL statement:

      ALTER SYSTEM SET COMPATIBLE=<value> SCOPE=SPFILE;
      
    3. If Redo Apply or SQL Apply is running, then stop them.

    4. Restart all instances of the standby database(s).

    5. If you previously stopped Redo Apply or SQL Apply, then restart them.

  2. Increase the value of the COMPATIBLE initialization parameter on the primary database, as follows:

    1. On one instance of the primary database, execute the following SQL statement:

      ALTER SYSTEM SET COMPATIBLE=<value> SCOPE=SPFILE;
      
    2. Restart all instances of the primary database.


See Also:


B.5 Downgrading Oracle Database with No Logical Standby in Place

Perform the following steps to downgrade Oracle Database in a Data Guard configuration that does not contain a logical standby database:

  1. Ensure that all physical standby databases are mounted, but not open.


    Note:

    The standby database(s) should not be opened until all redo generated by the downgrade of the primary database has been applied.

  2. Start Redo Apply, in real-time apply mode, on the physical standby database(s).

  3. Downgrade the primary database using the procedure described in Oracle Database Upgrade Guide, keeping the following in mind:

    • At each step of the downgrade procedure where a script is executed, execute the script only at the primary database. Do not perform the next downgrade step until all redo generated by the execution of the script at the primary database has been applied to each physical standby database.

    • At each step of the downgrade procedure where an action other than running a script is performed, perform the step at the primary database first and then at each physical standby database. Do not perform the next downgrade step at the primary database until the action has been performed at each physical standby database.

  4. If it becomes necessary to perform a failover during a downgrade, perform the failover and then continue with the downgrade procedure at the new primary database.

B.6 Downgrading Oracle Database with a Logical Standby in Place

Perform the following steps to downgrade Oracle Database in a Data Guard configuration that contains a logical standby database or a mixture of logical and physical standby databases.

  1. Issue the following command at the primary database (database P, for the sake of this discussion) before you downgrade it:

    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
    

    Database P is no longer in the primary database role.

  2. Wait for all standby databases in the configuration to finish applying all available redo. To determine whether each standby database has finished applying all available redo, run the following query at each standby database:

    SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
     
    SWITCHOVER_STATUS
    -----------------
    TO PRIMARY
    

    Do not continue on to step 3 until the query returns a value of TO PRIMARY for all standby databases in the configuration.

  3. Downgrade the logical standby databases using the procedures described in Oracle Database Upgrade Guide, keeping the following in mind:

    • At each step of the downgrade procedure where a script is executed, execute the script only at the logical standby databases. Do not perform the next downgrade step until all redo generated by executing the script at the logical standby database that was most recently in the primary role (database P) has been applied to each physical standby database.

    • At each step of the downgrade procedure where an action other than running a script is performed, first perform the step at the logical standby database that was most recently in the primary role (database P), and then perform the step at each physical standby database. Do not perform the next downgrade step at the logical standby database that was most recently in the primary role (database P) until the action has been performed at each physical standby database.

  4. After the logical standby that was most recently in the primary role (database P) has been successfully downgraded, open it, and issue the following command:

    SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;
    

    Database P is now back in the primary role.

  5. At each of the logical standby databases in the configuration, issue the following command (note that the command requires that a database link back to the primary exist in all of the logical standby databases):

    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY
    prim_db_link;
    
PKcK0N+NPKFJOEBPS/protection.htmK. Data Guard Protection Modes

5 Data Guard Protection Modes

This chapter contains the following sections:

5.1 Data Guard Protection Modes

This section describes the Data Guard protection modes.

In these descriptions, a synchronized standby database is meant to be one that meets the minimum requirements of the configured data protection mode and that does not have a redo gap. Redo gaps are discussed in Section 6.4.3.

Maximum Availability

This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to the standby redo log on at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.

Maximum Performance

This protection mode provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.

This is the default protection mode.

Maximum Protection

This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.

Transactions on the primary are considered protected as soon as Data Guard has written the redo data to persistent storage in a standby redo log file. Once that is done, acknowledgment is quickly made back to the primary database so that it can proceed to the next transaction. This minimizes the impact of synchronous transport on primary database throughput and response time. To fully benefit from complete Data Guard validation at the standby database, be sure to operate in real-time apply mode so that redo changes are applied to the standby database as fast as they are received. Data Guard signals any corruptions that are detected so that immediate corrective action can be taken.

Because this data protection mode prioritizes data protection over primary database availability, Oracle recommends that a minimum of two standby databases be used to protect a primary database that runs in maximum protection mode to prevent a single standby database failure from causing the primary database to shut down.


Note:

Asynchronously committed transactions are not protected by Data Guard against loss until the redo generated by those transactions has been written to the standby redo log of at least one synchronized standby database.

For more information about the asynchronous commit feature, see:


5.2 Setting the Data Protection Mode of a Primary Database

Perform the following steps to set the data protection mode of a primary database:

Step 1   Select a data protection mode that meets your availability, performance, and data protection requirements.

See Section 5.1 for a description of the data protection modes.

Step 2   Verify that at least one standby database meets the redo transport requirements for the desired data protection mode.

The LOG_ARCHIVE_DEST_n database initialization parameter that corresponds to at least one standby database must include the redo transport attributes listed in Table 5-1 for the desired data protection mode.

The standby database must also have a standby redo log.

See Chapter 6, "Redo Transport Services" for more information about configuring redo transport and standby redo logs.

Table 5-1 Required Redo Transport Attributes for Data Protection Modes

Maximum AvailabilityMaximum PerformanceMaximum Protection

AFFIRM

NOAFFIRM

AFFIRM

SYNC

ASYNC

SYNC

DB_UNIQUE_NAME

DB_UNIQUE_NAME

DB_UNIQUE_NAME


Step 3   Verify that the DB_UNIQUE_NAME database initialization parameter has been set to a unique value on the primary database and on each standby database.
Step 4   Verify that the LOG_ARCHIVE_CONFIG database initialization parameter has been defined on the primary database and on each standby database, and that its value includes a DG_CONFIG list that includes the DB_UNIQUE_NAME of the primary database and each standby database.

For example, the following SQL statement might be used to configure the LOG_ARCHIVE_CONFIG parameter:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(CHICAGO,BOSTON)';
Step 5   Set the data protection mode.

Execute the following SQL statement on the primary database:

SQL> ALTER DATABASE -
> SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE | PROTECTION};

Note that the data protection mode can be set to MAXIMUM PROTECTION on an open database only if the current data protection mode is MAXIMUM AVAILABILITY and if there is at least one synchronized standby database.

Step 6   Confirm that the primary database is operating in the new protection mode.

Perform the following query on the primary database to confirm that it is operating in the new protection mode:

SQL> SELECT PROTECTION_MODE FROM V$DATABASE;
PKb~P.K.PKFJOEBPS/index.htm Index

Index

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  Z 

A

activating
a logical standby database, 8.3.2, 16.1
a physical standby database, 11.8.6, 16.1
Active Data Guard
and physical standby databases, 2.1.1, 9.2
and the real-time query feature, 9.2.1
adding
datafiles, 9.3.1, A.10.1.1, A.10.1.1
indexes on logical standby databases, 2.1.2, 10.5.4.1
new or existing standby databases, 1.3
online redo log files, 9.3.5
tablespaces, 9.3.1
adjusting
initialization parameter file
for logical standby database, 4.2.4.2
AFFIRM attribute, 15
ALTER DATABASE statement
ABORT LOGICAL STANDBY clause, 16.1
ACTIVATE STANDBY DATABASE clause, 8.3.2, 11.8.6, 16.1, 16.1
ADD STANDBY LOGFILE clause, 16.1, A.1.1
ADD STANDBY LOGFILE MEMBER clause, 16.1, A.1.1, A.1.1
ADD SUPPLEMENTAL LOG DATA clause, 16.1
CLEAR UNARCHIVED LOGFILES clause, 9.5
COMMIT TO SWITCHOVER clause, 8.3.1, 8.3.1, 8.3.1, 16.1
in Oracle Real Application Clusters, D.3.1
troubleshooting, A.4.2, A.4.2, A.4.3
CREATE CONTROLFILE clause, 9.5
CREATE DATAFILE AS clause, A.1.1
CREATE STANDBY CONTROLFILE clause, 3.2.2, A.1.3
REUSE clause, 16.1
DROP LOGFILE clause, A.1.1
DROP STANDBY LOGFILE MEMBER clause, 16.1, 16.1, 16.1, A.1.1
FORCE LOGGING clause, 2.3.2, 3.1.1, 13.4, 13.4, 16.1
GUARD clause, 10.2
MOUNT STANDBY DATABASE clause, 16.1
OPEN READ ONLY clause, 16.1
OPEN RESETLOGS clause, 3.2.2, 9.5
PREPARE TO SWITCHOVER clause, 8.3.1, 8.3.1, 16.1
RECOVER MANAGED STANDBY DATABASE clause, 3.2.6, 4.2.5, 16.1, 16.1, 16.1
background process, 7.3.1
canceling, 7.3.2
controlling Redo Apply, 7.3.1, 11.8.2
failover, 16.1
foreground session, 7.3.1
overriding the delay interval, 7.2.2
starting real time apply, 7.3.1
REGISTER LOGFILE clause, 16.1, A.4.1
RENAME FILE clause, A.1.1, A.1.1
SET STANDBY DATABASE clause
TO MAXIMIZE AVAILABILITY clause, 16.1
TO MAXIMIZE PERFORMANCE clause, 8.1.4
TO MAXIMIZE PROTECTION clause, 16.1
START LOGICAL STANDBY APPLY clause, 7.4.1, 12.5, A.6
IMMEDIATE keyword, 7.4.1
starting SQL Apply, 4.2.5
STOP LOGICAL STANDBY APPLY clause, 7.4.2, 8.3.2, 16.1
ALTER SESSION DISABLE GUARD statement
overriding the database guard, 10.5.4
ALTER SESSION statement
ENABLE GUARD clause, 16.2
ALTER SYSTEM statement
SWITCH LOGFILE clause, 3.2.7
ALTER TABLESPACE statement, 9.3.4, 13.4.2, A.10.1.1
FORCE LOGGING clause, 9.3.6
alternate archive destinations
setting up initialization parameters for, A.2
ALTERNATE attribute, 15, 15
LOG_ARCHIVE_DEST_n initialization parameter, A.2
LOG_ARCHIVE_DEST_STATE_n initialization parameter, 6.2.2
ANALYZER process, 10.1
APPLIER process, 10.1
apply lag
monitoring in a real-time query environment, 9.2.1.1
apply lag tolerance
configuring in a real-time query environment, 9.2.1.2
apply services
defined, 1.2.2, 7.1
delaying application of redo data, 7.2.2, 15
real-time apply
defined, 7.2.1, 7.2.1
monitoring with LOG_ARCHIVE_TRACE, F.2
Redo Apply
defined, 7.1, 7.3
monitoring, 7.3.3
starting, 7.3.1
stopping, 7.3.2
SQL Apply
defined, 1.2.2, 7.1, 7.1
monitoring, 7.4.3
starting, 7.4.1
stopping, 7.4.2
applying
redo data immediately, 7.2.1
redo data on standby database, 1.2, 1.2.2, 7
SQL statements to logical standby databases, 7.4
applying state, 10.4.1
AQ_TM_PROCESSES dynamic parameter, A.4.2
archive destinations
alternate, A.2
archived redo log files
accessing information about, 9.5.1.3
applying
Redo Apply technology, 1.2.2
SQL Apply technology, 1.2.2
delaying application, 15
on the standby database, 7.2.2
deleting unneeded, 10.4.2
destinations
disabling, 6.2.2
enabling, 6.2.2
managing gaps, 1.7
See also gap management
manually transferring, 2.3.2
redo data transmitted, 1.2.2, 7.1
registering
during failover, 8.3.2
standby databases and, 7.3.3, 7.4.3, 9.5.1
troubleshooting switchover problems, A.4.1
ARCHIVELOG mode
software requirements, 2.3.2
archiver processes (ARCn)
influenced by MAX_CONNECTIONS attribute, 15
archiving
real-time apply, 7.2.1
specifying
failure resolution policies for, 15
standby redo logs, 6.2.3.2
to a fast recovery area, 6.2.3.2.2
to a local file system, 6.2.3.2.3
to failed destinations, 15
ASM
See Automatic Storage Management (ASM)
ASYNC attribute, 15
attributes
deprecated for the LOG_ARCHIVE_DEST_n initialization parameter, 15
AUD$ table
replication on logical standbys, C.12.2
automatic block repair, 9.2.1.5
automatic detection of missing log files, 1.2.1, 1.7
automatic failover, 1.2.3
Automatic Storage Management (ASM)
creating a standby database that uses, 13.5
automatic switchover, 1.2.3
See also switchovers

B

BACKUP INCREMENTAL FROM SCN command
scenarios using, 11.10
backup operations
after failovers, 8.3.2
after unrecoverable operations, 13.4.3, 13.4.3
configuring on a physical standby database, 1.1.3
datafiles, 13.4.2
offloading on the standby database, 1.7
primary databases, 1.1.2
used by the broker, 1.3
using RMAN, 11
basic readable standby database See simulating a standby database environment
batch processing
on a logical standby database, 10.1.1.4
benefits
Data Guard, 1.7
logical standby database, 2.1.2
of a rolling upgrade, 12.1
physical standby database, 2.1.1
BFILE data types
in logical standby databases, C.1.2
block repair, automatic, 9.2.1.5
broker
command-line interface, 1.7
defined, 1.3
graphical user interface, 1.7
BUILDER process, 10.1

C

cascading redo data, 6.3
configuration requirements, 6.3
data protection considerations, 6.3.2
restrictions, 6.3
character sets
changing on primary databases, 13.8
configurations with differing, C.15
checklist
tasks for creating physical standby databases, 3.2, 3.2
tasks for creating standby databases, 4.2, 4.2
checkpoints
V$LOGSTDBY_PROGRESS view, 10.1.1.3
chunking
transactions, 10.1.1.1
CJQ0 process, A.4.2
CLEAR UNARCHIVED LOGFILES clause
of ALTER DATABASE, 9.5
collections data types
in logical standby databases, C.1.2
command-line interface
broker, 1.7
commands, Recovery Manager
DUPLICATE, E.2.1
COMMIT TO SWITCHOVER clause
of ALTER DATABASE, 8.3.1, 8.3.1, 16.1
in Oracle Real Application Clusters, D.3.1
troubleshooting, A.4.2, A.4.2, A.4.3
COMMIT TO SWITCHOVER TO PRIMARY clause
of ALTER DATABASE, 8.3.1
communication
between databases in a Data Guard configuration, 1.1
COMPATIBLE initialization parameter
setting after upgrading Oracle Database software, B.4
setting for a rolling upgrade, 12.2, 12.5, 12.5
complementary technologies, 1.6
COMPRESSION attribute, 15
configuration options
creating with Data Guard broker, 1.3
overview, 1.1
physical standby databases
location and directory structure, 2.4
standby databases
delayed standby, 7.2.2
configuring
backups on standby databases, 1.1.3
disaster recovery, 1.1.3
initialization parameters
for alternate archive destinations, A.2
listener for physical standby databases, 3.2.5
no data loss, 1.2.3
physical standby databases, 2.4
reporting operations on a logical standby database, 1.1.3
standby databases at remote locations, 1.1.3
constraints
handled on a logical standby database, 10.6.3
Context
unsupported data types, C.1.2
Context data types
in logical standby databases, C.1.2
control files
copying, 3.2.4
creating for standby databases, 3.2.2
CONVERT TO SNAPSHOT STANDBY clause on the ALTER DATABASE statement, 16.1
converting
a logical standby database to a physical standby database
aborting, 4.2.4.1
a physical standby database to a logical standby database, 4.2.4.1
COORDINATOR process, 10.1
LSP background process, 10.1
copying
control files, 3.2.4
CREATE CONTROLFILE clause
of ALTER DATABASE, 9.5
CREATE DATABASE statement
FORCE LOGGING clause, 13.4
CREATE DATAFILE AS clause
of ALTER DATABASE, A.1.1
CREATE STANDBY CONTROLFILE clause
of ALTER DATABASE, 3.2.2, 16.1, A.1.3
CREATE TABLE AS SELECT (CTAS) statements
applied on a logical standby database, 10.1.1.5
creating
indexes on logical standby databases, 10.5.4.1

D

data availability
balancing against system performance requirements, 1.7
Data Guard broker
defined, 1.3
distributed management framework, 8
failovers, 1.3
fast-start, 8
manual, 1.3, 8
fast-start failover, 1.3
switchovers, 8
Data Guard configurations
archiving to standby destinations using the log writer process, 7.2.1
defined, 1.1
protection modes, 1.4
upgrading Oracle Database software, B
data loss
due to failover, 1.2.3
switchover and, 8.1
data protection
balancing against performance, 1.7
benefits, 1.7
flexibility, 1.7
provided by Data Guard, 1
data protection modes
enforced by redo transport services, 1.2.1
overview, 1.4, 1.4
Data Pump utility
using transportable tablespaces with physical standby databases, 9.3.3
data types
BFILE, C.1.2
collections in logical standby databases, C.1.2
ROWID, C.1.2
Spatial, Image, and Context, C.1.2
UROWID, C.1.2
user-defined, C.1.2
database guard, 10.5.4
overriding, 10.5.4
database incarnation
changes with OPEN RESETLOGS, 9.4, 9.4
database roles
primary, 1.1.1, 8.1
standby, 1.1.2, 8.1
transitions, 1.2.3
database schema
physical standby databases, 1.1.2
databases
failover and, 8.1.4
role transition and, 8.1
surviving disasters and data corruptions, 1
upgrading software versions, 12.1
datafiles
adding to primary database, 9.3.1
monitoring, 9.5, 13.4.2
renaming on the primary database, 9.3.4
DB_FILE_NAME_CONVERT initialization parameter
setting at standby site after a switchover, A.4.4
setting on physical standby database, 3.2.3
when planning standby location and directory structure, 2.4
DB_NAME initialization parameter, 3.1.4
DB_ROLE_CHANGE system event, 8.1.5
DB_UNIQUE_NAME attribute, 15
DB_UNIQUE_NAME initialization parameter, A.4.3
required with LOG_ARCHIVE_CONFIG parameter, 14
setting database initialization parameters, 3.1.4
DBA_DATA_FILES view, 9.5
DBA_LOGMNR_PURGED_LOG view
list archived redo log files that can be deleted, 10.4.2
DBA_LOGSTDBY_EVENTS view, 10.3.1, 17, A.6
recording unsupported operations in, 10.5.1
DBA_LOGSTDBY_HISTORY view, 17
DBA_LOGSTDBY_LOG view, 10.3.2, 17
DBA_LOGSTDBY_NOT_UNIQUE view, 17
DBA_LOGSTDBY_PARAMETERS view, 17
DBA_LOGSTDBY_SKIP view, 17
DBA_LOGSTDBY_SKIP_TRANSACTION view, 17
DBA_LOGSTDBY_UNSUPPORTED view, 17
DBA_TABLESPACES view, 9.5
DBMS_ALERT, C.9.2
DBMS_AQ, C.9.2
DBMS_DESCRIBE, C.9.1
DBMS_JAVA, C.9.2
DBMS_LOB, C.9.1
DBMS_LOGSTDBY package
INSTANTIATE_TABLE procedure, 10.5.5
SKIP procedure, A.6
SKIP_ERROR procedure, A.3
SKIP_TRANSACTION procedure, A.6
DBMS_LOGSTDBY.BUILD procedure
building a dictionary in the redo data, 4.2.3.2
DBMS_METADATA, C.9.1
DBMS_OBFUSCATION_TOOLKIT, C.9.1
DBMS_OUTPUT, C.9.1
DBMS_PIPE, C.9.1
DBMS_RANDOM, C.9.1
DBMS_REDEFINITION, C.9.2
DBMS_REFRESH, C.9.2
DBMS_REGISTRY, C.9.2
DBMS_SCHEDULER, C.9.1
DBMS_SPACE_ADMIN, C.9.2
DBMS_SQL, C.9.1
DBMS_TRACE, C.9.1
DBMS_TRANSACTION, C.9.1
DBSNMP process, A.4.2
DDL statements
supported by SQL Apply, C
DDL Statements
that use DBLINKS, C.12.1
DDL transactions
applied on a logical standby database, 10.1.1.5
applying to a logical standby database, 10.1.1.5
DEFER attribute
LOG_ARCHIVE_DEST_STATE_n initialization parameter, 6.2.2
DELAY attribute, 15
LOG_ARCHIVE_DEST_n initialization parameter, 7.2.2
DELAY option
of ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
cancelling, 7.2.2
delaying
application of archived redo log files, 15
application of redo log files, 7.2.2
deleting
archived redo log files
indicated by the DBA_LOGMNR_PURGED_LOG view, 10.4.2
not needed by SQL Apply, 10.4.2
deprecated attributes
on the LOG_ARCHIVE_DEST_n initialization parameter, 15
destinations
displaying with V$ARCHIVE_DEST view, 17
role-based definitions, 15
detecting
missing archived redo log files, 1.2.1, 1.7
DG_CONFIG attribute, 15
DGMGRL command-line interface
invoking failovers, 1.3, 8
simplifying switchovers, 1.3, 8
dictionary
building a LogMiner, 4.2.3.2
direct path inserts
SQL Apply DML considerations, 10.1.1.4
directory locations
Optimal Flexible Architecture (OFA), 2.4, 2.4
set up with ASM, 2.4
set up with OMF, 2.4
structure on standby databases, 2.4
disabling
a destination for archived redo log files, 6.2.2
disaster recovery
benefits, 1.7
configuring, 1.1.3
provided by Data Guard, 1
provided by standby databases, 1.1.3
disk I/O
controlling with the AFFIRM and NOAFFIRM attributes, 15
distributed transactions, C.13
DML
batch updates on a logical standby database, 10.1.1.4
DML transactions
applying to a logical standby database, 10.1.1.4
downgrading
Oracle Database software, B.6
DROP STANDBY LOGFILE clause
of ALTER DATABASE, A.1.1
DROP STANDBY LOGFILE MEMBER clause
of ALTER DATABASE, 16.1, 16.1, 16.1, A.1.1
dropping
online redo log files, 9.3.5
dynamic parameters
AQ_TM_PROCESSES, A.4.2
JOB_QUEUE_PROCESSES, A.4.2

E

ENABLE attribute
LOG_ARCHIVE_DEST_STATE_n initialization parameter, 6.2.2
ENABLE GUARD clause
of ALTER SESSION, 16.2
enabling
database guard on logical standby databases, 16.2
destinations for archived redo log files, 6.2.2
real-time apply
on logical standby databases, 7.4.1
on physical standby databases, 7.3.1
extensible indexes
supported by logical standby databases, C.1.2

F

failovers, 1.2.3
Data Guard broker, 1.3, 8
defined, 1.2.3, 8.1
displaying history with DBA_LOGSTDBY_HISTORY, 17
fast-start failover, 8
flashing back databases after, 8.4
logical standby databases and, 8.3.2
manual versus automatic, 1.2.3
performing backups after, 8.3.2
physical standby databases and, 16.1
preparing for, 8.1.4
simplifying with Data Guard broker, 8
transferring redo data before, 8.1.4
viewing characteristics for logical standby databases, 10.3.3
with maximum performance mode, 8.1.4
with maximum protection mode, 8.1.4
failure resolution policies
specifying for redo transport services, 15
fast-start failover
automatic failover, 1.3, 8
monitoring, 9.5
FGA_LOG$ table
replication on logical standbys, C.12.2
file specifications
renaming on the logical standby database, 10.5.3
Flashback Database
after a role transition, 8.4
after OPEN RESETLOGS, 13.3
after role transitions, 8.4
characteristics complementary to Data Guard, 1.6
physical standby database, 13.2.1
FORCE LOGGING clause
of ALTER DATABASE, 2.3.2, 3.1.1, 13.4, 13.4, 16.1
of ALTER TABLESPACE, 9.3.6
of CREATE DATABASE, 13.4

G

gap management
automatic detection and resolution, 1.2.1, 1.7
detecting missing log files, 1.7
registering archived redo log files
during failover, 8.3.2
GV$INSTANCE view, D.3.1

H

high availability
benefits, 1.7
provided by Data Guard, 1
provided by Oracle RAC and Data Guard, 1.6

I

idle state, 10.4.1
Image data types
in logical standby databases, C.1.2
incarnation of a database
changed, 9.4, 9.4
initialization parameters
DB_UNIQUE_NAME, 3.1.4, A.4.3
LOG_ARCHIVE_MIN_SUCCEED_DEST, 15
LOG_ARCHIVE_TRACE, F.2
LOG_FILE_NAME_CONVERT, E.2.2.4
modifying for physical standby databases, 3.2.3
setting for both the primary and standby roles, 15
INITIALIZING state, 10.4.1
INSTANTIATE_TABLE procedure
of DBMS_LOGSTDBY, 10.5.5

J

JOB_QUEUE_PROCESSES dynamic parameter, A.4.2

K

KEEP IDENTITY clause, 4.2.4.1

L

latency
on logical standby databases, 10.1.1.4, 10.1.1.5
listener.ora file
configuring, 3.2.5
redo transport services tuning and, A.7
troubleshooting, A.1.2, A.7
loading dictionary state, 10.4.1
LOCATION attribute, 15
setting
LOG_ARCHIVE_DEST_n initialization parameter, A.2
log apply services
Redo Apply
monitoring, 9.5.1
starting, 9.1.1
stopping, 9.1.2
tuning for Redo Apply, 9.6
log writer process (LGWR)
ASYNC network transmission, 15
NET_TIMEOUT attribute, 15
SYNC network transmission, 15
LOG_ARCHIVE_CONFIG initialization parameter, 3.1.4, 3.1.4, 3.2.3
example, 15
listing unique database names defined with, 17
relationship to DB_UNIQUE_NAME parameter, 14
relationship to DG_CONFIG attribute, 15
LOG_ARCHIVE_DEST_n initialization parameter
AFFIRM attribute, 15
ALTERNATE attribute, 15, 15, A.2
ASYNC attribute, 15
COMPRESSION attribute, 15
DB_UNIQUE_NAME attribute, 15
DELAY attribute, 7.2.2, 15
deprecated attributes, 15
LOCATION attribute, 15, A.2
MANDATORY attribute, 15
MAX_CONNECTIONS attribute, 15
MAX_FAILURE attribute, 15
NET_TIMEOUT attribute, 15
NOAFFIRM attribute, 15
NOALTERNATE attribute, A.2
NODELAY attribute, 7.2.2
NOREGISTER attribute, 15
REOPEN attribute, 15, 15
SERVICE attribute, 15
SYNC attribute, 15
VALID_FOR attribute, 15
LOG_ARCHIVE_DEST_STATE_n initialization parameter
ALTERNATE attribute, 6.2.2
DEFER attribute, 6.2.2
ENABLE attribute, 6.2.2
LOG_ARCHIVE_MAX_PROCESSES initialization parameter
relationship to MAX_CONNECTIONS, 15
LOG_ARCHIVE_MIN_SUCCEED_DEST initialization parameter, 15
LOG_ARCHIVE_TRACE initialization parameter, F.2
LOG_FILE_NAME_CONVERT initialization parameter
setting at standby site after a switchover, A.4.4
setting on physical standby databases, 3.2.3
when planning standby location and directory structure, 2.4
logical change records (LCR)
converted by PREPARER process, 10.1
exhausted cache memory, 10.1.1.2
staged, 10.1
logical standby databases, 1.1.2
adding
datafiles, A.10.1.1
indexes, 2.1.2, 10.5.4.1
tables, 10.5.5
background processes, 10.1
benefits, 2.1.2
controlling user access to tables, 10.2
creating, 4
converting from a physical standby database, 4.2.4.1
with Data Guard broker, 1.3
data types
supported, C, C.1.1
unsupported, C.1.2
database guard
overriding, 10.5.4
executing SQL statements on, 1.1.2
failovers, 8.3.2
displaying history of, 17, 17
handling failures, A.3
viewing characteristics with V$LOGSTDBY_STATS, 10.3.3
logical standby process (LSP) and, 10.1
materialized views
creating on, 2.1.2
support for, C.11
monitoring, 7.4.3, 17
renaming the file specification, 10.5.3
setting up a skip handler, 10.5.3
SQL Apply, 1.2.2
resynchronizing with primary database branch of redo, 10.6.5
skipping DDL statements, C.11
skipping SQL statements, C.11
starting real-time apply, 7.4.1
stopping, 7.4.2
technology, 7.1
transaction size considerations, 10.1.1.1
starting
real-time apply, 7.4.1, 7.4.1
states
applying, 10.4.1
idle, 10.4.1
initializing, 10.4.1
loading dictionary, 10.4.1
waiting on gaps, 10.4.1
support for primary databases with Transparent Data Encryption, C.2
switchovers, 8.3.1, 8.3.1
throughput and latency, 10.1.1.4, 10.1.1.5
upgrading, B.3
rolling upgrades, 2.3.2
logical standby process (LSP)
COORDINATOR process, 10.1
LogMiner dictionary
using DBMS_LOGSTDBY.BUILD procedure to build, 4.2.3.2
when creating a logical standby database, 4.2.4.1

M

managed recovery operations
See Redo Apply
MANDATORY attribute, 15
materialized views
creating on logical standby databases, 2.1.2
MAX_CONNECTIONS attribute
configuring Oracle RAC for parallel archival, 15
reference, 15
MAX_FAILURE attribute, 15
maximum availability mode
introduction, 1.4
maximum performance mode, 8.1.4
introduction, 1.4
maximum performance protection mode, 5.1
maximum protection mode
for Oracle Real Application Clusters, D.2.2
introduction, 1.4
standby databases and, 8.1.4
memory
exhausted LCR cache, 10.1.1.2
missing log sequence
See also gap management
detecting, 1.7, 1.7
modifying
a logical standby database, 10.5.4
initialization parameters for physical standby databases, 3.2.3
monitoring
primary database events, 9.5
tablespace status, 9.5
MOUNT STANDBY DATABASE clause
of ALTER DATABASE, 16.1
multimedia data types
in logical standby databases, C.1.2
unsupported by logical standby databases, C.1.2

N

NET_TIMEOUT attribute, 15
network connections
configuring multiple, 15
in an Oracle RAC environment, 15
network I/O operations
network timers
NET_TIMEOUT attribute, 15
tuning
redo transport services, A.7
network timeouts
acknowledging, 15
no data loss
data protection modes overview, 1.4
ensuring, 1.2.3
guaranteeing, 1.2.3
provided by maximum availability mode, 1.4
provided by maximum protection mode, 1.4
NOAFFIRM attribute, 15
NOALTERNATE attribute
LOG_ARCHIVE_DEST_n initialization parameter, A.2
NODELAY attribute
LOG_ARCHIVE_DEST_n initialization parameter, 7.2.2
NOREGISTER attribute, 15

O

OMF
See Oracle Managed Files (OMF)
on-disk database structures
physical standby databases, 1.1.2
online redo log files
adding, 9.3.5
dropping, 9.3.5
OPEN READ ONLY clause
of ALTER DATABASE, 16.1
OPEN RESETLOGS
flashing back after, 13.3
OPEN RESETLOGS clause
database incarnation change, 9.4, 9.4
of ALTER DATABASE, 3.2.2, 9.5
recovery, 9.4, 9.4
operational requirements, 2.3, 2.3.2
Optimal Flexible Architecture (OFA)
directory structure, 2.4, 2.4
ORA-01102 message
causing switchover failures, A.4.3
Oracle Automatic Storage Management (ASM), 2.4
Oracle Database software
requirements for upgrading with SQL Apply, 12.2
upgrading, 2.3.2, B.1
upgrading with SQL Apply, 12.1
Oracle Enterprise Manager
invoking failovers, 1.3, 8
invoking switchovers, 1.3, 8
Oracle Managed Files (OMF), 2.4
creating a standby database that uses, 13.5
Oracle Net
communication between databases in a Data Guard configuration, 1.1
Oracle Real Application Clusters
characteristics complementary to Data Guard, 1.6
configuring for multiple network connections, 15
primary databases and, 1.1.1, D.1.1
setting
maximum data protection, D.2.2
standby databases and, 1.1.2, D.1
Oracle Recovery Manager utility (RMAN)
backing up files on a physical standby database, 11
Oracle Standard Edition
simulating a standby database environment, 2.3.2

P

pageout considerations, 10.1.1.2
pageouts
SQL Apply, 10.1.1.2
parallel DML (PDML) transactions
SQL Apply, 10.1.1.3, 10.1.1.4
patch set releases
upgrading, 2.3.2
performance
balancing against data availability, 1.7
balancing against data protection, 1.7
physical standby databases
and Oracle Active Data Guard, 2.1.1
applying redo data, 7.1, 7.3
Redo Apply technology, 7.3
applying redo log files
starting, 7.3.1
benefits, 2.1.1
configuration options, 2.4
converting datafile path names, 3.2.3
converting log file path names, 3.2.3
converting to a logical standby database, 4.2.4.1
creating
checklist of tasks, 3.2
configuring a listener, 3.2.5
directory structure, 2.4
initialization parameters for, 3.2.3
with Data Guard broker, 1.3
defined, 1.1.2
failover
checking for updates, 8.1.4
flashing back after failover, 13.2.1
monitoring, 7.3.3, 9.5.1, 17
opening for read-only or read/write access, 9.2
read-only, 9.2
recovering through OPEN RESETLOGS, 9.4
Redo Apply, 1.2.2
resynchronizing with primary database branch of redo, 9.4, 9.4
role transition and, 8.2
rolling forward with BACKUP INCREMENTAL FROM SCN command, 11.10
shutting down, 9.1.2
starting
apply services, 7.3.1
real-time apply, 7.3.1
synchronizing with the primary database, 11.10
tuning the log apply rate, 9.6
upgrading, B.2
using transportable tablespaces, 9.3.3
PL/SQL supplied packages
supported, C.9.1
unsupported, C.9.2
PREPARE TO SWITCHOVER clause
of ALTER DATABASE, 8.3.1, 8.3.1, 16.1
PREPARER process, 10.1
staging LCRs in SGA, 10.1
primary database
backups and, 8.3.2
configuring
on Oracle Real Application Clusters, 1.1.1
single-instance, 1.1.1
datafiles
adding, 9.3.1
defined, 1.1.1
failover and, 8.1
gap resolution, 1.7
initialization parameters
and physical standby database, 3.2.3
monitoring events on, 9.5
network connections
avoiding network hangs, 15
handling network timeouts, 15
Oracle Real Application Clusters and
setting up, D.1.1
preparing for
physical standby database creation, 3.1
prerequisite conditions for
logical standby database creation, 4.1
redo transport services on, 1.2.1
reducing workload on, 1.7
switchover, 8.1.3
tablespaces
adding, 9.3.1
primary databases
ARCHIVELOG mode, 2.3.2
software requirements, 2.3.2
primary key columns
logged with supplemental logging, 4.2.3.2, 10.1.1.4
primary role, 1.1.1
processes
CJQ0, A.4.2
DBSNMP, A.4.2
preventing switchover, A.4.2
QMN0, A.4.2
SQL Apply architecture, 10.1, 10.4.1
protection modes
maximum availability mode, 1.4
maximum performance, 5.1
maximum performance mode, 1.4
maximum protection mode, 1.4
monitoring, 9.5
setting on a primary database, 5.2

Q

QMN0 process, A.4.2
queries
offloading on the standby database, 1.7

R

READER process, 10.1
read-only operations, 1.2.2
physical standby databases and, 9.2
real-time apply
defined, 7.2.1
overview of log apply services, 1.2
starting, 7.3.1
on logical standby, 7.4.1
starting on logical standby databases, 7.4.1
starting on physical standby databases, 7.3.1
stopping
on logical standby, 7.4.2
on physical standby databases, 9.1.2
tracing data with LOG_ARCHIVE_TRACE initialization parameter, F.2
real-time query feature, 9.2
and Oracle Active Data Guard, 9.2, 9.2.1
configuring apply lag tolerance, 9.2.1.2
forcing Redo Apply synchronization, 9.2.1.3
monitoring apply lag, 9.2.1.1
restrictions, 9.2.1.4
using, 9.2.1
RECORD_UNSUPPORTED_OPERATIONS
example, 10.5.1
RECOVER MANAGED STANDBY DATABASE CANCEL clause
aborting, 4.2.4.1
RECOVER MANAGED STANDBY DATABASE clause
canceling the DELAY control option, 7.2.2
of ALTER DATABASE, 3.2.6, 4.2.5, 7.3.1, 16.1, 16.1, 16.1, 16.1
background process, 7.3.1
controlling Redo Apply, 7.3.1, 11.8.2
foreground session, 7.3.1
overriding the delay interval, 7.2.2
starting real time apply, 7.3.1
RECOVER TO LOGICAL STANDBY clause
converting a physical standby database to a logical standby database, 4.2.4.1
recovering
from errors, A.10.1
logical standby databases, 10.6.5
physical standby databases
after an OPEN RESETLOGS, 9.4, 9.4
through resetlogs, 9.4, 10.6.5
Recovery Manager
characteristics complementary to Data Guard, 1.6
commands
DUPLICATE, E.2.1
standby database
creating, E.2.1
LOG_FILE_NAME_CONVERT initialization parameter, E.2.2.4
preparing using RMAN, E.2.2
re-creating
a table on a logical standby database, 10.5.5
Redo Apply
defined, 1.2.2, 7.1
flashing back after failover, 13.2.1
starting, 3.2.6, 7.3.1
stopping, 9.1.2
technology, 1.2.2
tuning the log apply rate, 9.6
redo data
applying
through Redo Apply technology, 1.2.2
through SQL Apply technology, 1.2.2
to standby database, 7.1
to standby databases, 1.1.2
applying during conversion of a physical standby database to a logical standby database, 4.2.4.1
archiving on the standby system, 1.2.2, 7.1
building a dictionary in, 4.2.3.2
cascading, 6.3
manually transferring, 2.3.2
transmitting, 1.1.2, 1.2.1
redo gaps, 6.4.3
manual resolution, 6.4.3.1
reducing resolution time, 6.4.3
redo log files
delaying application, 7.2.2
redo logs
automatic application on physical standby databases, 7.3.1
update standby database tables, 1.7
redo transport services, 6
archive destinations
alternate, A.2
re-archiving to failed destinations, 15
authenticating sessions
using a password file, 6.2.1.2
using SSL, 6.2.1.1
configuring, 6.2
configuring security, 6.2.1
defined, 1.2.1
gap detection, 6.4.3
handling archive failures, 15
monitoring status, 6.4.1
network
tuning, A.7
protection modes
maximum availability mode, 1.4
maximum performance mode, 1.4
maximum protection mode, 1.4
receiving redo data, 6.2.3
sending redo data, 6.2.2
synchronous and asynchronous disk I/O, 15
wait events, 6.4.4
REGISTER LOGFILE clause
of ALTER DATABASE, 16.1, A.4.1
REGISTER LOGICAL LOGFILE clause
of ALTER DATABASE, 8.3.2
registering
archived redo log files
during failover, 8.3.2
RELY constraint
creating, 4.1.2
remote file server process (RFS)
log writer process and, 7.2.1
RENAME FILE clause
of ALTER DATABASE, A.1.1, A.1.1
renaming
datafiles
on the primary database, 9.3.4
setting the STANDBY_FILE_MANAGEMENT parameter, 9.3.4
REOPEN attribute, 15, 15
reporting operations
configuring, 1.1.3
offloading on the standby database, 1.7
performing on a logical standby database, 1.1.2
requirements
of a rolling upgrade, 12.2
restart considerations
SQL Apply, 10.1.1.3
resynchronizing
logical standby databases with a new branch of redo, 10.6.5
physical standby databases with a new branch of redo, 9.4, 9.4
retrieving
missing archived redo log files, 1.2.1, 1.7
RMAN
incremental backups, 11.10
rolling forward physical standby databases, 11.10
RMAN BACKUP INCREMENTAL FROM SCN command, 11.10
RMAN backups
accessibility in Data Guard environment, 11.1.3
association in Data Guard environment, 11.1.2
interchangeability in Data Guard environment, 11.1.1
role management services
defined, 8
role transition triggers, 8.1.5
DB_ROLE_CHANGE system event, 8.1.5
role transitions, 1.2.3, 8.1
choosing a type of, 8.1.1
defined, 1.2.3
flashing back the databases after, 8.4
logical standby database and, 8.3
monitoring, 9.5
physical standby databases and, 8.2
reversals, 1.2.3, 8.1
role-based destinations
setting, 15
rollback
after switchover failures, A.4.5
rolling upgrade
software requirements, 2.3.2
rolling upgrades
benefits, 12.1
patch set releases, 2.3.2
requirements, 12.2
setting the COMPATIBLE initialization parameter, 12.2, 12.5, 12.5
unsupported data types and storage attributes, 12.4
use of KEEP IDENTITY clause, 4.2.4.1
ROWID data types
in logical standby databases, C.1.2

S

scenarios
recovering
after NOLOGGING is specified, 13.4
schemas
identical to primary database, 1.1.2
SCN
using for incremental backups, 11.10
sequences
unsupported on logical standby databases, C.10
SERVICE attribute, 15
SET STANDBY DATABASE clause
of ALTER DATA, 16.1
of ALTER DATABASE, 8.1.4, 16.1
shutting down
physical standby database, 9.1.2
simulating
standby database environment, 2.3.2
skip handler
setting up on a logical standby database, 10.5.3
SKIP procedure
of DBMS_LOGSTDBY, A.6
SKIP_ERROR procedure
of the DBMS_LOGSTDBY package, A.3
SKIP_TRANSACTION procedure
of DBMS_LOGSTDBY, A.6
snapshot standby databases, 1.1.2
managing, 9.7
software requirements, u=2.3.2
rolling upgrades, 2.3.2, 2.3.2
Spatial data types
in logical standby databases, C.1.2
SQL Apply, 7.4.2, 10.1.1.2
after an OPEN RESETLOGS, 10.6.5
ANALYZER process, 10.1
APPLIER process, 10.1
applying CREATE TABLE AS SELECT (CTAS) statements, 10.1.1.5
applying DDL transactions, 10.1.1.5, 10.1.1.5
applying DML transactions, 10.1.1.4
architecture, 10.1, 10.4.1
BUILDER process, 10.1
COORDINATOR process, 10.1
defined, 1.2.2, 7.1
deleting archived redo log files, 10.4.2
parallel DML (PDML) transactions, 10.1.1.3, 10.1.1.4
performing a rolling upgrade, 12.1
PREPARER process, 10.1
READER process, 10.1
requirements for rolling upgrades, 12.2
restart considerations, 10.1.1.3
rolling upgrades, 2.3.2
starting
real-time apply, 7.4.1
stopping
real-time apply, 7.4.2
support for DDL statements, C
support for PL/SQL supplied packages, C.9.1
supported data types, C.1.1
transaction size considerations, 10.1.1.1
unsupported data types, C.1.2
unsupported PL/SQL supplied packages, C.9.2
viewing current activity, 10.1
of processes, 10.1
what to do if it stops, A.6
SQL sessions
causing switchover failures, A.4.2
SQL statements
executing on logical standby databases, 1.1.2, 1.2.2
skipping on logical standby databases, C.11
standby database
creating logical, 4
standby databases
about creating using RMAN, E.2.1
apply services on, 7.1
applying redo data on, 7
applying redo log files on, 1.2.2, 1.7
ARCn processes using multiple network connections, 15
configuring, 1.1
maximum number of, 2
on Oracle Real Application Clusters, 1.1.2, D.1
on remote locations, 1.1.3
single-instance, 1.1.2
creating, 1.1.2, 3
checklist of tasks, 4.2
directory structure considerations, 2.4
if primary uses ASM or OMF, 13.5
on remote host with same directory structure, E.3
with a time lag, 7.2.2
defined, 2.1
failover
preparing for, 8.1.4
failover to, 8.1.4
LOG_FILE_NAME_CONVERT initialization parameter, E.2.2.4
operational requirements, 2.3, 2.3.2
preparing to use RMAN, E.2.2
recovering through OPEN RESETLOGS, 9.4
resynchronizing with the primary database, 1.7
rolling forward with RMAN incremental backups, 11.10
SET AUXNAME command, E.2.2.4
SET NEWNAME command, E.2.2.4
software requirements, 2.3.2
starting apply services on physical, 7.3.1
See also physical standby databases
standby redo log files
and real-time apply, 7.2.1
standby redo logs
archiving to a fast recovery area, 6.2.3.2.2
archiving to a local file system, 6.2.3.2.3
configuring archival of, 6.2.3.2
creating and managing, 6.2.3.1
standby role, 1.1.2
STANDBY_FILE_MANAGEMENT initialization parameter
when renaming datafiles, 9.3.4
START LOGICAL STANDBY APPLY clause
IMMEDIATE keyword, 7.4.1
of ALTER DATABASE, 4.2.5, 7.4.1, 12.5, A.6
starting
logical standby databases, 4.2.5
physical standby databases, 3.2.6
real-time apply, 7.4.1, 7.4.1
on logical standby databases, 7.4.1, 7.4.1
on physical standby databases, 7.3.1, 7.3.1
Redo Apply, 3.2.6, 7.3.1, 9.1.1
SQL Apply, 4.2.5, 7.4.1
STOP LOGICAL STANDBY APPLY clause
of ALTER DATABASE, 7.4.2, 8.3.2, 16.1
stopping
real-time apply
on logical standby databases, 7.4.2
real-time apply on physical standby databases, 7.3.2
Redo Apply, 7.3.2
SQL Apply, 7.4.2
storage attributes
unsupported during a rolling upgrade, 12.4
streams capture
running on a logical standby, 10.6.6
supplemental logging
setting up to log primary key and unique-index columns, 4.2.3.2, 10.1.1.4
supported data types
for logical standby databases, C, C.12
supported PL/SQL supplied packages, C.9.1
SWITCH LOGFILE clause
of ALTER SYSTEM, 3.2.7
SWITCHOVER_STATUS column
of V$DATABASE view, A.4.1
switchovers, 1.2.3
choosing a target standby database, 8.1.2
defined, 1.2.3, 8.1
displaying history with DBA_LOGSTDBY_HISTORY, 17
fails with ORA-01102, A.4.3
flashing back databases after, 8.4
logical standby databases and, 8.3.1
manual versus automatic, 1.2.3
monitoring, 9.5
no data loss and, 8.1
preparing for, 8.1.3
prevented by
active SQL sessions, A.4.2
CJQ0 process, A.4.2
DBSNMP process, A.4.2
processes, A.4.2
QMN0 process, A.4.2
seeing if the last archived redo log file was transmitted, A.4.1
setting DB_FILE_NAME_CONVERT after, A.4.4
setting LOG_FILE_NAME_CONVERT after, A.4.4
simplifying with Data Guard broker, 1.3, 8
starting over, A.4.5
typical use for, 8.1.3
SYNC attribute, 15
system events
role transitions, 8.1.5
system global area (SGA)
logical change records staged in, 10.1
system resources
efficient utilization of, 1.7

T

tables
logical standby databases
adding on, 10.5.5
re-creating tables on, 10.5.5
unsupported on, C.10
tablespaces
adding
a new datafile, A.10.1.1
to primary database, 9.3.1
monitoring status changes, 9.5
moving between databases, 9.3.3
target standby database
for switchover, 8.1.2
terminating
network connection, 15
text indexes
supported by logical standby databases, C.1.2
throughput
on logical standby databases, 10.1.1.4, 10.1.1.5
time lag
delaying application of archived redo log files, 7.2.2, 15
in standby database, 7.2.2
TIME_COMPUTED column, 8.1.2
TIME_COMPUTED column of the V$DATAGUARD_STATS view, 8.1.2
tnsnames.ora file
redo transport services tuning and, A.7
troubleshooting, A.1.2, A.4.4, A.7
trace files
levels of tracing data, F.2
setting, F.1
tracking real-time apply, F.2
transaction size considerations
SQL Apply, 10.1.1.1
Transparent Data Encryption
support by SQL Apply, C.2
transportable tablespaces
using with a physical standby database, 9.3.3
triggers
handled on a logical standby database, 10.6.3
role transitions, 8.1.5
troubleshooting
if SQL Apply stops, A.6
last redo data was not transmitted, A.4.1
listener.ora file, A.1.2, A.7
logical standby database failures, A.3
processes that prevent switchover, A.4.2
SQL Apply, A.6
switchovers, A.4
active SQL sessions, A.4.2
ORA-01102 message, A.4.3
roll back and start over, A.4.5
tnsnames.ora file, A.1.2, A.4.4, A.7
tuning
log apply rate for Redo Apply, 9.6

U

unique-index columns
logged with supplemental logging, 4.2.3.2, 10.1.1.4
unrecoverable operations, 13.4.2
backing up after, 13.4.3
unsupported data types
during a rolling upgrade, 12.4
unsupported operations
capturing in DBA_LOGSTDBY_EVENTS view, 10.5.1
unsupported PL/SQL supplied packages, C.9.2
upgrading
Oracle Database software, 2.3.2, 12.1, B, B.1
setting the COMPATIBLE initialization parameter, B.4
UROWID data types
in logical standby databases, C.1.2
user-defined data types
in logical standby databases, C.1.2
USING CURRENT LOGFILE clause
starting real time apply, 7.3.1

V

V$ARCHIVE_DEST view, 17, A.1.2
displaying information for all destinations, 17
V$ARCHIVE_DEST_STATUS view, 17
V$ARCHIVE_GAP view, 17
V$ARCHIVED_LOG view, 9.5.1.3, 17, A.4.1
V$DATABASE view, 17
monitoring fast-start failover, 9.5
SWITCHOVER_STATUS column and, A.4.1
V$DATABASE_INCARNATION view, 17
V$DATAFILE view, 13.4.2, 13.4.3, 17
V$DATAGUARD_CONFIG view, 17
listing database names defined with LOG_ARCHIVE_CONFIG, 17
V$DATAGUARD_STATS view, 8.1.2, 17
V$DATAGUARD_STATUS view, 9.5.1.5, 17
V$FS_FAILOVER_STATS view, 17
V$LOG view, 17
V$LOG_HISTORY view, 9.5.1.4, 17
V$LOGFILE view, 17
V$LOGSTDBY_PROCESS view, 10.1, 10.3.4, 10.3.4, 10.4.1, 10.7.3.1, 10.7.3.2, 17
V$LOGSTDBY_PROGRESS view, 10.3.5, 17
RESTART_SCN column, 10.1.1.3
V$LOGSTDBY_STATE view, 8.1.2, 10.3.6, 10.4.1, 17
V$LOGSTDBY_STATS view, 10.1, 10.3.7, 17
failover characteristics, 10.3.3
V$LOGSTDBY_TRANSACTION view, 17
V$MANAGED_STANDBY view, 9.5.1.2, 9.5.1.2, 17
V$REDO_DEST_RESP_HISTOGRAM
using to monitor synchronous redo transport response time, 6.4.2
V$REDO_DEST_RESP_HISTOGRAM view, 17
V$SESSION view, A.4.2
V$STANDBY_EVENT_HISTOGRAM view, 17
V$STANDBY_LOG view, 17
V$THREAD view, 9.5
VALID_FOR attribute, 15
verifying
logical standby databases, 4.2.6
physical standby databases, 3.2.7
versions
upgrading Oracle Database software, 12.1
views
DBA_LOGSTDBY_EVENTS, 10.3.1, 17, A.6
DBA_LOGSTDBY_HISTORY, 17
DBA_LOGSTDBY_LOG, 10.3.2, 17
DBA_LOGSTDBY_NOT_UNIQUE, 17
DBA_LOGSTDBY_PARAMETERS, 17
DBA_LOGSTDBY_SKIP, 17
DBA_LOGSTDBY_SKIP_TRANSACTION, 17
DBA_LOGSTDBY_UNSUPPORTED, 17
GV$INSTANCE, D.3.1
V$ARCHIVE_DEST, 17, A.1.2
V$ARCHIVE_DEST_STATUS, 17
V$ARCHIVED_GAP, 17
V$ARCHIVED_LOG, 9.5.1.3, 17
V$DATABASE, 17
V$DATABASE_INCARNATION, 17
V$DATAFILE, 13.4.2, 13.4.3, 17
V$DATAGUARD_CONFIG, 17
V$DATAGUARD_STATS, 17
V$DATAGUARD_STATUS, 9.5.1.5, 17
V$FS_FAILOVER_STATS, 17
V$LOG, 17
V$LOG_HISTORY, 9.5.1.4, 17
V$LOGFILE, 17
V$LOGSTDBY_PROCESS, 10.1, 10.3.4, 17
V$LOGSTDBY_PROGRESS, 10.3.5, 17
V$LOGSTDBY_STATE, 10.3.6, 17
V$LOGSTDBY_STATS, 10.1, 10.3.7, 17
V$LOGSTDBY_TRANSACTION, 17
V$MANAGED_STANDBY, 9.5.1.2, 9.5.1.2, 17
V$REDO_DEST_RESP_HISTOGRAM, 17
V$SESSION, A.4.2
V$STANDBY_EVENT_HISTOGRAM, 17
V$STANDBY_LOG, 17
V$THREAD, 9.5

W

wait events
for redo transport services, 6.4.4
WAITING FOR DICTIONARY LOGS state, 10.4.1
waiting on gap state, 10.4.1

Z

zero downtime instantiation
logical standby databases, 4.2
PKpPKFJOEBPS/scenarios.htm Data Guard Scenarios

13 Data Guard Scenarios

This chapter describes scenarios you might encounter while administering your Data Guard configuration. Each scenario can be adapted to your specific environment. Table 13-1 lists the scenarios presented in this chapter.

13.1 Configuring Logical Standby Databases After a Failover

This section presents the steps required on a logical standby database after the primary database has failed over to another standby database. After a failover has occurred, a logical standby database cannot act as a standby database for the new primary database until it has applied the final redo from the original primary database. This is similar to the way the new primary database applied the final redo during the failover. The steps you must perform depend on whether the new primary database was a physical standby or a logical standby database prior to the failover:

13.1.1 When the New Primary Database Was Formerly a Physical Standby Database

This scenario demonstrates how to configure a logical standby database to support a new primary database that was a physical standby database before it assumed the primary role. In this scenario, SAT is the logical standby database and NYC is the primary database.

Step 1   Configure the FAL_SERVER parameter to enable automatic recovery of log files.

On the SAT database, issue the following statement:

SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
Step 2   Verify the logical standby database is capable of serving as a standby database to the new primary database.

Call the PREPARE_FOR_NEW_PRIMARY routine to verify and make ready the local logical standby for configuration with the new primary. During this step, local copies of log files that pose a risk for data divergence are deleted from the local database. These log files are then requested for re-archival directly from the new primary database.

On the SAT database, issue the following statement:

SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( -
>  former_standby_type => 'PHYSICAL' -
>  dblink => 'nyc_link');

Note:

If the ORA-16109 message is returned and the 'LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.' warning is written in the alert.log, perform the following steps:
  1. Flash back the database to the SCN as stated in the warning and then

  2. Repeat this step before continuing.

See Section 13.2.3 for an example of how to flash back a logical standby database to an Apply SCN.


Step 3   Start SQL Apply.

On the SAT database, issue the following statement:

SQL> START LOGICAL STANDBY APPLY IMMEDIATE;

13.1.2 When the New Primary Database Was Formerly a Logical Standby Database

This scenario demonstrates how to configure a logical standby database to support a new primary database that was a logical standby database before it assumed the primary role. In this scenario, SAT is the logical standby database and NYC is the primary database.

Step 1   Ensure the new primary database is ready to support logical standby databases.

On the NYC database, ensure the following query returns a value of READY. Otherwise the new primary database has not completed the work required to enable support for logical standby databases. For example:

SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS - 
>   WHERE NAME = 'REINSTATEMENT_STATUS';

Note:

If the VALUE column contains NOT POSSIBLE it means that no logical standby database may be configured with the new primary database, and you must reinstate the database.

Step 2   Configure the FAL_SERVER parameter to enable automatic recovery of log files.

On the SAT database, issue the following statement:

SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
Step 3   Verify the logical standby database is capable of being a standby to the new primary.

Call the PREPARE_FOR_NEW_PRIMARY routine to verify and make ready the local logical standby for configuration with the new primary. During this step, local copies of log files which pose a risk for data divergence are deleted from the local database. These log files are then requested for re-archival directly from the new primary database.

On the SAT database, issue the following statement:

SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( -
> former_standby_type => 'LOGICAL' -
> dblink => 'nyc_link');

Note:

If the ORA-16109 message is returned and the 'LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.' warning is written in the alert.log file, perform the following steps:
  1. Flash back the database to the SCN as stated in the warning and then

  2. Repeat this step before continuing.

See Section 13.2.3 for an example of how to flash back a logical standby database to an Apply SCN.


Step 4   Start SQL Apply.

On the SAT database, issue the following statements:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY nyc_link;

Note that you must always issue this statement without the real-time apply option enabled. If you want to enable real-time apply on the logical standby database, wait for the above statement to complete successfully, and then issue the following statements:

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

13.2 Converting a Failed Primary Into a Standby Database Using Flashback Database

After a failover occurs, the original primary database can no longer participate in the Data Guard configuration until it is repaired and established as a standby database in the new configuration. To do this, you can use the Flashback Database feature to recover the failed primary database to a point in time before the failover occurred, and then convert it into a physical or logical standby database in the new configuration. The following sections describe:

13.2.1 Flashing Back a Failed Primary Database into a Physical Standby Database

The following steps assume that a failover has been performed to a physical standby database and that Flashback Database was enabled on the old primary database at the time of the failover. This procedure brings the old primary database back into the Data Guard configuration as a physical standby database.

Step 1   Determine the SCN at which the old standby database became the primary database.

On the new primary database, issue the following query to determine the SCN at which the old standby database became the new primary database:

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
Step 2   Flash back the failed primary database.

Shut down the old primary database (if necessary), mount it, and flash it back to the value for STANDBY_BECAME_PRIMARY_SCN that was determined in Step 1.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;
Step 3   Convert the database to a physical standby database.

Perform the following steps on the old primary database:

  1. Issue the following statement on the old primary database:

    SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
    

    This statement will dismount the database after successfully converting the control file to a standby control file.

  2. Shut down and restart the database:

    SQL> SHUTDOWN IMMEDIATE;
    SQL> STARTUP MOUNT;
    
Step 4   Start transporting redo to the new physical standby database.

Perform the following steps on the new primary database:

  1. Issue the following query to see the current state of the archive destinations:

    SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
    > ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
    
  2. If necessary, enable the destination:

    SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
    
  3. Perform a log switch to ensure the standby database begins receiving redo data from the new primary database, and verify it was sent successfully. Issue the following SQL statements on the new primary database:

    SQL> ALTER SYSTEM SWITCH LOGFILE;
    SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION,- 
    > ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
    

    On the new standby database, you may also need to change the LOG_ARCHIVE_DEST_n initialization parameters so that redo transport services do not transmit redo data to other databases.

Step 5   Start Redo Apply on the new physical standby database.

Issue the following SQL statement on the new physical standby database:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
> USING CURRENT LOGFILE DISCONNECT;

Redo Apply automatically stops each time it encounters a redo record that is generated as the result of a role transition, so Redo Apply will need to be restarted one or more times until it has applied beyond the SCN at which the new primary database became the primary database. Once the failed primary database is restored and is running in the standby role, you can optionally perform a switchover to transition the databases to their original (pre-failure) roles. See Section 8.2.1, "Performing a Switchover to a Physical Standby Database" for more information.

13.2.2 Flashing Back a Failed Primary Database into a Logical Standby Database

These steps assume that the Data Guard configuration has already completed a failover involving a logical standby database and that Flashback Database has been enabled on the old primary database. This procedure brings the old primary database back into the Data Guard configuration as a new logical standby database without having to formally instantiate it from the new primary database.

Step 1   Determine the flashback SCN and the recovery SCN.

The flashback SCN is the SCN to which the failed primary database will be flashed back. The recovery SCN is the SCN to which the failed primary database will be recovered. Issue the following query on the new primary to identify these SCNs:

SQL> SELECT merge_change# AS FLASHBACK_SCN, processed_change# AS RECOVERY_SCN -
> FROM DBA_LOGSTDBY_HISTORY -
> WHERE stream_sequence# = (SELECT MAX(stream_sequence#)-1 -
> FROM DBA_LOGSTDBY_HISTORY);
Step 2   Flash back the failed primary database to the flashback SCN identified in Step 1.
SQL> FLASHBACK DATABASE TO SCN flashback_scn;
Step 3   Convert the failed primary into a physical standby, and remount the standby database in preparation for recovery.
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
Step 4   Configure the FAL_SERVER parameter to enable automatic recovery of log files.

On the physical standby (failed primary) issue the following statement:

SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
Step 5   Remove divergent archive logs from the failed primary database.

Remove any archive logs created at the time of or, after the failover operation, from the failed primary database. If the failed primary database was isolated from the standby, it could have divergent archive logs that are not consistent with the current primary database. To ensure these divergent archive logs are never applied, they must be deleted from backups and the fast recovery area. You can use the following RMAN command to delete the relevant archive logs from the fast recovery area:

RMAN> DELETE FORCE ARCHIVELOG FROM SCN ARCHIVE_SCN;

Once deleted, these divergent logs and subsequent transactions can never be recovered.