PK +Aoa,mimetypeapplication/epub+zipPK+AiTunesMetadata.plistV artistName Oracle Corporation book-info cover-image-hash 144309630 cover-image-path OEBPS/dcommon/oracle-logo.jpg package-file-hash 359881004 publisher-unique-id E10705-09 unique-id 593597054 genre Oracle Documentation itemName Oracle® Streams Replication Administrator's Guide, 11g Release 2 (11.2) releaseDate 2011-08-01T12:45:53Z year 2011 PKi[VPK+AMETA-INF/container.xml PKYuPK+AOEBPS/rep2strm.htm Migrating Advanced Replication to Oracle Streams

A Migrating Advanced Replication to Oracle Streams

Database administrators who have been using Advanced Replication to maintain replicated database objects at different sites can migrate their Advanced Replication environment to an Oracle Streams environment. This chapter provides a conceptual overview of the steps in this process and documents each step with procedures and examples.

This chapter contains these topics:


See Also:

Oracle Database Advanced Replication and Oracle Database Advanced Replication Management API Reference for more information about Advanced Replication

Overview of the Migration Process

The following sections provide a conceptual overview of the migration process:

Migration Script Generation and Use

You can use the procedure DBMS_REPCAT.STREAMS_MIGRATION to generate a SQL*Plus script that migrates an existing Advanced Replication environment to an Oracle Streams environment. When you run the DBMS_REPCAT.STREAMS_MIGRATION procedure at a master definition site in a multimaster replication environment, it generates a SQL*Plus script in a file at a location that you specify. Once the script is generated, you run it at each master site in your Advanced Replication environment to set up an Oracle Streams environment for each master site. To successfully generate the Oracle Streams environment for your replication groups, the replication groups for which you run the script must have the same master sites. If replication groups have different master sites, then you can generate multiple scripts to migrate each replication group to Oracle Streams.

At times, you must stop, or quiesce, all replication activity for a replication group so that you can perform certain administrative tasks. You do not need to quiesce the replication groups when you run the DBMS_REPCAT.STREAMS_MIGRATION procedure. However, you must quiesce the replication groups being migrated to Oracle Streams when you run the generated script at the master sites. Because you have quiesced the replication groups to run the script at the master sites, you do not have to stop any existing capture processes, propagation jobs, or apply processes at these sites.

Modification of the Migration Script

The generated migration script uses comments to indicate Advanced Replication elements that cannot be converted to Oracle Streams. It also provides suggestions for modifying the script to convert these elements to Oracle Streams. You can use these suggestions to edit the script before you run it. You can also customize the migration script in other ways to meet your needs.

The script sets all parameters when it runs PL/SQL procedures and functions. When you generate the script, it sets default values for parameters that typically do not need to be changed. However, you can change these default parameters by editing the script if necessary. The parameters with default settings include the following:

  • include_dml

  • include_ddl

  • include_tagged_lcr

The beginning of the script has a list of variables for names that are used by the procedures and functions in the script. When you generate the script, it sets these variables to default values that you should not need to change. However, you can change the default settings for these variables if necessary. The variables specify names of queues, capture processes, propagations, and apply processes.

Actions Performed by the Generated Script

The migration script performs the following actions:

  • Prints warnings in comments if the replication groups contain features that cannot be converted to Oracle Streams.

  • Creates ANYDATA queues, if needed, using the DBMS_STREAMS_ADM.SET_UP_QUEUE procedure.

  • Configures propagation between all master sites using the DBMS_STREAMS_ADMIN.ADD_TABLE_PROPAGATION_RULES procedure for each table.

  • Configures capture at each master site using the DBMS_STREAMS_ADMIN.ADD_TABLE_RULES procedure for each table.

  • Configures apply for changes from all the other master sites using the DBMS_STREAMS_ADMIN.ADD_TABLE_RULES procedure for each table.

  • Sets the instantiation SCN for each replicated object at each site where changes to the object are applied.

  • Creates the necessary supplemental log groups at source databases.

  • Sets key columns, if any.

  • Configures conflict resolution if it was configured for the Advanced Replication environment being migrated.

Migration Script Errors

If Oracle encounters an error while running the migration script, then the migration script exits immediately. If this happens, then you must modify the script to run any commands that have not already been executed successfully.

Manual Migration of Updatable Materialized Views

You cannot migrate updatable materialized views using the migration script. You must migrate updatable materialized views from an Advanced Replication environment to an Oracle Streams environment manually.


See Also:

"Re-creating Master Sites to Retain Materialized View Groups"

Advanced Replication Elements that Cannot Be Migrated to Oracle Streams

Oracle Streams does not support the following:

  • Replication of changes to tables with columns of the following data types: BFILE, ROWID, and user-defined types (including object types, REFs, varrays, and nested tables)

  • Synchronous replication

If your current Advanced Replication environment uses these features, then these elements of the environment cannot be migrated to Oracle Streams. In this case, you might decide not to migrate the environment to Oracle Streams now, or you might decide to modify the environment so that it can be migrated to Oracle Streams.

Preparing to Generate the Migration Script

Before generating the migration script, ensure that all the following conditions are met:

Generating and Modifying the Migration Script

To generate the migration script, use the procedure DBMS_REPCAT.STREAMS_MIGRATION in the DBMS_REPCAT package. The syntax for this procedure is as follows:

DBMS_REPCAT.STREAMS_MIGRATION ( 
     gnames              IN   DBMS_UTILITY.NAME_ARRAY, 
     file_location       IN   VARCHAR2, 
     filename            IN   VARCHAR2);

Parameters for the DBMS_REPCAT.STREAMS_MIGRATION procedure include the following:

This procedure generates a script for setting up an Oracle Streams environment for the given replication groups. The script can be customized and run at each master site.

Example Advanced Replication Environment to be Migrated to Oracle Streams

Figure A-1 shows the Advanced Replication environment that will be migrated to Oracle Streams in this example.

Figure A-1 Advanced Replication Environment to be Migrated to Oracle Streams

Description of Figure A-1 follows
Description of "Figure A-1 Advanced Replication Environment to be Migrated to Oracle Streams"

This Advanced Replication environment has the following characteristics:

  • The orc1.example.com database is the master definition site for a three-way master configuration that also includes orc2.example.com and orc3.example.com.

  • The orc1.example.com database is the master site for the mv1.example.com materialized view site.

  • The environment replicates changes to the database objects in the hr schema between the three master sites and between the master site and the materialized view site. A single replication group named hr_repg contains the replicated objects.

  • Conflict resolution is configured for the hr.countries table in the multimaster environment. The latest time stamp conflict resolution method resolves conflicts on this table.

  • The materialized views at the mv1.example.com site are updatable.

You can configure this Advanced Replication environment by completing the tasks described in the following sections of the Oracle Database Advanced Replication Management API Reference:

To generate the migration script for this Advanced Replication environment, complete the following steps:

  1. Create the Oracle Streams Administrator at All Master Sites

  2. Make a Directory Location Accessible

  3. Generate the Migration Script

  4. Verify the Generated Migration Script Creation and Modify Script

Step 1   Create the Oracle Streams Administrator at All Master Sites

Complete the following steps to create the Oracle Streams administrator at each master site for the replication groups being migrated to Oracle Streams. For the sample environment described in "Example Advanced Replication Environment to be Migrated to Oracle Streams", complete these steps at orc1.example.com, orc2.example.com, and orc3.example.com:

  1. Connect as an administrative user who can create users, grant privileges, and create tablespaces.

  2. Either create a tablespace for the Oracle Streams administrator or use an existing tablespace. For example, the following statement creates a new tablespace for the Oracle Streams administrator:

    CREATE TABLESPACE streams_tbs DATAFILE '/usr/oracle/dbs/streams_tbs.dbf' 
  SIZE 25 M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

  3. Create a new user to act as the Oracle Streams administrator or use an existing user. For example, to create a user named strmadmin and specify that this user uses the streams_tbs tablespace, run the following statement:

    CREATE USER strmadmin IDENTIFIED BY password
   DEFAULT TABLESPACE streams_tbs
   QUOTA UNLIMITED ON streams_tbs;

GRANT DBA TO strmadmin;

    Note:

    • The migration script assumes that the user name of the Oracle Streams administrator is strmadmin. If your Oracle Streams administrator has a different user name, then edit the migration script to replace all instances of strmadmin with the user name of your Oracle Streams administrator.

    • Ensure that you grant DBA role to the Oracle Streams administrator.


  4. Grant any additional privileges required by the Oracle Streams administrator at each master site. The necessary privileges depend on your specific Oracle Streams environment.


    See Also:

    "Configuring an Oracle Streams Administrator on All Databases" for information about addition privileges that might be required for an Oracle Streams administrator

Step 2   Make a Directory Location Accessible

The directory specified by the file_location parameter in the DBMS_REPCAT.STREAMS_MIGRATION procedure must be accessible to PL/SQL. If you do not have directory object that is accessible to the Oracle Streams administrator at the master definition site currently, then connect as the Oracle Streams administrator, and create a directory object using the SQL statement CREATE DIRECTORY.

A directory object is similar to an alias for the directory. For example, to create a directory object called MIG2STR_DIR for the /usr/scripts directory on your computer system, run the following procedure:

CONNECT strmadmin@orc1.example.com
Enter password: password

CREATE DIRECTORY MIG2STR_DIR AS '/usr/scripts';

See Also:

Oracle Database SQL Language Reference for more information about the CREATE DIRECTORY statement

Step 3   Generate the Migration Script

To generate the migration script, run the DBMS_REPCAT.STREAMS_MIGRATION procedure at the master definition site and specify the appropriate parameters. For example, the following procedure generates a script that migrates an Advanced Replication environment with one replication group named hr_repg. The script name is rep2streams.sql, and it is generated into the /usr/scripts directory on the local computer system. This directory is represented by the directory object MIG2STR_DIR.

CONNECT strmadmin@orc1.example.com
Enter password: password

DECLARE
  rep_groups DBMS_UTILITY.NAME_ARRAY;
  BEGIN
    rep_groups(1) := 'HR_REPG';
    DBMS_REPCAT.STREAMS_MIGRATION(
      gnames         =>  rep_groups,
      file_location  =>  'MIG2STR_DIR',
      filename       =>  'rep2streams.sql');
END;
/

See Also:

"Example Advanced Replication to Oracle Streams Migration Script" to view the script generated in this example

Step 4   Verify the Generated Migration Script Creation and Modify Script

After generating the migration script, verify that the script was created viewing the script in the specified directory. If necessary, you can modify it to support the following:

  • If your environment requires conflict resolution that used the additive, average, priority group, or site priority Advanced Replication conflict resolution methods, then configure user-defined conflict resolution methods to resolve conflicts. Oracle Streams does not provide prebuilt conflict resolution methods that are equivalent to these methods.

    However, the migration script supports the following conflict resolution methods automatically: overwrite, discard, maximum, and minimum. The script converts an earliest time stamp method to a minimum method automatically, and it converts a latest time stamp method to a maximum method automatically. If you use a time stamp conflict resolution method, then the script assumes that any triggers necessary to populate the time stamp column in a table already exist.

  • Unique conflict resolution.

  • Delete conflict resolution.

  • Multiple conflict resolution methods to be executed in a specified order when a conflict occurs. Oracle Streams allows only one conflict resolution method to be specified for each column list.

  • Procedural replication.

  • Replication of data definition language (DDL) changes for nontable objects, including the following:

    • Functions

    • Indexes

    • Indextypes

    • Operators

    • Packages

    • Package bodies

    • Procedures

    • Synonyms

    • Triggers

    • Types

    • Type bodies

    • Views

Because changes to these objects were being replicated by Advanced Replication at all sites, the migration script does not need to take any action to migrate these objects. You can add DDL rules to the Oracle Streams environment to support the future modification and creation of these types of objects.

For example, to specify that a capture process named streams_capture at the orc1.example.com database captures DDL changes to all of the database objects in the hr schema, add the following to the script:

BEGIN
  DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
    schema_name        => 'hr',
    streams_type       => 'capture',
    streams_name       => 'streams_capture',
    queue_name         => 'strmadmin.streams_queue',
    include_dml        => FALSE,
    include_ddl        => TRUE,
    include_tagged_lcr => FALSE,
    source_database    => 'orc1.example.com');
END;
/

Notice that the include_ddl parameter is set to TRUE. By setting this parameter to TRUE, this procedure adds a schema rule for DDL changes to the hr schema to the rule set for the capture process. This rule instructs the capture process to capture DDL changes to the hr schema and its objects. For the DDL changes to be replicated, you must add similar rules to the appropriate propagations and apply processes.


See Also:


Performing the Migration for Advanced Replication to Oracle Streams

This section explains how to perform the migration from an Advanced Replication environment to an Oracle Streams environment.

This section contains the following topics:

Before Executing the Migration Script

Complete the following steps before executing the migration script:

  1. Set Initialization Parameters That Are Relevant to Oracle Streams

  2. Enable Archive Logging at All Sites

  3. Create Database Links

  4. Quiesce Each Replication Group That You Are Migrating to Oracle Streams

Step 1   Set Initialization Parameters That Are Relevant to Oracle Streams

At each replication database, set initialization parameters that are relevant to Oracle Streams and restart the database if necessary.


See Also:

"Setting Initialization Parameters Relevant to Oracle Streams" for information about initialization parameters that are important to Oracle Streams

Step 2   Enable Archive Logging at All Sites

Ensure that each master site is running in ARCHIVELOG mode, because a capture process requires ARCHIVELOG mode. In the sample environment, orc1.example.com, orc2.example.com, and orc3.example.com must be running in ARCHIVELOG mode. You can check the log mode for a database by querying the LOG_MODE column in the V$DATABASE dynamic performance view.


See Also:

Oracle Database Administrator's Guide for information about running a database in ARCHIVELOG mode

Step 3   Create Database Links

Create a database link from the Oracle Streams administrator at each master site to the Oracle Streams administrator at the other master sites. For the sample environment described in "Example Advanced Replication Environment to be Migrated to Oracle Streams", create the following database links:

CONNECT strmadmin@orc1.example.com
Enter password: password

CREATE DATABASE LINK orc2.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'orc2.example.com';

CREATE DATABASE LINK orc3.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'orc3.example.com';


CONNECT strmadmin@orc2.example.com
Enter password: password

CREATE DATABASE LINK orc1.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'orc1.example.com';

CREATE DATABASE LINK orc3.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'orc3.example.com';


CONNECT strmadmin@orc3.example.com
Enter password: password

CREATE DATABASE LINK orc1.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'orc1.example.com';

CREATE DATABASE LINK orc2.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'orc2.example.com';
Step 4   Quiesce Each Replication Group That You Are Migrating to Oracle Streams

Run the DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY procedure at the master definition site for each replication group that you are migrating to Oracle Streams.

In the sample environment, orc1.example.com is the master definition site, and hr_repg is the replication group being migrated to Oracle Streams. So, connect to orc1.example.com as the replication administrator and run the SUSPEND_MASTER_ACTIVITY procedure:

CONNECT repadmin@orc1.example.com
Enter password: password

BEGIN
   DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY (
      gname => 'hr_repg');
END;
/

Do not proceed until the master group is quiesced. You can check the status of a master group by querying the STATUS column in the DBA_REPGROUP data dictionary view.

Executing the Migration Script

Perform the following steps to migrate:

  1. Connect as the Oracle Streams Administrator and Run the Script at Each Site

  2. Verify That Oracle Streams Configuration Completed Successfully at All Sites

Step 1   Connect as the Oracle Streams Administrator and Run the Script at Each Site

In the sample environment, connect in SQL*Plus as the Oracle Streams administrator strmadmin in SQL*Plus at orc1.example.com, orc2.example.com, and orc3.example.com and execute the migration script rep2streams.sql:

CONNECT strmadmin@orc1.example.com
Enter password: password

SET ECHO ON
SPOOL rep2streams.out
@rep2streams.sql

CONNECT strmadmin@orc2.example.com
Enter password: password

SET ECHO ON
SPOOL rep2streams.out
@rep2streams.sql

CONNECT strmadmin@orc3.example.com
Enter password: password

SET ECHO ON
SPOOL rep2streams.out
@rep2streams.sql
Step 2   Verify That Oracle Streams Configuration Completed Successfully at All Sites

Check the spool file at each site to ensure that there are no errors. If there are errors, then you should modify the script to execute the steps that were not completed successfully, and then rerun the script. In the sample environment, the spool file is rep2streams.out at each master site.

After Executing the Script

Perform the following steps to complete the migration process:

  1. Drop Replication Groups You Migrated at Each Site

  2. Start the Apply Processes at Each Site

  3. Start the Capture Process at Each Site

Step 1   Drop Replication Groups You Migrated at Each Site

To drop a replication group that you successfully migrated to Oracle Streams, connect as the replication administrator to the master definition site, and run the DBMS_REPCAT.DROP_MASTER_REPGROUP procedure.


Caution:

Ensure that the drop_contents parameter is set to FALSE in the DROP_MASTER_REPGROUP procedure. If it is set to TRUE, then the replicated database objects are dropped.

CONNECT repadmin@orc1.example.com
Enter password: password

BEGIN
   DBMS_REPCAT.DROP_MASTER_REPGROUP (
     gname         => 'hr_repg',
     drop_contents => FALSE,
     all_sites     => TRUE);
END;
/

To ensure that the migrated replication groups are dropped at each database, query the GNAME column in the DBA_REPGROUP data dictionary view. The migrated replication groups should not appear in the query output at any database.

If you no longer need the replication administrator, then you can drop this user also.


Caution:

Do not resume any Advanced Replication activity once Oracle Streams is set up.

Step 2   Start the Apply Processes at Each Site

You can view the names of the apply processes at each site by running the following query while connected as the Oracle Streams administrator:

SELECT APPLY_NAME FROM DBA_APPLY;

When you know the names of the apply processes, you can start each one by running the START_APPLY procedure in the DBMS_APPLY_ADM package while connected as the Oracle Streams administrator. For example, the following procedure starts an apply process named apply_from_orc2 at orc1.example.com:

CONNECT strmadmin@orc1.example.com
Enter password: password

BEGIN
  DBMS_APPLY_ADM.START_APPLY(
    apply_name => 'apply_from_orc2');
END;
/

Ensure that you start each apply process at every database in the new Oracle Streams environment.

Step 3   Start the Capture Process at Each Site

You can view the name of the capture process at each site by running the following query while connected as the Oracle Streams administrator:

SELECT CAPTURE_NAME FROM DBA_CAPTURE;

When you know the name of the capture process, you can start each one by running the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package while connected as the Oracle Streams administrator. For example, the following procedure starts a capture process named streams_capture at orc1.example.com:

CONNECT strmadmin@orc1.example.com
Enter password: password

BEGIN
  DBMS_CAPTURE_ADM.START_CAPTURE(
    capture_name => 'streams_capture');
END;
/

Ensure that you start each capture process at every database in the new Oracle Streams environment.

Re-creating Master Sites to Retain Materialized View Groups

If one or more materialized view groups used a master group that you migrated to Oracle Streams, then you must re-create the master group to retain these materialized view groups. Therefore, each database acting as the master site for a materialized view group must become the master definition site for a one-master configuration of a replication group that contains the tables used by the materialized views in the materialized view group.

Use the replication management APIs to create a replication group similar to the original replication group that was migrated to Oracle Streams. That is, the new replication group should have the same replication group name, objects, conflict resolution methods, and key columns. To retain the existing materialized view groups, you must re-create each master group at each master site that contained a master group for a materialized view group, re-create the master replication objects in the master group, regenerate replication support for the master group, and resume replication activity for the master group.

For example, consider the following Advanced Replication environment:

If the rg1 replication group is migrated to Oracle Streams at both mdb1.example.com and mdb2.example.com, and you want to retain the materialized view groups mvg1 at mv1.example.com and mvg2 at mv2.example.com, then you must re-create the rg1 replication group at mdb1.example.com and mdb2.example.com after the migration to Oracle Streams. You configure both mdb1.example.com and mdb2.example.com to be the master definition site for the rg1 replication group in a one-master environment.

It is not necessary to drop or re-create materialized view groups at the materialized view sites. If a new master replication group resembles the original replication group, then the materialized view groups are not affected. Do not refresh these materialized view groups until generation of replication support for each master object is complete (Step 3 in the task in this section). Similarly, do not push the deferred transaction queue at any materialized view site with updatable materialized views until generation of replication support for each master object is complete.

For the sample environment described in "Example Advanced Replication Environment to be Migrated to Oracle Streams", only the hr_repg replication group at orc1.example.com was the master group to a materialized view group at mv1.example.com. To retain this materialized view group at mv1.example.com, complete the following steps while connected as the replication administrator:

  1. Create the master group hr_repg at orc1.example.com.

    CONNECT repadmin@orc1.example.com
Enter password: password

BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPGROUP (
      gname => 'hr_repg');
END;
/

  2. Add the tables in the hr schema to the hr_repg master group. These tables are master tables to the materialized views at mv1.example.com.

    BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
      gname               => 'hr_repg',
      type                => 'TABLE',
      oname               => 'countries',
      sname               => 'hr',
      use_existing_object => TRUE,
      copy_rows           => FALSE);
END;
/

BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
      gname               => 'hr_repg',
      type                => 'TABLE',
      oname               => 'departments',
      sname               => 'hr',
      use_existing_object => TRUE,
      copy_rows           => FALSE);
END;
/

BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
      gname               => 'hr_repg',
      type                => 'TABLE',
      oname               => 'employees',
      sname               => 'hr',
      use_existing_object => TRUE,
      copy_rows           => FALSE);
END;
/

BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
      gname               => 'hr_repg',
      type                => 'TABLE',
      oname               => 'jobs',
      sname               => 'hr',
      use_existing_object => TRUE,
      copy_rows           => FALSE);
END;
/

BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
      gname               => 'hr_repg',
      type                => 'TABLE',
      oname               => 'job_history',
      sname               => 'hr',
      use_existing_object => TRUE,
      copy_rows           => FALSE);
END;
/

BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
      gname               => 'hr_repg',
      type                => 'TABLE',
      oname               => 'locations',
      sname               => 'hr',
      use_existing_object => TRUE,
      copy_rows           => FALSE);
END;
/

BEGIN
   DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
      gname               => 'hr_repg',
      type                => 'TABLE',
      oname               => 'regions',
      sname               => 'hr',
      use_existing_object => TRUE,
      copy_rows           => FALSE);
END;
/

  3. Generate replication support for each object in the hr_repg master group.

    BEGIN 
    DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
      sname             => 'hr',
      oname             => 'countries', 
      type              => 'TABLE'); 
END;
/

BEGIN 
    DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
      sname             => 'hr',
      oname             => 'departments', 
      type              => 'TABLE'); 
END;
/

BEGIN 
    DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
      sname             => 'hr',
      oname             => 'employees', 
      type              => 'TABLE'); 
END;
/

BEGIN 
    DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
      sname             => 'hr',
      oname             => 'jobs', 
      type              => 'TABLE'); 
END;
/

BEGIN 
    DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
      sname             => 'hr',
      oname             => 'job_history', 
      type              => 'TABLE'); 
END;
/

BEGIN 
    DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
      sname             => 'hr',
      oname             => 'locations', 
      type              => 'TABLE'); 
END;
/

BEGIN 
    DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
      sname             => 'hr',
      oname             => 'regions', 
      type              => 'TABLE'); 
END;
/

  4. Resume master activity for the hr_repg master group.

    BEGIN 
   DBMS_REPCAT.RESUME_MASTER_ACTIVITY (
      gname => 'hr_repg'); 
END;
/

    Note:

    A materialized view log should exist for each table you added to the hr_repg master group, unless you deleted these logs manually after you migrated the replication group to Oracle Streams. If these materialized view logs do not exist, then you must create them.

Example Advanced Replication to Oracle Streams Migration Script

The following is an example script generated for the environment:

The following is an example script generated for the environment:
----------------------------------------------------------
-- Migration Script Generated on 12-JUN-05 by user STRMADMIN. --
----------------------------------------------------------
 
----------------------------------------------------------
--  ************** Notes and Assumptions ************** --
--
-- 1. The Oracle Streams Administrator is "strmadmin".
--    The user "strmadmin" must be created and granted the
--    required privileges before running the script.
--
-- 2. Names of queue tables, queues, capture processes
--    propagation jobs, and apply processes will be the
--    same at all sites. If the DBA wants different names,
--    he must edit the script manually before running it
--    at each master site.
--
-- 3. Archive logging must be enabled at all sites before
--    running the script.
--
-- 4. Users must set up database links for queue to queue
--    propagation, if needed.
--
-- 5. Repgroups must be quiesced before running the script.
----------------------------------------------------------
 
set pagesize 1000
set echo on
set serveroutput on
whenever sqlerror exit sql.sqlcode;
 
--
-- Raise error if Repgroups are not Quiesced.
--
declare
  repgroup_status VARCHAR2(10);
begin
  select status into repgroup_status
    from dba_repcat
   where gname = 'HR_REPG';
 
   if (repgroup_status != 'QUIESCED') THEN
     raise_application_error(-20000,
       'ORA-23310: object group "HR_REPG" is not quiesced.');
   end if;
exception when no_data_found then
  null;
end;
/
 
-------------------------------
-- Queue Owner
-------------------------------
-- streams queue owner at ORC1.EXAMPLE.COM
define QUEUE_OWNER_ORC1 = strmadmin
 
-- streams queue owner at ORC2.EXAMPLE.COM
define QUEUE_OWNER_ORC2 = strmadmin
 
-- streams queue owner at ORC3.EXAMPLE.COM
define QUEUE_OWNER_ORC3 = strmadmin
 
-------------------------------
-- Queue Table
-------------------------------
-- streams queue table at ORC1.EXAMPLE.COM
define QUEUE_TABLE_ORC1 = streams_queue_table
 
-- streams queue table at ORC2.EXAMPLE.COM
define QUEUE_TABLE_ORC2 = streams_queue_table
 
-- streams queue table at ORC3.EXAMPLE.COM
define QUEUE_TABLE_ORC3 = streams_queue_table
 
-------------------------------
-- Queue
-------------------------------
-- streams queue at ORC1.EXAMPLE.COM
define QUEUE_ORC1 = streams_queue
 
-- streams queue at ORC2.EXAMPLE.COM
define QUEUE_ORC2 = streams_queue
 
-- streams queue at ORC3.EXAMPLE.COM
define QUEUE_ORC3 = streams_queue
 
-------------------------------
-- Propagation names
-------------------------------
-- propagation process to ORC1.EXAMPLE.COM
define PROP_ORC1 = prop_to_ORC1
 
-- propagation process to ORC2.EXAMPLE.COM
define PROP_ORC2 = prop_to_ORC2
 
-- propagation process to ORC3.EXAMPLE.COM
define PROP_ORC3 = prop_to_ORC3
 
-------------------------------
-- Capture Process
-------------------------------
-- capture process to be used or created at the local site
define CAPTURE_NAME = streams_capture
 
-------------------------------
-- Apply processes
-------------------------------
-- apply process for applying LCRs from ORC1.EXAMPLE.COM
define APPLY_ORC1 = apply_from_ORC1
 
-- apply process for applying LCRs from ORC2.EXAMPLE.COM
define APPLY_ORC2 = apply_from_ORC2
 
-- apply process for applying LCRs from ORC3.EXAMPLE.COM
define APPLY_ORC3 = apply_from_ORC3
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- DEPT_LOCATION_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- EMP_MANAGER_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- INSERT_TIME of type TRIGGER belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_DEPARTMENT_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_EMPLOYEE_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- JHIST_JOB_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
--
-- ** WARNING ** --
-- Oracle Streams does not support the repobject
-- LOC_COUNTRY_IX of type INDEX belonging to repgroup HR_REPG.
-- The user can add DDL rules to the Oracle Streams environment
-- to support creation or any future modifications
-- of this type of object.
--
 
-------------------------------
-- Setup Queue
-------------------------------
 
variable local_db          varchar2(128);
variable local_queue_table varchar2(30);
variable local_queue       varchar2(30);
variable local_queue_owner varchar2(30);
 
-- get the local database name
declare
  global_name varchar2(128);
begin
  select global_name into :local_db from global_name;
  dbms_output.put_line('The local database name is: ' || :local_db);
end;
/
 
-- get the local queue table and queue name
begin
  if :local_db = 'ORC1.EXAMPLE.COM' then
    :local_queue_table := '&QUEUE_TABLE_ORC1';
    :local_queue := '&QUEUE_ORC1';
    :local_queue_owner := '&QUEUE_OWNER_ORC1';
 
  elsif :local_db = 'ORC2.EXAMPLE.COM' then
    :local_queue_table := '&QUEUE_TABLE_ORC2';
    :local_queue := '&QUEUE_ORC2';
    :local_queue_owner := '&QUEUE_OWNER_ORC2';
 
  elsif :local_db = 'ORC3.EXAMPLE.COM' then
    :local_queue_table := '&QUEUE_TABLE_ORC3';
    :local_queue := '&QUEUE_ORC3';
    :local_queue_owner := '&QUEUE_OWNER_ORC3';
 
  end if;
 
  dbms_output.put_line('The local queue owner is: ' || :local_queue_owner);
  dbms_output.put_line('The local queue table is: ' || :local_queue_table);
  dbms_output.put_line('The local queue name  is: ' || :local_queue);
end;
/
 
begin
  dbms_streams_adm.set_up_queue(
    queue_table => :local_queue_table,
    storage_clause => NULL,
    queue_name => :local_queue,
    queue_user => :local_queue_owner,
    comment => 'streams_comment');
end;
/
 
-------------------------------
-- Set Instantiation SCN
-------------------------------
 
variable flashback_scn number;
 
begin
  select dbms_flashback.get_system_change_number into :flashback_scn
    from dual;
  dbms_output.put_line('local flashback SCN is: ' || :flashback_scn);
end;
/
 
--
-- Setup instantiation SCN for ORC1.EXAMPLE.COM
--
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."COUNTRIES" at
  -- ORC1.EXAMPLE.COM
  --
  if (:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
      source_object_name => '"HR"."COUNTRIES"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."DEPARTMENTS" at
  -- ORC1.EXAMPLE.COM
  --
  if (:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
      source_object_name => '"HR"."DEPARTMENTS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."EMPLOYEES" at
  -- ORC1.EXAMPLE.COM
  --
  if (:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
      source_object_name => '"HR"."EMPLOYEES"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."JOBS" at
  -- ORC1.EXAMPLE.COM
  --
  if (:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
      source_object_name => '"HR"."JOBS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."JOB_HISTORY" at
  -- ORC1.EXAMPLE.COM
  --
  if (:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
      source_object_name => '"HR"."JOB_HISTORY"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."LOCATIONS" at
  -- ORC1.EXAMPLE.COM
  --
  if (:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
      source_object_name => '"HR"."LOCATIONS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."REGIONS" at
  -- ORC1.EXAMPLE.COM
  --
  if (:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC1.EXAMPLE.COM(
      source_object_name => '"HR"."REGIONS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
--
-- Setup instantiation SCN for ORC2.EXAMPLE.COM
--
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."COUNTRIES" at
  -- ORC2.EXAMPLE.COM
  --
  if (:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
      source_object_name => '"HR"."COUNTRIES"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."DEPARTMENTS" at
  -- ORC2.EXAMPLE.COM
  --
  if (:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
      source_object_name => '"HR"."DEPARTMENTS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."EMPLOYEES" at
  -- ORC2.EXAMPLE.COM
  --
  if (:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
      source_object_name => '"HR"."EMPLOYEES"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."JOBS" at
  -- ORC2.EXAMPLE.COM
  --
  if (:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
      source_object_name => '"HR"."JOBS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."JOB_HISTORY" at
  -- ORC2.EXAMPLE.COM
  --
  if (:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
      source_object_name => '"HR"."JOB_HISTORY"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."LOCATIONS" at
  -- ORC2.EXAMPLE.COM
  --
  if (:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
      source_object_name => '"HR"."LOCATIONS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."REGIONS" at
  -- ORC2.EXAMPLE.COM
  --
  if (:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC2.EXAMPLE.COM(
      source_object_name => '"HR"."REGIONS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
--
-- Setup instantiation SCN for ORC3.EXAMPLE.COM
--
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."COUNTRIES" at
  -- ORC3.EXAMPLE.COM
  --
  if (:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
      source_object_name => '"HR"."COUNTRIES"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."DEPARTMENTS" at
  -- ORC3.EXAMPLE.COM
  --
  if (:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
      source_object_name => '"HR"."DEPARTMENTS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."EMPLOYEES" at
  -- ORC3.EXAMPLE.COM
  --
  if (:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
      source_object_name => '"HR"."EMPLOYEES"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."JOBS" at
  -- ORC3.EXAMPLE.COM
  --
  if (:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
      source_object_name => '"HR"."JOBS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."JOB_HISTORY" at
  -- ORC3.EXAMPLE.COM
  --
  if (:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
      source_object_name => '"HR"."JOB_HISTORY"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."LOCATIONS" at
  -- ORC3.EXAMPLE.COM
  --
  if (:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
      source_object_name => '"HR"."LOCATIONS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Set instantiation SCN for "HR"."REGIONS" at
  -- ORC3.EXAMPLE.COM
  --
  if (:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_apply_adm.set_table_instantiation_scn@ORC3.EXAMPLE.COM(
      source_object_name => '"HR"."REGIONS"',
      source_database_name => :local_db,
      instantiation_scn => :flashback_scn,
      apply_database_link => NULL);
  end if;
end;
/
 
-------------------------------
-- Setup Propagation
-------------------------------
 
--
-- Propagation from local queue to ORC1.EXAMPLE.COM
--
begin
  if :local_db != 'ORC1.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "COUNTRIES" from local queue to ORC1
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."COUNTRIES"',
      streams_name => '&PROP_ORC1',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC1' ||
        '.' || '&QUEUE_ORC1' ||
        '@ORC1.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC1.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "DEPARTMENTS" from local queue to ORC1
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."DEPARTMENTS"',
      streams_name => '&PROP_ORC1',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC1' ||
        '.' || '&QUEUE_ORC1' ||
        '@ORC1.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC1.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "EMPLOYEES" from local queue to ORC1
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."EMPLOYEES"',
      streams_name => '&PROP_ORC1',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC1' ||
        '.' || '&QUEUE_ORC1' ||
        '@ORC1.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC1.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "JOBS" from local queue to ORC1
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."JOBS"',
      streams_name => '&PROP_ORC1',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC1' ||
        '.' || '&QUEUE_ORC1' ||
        '@ORC1.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC1.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "JOB_HISTORY" from local queue to ORC1
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."JOB_HISTORY"',
      streams_name => '&PROP_ORC1',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC1' ||
        '.' || '&QUEUE_ORC1' ||
        '@ORC1.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC1.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "LOCATIONS" from local queue to ORC1
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."LOCATIONS"',
      streams_name => '&PROP_ORC1',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC1' ||
        '.' || '&QUEUE_ORC1' ||
        '@ORC1.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC1.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "REGIONS" from local queue to ORC1
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."REGIONS"',
      streams_name => '&PROP_ORC1',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC1' ||
        '.' || '&QUEUE_ORC1' ||
        '@ORC1.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
--
-- Propagation from local queue to ORC2.EXAMPLE.COM
--
begin
  if :local_db != 'ORC2.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "COUNTRIES" from local queue to ORC2
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."COUNTRIES"',
      streams_name => '&PROP_ORC2',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC2' ||
        '.' || '&QUEUE_ORC2' ||
        '@ORC2.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC2.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "DEPARTMENTS" from local queue to ORC2
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."DEPARTMENTS"',
      streams_name => '&PROP_ORC2',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC2' ||
        '.' || '&QUEUE_ORC2' ||
        '@ORC2.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC2.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "EMPLOYEES" from local queue to ORC2
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."EMPLOYEES"',
      streams_name => '&PROP_ORC2',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC2' ||
        '.' || '&QUEUE_ORC2' ||
        '@ORC2.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC2.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "JOBS" from local queue to ORC2
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."JOBS"',
      streams_name => '&PROP_ORC2',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC2' ||
        '.' || '&QUEUE_ORC2' ||
        '@ORC2.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC2.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "JOB_HISTORY" from local queue to ORC2
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."JOB_HISTORY"',
      streams_name => '&PROP_ORC2',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC2' ||
        '.' || '&QUEUE_ORC2' ||
        '@ORC2.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC2.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "LOCATIONS" from local queue to ORC2
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."LOCATIONS"',
      streams_name => '&PROP_ORC2',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC2' ||
        '.' || '&QUEUE_ORC2' ||
        '@ORC2.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC2.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "REGIONS" from local queue to ORC2
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."REGIONS"',
      streams_name => '&PROP_ORC2',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC2' ||
        '.' || '&QUEUE_ORC2' ||
        '@ORC2.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
--
-- Propagation from local queue to ORC3.EXAMPLE.COM
--
begin
  if :local_db != 'ORC3.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "COUNTRIES" from local queue to ORC3
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."COUNTRIES"',
      streams_name => '&PROP_ORC3',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC3' ||
        '.' || '&QUEUE_ORC3' ||
        '@ORC3.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC3.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "DEPARTMENTS" from local queue to ORC3
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."DEPARTMENTS"',
      streams_name => '&PROP_ORC3',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC3' ||
        '.' || '&QUEUE_ORC3' ||
        '@ORC3.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC3.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "EMPLOYEES" from local queue to ORC3
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."EMPLOYEES"',
      streams_name => '&PROP_ORC3',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC3' ||
        '.' || '&QUEUE_ORC3' ||
        '@ORC3.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC3.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "JOBS" from local queue to ORC3
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."JOBS"',
      streams_name => '&PROP_ORC3',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC3' ||
        '.' || '&QUEUE_ORC3' ||
        '@ORC3.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC3.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "JOB_HISTORY" from local queue to ORC3
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."JOB_HISTORY"',
      streams_name => '&PROP_ORC3',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC3' ||
        '.' || '&QUEUE_ORC3' ||
        '@ORC3.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC3.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "LOCATIONS" from local queue to ORC3
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."LOCATIONS"',
      streams_name => '&PROP_ORC3',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC3' ||
        '.' || '&QUEUE_ORC3' ||
        '@ORC3.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
begin
  if :local_db != 'ORC3.EXAMPLE.COM' then
    --
    -- HR_REPG: Propagate "REGIONS" from local queue to ORC3
    --
    dbms_streams_adm.add_table_propagation_rules(
      table_name => '"HR"."REGIONS"',
      streams_name => '&PROP_ORC3',
      source_queue_name => :local_queue_owner || '.' || :local_queue,
      destination_queue_name => '&QUEUE_OWNER_ORC3' ||
        '.' || '&QUEUE_ORC3' ||
        '@ORC3.EXAMPLE.COM',
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => :local_db);
  end if;
end;
/
 
-------------------------------
-- Setup Capture
-------------------------------
begin
  --
  -- HR_REPG : Add "COUNTRIES"
  --
  dbms_streams_adm.add_table_rules(
    table_name => '"HR"."COUNTRIES"',
    streams_type => 'CAPTURE',
    streams_name => '&CAPTURE_NAME',
    queue_name => :local_queue_owner || '.' || :local_queue,
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => FALSE,
    source_database => :local_db);
end;
/
 
begin
  --
  -- HR_REPG : Add "DEPARTMENTS"
  --
  dbms_streams_adm.add_table_rules(
    table_name => '"HR"."DEPARTMENTS"',
    streams_type => 'CAPTURE',
    streams_name => '&CAPTURE_NAME',
    queue_name => :local_queue_owner || '.' || :local_queue,
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => FALSE,
    source_database => :local_db);
end;
/
 
begin
  --
  -- HR_REPG : Add "EMPLOYEES"
  --
  dbms_streams_adm.add_table_rules(
    table_name => '"HR"."EMPLOYEES"',
    streams_type => 'CAPTURE',
    streams_name => '&CAPTURE_NAME',
    queue_name => :local_queue_owner || '.' || :local_queue,
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => FALSE,
    source_database => :local_db);
end;
/
 
begin
  --
  -- HR_REPG : Add "JOBS"
  --
  dbms_streams_adm.add_table_rules(
    table_name => '"HR"."JOBS"',
    streams_type => 'CAPTURE',
    streams_name => '&CAPTURE_NAME',
    queue_name => :local_queue_owner || '.' || :local_queue,
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => FALSE,
    source_database => :local_db);
end;
/
 
begin
  --
  -- HR_REPG : Add "JOB_HISTORY"
  --
  dbms_streams_adm.add_table_rules(
    table_name => '"HR"."JOB_HISTORY"',
    streams_type => 'CAPTURE',
    streams_name => '&CAPTURE_NAME',
    queue_name => :local_queue_owner || '.' || :local_queue,
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => FALSE,
    source_database => :local_db);
end;
/
 
begin
  --
  -- HR_REPG : Add "LOCATIONS"
  --
  dbms_streams_adm.add_table_rules(
    table_name => '"HR"."LOCATIONS"',
    streams_type => 'CAPTURE',
    streams_name => '&CAPTURE_NAME',
    queue_name => :local_queue_owner || '.' || :local_queue,
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => FALSE,
    source_database => :local_db);
end;
/
 
begin
  --
  -- HR_REPG : Add "REGIONS"
  --
  dbms_streams_adm.add_table_rules(
    table_name => '"HR"."REGIONS"',
    streams_type => 'CAPTURE',
    streams_name => '&CAPTURE_NAME',
    queue_name => :local_queue_owner || '.' || :local_queue,
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => FALSE,
    source_database => :local_db);
end;
/
 
-------------------------------
-- Setup Apply
-------------------------------
--
-- Setup Apply from ORC1.EXAMPLE.COM
--
 
begin
  --
  -- HR_REPG : Add "COUNTRIES" to apply rules for apply from
  -- ORC1.EXAMPLE.COM
  --
  if(:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."COUNTRIES"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC1',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC1.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "DEPARTMENTS" to apply rules for apply from
  -- ORC1.EXAMPLE.COM
  --
  if(:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."DEPARTMENTS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC1',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC1.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "EMPLOYEES" to apply rules for apply from
  -- ORC1.EXAMPLE.COM
  --
  if(:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."EMPLOYEES"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC1',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC1.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "JOBS" to apply rules for apply from
  -- ORC1.EXAMPLE.COM
  --
  if(:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."JOBS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC1',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC1.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "JOB_HISTORY" to apply rules for apply from
  -- ORC1.EXAMPLE.COM
  --
  if(:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."JOB_HISTORY"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC1',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC1.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "LOCATIONS" to apply rules for apply from
  -- ORC1.EXAMPLE.COM
  --
  if(:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."LOCATIONS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC1',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC1.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "REGIONS" to apply rules for apply from
  -- >+ORC1.EXAMPLE.COM
  --
  if(:local_db != 'ORC1.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."REGIONS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC1',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC1.EXAMPLE.COM');
  end if;
end;
/
 
--
-- Setup Apply from ORC2.EXAMPLE.COM
--
 
begin
  --
  -- HR_REPG : Add "COUNTRIES" to apply rules for apply from
  -- ORC2.EXAMPLE.COM
  --
  if(:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."COUNTRIES"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC2',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC2.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "DEPARTMENTS" to apply rules for apply from
  -- ORC2.EXAMPLE.COM
  --
  if(:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."DEPARTMENTS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC2',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC2.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "EMPLOYEES" to apply rules for apply from
  -- ORC2.EXAMPLE.COM
  --
  if(:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."EMPLOYEES"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC2',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC2.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "JOBS" to apply rules for apply from
  -- ORC2.EXAMPLE.COM
  --
  if(:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."JOBS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC2',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC2.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "JOB_HISTORY" to apply rules for apply from
  -- ORC2.EXAMPLE.COM
  --
  if(:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."JOB_HISTORY"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC2',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC2.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "LOCATIONS" to apply rules for apply from
  -- ORC2.EXAMPLE.COM
  --
  if(:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."LOCATIONS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC2',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC2.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "REGIONS" to apply rules for apply from
  -- ORC2.EXAMPLE.COM
  --
  if(:local_db != 'ORC2.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."REGIONS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC2',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC2.EXAMPLE.COM');
  end if;
end;
/
 
--
-- Setup Apply from ORC3.EXAMPLE.COM
--
 
begin
  --
  -- HR_REPG : Add "COUNTRIES" to apply rules for apply from
  -- ORC3.EXAMPLE.COM
  --
  if(:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."COUNTRIES"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC3',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC3.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "DEPARTMENTS" to apply rules for apply from
  -- ORC3.EXAMPLE.COM
  --
  if(:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."DEPARTMENTS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC3',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC3.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "EMPLOYEES" to apply rules for apply from
  -- ORC3.EXAMPLE.COM
  --
  if(:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."EMPLOYEES"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC3',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC3.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "JOBS" to apply rules for apply from
  -- ORC3.EXAMPLE.COM
  --
  if(:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."JOBS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC3',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC3.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "JOB_HISTORY" to apply rules for apply from
  -- ORC3.EXAMPLE.COM
  --
  if(:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."JOB_HISTORY"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC3',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC3.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "LOCATIONS" to apply rules for apply from
  -- ORC3.EXAMPLE.COM
  --
  if(:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."LOCATIONS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC3',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC3.EXAMPLE.COM');
  end if;
end;
/
 
begin
  --
  -- HR_REPG : Add "REGIONS" to apply rules for apply from
  -- ORC3.EXAMPLE.COM
  --
  if(:local_db != 'ORC3.EXAMPLE.COM') then
    dbms_streams_adm.add_table_rules(
      table_name => '"HR"."REGIONS"',
      streams_type => 'APPLY',
      streams_name => '&APPLY_ORC3',
      queue_name => :local_queue_owner || '.' || :local_queue,
      include_dml => TRUE,
      include_ddl => FALSE,
      include_tagged_lcr => FALSE,
      source_database => 'ORC3.EXAMPLE.COM');
  end if;
end;
/
 
-------------------------------
-- Add Supplemental Log Groups
-------------------------------
--
-- ** NOTE ** --
-- The primary key columns must be supplementally logged.
--
alter database add supplemental log data (primary key) columns;
 
--
-- ** NOTE ** --
-- The unique key columns must be supplementally logged.
--
alter database add supplemental log data (unique index) columns;
 
--
-- ** NOTE ** --
-- All the columns in a column group that is assigned an Oracle Streams
-- supported update conflict handler must be supplementally logged.
--
 
-- Supplementally log columns in column group 'COUNTRIES_TIMESTAMP_CG'
-- that is assigned the LATEST TIMESTAMP update conflict resolution method.
alter table "HR"."COUNTRIES" add supplemental log group COUNTRIES_LogGrp1 (
"COUNTRY_NAME"
,"REGION_ID"
,"TIMESTAMP"
);
 
-------------------------------
-- Setup Conflict Resolution
-------------------------------
--
-- ** WARNING ** --
-- Oracle Streams does not support LATEST TIMESTAMP
-- conflict resolution method.
-- Changing LATEST TIMESTAMP to MAXIMUM as
-- they handle the conflicts in a similar manner.
--
declare
  cols dbms_utility.name_array;
begin
  cols(1) := 'COUNTRY_NAME';
  cols(2) := 'REGION_ID';
  cols(3) := 'TIMESTAMP';
  dbms_apply_adm.set_update_conflict_handler(
    object_name => 'HR.COUNTRIES',
    method_name => 'MAXIMUM',
    resolution_column => 'TIMESTAMP',
    column_list => cols);
end;
/
 
-------------------------------
-- Verify Oracle Streams Setup
-------------------------------
 
-- Verify creation of queues
select * from dba_queues
 where name = upper(:local_queue)
   and owner = upper(:local_queue_owner)
   and queue_table = upper(:local_queue_table)
 order by name;
 
-- Verify creation of capture_process
select * from dba_capture
 where capture_name = upper('&CAPTURE_NAME');
 
-- Verify creation of apply processes
select * from dba_apply
 where apply_name IN (
       upper('&APPLY_ORC1'),
       upper('&APPLY_ORC2'),
       upper('&APPLY_ORC3') )
 order by apply_name;
 
-- Verify propagation processes
select * from dba_propagation
 where propagation_name IN (
       upper('&PROP_ORC1'),
       upper('&PROP_ORC2'),
       upper('&PROP_ORC3') )
 order by propagation_name;
 
-- Verify Oracle Streams rules
select * from dba_streams_table_rules
 where streams_name = upper('&CAPTURE_NAME');
 
select * from dba_streams_table_rules
 where streams_name IN (
       upper('&APPLY_ORC1'),
       upper('&APPLY_ORC2'),
       upper('&APPLY_ORC3') )
 order by source_database;
 
select * from dba_streams_table_rules
 where streams_name IN (
       upper('&PROP_ORC1'),
       upper('&PROP_ORC2'),
       upper('&PROP_ORC3') )
 order by source_database;
 
-- Do not resume Repcat activity once Oracle Streams is set up.
-- Drop all the repgroups that have been migrated to Oracle Streams.
-- Start apply and capture processes at all sites.
PK6R>PK+AOEBPS/rep_tags.htm Oracle Streams Tags

10 Oracle Streams Tags

This chapter explains the concepts related to Oracle Streams tags.

This chapter contains these topics:


See Also:

"Managing Oracle Streams Tags"

Introduction to Tags

Every redo entry in the redo log has a tag associated with it. The data type of the tag is RAW. By default, when a user or application generates redo entries, the value of the tag is NULL for each redo entry, and a NULL tag consumes no space. The size limit for a tag value is 2000 bytes.

You can configure how tag values are interpreted. For example, you can use a tag to determine whether an LCR contains a change that originated in the local database or at a different database, so that you can avoid change cycling (sending an LCR back to the database where it originated). Tags can be used for other LCR tracking purposes as well. You can also use tags to specify the set of destination databases for each LCR.

You can control the value of the tags generated in the redo log in the following ways:

Based on the rules in the rule sets for a capture process, the tag value in the redo entry for a change can determine whether the change is captured. Based on the rules in the rule sets for a synchronous capture, the session tag value for a change can determine whether the change is captured. The tags become part of the LCRs captured by a capture process or synchronous capture.

Similarly, once a tag is part of an LCR, the value of the tag can determine whether a propagation propagates the LCR and whether an apply process applies the LCR. The behavior of a custom rule-based transformation or apply handler can also depend on the value of the tag. In addition, you can set the tag value for an existing LCR using the SET_TAG member procedure for the LCR in a custom rule-based transformation or an apply handler that uses a PL/SQL procedure. You cannot set a tag value for an existing LCR in a statement DML handler or change handler.


See Also:


Tags and Rules Created by the DBMS_STREAMS_ADM Package

When you use a procedure in the DBMS_STREAMS_ADM package to create rules and set the include_tagged_lcr parameter to FALSE, each rule contains a condition that evaluates to TRUE only if the tag is NULL. In DML rules, the condition is the following:

:dml.is_null_tag()='Y'

In DDL rules, the condition is the following:

:ddl.is_null_tag()='Y'

Consider a positive rule set with a single rule and assume the rule contains such a condition. In this case, Oracle Streams capture processes, synchronous captures, propagations, and apply processes behave in the following way:

Alternatively, consider a negative rule set with a single rule and assume the rule contains such a condition. In this case, Oracle Streams capture processes, propagations, and apply processes behave in the following way:

In most cases, specify TRUE for the include_tagged_lcr parameter if rules are being added to a negative rule set so that changes are discarded regardless of their tag values.

The following procedures in the DBMS_STREAMS_ADM package create rules that contain one of these conditions by default:

If you do not want the rules to contain such a condition, then set the include_tagged_lcr parameter to TRUE when you run these procedures. This setting results in no conditions relating to tags in the rules. Therefore, rule evaluation of the database change does not depend on the value of the tag.

For example, consider a table rule that evaluates to TRUE for all DML changes to the hr.locations table that originated at the dbs1.example.com source database.

Assume the ADD_TABLE_RULES procedure is run to generate this rule:

BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name               =>  'hr.locations',
    streams_type             =>  'capture',
    streams_name             =>  'capture',
    queue_name               =>  'streams_queue',
    include_tagged_lcr       =>  FALSE,  -- Note parameter setting
    source_database          =>  'dbs1.example.com',
    include_dml              =>  TRUE,
    include_ddl              =>  FALSE);
END;
/

Notice that the include_tagged_lcr parameter is set to FALSE, which is the default. The ADD_TABLE_RULES procedure generates a rule with a rule condition similar to the following:

(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'LOCATIONS')) 
and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 
'DBS1.EXAMPLE.COM' )

If a capture process uses a positive rule set that contains this rule, then the rule evaluates to FALSE if the tag for a change in a redo entry is a non-NULL value, such as '0' or '1'. So, if a redo entry contains a row change to the hr.locations table, then the change is captured only if the tag for the redo entry is NULL.

However, suppose the include_tagged_lcr parameter is set to TRUE when ADD_TABLE_RULES is run:

BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name               =>  'hr.locations',
    streams_type             =>  'capture',
    streams_name             =>  'capture',
    queue_name               =>  'streams_queue',
    include_tagged_lcr       =>  TRUE,   -- Note parameter setting
    source_database          =>  'dbs1.example.com',
    include_dml              =>  TRUE,
    include_ddl              =>  FALSE);
END;
/

In this case, the ADD_TABLE_RULES procedure generates a rule with a rule condition similar to the following:

(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'LOCATIONS')) 
and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )

Notice that there is no condition relating to the tag. If a capture process uses a positive rule set that contains this rule, then the rule evaluates to TRUE if the tag in a redo entry for a DML change to the hr.locations table is a non-NULL value, such as '0' or '1'. The rule also evaluates to TRUE if the tag is NULL. So, if a redo entry contains a DML change to the hr.locations table, then the change is captured regardless of the value for the tag.

To modify the is_null_tag condition in an existing system-created rule, use an appropriate procedure in the DBMS_STREAMS_ADM package to create a rule that is the same as the rule you want to modify, except for the is_null_tag condition. Next, use the REMOVE_RULE procedure in the DBMS_STREAMS_ADM package to remove the old rule from the appropriate rule set. In addition, you can use the and_condition parameter for the procedures that create rules in the DBMS_STREAMS_ADM package to add conditions relating to tags to system-created rules.

If you created a rule with the DBMS_RULE_ADM package, then you can add, remove, or modify the is_null_tag condition in the rule by using the ALTER_RULE procedure in this package.


See Also:


Tags and Online Backup Statements

If you are using global rules to capture and apply DDL changes for an entire database, then online backup statements will be captured, propagated, and applied by default. Typically, database administrators do not want to replicate online backup statements. Instead, they only want them to run at the database where they are executed originally. An online backup statement uses the BEGIN BACKUP and END BACKUP clauses in an ALTER TABLESPACE or ALTER DATABASE statement.

To avoid replicating online backup statements, you can use one of the following strategies:


Note:

If you use Recovery Manager (RMAN) to perform an online backup, then the online backup statements are not used, and there is no need to set Oracle Streams tags for backups.


See Also:

Oracle Database Backup and Recovery User's Guide for information about making backups

Tags and an Apply Process

An apply process generates entries in the redo log of a destination database when it applies DML or DDL changes. For example, if the apply process applies a change that updates a row in a table, then that change is recorded in the redo log at the destination database. You can control the tags in these redo entries by setting the apply_tag parameter in the CREATE_APPLY or ALTER_APPLY procedure in the DBMS_APPLY_ADM package. For example, an apply process can generate redo tags that are equivalent to the hexadecimal value of '0' (zero) or '1'.

The default tag value generated in the redo log by an apply process is '00' (double zero). This value is the default tag value for an apply process if you use a procedure in the DBMS_STREAMS_ADM package or the CREATE_APPLY procedure in the DBMS_APPLY_ADM package to create the apply process. There is nothing special about this value beyond the fact that it is a non-NULL value. The fact that it is a non-NULL value is important because rules created by the DBMS_STREAMS_ADM package by default contain a condition that evaluates to TRUE only if the tag is NULL in a redo entry or an LCR. You can alter the tag value for an existing apply process using the ALTER_APPLY procedure in the DBMS_APPLY_ADM package.

Redo entries generated by an apply handler for an apply process have the tag value of the apply process, unless the handler sets the tag to a different value using the SET_TAG procedure. If a procedure DML handler, DDL handler, or message handler calls the SET_TAG procedure in the DBMS_STREAMS package, then any subsequent redo entries generated by the handler will include the tag specified in the SET_TAG call, even if the tag for the apply process is different. When the handler exits, any subsequent redo entries generated by the apply process have the tag specified for the apply process.


See Also:


Oracle Streams Tags in a Replication Environment

In an Oracle Streams environment that includes multiple databases sharing data bidirectionally, you can use tags to avoid change cycling. Change cycling means sending a change back to the database where it originated. Typically, change cycling should be avoided because it can result in each change going through endless loops back to the database where it originated. Such loops can result in unintended data in the database and tax the networking and computer resources of an environment. By default, Oracle Streams is designed to avoid change cycling.

Using tags and appropriate rules for Oracle Streams capture processes, synchronous captures, propagations, and apply processes, you can avoid such change cycles. This section describes common Oracle Streams environments and how you can use tags and rules to avoid change cycling in these environments.

This section contains these topics:

N-Way Replication Environments

An n-way replication environment is one in which each database is a source database for every other database, and each database is a destination database of every other database. Each database communicates directly with every other database.

For example, consider an environment that replicates the database objects and data in the hrmult schema between three Oracle databases: mult1.example.com, mult2.example.com, and mult3.example.com. DML and DDL changes made to tables in the hrmult schema are captured at all three databases in the environment and propagated to each of the other databases in the environment, where changes are applied. Figure 10-1 illustrates a sample n-way replication environment.

Figure 10-1 Each Database Is a Source and Destination Database

Description of Figure 10-1 follows
Description of "Figure 10-1 Each Database Is a Source and Destination Database"

You can avoid change cycles by configuring such an environment in the following way:

  • Configure one apply process at each database to generate non-NULL redo tags for changes from each source database. If you use a procedure in the DBMS_STREAMS_ADM package to create an apply process, then the apply process generates non-NULL tags with a value of '00' in the redo log by default. In this case, no further action is required for the apply process to generate non-NULL tags.

    If you use the CREATE_APPLY procedure in the DBMS_APPLY_ADM package to create an apply process, then do not set the apply_tag parameter. Again, the apply process generates non-NULL tags with a value of '00' in the redo log by default, and no further action is required.

  • Configure the capture process at each database to capture changes only if the tag in the redo entry for the change is NULL. You do this by ensuring that each DML rule in the positive rule set used by the capture process has the following condition:

    :dml.is_null_tag()='Y'

    Each DDL rule should have the following condition:

    :ddl.is_null_tag()='Y'

    These rule conditions indicate that the capture process captures a change only if the tag for the change is NULL. If you use the DBMS_STREAMS_ADM package to generate rules, then each rule has such a condition by default.

This configuration prevents change cycling because all of the changes applied by the apply processes are never recaptured (they were captured originally at the source databases). Each database sends all of its changes to the hrmult schema to every other database. So, in this environment, no changes are lost, and all databases are synchronized. Figure 10-2 illustrates how tags can be used in a database in an n-way replication environment.

Figure 10-2 Tag Use When Each Database Is a Source and Destination Database

Description of Figure 10-2 follows
Description of "Figure 10-2 Tag Use When Each Database Is a Source and Destination Database"


See Also:

Oracle Streams Extended Examples for a detailed illustration of this example

Hub-and-Spoke Replication Environments

A hub-and-spoke replication environment is one in which a primary database, or hub, communicates with secondary databases, or spokes. The spokes do not communicate directly with each other. In a hub-and-spoke replication environment, the spokes might or might not allow changes to the replicated database objects.

If the spokes do not allow changes to the replicated database objects, then the primary database captures local changes to the shared data and propagates these changes to all secondary databases, where these changes are applied at each secondary database locally. Change cycling is not possible when none of the secondary databases allow changes to the replicated database objects because changes to the replicated database objects are captured in only one location.

If the spokes allow changes to the replicated database objects, then changes are captured, propagated, and applied in the following way:

  • The primary database captures local changes to the shared data and propagates these changes to all secondary databases, where these changes are applied at each secondary database locally.

  • Each secondary database captures local changes to the shared data and propagates these changes to the primary database only, where these changes are applied at the primary database locally.

  • The primary database applies changes from each secondary database locally. Next, these changes are captured at the primary database and propagated to all secondary databases, except for the one at which the change originated. Each secondary database applies the changes from the other secondary databases locally, after they have gone through the primary database. This configuration is an example of apply forwarding.

    An alternate scenario might use queue forwarding. If this environment used queue forwarding, then changes from secondary databases that are applied at the primary database are not captured at the primary database. Instead, these changes are forwarded from the queue at the primary database to all secondary databases, except for the one at which the change originated.


See Also:

Oracle Streams Concepts and Administration for more information about apply forwarding and queue forwarding

For example, consider an environment that replicates the database objects and data in the hr schema between one primary database named ps1.example.com and three secondary databases named ps2.example.com, ps3.example.com, and ps4.example.com. DML and DDL changes made to tables in the hr schema are captured at the primary database and at the three secondary databases in the environment. Next, these changes are propagated and applied as described previously. The environment uses apply forwarding, not queue forwarding, to share data between the secondary databases through the primary database. Figure 10-3 illustrates a sample environment which has one primary database and multiple secondary databases.

Figure 10-3 Primary Database Sharing Data with Several Secondary Databases

Description of Figure 10-3 follows
Description of "Figure 10-3 Primary Database Sharing Data with Several Secondary Databases"

You can avoid change cycles by configuring the environment in the following way:

  • Configure each apply process at the primary database ps1.example.com to generate non-NULL redo tags that indicate the site from which it is receiving changes. In this environment, the primary database has at least one apply process for each secondary database from which it receives changes. For example, if an apply process at the primary database receives changes from the ps2.example.com secondary database, then this apply process can generate a raw value that is equivalent to the hexadecimal value '2' for all changes it applies. You do this by setting the apply_tag parameter in the CREATE_APPLY or ALTER_APPLY procedure in the DBMS_APPLY_ADM package to the non-NULL value.

    For example, run the following procedure to create an apply process that generates redo entries with tags that are equivalent to the hexadecimal value '2':

    BEGIN
  DBMS_APPLY_ADM.CREATE_APPLY(
    queue_name      => 'strmadmin.streams_queue',
    apply_name      => 'apply_ps2',
    rule_set_name   => 'strmadmin.apply_rules_ps2',
    apply_tag       => HEXTORAW('2'),
    apply_captured  => TRUE);
END;
/

  • Configure the apply process at each secondary database to generate non-NULL redo tags. The exact value of the tags is irrelevant if it is non-NULL. In this environment, each secondary database has one apply process that applies changes from the primary database.

    If you use a procedure in the DBMS_STREAMS_ADM package to create an apply process, then the apply process generates non-NULL tags with a value of '00' in the redo log by default. In this case, no further action is requi^.red for the apply process to generate non-NULL tags.

    For example, assuming no apply processes exist at the secondary databases, run the ADD_SCHEMA_RULES procedure in the DBMS_STREAMS_ADM package at each secondary database to create an apply process that generates non-NULL redo entries with tags that are equivalent to the hexadecimal value '00':

    BEGIN
  DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
    schema_name     => 'hr',   
    streams_type    => 'apply',
    streams_name    => 'apply',
    queue_name      => 'strmadmin.streams_queue',
    include_dml     => TRUE,
    include_ddl     => TRUE,
    source_database => 'ps1.example.com',
    inclusion_rule  => TRUE);
END;
/

  • Configure the capture process at the primary database to capture changes to the shared data regardless of the tags. You do this by setting the include_tagged_lcr parameter to TRUE when you run one of the procedures that generate capture process rules in the DBMS_STREAMS_ADM package. If you use the DBMS_RULE_ADM package to create rules for the capture process at the primary database, then ensure that the rules do not contain is_null_tag conditions, because these conditions involve tags in the redo log.

    For example, run the following procedure at the primary database to produce one DML capture process rule and one DDL capture process rule that each have a condition that evaluates to TRUE for changes in the hr schema, regardless of the tag for the change:

    BEGIN
  DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
    schema_name         => 'hr',   
    streams_type        => 'capture',
    streams_name        => 'capture',
    queue_name          => 'strmadmin.streams_queue',
    include_tagged_lcr  => TRUE, -- Note parameter setting
    include_dml         => TRUE,
    include_ddl         => TRUE,
    inclusion_rule      => TRUE);
END;
/

  • Configure the capture process at each secondary database to capture changes only if the tag in the redo entry for the change is NULL. You do this by ensuring that each DML rule in the positive rule set used by the capture process at the secondary database has the following condition:

    :dml.is_null_tag()='Y'

    DDL rules should have the following condition:

    :ddl.is_null_tag()='Y'

    These rules indicate that the capture process captures a change only if the tag for the change is NULL. If you use the DBMS_STREAMS_ADM package to generate rules, then each rule has one of these conditions by default. If you use the DBMS_RULE_ADM package to create rules for the capture process at a secondary database, then ensure that each rule contains one of these conditions.

  • Configure one propagation from the queue at the primary database to the queue at each secondary database. Each propagation should use a positive rule set with rules that instruct the propagation to propagate all LCRs in the queue at the primary database to the queue at the secondary database, except for changes that originated at the secondary database.

    For example, if a propagation propagates changes to the secondary database ps2.example.com, whose tags are equivalent to the hexadecimal value '2', then the rules for the propagation should propagate all LCRs relating to the hr schema to the secondary database, except for LCRs with a tag of '2'. For row LCRs, such rules should include the following condition:

    :dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('2')

    For DDL LCRs, such rules should include the following condition:

    :ddl.get_tag() IS NULL OR :ddl.get_tag()!=HEXTORAW('2')

    Alternatively, you can add rules to the negative rule set for the propagation so that the propagation discards LCRs with the tag value. For row LCRs, such rules should include the following condition:

    :dml.get_tag()=HEXTORAW('2')

    For DDL LCRs, such rules should include the following condition:

    :ddl.get_tag()=HEXTORAW('2')

    You can use the and_condition parameter in a procedure in the DBMS_STREAMS_ADM package to add these conditions to system-created rules, or you can use the CREATE_RULE procedure in the DBMS_RULE_ADM package to create rules with these conditions. When you specify the condition in the and_condition parameter, specify :lcr instead of :dml or :ddl. See Oracle Streams Concepts and Administration for more information about the and_condition parameter.

  • Configure one propagation from the queue at each secondary database to the queue at the primary database. A queue at one of the secondary databases contains only local changes made by user sessions and applications at the secondary database, not changes made by an apply process. Therefore, no further configuration is necessary for these propagations.

This configuration prevents change cycling in the following way:

  • Changes that originated at a secondary database are never propagated back to that secondary database.

  • Changes that originated at the primary database are never propagated back to the primary database.

  • All changes made to the shared data at any database in the environment are propagated to every other database in the environment.

So, in this environment, no changes are lost, and all databases are synchronized.

Figure 10-4 illustrates how tags are used at the primary database ps1.example.com.

Figure 10-4 Tags Used at the Primary Database

Description of Figure 10-4 follows
Description of "Figure 10-4 Tags Used at the Primary Database"

Figure 10-5 illustrates how tags are used at one of the secondary databases (ps2.example.com).

Figure 10-5 Tags Used at a Secondary Database

Description of Figure 10-5 follows
Description of "Figure 10-5 Tags Used at a Secondary Database"


See Also:

Oracle Database 2 Day + Data Replication and Integration Guide for more information about hub-and-spoke replication environments and for examples that configure such environments

Hub-and-Spoke Replication Environment with Several Extended Secondary Databases

In this environment, one primary database shares data with several secondary databases, but the secondary databases have other secondary databases connected to them, which will be called remote secondary databases. This environment is an extension of the environment described in "Hub-and-Spoke Replication Environments".

If a remote secondary database allows changes to the replicated database objects, then the remote secondary database does not share data directly with the primary database. Instead, it shares data indirectly with the primary database through a secondary database. So, the shared data exists at the primary database, at each secondary database, and at each remote secondary database. Changes made at any of these databases can be captured and propagated to all of the other databases. Figure 10-6 illustrates an environment with one primary database and multiple extended secondary databases.

Figure 10-6 Primary Database and Several Extended Secondary Databases

Description of Figure 10-6 follows
Description of "Figure 10-6 Primary Database and Several Extended Secondary Databases"

In such an environment, you can avoid change cycling in the following way:

  • Configure the primary database in the same way that it is configured in the example described in "Hub-and-Spoke Replication Environments".

  • Configure each remote secondary database similar to the way that each secondary database is configured in the example described in "Hub-and-Spoke Replication Environments". The only difference is that the remote secondary databases share data directly with secondary databases, not the primary database.

  • At each secondary database, configure one apply process to apply changes from the primary database with a redo tag value that is equivalent to the hexadecimal value '00'. This value is the default tag value for an apply process.

  • At each secondary database, configure one apply process to apply changes from each of its remote secondary databases with a redo tag value that is unique for the remote secondary database.

  • Configure the capture process at each secondary database to capture all changes to the shared data in the redo log, regardless of the tag value for the changes.

  • Configure one propagation from the queue at each secondary database to the queue at the primary database. The propagation should use a positive rule set with rules that instruct the propagation to propagate all LCRs in the queue at the secondary database to the queue at the primary database, except for changes that originated at the primary database. You do this by adding a condition to the rules that evaluates to TRUE only if the tag in the LCR does not equal '00'. For example, enter a condition similar to the following for row LCRs:

    :dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('00')

    You can use the and_condition parameter in a procedure in the DBMS_STREAMS_ADM package to add this condition to system-created rules, or you can use the CREATE_RULE procedure in the DBMS_RULE_ADM package to create rules with this condition. When you specify the condition in the and_condition parameter, specify :lcr instead of :dml or :ddl. See Oracle Streams Concepts and Administration for more information about the and_condition parameter.

  • Configure one propagation from the queue at each secondary database to the queue at each remote secondary database. Each propagation should use a positive rule set with rules that instruct the propagation to propagate all LCRs in the queue at the secondary database to the queue at the remote secondary database, except for changes that originated at the remote secondary database. You do this by adding a condition to the rules that evaluates to TRUE only if the tag in the LCR does not equal the tag value for the remote secondary database.

    For example, if the tag value of a remote secondary database is equivalent to the hexadecimal value '19', then enter a condition similar to the following for row LCRs:

    :dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('19')

    You can use the and_condition parameter in a procedure in the DBMS_STREAMS_ADM package to add this condition to system-created rules, or you can use the CREATE_RULE procedure in the DBMS_RULE_ADM package to create rules with this condition. When you specify the condition in the and_condition parameter, specify :lcr instead of :dml or :ddl. See Oracle Streams Concepts and Administration for more information about the and_condition parameter.

By configuring the environment in this way, you prevent change cycling, and no changes originating at any database are lost.


See Also:

Oracle Database 2 Day + Data Replication and Integration Guide for more information about hub-and-spoke replication environments and for examples that configure such environments

Managing Oracle Streams Tags

You can set or get the value of the tags generated by the current session or by an apply process. The following sections describe how to set and get tag values.


See Also:

"Monitoring Oracle Streams Tags"

Managing Oracle Streams Tags for the Current Session

This section contains instructions for setting and getting the tag for the current session.

Setting the Tag Values Generated by the Current Session

You can set the tag for all redo entries generated by the current session using the SET_TAG procedure in the DBMS_STREAMS package. For example, to set the tag to the hexadecimal value of '1D' in the current session, run the following procedure:

BEGIN
   DBMS_STREAMS.SET_TAG(
      tag  =>  HEXTORAW('1D'));
END;
/

After running this procedure, each redo entry generated by DML or DDL statements in the current session will have a tag value of 1D. Running this procedure affects only the current session.

The following are considerations for the SET_TAG procedure:

  • This procedure is not transactional. That is, the effects of SET_TAG cannot be rolled back.

  • If the SET_TAG procedure is run to set a non-NULL session tag before a data dictionary build has been performed on the database, then the redo entries for a transaction that started before the dictionary build might not include the specified tag value for the session. Therefore, perform a data dictionary build before using the SET_TAG procedure in a session. A data dictionary build happens when the DBMS_CAPTURE_ADM.BUILD procedure is run. The BUILD procedure can be run automatically when a capture process is created.

Getting the Tag Value for the Current Session

You can get the tag for all redo entries generated by the current session using the GET_TAG procedure in the DBMS_STREAMS package. For example, to get the hexadecimal value of the tags generated in the redo entries for the current session, run the following procedure:

SET SERVEROUTPUT ON
DECLARE
   raw_tag RAW(2048);
BEGIN
   raw_tag := DBMS_STREAMS.GET_TAG();
   DBMS_OUTPUT.PUT_LINE('Tag Value = ' || RAWTOHEX(raw_tag));
END;
/

You can also display the tag value for the current session by querying the DUAL view:

SELECT DBMS_STREAMS.GET_TAG FROM DUAL;

Managing Oracle Streams Tags for an Apply Process

This section contains instructions for setting and removing the tag for an apply process.


See Also:


Setting the Tag Values Generated by an Apply Process

An apply process generates redo entries when it applies changes to a database or invokes handlers. You can set the default tag for all redo entries generated by an apply process when you create the apply process using the CREATE_APPLY procedure in the DBMS_APPLY_ADM package, or when you alter an existing apply process using the ALTER_APPLY procedure in the DBMS_APPLY_ADM package. In both of these procedures, set the apply_tag parameter to the value you want to specify for the tags generated by the apply process.

For example, to set the value of the tags generated in the redo log by an existing apply process named strep01_apply to the hexadecimal value of '7', run the following procedure:

BEGIN
  DBMS_APPLY_ADM.ALTER_APPLY(
     apply_name  =>  'strep01_apply',
     apply_tag   =>  HEXTORAW('7'));
END;
/

After running this procedure, each redo entry generated by the apply process will have a tag value of 7.

Removing the Apply Tag for an Apply Process

You remove the apply tag for an apply process by setting the remove_apply_tag parameter to TRUE in the ALTER_APPLY procedure in the DBMS_APPLY_ADM package. Removing the apply tag means that each redo entry generated by the apply process has a NULL tag. For example, the following procedure removes the apply tag from an apply process named strep01_apply.

BEGIN
  DBMS_APPLY_ADM.ALTER_APPLY(
    apply_name       => 'strep01_apply',
    remove_apply_tag => TRUE);
END;
/

Monitoring Oracle Streams Tags

The following sections contain queries that you can run to display the Oracle Streams tag for the current session and the default tag for each apply process:


See Also:


Displaying the Tag Value for the Current Session

You can display the tag value generated in all redo entries for the current session by querying the DUAL view:

SELECT DBMS_STREAMS.GET_TAG FROM DUAL;

Your output looks similar to the following:

GET_TAG
--------------------------------------------------------------------------------
1D

You can also determine the tag for a session by calling the DBMS_STREAMS.GET_TAG function.

Displaying the Default Tag Value for Each Apply Process

You can get the default tag for all redo entries generated by each apply process by querying for the APPLY_TAG value in the DBA_APPLY data dictionary view. For example, to get the hexadecimal value of the default tag generated in the redo entries by each apply process, run the following query:

COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A30
COLUMN APPLY_TAG HEADING 'Tag Value' FORMAT A30

SELECT APPLY_NAME, APPLY_TAG FROM DBA_APPLY;

Your output looks similar to the following:

Apply Process Name             Tag Value
------------------------------ ------------------------------
APPLY_FROM_MULT2               00
APPLY_FROM_MULT3               00

A handler or custom rule-based transformation function associated with an apply process can get the tag by calling the DBMS_STREAMS.GET_TAG function.

PK=PK+AOEBPS/config_flex.htm Flexible Oracle Streams Replication Configuration

3 Flexible Oracle Streams Replication Configuration

This chapter describes flexible methods for configuring Oracle Streams replication between two or more databases. This chapter includes step-by-step instructions for configuring each Oracle Streams component to build a single-source or multiple-source replication environment.

One common type of single-source replication environment is a hub-and-spoke replication environment that does not allow changes to the replicated database objects in the spoke databases. The following are common types of multiple-source replication environments:

Oracle Database 2 Day + Data Replication and Integration Guide describes these common types of replication environments in detail.

If possible, consider using a simple method for configuring Oracle Streams replication described in Chapter 2, "Simple Oracle Streams Replication Configuration". You can either use the Oracle Streams tool in Enterprise Manager or a single procedure in the DBMS_STREAMS_ADM package configure all of the Oracle Streams components in a replication environment with two databases. Also, you can use a simple method and still meet custom requirements for your replication environment in one of the following ways:

However, if you require more flexibility in your Oracle Streams replication configuration than what is available with the simple methods, then you can follow the instructions in this chapter to configure the environment.

This chapter contains these topics:


Note:

  • The instructions in the following sections assume you will use the DBMS_STREAMS_ADM package to configure your Oracle Streams environment. If you use other packages, then extra steps might be necessary for each task.

  • Certain types of database objects are not supported by Oracle Streams. When you configure an Oracle Streams environment, ensure that no capture process attempts to capture changes to an unsupported database object. Also, ensure that no synchronous capture or apply process attempts to process changes to unsupported columns. To list unsupported database objects and unsupported columns, query the DBA_STREAMS_UNSUPPORTED and DBA_STREAMS_COLUMNS data dictionary views.



See Also:

Oracle Streams Concepts and Administration for instructions on determining which database objects are not supported by Oracle Streams

Creating a New Oracle Streams Single-Source Environment

This section lists the general steps to perform when creating a new single-source Oracle Streams environment. A single-source environment is one in which there is only one source database for replicated data. There can be multiple source databases in a single-source environment, but no two source databases capture any of the same data. A one-way replication environment with two databases is an example of a single-source environment.

Before starting capture processes, creating synchronous captures, and configuring propagations in a new Oracle Streams environment, ensure that any propagations or apply processes that will receive LCRs are configured to handle these LCRs. That is, the propagations or apply processes should exist, and each one should be associated with rule sets that handle the LCRs appropriately. If these propagations and apply processes are not configured properly to handle these LCRs, then LCRs can be lost.

This example assumes that the replicated database objects are read-only at the destination databases. If the replicated database objects are read/write at the destination databases, then the replication environment will not stay synchronized because Oracle Streams is not configured to replicate the changes made to the replicated objects at the destination databases.

Figure 3-1 shows an example Oracle Streams single-source replication environment.

Figure 3-1 Example Oracle Streams Single-Source Environment

Description of Figure 3-1 follows
Description of "Figure 3-1 Example Oracle Streams Single-Source Environment"

You can create an Oracle Streams replication environment that is more complicated than the one shown in Figure 3-1. For example, a single-source Oracle Streams replication environment can use downstream capture and directed networks.

In general, if you are configuring a new Oracle Streams single-source environment in which changes to replicated database objects are captured at one database and then propagated and applied at remote databases, then you should configure the environment in the following order:

  1. Make the necessary decisions about configuring the replication environment. See "Decisions to Make Before Configuring Oracle Streams Replication".

  2. Complete the necessary tasks to prepare each database in your environment for Oracle Streams. See "Tasks to Complete Before Configuring Oracle Streams Replication".

    Some of these tasks might not be required at certain databases.

  3. Create any necessary ANYDATA queues that do not already exist. When you create a capture process, synchronous capture, or apply process, you associate the process with a specific ANYDATA queue. When you create a propagation, you associate it with a specific source queue and destination queue. See "Creating an ANYDATA Queue" for instructions.

  4. Specify supplemental logging at each source database for any replicated database object. See "Specifying Supplemental Logging" for instructions.

  5. At each database, create the required capture processes, synchronous captures, propagations, and apply processes for your environment. You can create capture processes, propagations, and apply processes in any order. If you create synchronous captures, then create them after you create the relevant propagations and apply processes.

    • Create one or more capture processes at each database that will capture changes with a capture process. Ensure that each capture process uses rule sets that are appropriate for capturing changes. Do not start the capture processes you create. Oracle recommends that you use only one capture process for each source database. See "Configuring a Capture Process" for instructions.

      When you use a procedure in the DBMS_STREAMS_ADM package to add the capture process rules, it automatically runs the PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively, if the capture process is a local capture process or a downstream capture process with a database link to the source database.

      You must run the appropriate procedure to prepare for instantiation manually if any of the following conditions is true:

      • You use the DBMS_RULE_ADM package to add or modify rules.

      • You use an existing capture process and do not add capture process rules for any replicated object.

      • You use a downstream capture process with no database link to the source database.

      If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.

    • Create all propagations that send the captured LCRs from a source queue to a destination queue. Ensure that each propagation uses rule sets that are appropriate for sending changes. See "Creating Oracle Streams Propagations Between ANYDATA Queues" for instructions.

    • Create one or more apply processes at each database that will apply changes. Ensure that each apply process uses rule sets that are appropriate for applying changes. Do not start the apply processes you create. See Chapter 7, "Configuring Implicit Apply" for instructions.

    • Create one or more synchronous captures at each database that will capture changes with a synchronous capture. Ensure that each synchronous capture use a rule set that is appropriate for capturing changes. Do not create the synchronous capture until you create all of the propagations and apply processes that will process its LCRs. See "Configuring Synchronous Capture" for instructions.

      When you use a procedure in the DBMS_STREAMS_ADM package to add the synchronous capture rules, it automatically runs the PREPARE_SYNC_INSTANTIATION function in the DBMS_CAPTURE_ADM package for the specified table.

  6. Either instantiate, or set the instantiation SCN for, each database object for which changes are applied by an apply process. If the database objects do not exist at a destination database, then instantiate them using export/import, transportable tablespaces, or RMAN. If the database objects already exist at a destination database, then set the instantiation SCNs for them manually.

    • To instantiate database objects using export/import, first export them at the source database. Next, import them at the destination database. See Chapter 8, "Instantiation and Oracle Streams Replication".

      Do not allow any changes to the database objects being exported during export at the source database. Do not allow changes to the database objects being imported during import at the destination database.

      You can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.

    • To set the instantiation SCN for a table, schema, or database manually, run the appropriate procedure or procedures in the DBMS_APPLY_ADM package at the destination database:

      • SET_TABLE_INSTANTIATION_SCN

      • SET_SCHEMA_INSTANTIATION_SCN

      • SET_GLOBAL_INSTANTIATION_SCN

      When you run one of these procedures, you must ensure that the replicated objects at the destination database are consistent with the source database as of the instantiation SCN.

      If you run SET_GLOBAL_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to TRUE so that the instantiation SCN also is set for each schema at the destination database and for the tables owned by these schemas.

      If you run SET_SCHEMA_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to TRUE so that the instantiation SCN also is set for each table in the schema.

      If you set the recursive parameter to TRUE in the SET_GLOBAL_INSTANTIATION_SCN procedure or the SET_SCHEMA_INSTANTIATION_SCN procedure, then a database link from the destination database to the source database is required. This database link must have the same name as the global name of the source database and must be accessible to the user who executes the procedure. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.

      Alternatively, you can perform a metadata export/import to set the instantiation SCNs for existing database objects. If you choose this option, then ensure that no rows are imported. Also, ensure that the replicated database objects at all of the destination databases are consistent with the source database that performed the export at the time of the export. If you are sharing DML changes only, then table level export/import is sufficient. If you are sharing DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.

  7. Start each apply process you created in Step 5 using the START_APPLY procedure in the DBMS_APPLY_ADM package.

  8. Start each capture process you created in Step 5 using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.

When you are configuring the environment, remember that capture processes and apply processes are stopped when they are created. However, synchronous captures start to capture changes immediately when they are created, and propagations are scheduled to send LCRs immediately when they are created. A capture process or synchronous capture must be created before the relevant objects are instantiated at a remote destination database. You must create the propagations and apply processes before starting the capture process or creating the synchronous capture, and you must instantiate the objects before running the whole stream.


See Also:


Creating a New Oracle Streams Multiple-Source Environment

This section lists the general steps to perform when creating a new multiple-source Oracle Streams environment. A multiple-source environment is one in which there are multiple source databases for any of the replicated data. An n-way replication environment is an example of a multiple-source environment.

This example uses the following terms:

Figure 3-2 shows an example multiple-source Oracle Streams environment.

Figure 3-2 Example Oracle Streams Multiple-Source Environment

Description of Figure 3-2 follows
Description of "Figure 3-2 Example Oracle Streams Multiple-Source Environment"

You can create an Oracle Streams replication environment that is more complicated than the one shown in Figure 3-2. For example, a multiple-source Oracle Streams replication environment can use downstream capture and directed networks.

When there are multiple source databases in an Oracle Streams replication environment, change cycling is possible. Change cycling happens when a change is sent back to the database where it originated. Typically, you should avoid change cycling. Before you configure your replication environment, see Chapter 10, "Oracle Streams Tags", and ensure that you configure the replication environment to avoid change cycling.

Complete the following steps to create a multiple-source environment:


Note:

Ensure that no changes are made to the objects being shared at a database you are adding to the Oracle Streams environment until the instantiation at the database is complete.

  1. Make the necessary decisions about configuring the replication environment. See "Decisions to Make Before Configuring Oracle Streams Replication".

  2. Complete the necessary tasks to prepare each database in your environment for Oracle Streams. See "Tasks to Complete Before Configuring Oracle Streams Replication".

    Some of these tasks might not be required at certain databases.

  3. At each populated database, specify any necessary supplemental logging for the replicated database objects. See "Specifying Supplemental Logging" for instructions.

  4. Create any necessary ANYDATA queues that do not already exist. When you create a capture process, synchronous capture, or apply process, you associate the process with a specific ANYDATA queue. When you create a propagation, you associate it with a specific source queue and destination queue. See "Creating an ANYDATA Queue" for instructions.

  5. At each database, create the required capture processes, synchronous captures, propagations, and apply processes for your environment. You can create capture processes, propagations, and apply processes in any order. If you create synchronous captures, then create them after you create the relevant propagations and apply processes.

    • Create one or more capture processes at each database that will capture changes with a capture process. Ensure that each capture process uses rule sets that are appropriate for capturing changes. Do not start the capture processes you create. Oracle recommends that you use only one capture process for each source database. See "Configuring a Capture Process" for instructions.

      When you use a procedure in the DBMS_STREAMS_ADM package to add the capture process rules, it automatically runs the PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively, if the capture process is a local capture process or a downstream capture process with a database link to the source database.

      You must run the appropriate procedure to prepare for instantiation manually if any of the following conditions is true:

      • You use the DBMS_RULE_ADM package to add or modify rules.

      • You use an existing capture process and do not add capture process rules for any replicated database object.

      • You use a downstream capture process with no database link to the source database.

      If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.

    • Create all propagations that propagate the captured LCRs from a source queue to a destination queue. Ensure that each propagation uses rule sets that are appropriate for propagating changes. See "Creating Oracle Streams Propagations Between ANYDATA Queues" for instructions.

    • Create one or more apply processes at each database that will apply changes. Ensure that each apply process uses rule sets that are appropriate for applying changes. Do not start the apply processes you create. See Chapter 7, "Configuring Implicit Apply" for instructions.

    • Create one or more synchronous captures at each database that will capture changes with a synchronous capture. Ensure that each synchronous capture uses rule sets that are appropriate for capturing changes. Do not create the synchronous capture until you create all of the propagations and apply processes that will process its LCRs. See "Configuring Synchronous Capture" for instructions.

      When you use a procedure in the DBMS_STREAMS_ADM package to add the synchronous capture rules, it automatically runs the PREPARE_SYNC_INSTANTIATION function in the DBMS_CAPTURE_ADM package for the specified table.

After completing these steps, complete the steps in each of the following sections that apply to your environment. You might need to complete the steps in only one of these sections or in both of these sections:

Configuring Populated Databases When Creating a Multiple-Source Environment

After completing the steps in "Creating a New Oracle Streams Multiple-Source Environment", complete the following steps for the populated databases if your environment has multiple populated databases:

  1. For each populated database, set the instantiation SCN at each of the other populated databases in the environment that will be a destination database of the populated source database. These instantiation SCNs must be set, and only the changes made at a particular populated database that are committed after the corresponding SCN for that database will be applied at another populated database.

    For each populated database, you can set these instantiation SCNs in one of the following ways:

    • Perform a metadata only export of the replicated database objects at the populated database and import the metadata at each of the other populated databases. Such an import sets the required instantiation SCNs for the populated database at the other populated databases. Ensure that no rows are imported. Also, ensure that the replicated database objects at each populated database performing a metadata import are consistent with the populated database that performed the metadata export at the time of the export.

      If you are replicating DML changes only, then table level export/import is sufficient. If you are replicating DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.

    • Set the instantiation SCNs manually at each of the other populated databases. Do this for each of the replicated database objects. Ensure that the replicated database objects at each populated database are consistent with the instantiation SCNs you set at that database. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.

Adding Replicated Objects to Import Databases When Creating a New Environment

After completing the steps in "Creating a New Oracle Streams Multiple-Source Environment", complete the following steps for the import databases:

  1. Pick the populated database that you will use as the export database. Do not perform the instantiations yet.

  2. For each import database, set the instantiation SCNs at all of the other databases in the environment that will be a destination database of the import database. In this case, the import database will be the source database for these destination databases. The databases where you set the instantiation SCNs can include populated databases and other import databases.

    1. If one or more schemas will be created at an import database during instantiation or by a subsequent replicated DDL change, then run the SET_GLOBAL_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for this import database at all of the other databases in the environment.

    2. If a schema exists at an import database, and one or more tables will be created in the schema during instantiation or by a subsequent replicated DDL change, then run the SET_SCHEMA_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for the schema at all of the other databases in the environment for the import database. Do this for each such schema.

    See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.

    Because you run these procedures before any tables are instantiated at the import databases, and because the local capture processes or synchronous captures are configured already for these import databases, you will not need to run the SET_TABLE_INSTANTIATION_SCN procedure for each table created during the instantiation. Instantiation SCNs will be set automatically for these tables at all of the other databases in the environment that will be destination databases of the import database.

  3. At the export database you chose in Step 1, perform an export of the replicated database objects. Next, perform an import of the replicated database objects at each import database. See Chapter 8, "Instantiation and Oracle Streams Replication" and Oracle Database Utilities for information about using export/import.

    Do not allow any changes to the database objects being exported while exporting these database objects at the source database. Do not allow changes to the database objects being imported while importing these database objects at the destination database.

    You can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.

  4. For each populated database, except for the export database, set the instantiation SCNs at each import database that will be a destination database of the populated source database. These instantiation SCNs must be set, and only the changes made at a populated database that are committed after the corresponding SCN for that database will be applied at an import database.

    You can set these instantiation SCNs in one of the following ways:

    • Perform a metadata only export at each populated database and import the metadata at each import database. Each import sets the required instantiation SCNs for the populated database at the import database. In this case, ensure that the replicated database objects at the import database are consistent with the populated database at the time of the export.

      If you are sharing DML changes only, then table level export/import is sufficient. If you are sharing DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.

    • For each populated database, set the instantiation SCN manually for each replicated database object at each import database. Ensure that the replicated database objects at each import database are consistent with the populated database as of the corresponding instantiation SCN. See v"Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.

Complete the Multiple-Source Environment Configuration

Before completing the steps in this section, you should have completed the following tasks:

When all of the previous configuration steps are finished, complete the following steps:

  1. At each database, configure conflict resolution if conflicts are possible. See Chapter 9, "Oracle Streams Conflict Resolution" for instructions.

  2. Start each apply process in the environment using the START_APPLY procedure in the DBMS_APPLY_ADM package.

  3. Start each capture process the environment using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.


See Also:

Oracle Streams Extended Examples for a detailed example that creates a multiple-source environment

PKKo,vPK+AOEBPS/cover.htmO Cover

Oracle Corporation

PK[pTOPK+AOEBPS/ptrep_best.htm7 Oracle Streams Replication Best Practices

Part III

Oracle Streams Replication Best Practices

You can configure Oracle Streams replication in many different ways depending on your business requirements. For example, Oracle Streams can be configured to fulfill the following requirements:

The following chapters in this part describe Oracle Streams replication best practices:

PK96< 7 PK+AOEBPS/title.htm Oracle Streams Replication Administrator's Guide, 11g Release 2 (11.2)

Oracle® Streams

Replication Administrator's Guide

11g Release 2 (11.2)

E10705-09

August 2011

Oracle Streams Replication Administrator's Guide, 11g Release 2 (11.2)

E10705-09

Copyright © 2003, 2011, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Randy Urbano

Contributors:  Katherine Weill, Nimar Arora, Lance Ashdown, Ram Avudaiappan, Neerja Bhatt, Ragamayi Bhyravabhotla, Alan Downing, Curt Elsbernd, Yong Feng, Jairaj Galagali, Lei Gao, Thuvan Hoang, Lewis Kaplan, Tianshu Li, Jing Liu, Edwina Lu, Raghu Mani, Rui Mao, Pat McElroy, Shailendra Mishra, Valarie Moore, Bhagat Nainani, Maria Pratt, Arvind Rajaram, Viv Schupmann, Vipul Shah, Neeraj Shodhan, Wayne Smith, Jim Stamos, Janet Stern, Mahesh Subramaniam, Bob Thome, Byron Wang, Wei Wang, James M. Wilson, Lik Wong, Jingwei Wu, Haobo Xu, Jun Yuan, David Zhang

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.

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.

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, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software 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 which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.

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.

This software or hardware and documentation may provide access to or information on 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. 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.

PKzPK+AOEBPS/hetero.htm Oracle Streams Heterogeneous Information Sharing

11 Oracle Streams Heterogeneous Information Sharing

This chapter explains concepts relating to Oracle Streams support for information sharing between Oracle databases and non-Oracle databases.

This chapter contains these topics:

Oracle to Non-Oracle Data Sharing with Oracle Streams

To share DML changes from an Oracle source database to a non-Oracle destination database, the Oracle database functions as a proxy and carries out some steps that would usually be done at the destination database. That is, the LCRs intended for the non-Oracle destination database are dequeued in the Oracle database itself and an apply process at the Oracle database applies the changes to the non-Oracle database across a network connection through an Oracle Database Gateway. Figure 11-1 shows an Oracle database sharing data with a non-Oracle database.

Figure 11-1 Oracle to Non-Oracle Heterogeneous Data Sharing

Description of Figure 11-1 follows
Description of "Figure 11-1 Oracle to Non-Oracle Heterogeneous Data Sharing"

You should configure the Oracle Database Gateway to use the transaction model COMMIT_CONFIRM.


See Also:

The Oracle documentation for your specific Oracle Database Gateway for information about using the transaction model COMMIT_CONFIRM for your Oracle Database Gateway

Change Capture and Staging in an Oracle to Non-Oracle Environment

In an Oracle to non-Oracle environment, a capture process or a synchronous capture functions the same way as it would in an Oracle-only environment. That is, a capture process finds changes in the redo log, captures them based on its rules, and enqueues the captured changes as logical change records (LCRs) into an ANYDATA queue. A synchronous capture uses an internal mechanism to capture changes based on its rules and enqueue the captured changes as row LCRs into an ANYDATA queue. In addition, a single capture process or synchronous capture can capture changes that will be applied at both Oracle and non-Oracle databases.

Similarly, the ANYDATA queue that stages the LCRs functions the same way as it would in an Oracle-only environment, and you can propagate LCRs to any number of intermediate queues in Oracle databases before they are applied at a non-Oracle database.


See Also:


Change Apply in an Oracle to Non-Oracle Environment

An apply process running in an Oracle database uses Heterogeneous Services and an Oracle Database Gateway to apply changes encapsulated in LCRs directly to database objects in a non-Oracle database. The LCRs are not propagated to a queue in the non-Oracle database, as they would be in an Oracle-only Oracle Streams environment. Instead, the apply process applies the changes directly through a database link to the non-Oracle database.


Note:

Oracle Streams apply processes do not support Generic Connectivity.


See Also:

Oracle Streams Concepts and Administration

Apply Process Configuration in an Oracle to Non-Oracle Environment

This section describes the configuration of an apply process that will apply changes to a non-Oracle database.

Before Creating an Apply Process in an Oracle to Non-Oracle Environment

Before you create an apply process that will apply changes to a non-Oracle database, configure Heterogeneous Services, the Oracle Database Gateway, and a database link.

Oracle Streams supports the following Oracle Database Gateways:

  • Oracle Database Gateway for Sybase

  • Oracle Database Gateway for Informix

  • Oracle Database Gateway for SQL Server

  • Oracle Database Gateway for DRDA

The database link will be used by the apply process to apply the changes to the non-Oracle database. The database link must be created with an explicit CONNECT TO clause.


See Also:


Apply Process Creation in an Oracle to Non-Oracle Environment

After the database link has been created and is working properly, create the apply process using the CREATE_APPLY procedure in the DBMS_APPLY_ADM package and specify the database link for the apply_database_link parameter. After you create an apply process, you can use apply process rules to specify which changes are applied at the non-Oracle database.


See Also:


Substitute Key Columns in an Oracle to Non-Oracle Heterogeneous Environment

If you use substitute key columns for any of the tables at the non-Oracle database, then specify the database link to the non-Oracle database when you run the SET_KEY_COLUMNS procedure in the DBMS_APPLY_ADM package.

Parallelism in an Oracle to Non-Oracle Heterogeneous Environment

You must set the parallelism apply process parameter to 1, the default setting, when an apply process is applying changes to a non-Oracle database. Currently, parallel apply to non-Oracle databases is not supported. However, you can use multiple apply processes to apply changes a non-Oracle database.

Procedure DML Handlers in an Oracle to Non-Oracle Heterogeneous Environment

If you use a procedure DML handler to process row LCRs for any of the tables at the non-Oracle database, then specify the database link to the non-Oracle database when you run the SET_DML_HANDLER procedure in the DBMS_APPLY_ADM package.


See Also:

Oracle Streams Concepts and Administration for information about message processing options for an apply process

Message Handlers in an Oracle to Non-Oracle Heterogeneous Environment

If you want to use a message handler to process user messages for a non-Oracle database, then, when you run the CREATE_APPLY procedure in the DBMS_APPLY_ADM package, specify the database link to the non-Oracle database using the apply_database_link parameter, and specify the message handler procedure using the message_handler parameter.

Error and Conflict Handlers in an Oracle to Non-Oracle Heterogeneous Environment

Currently, error handlers and conflict handlers are not supported when sharing data from an Oracle database to a non-Oracle database. If an apply error occurs, then the transaction containing the LCR that caused the error is moved into the error queue in the Oracle database.

Data Types Applied at Non-Oracle Databases

When applying changes to a non-Oracle database, an apply process applies changes made to columns of only the following data types:

  • CHAR

  • VARCHAR2

  • NCHAR

  • NVARCHAR2

  • NUMBER

  • DATE

  • RAW

  • TIMESTAMP

  • TIMESTAMP WITH TIME ZONE

  • TIMESTAMP WITH LOCAL TIME ZONE

  • INTERVAL YEAR TO MONTH

  • INTERVAL DAY TO SECOND

The apply process does not apply changes in columns of the following data types to non-Oracle databases: CLOB, NCLOB, BLOB, BFILE, LONG, LONG RAW, ROWID, UROWID, user-defined types (including object types, REFs, varrays, and nested tables), and Oracle-supplied types (including Any types, XML types, spatial types, and media types). The apply process raises an error when an LCR contains a data type that is not listed, and the transaction containing the LCR that caused the error is moved to the error queue in the Oracle database.

Each Oracle Database Gateway might have further limitations regarding data types. For a data type to be supported in an Oracle to non-Oracle environment, the data type must be supported by both Oracle Streams and the Oracle Database Gateway being used.


See Also:


Types of DML Changes Applied at Non-Oracle Databases

When you specify that DML changes made to certain tables should be applied at a non-Oracle database, an apply process can apply only the following types of DML changes:

  • INSERT

  • UPDATE

  • DELETE


Note:

The apply process cannot apply DDL changes at non-Oracle databases.

Instantiation in an Oracle to Non-Oracle Environment

Before you start an apply process that applies changes to a non-Oracle database, complete the following steps to instantiate each table at the non-Oracle database:

  1. Use the DBMS_HS_PASSTHROUGH package or the tools supplied with the non-Oracle database to create the table at the non-Oracle database.

    The following is an example that uses the DBMS_HS_PASSTHROUGH package to create the hr.regions table in the het.example.com non-Oracle database:

    DECLARE 
 ret INTEGER; 
BEGIN 
ret := DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@het.example.com ( 
  'CREATE TABLE regions (region_id INTEGER, region_name VARCHAR(50))'); 
END; 
/ 
COMMIT;

    See Also:

    Oracle Database Heterogeneous Connectivity User's Guide and the Oracle documentation for your specific Oracle Database Gateway for more information about Heterogeneous Services and Oracle Database Gateway

  2. If the changes that will be shared between the Oracle and non-Oracle database are captured by a capture process or synchronous capture at the Oracle database, then prepare all tables that will share data for instantiation.

  3. Create a PL/SQL procedure (or a C program) that performs the following actions:

    • Gets the current SCN using the GET_SYSTEM_CHANGE_NUMBER function in the DBMS_FLASHBACK package.

    • Invokes the ENABLE_AT_SYSTEM_CHANGE_NUMBER procedure in the DBMS_FLASHBACK package to set the current session to the obtained SCN. This action ensures that all fetches are done using the same SCN.

    • Populates the table at the non-Oracle site by fetching row by row from the table at the Oracle database and then inserting row by row into the table at the non-Oracle database. All fetches should be done at the SCN obtained using the GET_SYSTEM_CHANGE_NUMBER function.

    For example, the following PL/SQL procedure gets the flashback SCN, fetches each row in the hr.regions table in the current Oracle database, and inserts them into the hr.regions table in the het.example.com non-Oracle database. Notice that flashback is disabled before the rows are inserted into the non-Oracle database.

    SET SERVEROUTPUT ON
CREATE OR REPLACE PROCEDURE insert_reg IS
  CURSOR c1 IS
    SELECT region_id, region_name FROM hr.regions;
  c1_rec c1 % ROWTYPE;
  scn NUMBER;
BEGIN
  scn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER(
     query_scn  =>  scn);
  /* Open c1 in flashback mode */
  OPEN c1;
  /* Disable Flashback */
  DBMS_FLASHBACK.DISABLE;
  LOOP
    FETCH c1 INTO c1_rec;
    EXIT WHEN c1%NOTFOUND;
   /*
     Note that all the DML operations inside the loop are performed
     with Flashback disabled
   */
   INSERT INTO hr.regions@het.example.com VALUES (
     c1_rec.region_id,
     c1_rec.region_name);
  END LOOP;
  COMMIT;
  DBMS_OUTPUT.PUT_LINE('SCN = ' || scn);
  EXCEPTION WHEN OTHERS THEN 
    DBMS_FLASHBACK.DISABLE; 
    RAISE;
END;
/

    Make a note of the SCN returned.

    If the Oracle Database Gateway you are using supports the Heterogeneous Services callback functionality, then you can replace the loop in the previous example with the following SQL statement:

    INSERT INTO hr.region@het.example.com SELECT * FROM hr.region@!;

    Note:

    The user who creates and runs the procedure in the previous example must have EXECUTE privilege on the DBMS_FLASHBACK package and all privileges on the tables involved.


    See Also:

    Oracle Database Heterogeneous Connectivity User's Guide and the Oracle documentation for your specific Oracle Database Gateway for information about callback functionality and your Oracle Database Gateway

  4. Set the instantiation SCN for the table at the non-Oracle database. Specify the SCN you obtained in Step 3 in the SET_TABLE_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package to instruct the apply process to skip all LCRs with changes that occurred before the SCN you obtained in Step 3. Ensure that you set the apply_database_link parameter to the database link for the remote non-Oracle database.


    See Also:

    "Setting Instantiation SCNs at a Destination Database" and Oracle Database PL/SQL Packages and Types Reference for more information about the SET_TABLE_INSTANTIATION_SCN procedure

Transformations in an Oracle to Non-Oracle Environment

In an Oracle to non-Oracle environment, you can specify rule-based transformations during capture or apply the same way as you would in an Oracle-only environment. In addition, if your environment propagates LCRs to one or more intermediate Oracle databases before they are applied at a non-Oracle database, then you can specify a rule-based transformation during propagation from a queue at an Oracle database to another queue at an Oracle database.


See Also:

Oracle Streams Concepts and Administration for more information about rule-based transformations

Messaging Gateway and Oracle Streams

Messaging Gateway is a feature of the Oracle database that provides propagation between Oracle queues and non-Oracle message queuing systems. Messages enqueued into an Oracle queue are automatically propagated to a non-Oracle queue, and the messages enqueued into a non-Oracle queue are automatically propagated to an Oracle queue. It provides guaranteed message delivery to the non-Oracle messaging system and supports the native message format for the non-Oracle messaging system. It also supports specification of user-defined transformations that are invoked while propagating from an Oracle queue to the non-Oracle messaging system or from the non-Oracle messaging system to an Oracle queue.


See Also:

Oracle Streams Advanced Queuing User's Guide for more information about the Messaging Gateway

Error Handling in an Oracle to Non-Oracle Environment

If the apply process encounters an unhandled error when it tries to apply an LCR at a non-Oracle database, then the transaction containing the LCR is placed in the error queue in the Oracle database that is running the apply process. The apply process detects data conflicts in the same way as it does in an Oracle-only environment, but automatic conflict resolution is not supported currently in an Oracle to non-Oracle environment. Therefore, any data conflicts encountered are treated as apply errors.

Example Oracle to Non-Oracle Streams Environment

Oracle Streams Extended Examples contains a detailed example that includes sharing data in an Oracle to non-Oracle Streams environment.

Non-Oracle to Oracle Data Sharing with Oracle Streams

To capture and propagate changes from a non-Oracle database to an Oracle database, a custom application is required. This application gets the changes made to the non-Oracle database by reading from transaction logs, by using triggers, or by some other method. The application must assemble and order the transactions and must convert each change into a logical change record (LCR). Next, the application must enqueue the LCRs in an Oracle database using the DBMS_STREAMS_MESSAGING package or the DBMS_AQ package. The application must commit after enqueuing all LCRs in each transaction. Figure 11-2 shows a non-Oracle databases sharing data with an Oracle database.

Figure 11-2 Non-Oracle to Oracle Heterogeneous Data Sharing

Description of Figure 11-2 follows
Description of "Figure 11-2 Non-Oracle to Oracle Heterogeneous Data Sharing"

Change Capture in a Non-Oracle to Oracle Environment

Because the custom user application is responsible for assembling changes at the non-Oracle database into LCRs and enqueuing the LCRs at the Oracle database, the application is completely responsible for change capture. Therefore, the application must construct LCRs that represent changes at the non-Oracle database and then enqueue these LCRs into the queue at the Oracle database. The application can enqueue multiple transactions concurrently, but the transactions must be committed in the same order as the transactions on the non-Oracle source database.


See Also:

"Constructing and Enqueuing LCRs" for more information about constructing and enqueuing LCRs

Staging in a Non-Oracle to Oracle Environment

To ensure the same transactional consistency at both the Oracle database where changes are applied and the non-Oracle database where changes originate, you must use a transactional queue to stage the LCRs at the Oracle database. For example, suppose a single transaction contains three row changes, and the custom application enqueues three row LCRs, one for each change, and then commits. With a transactional queue, a commit is performed by the apply process after the third row LCR, retaining the consistency of the transaction. If you use a nontransactional queue, then a commit is performed for each row LCR by the apply process. The SET_UP_QUEUE procedure in the DBMS_STREAMS_ADM package creates a transactional queue automatically.

Also, the queue at the Oracle database should be a commit-time queue. A commit-time queue orders LCRs by approximate commit system change number (approximate CSCN) of the transaction that includes the LCRs. Commit-time queues preserve transactional dependency ordering between LCRs in the queue, if the application that enqueued the LCRs commits the transactions in the correct order. Also, commit-time queues ensure consistent browses of LCRs in a queue.


See Also:

Oracle Streams Concepts and Administration for more information about transactional queues and commit-time queues

Change Apply in a Non-Oracle to Oracle Environment

In a non-Oracle to Oracle environment, the apply process functions the same way as it would in an Oracle-only environment. That is, it dequeues each LCR from its associated queue based on apply process rules, performs any rule-based transformation, and either sends the LCR to a handler or applies it directly. Error handling and conflict resolution also function the same as they would in an Oracle-only environment. So, you can specify a prebuilt update conflict handler or create a custom conflict handler to resolve conflicts.

The apply process should be configured to apply persistent LCRs, not captured LCRs. So, the apply process should be created using the CREATE_APPLY procedure in the DBMS_APPLY_ADM package, and the apply_captured parameter should be set to FALSE when you run this procedure. After the apply process is created, you can use procedures in the DBMS_STREAMS_ADM package to add rules for LCRs to the apply process rule sets.


See Also:


Instantiation from a Non-Oracle Database to an Oracle Database

There is no automatic way to instantiate tables that exist at a non-Oracle database at an Oracle database. However, you can perform the following general procedure to instantiate a table manually:

  1. At the non-Oracle database, use a non-Oracle utility to export the table to a flat file.

  2. At the Oracle database, create an empty table that matches the table at the non-Oracle database.

  3. At the Oracle database, use SQL*Loader to load the contents of the flat file into the table.


See Also:

Oracle Database Utilities for information about using SQL*Loader

Non-Oracle to Non-Oracle Data Sharing with Oracle Streams

Oracle Streams supports data sharing between two non-Oracle databases through a combination of non-Oracle to Oracle data sharing and Oracle to non-Oracle data sharing. Such an environment would use Oracle Streams in an Oracle database as an intermediate database between two non-Oracle databases.

For example, a non-Oracle to non-Oracle environment can consist of the following databases:

A user application assembles changes at het1.example.com and enqueues them in dbs1.example.com. Next, the apply process at dbs1.example.com applies the changes to het2.example.com using Heterogeneous Services and an Oracle Database Gateway. Another apply process at dbs1.example.com could apply some or all of the changes in the queue locally at dbs1.example.com. One or more propagations at dbs1.example.com could propagate some or all of the changes in the queue to other Oracle databases.

PK32(PK+AOEBPS/best_apply.htm{A Best Practices for Apply

18 Best Practices for Apply

This chapter describes the best practices for applying changes with an apply process in an Oracle Streams replication environment. This chapter includes these topics:


See Also:

"Best Practices for Oracle Real Application Clusters and Oracle Streams"

Best Practices for Destination Database Configuration

In an Oracle Streams replication environment, a destination database is a database where an apply process applies changes. This section contains these topics:

Grant Required Privileges to the Apply User

The apply user is the user in whose security domain an apply process performs the following actions:

  • Dequeues messages that satisfy its rule sets

  • Runs custom rule-based transformations configured for apply process rules

  • Applies messages directly to database objects

  • Runs apply handlers configured for the apply process

The apply user for an apply process is configured when you create an apply process, and the apply user can be modified when you alter an apply process. Grant the following privileges to the apply user:

  • If the apply process applies data manipulation language (DML) changes to a table, then grant INSERT, UPDATE, and DELETE privileges on the table to the apply user.

  • If the apply process applies data definition language (DDL) changes to a table, then grant CREATE TABLE or CREATE ANY TABLE, CREAT INDEX or CREATE ANY INDEX, and CREATE PROCEDURE or CREATE ANY PROCEDURE to the apply user.

  • Grant EXECUTE privilege on the rule sets used by the apply process.

  • Grant EXECUTE privilege on all custom rule-based transformation functions specified for rules in the positive rule set of the apply process.

  • Grant EXECUTE privilege on any apply handlers used by the apply process.

  • Grant privileges to dequeue messages from the apply process's queue.

These privileges can be granted directly to the apply user, or they can be granted through roles.

In addition, the apply user must be granted EXECUTE privilege on all packages, including Oracle-supplied packages, that are invoked in subprograms run by the apply process. These privileges must be granted directly to the apply user. They cannot be granted through roles.


See Also:


Set Instantiation SCN Values

An instantiation SCN value must be set for each database object to which an apply process applies changes. Confirm that an instantiation SCN is set for all such objects, and set any required instantiation SCN values that are not set.

Instantiation SCN values can be set in various ways, including during export/import, by Recovery Manager (RMAN), or manually. To set instantiation SCN values manually, use one of the following procedures in the DBMS_APPLY_ADM package:

For example, to set the instantiation SCN manually for each table in the a schema, run the SET_SCHEMA_INSTANTIATION_SCN procedure with the recursive parameter set to TRUE. If an apply process applies data definition language (DDL) changes, then set the instantiation SCN values at a level higher than table level using either the SET_SCHEMA_INSTANTIATION_SCN or SET_GLOBAL_INSTANTIATION_SCN procedure.


See Also:

Chapter 8, "Instantiation and Oracle Streams Replication" for more information about instantiation and setting instantiation SCN values

Configure Conflict Resolution

If updates will be performed at multiple databases for the same shared database object, then ensure that you configure conflict resolution for that object. To simplify conflict resolution for tables with LOB columns, create an error handler to handle errors for the table. When registering the error handler using the DBMS_APPLY_ADM.SET_DML_HANDLER procedure, ensure that you set the assemble_lobs parameter to TRUE.

If you configure conflict resolution at a destination database, then additional supplemental logging is required at the source database. Specifically, the columns specified in a column list for conflict resolution during apply must be conditionally logged if more than one column at the source database is used in the column list at the destination database.


See Also:


Best Practices for Apply Process Configuration

The following sections describe best practices for configuring apply processes:

Set Apply Process Parallelism

Set the parallelism of an apply process by specifying the parallelism parameter in the DBMS_APPLY_ADM.SET_PARAMETER procedure. The parallelism parameter controls the number of processes that concurrently apply changes. The default setting for the parallelism apply process parameter is 4.

Typically, apply process parallelism is set to either 1, 4, 8, or 16. The setting that is best for a particular apply process depends on the load applied and the processing power of the computer system running the database. Follow these guidelines when setting apply process parallelism:

  • If the load is heavy for the apply process and the computer system running the database has excellent processing power, then set apply process parallelism to 8 or 16. Multiple high-speed CPUs provide excellent processing power.

  • If the is light for the apply process, then set apply process parallelism to 1 or 4.

  • If the computer system running the database has less than optimal processing power, then set apply process parallelism to 1 or 4.

Ensure that the PROCESSES initialization parameter is set appropriately when you set the parallelism apply process parameter.

In addition, if parallelism is greater than 1 for an apply process, then ensure that any database objects whose changes are applied by the apply process have the appropriate settings for the INITRANS and PCTFREE parameters. The INITRANS parameter specifies the initial number of concurrent transaction entries allocated within each data block allocated to the database object. Set the INITRANS parameter to the parallelism of the apply process or higher. The PCTFREE parameter specifies the percentage of space in each data block of the database object reserved for future updates to rows of the object. The PCTFREE parameter should be set to 10 or higher. You can modify these parameters for a table using the ALTER TABLE statement


See Also:


Consider Allowing Apply Processes to Continue When They Encounter Errors

When the disable_on_error apply process parameter is set to Y, the apply process is disabled on the first unresolved error, even if the error is not irrecoverable. When the disable_on_error apply process parameter is set to N, the apply process continues regardless of unresolved errors. The default setting for this parameter is Y. If you do not want an apply process to become disabled when it encounters errors, then set the disable_on_error parameter to N.

Best Practices for Apply Process Operation

The following section describes best practices for operating existing apply processes.

Manage Apply Errors

The error queue contains all of the current apply errors for a database. If there are multiple apply processes in a database, then the error queue contains the apply errors for each apply process. If an apply process encounters an error when it tries to apply a logical change record (LCR) in a transaction, then all of the LCRs in the transaction are moved to the error queue. To view information about apply errors, query the DBA_APPLY_ERROR data dictionary view or use Enterprise Manager.

The MESSAGE_NUMBER column in the DBA_APPLY_ERROR view indicates the LCR within the transaction that resulted in the error. When apply errors are encountered, correct the problem(s) that caused the error(s), and either retry or delete the error transaction in the error queue.


See Also:

Oracle Streams Concepts and Administration for information about managing apply errors and for information about displaying detailed information for the column values of each LCR in an error transaction

PKGA{APK+AOEBPS/best_prop.htmn1 Best Practices for Propagation

17 Best Practices for Propagation

This chapter describes the best practices for propagating messages in an Oracle Streams replication environment. This chapter includes these topics:


See Also:

"Best Practices for Oracle Real Application Clusters and Oracle Streams"

Best Practices for Propagation Configuration

This following sections describe best practices for configuring propagations:

Use Queue-to-Queue Propagations

A propagation can be queue-to-queue or queue-to-database link (queue-to-dblink). Use queue-to-queue propagations whenever possible. A queue-to-queue propagation always has its own exclusive propagation job to propagate messages from the source queue to the destination queue. Because each propagation job has its own propagation schedule, the propagation schedule of each queue-to-queue propagation can be managed separately. Even when multiple queue-to-queue propagations use the same database link, you can enable, disable, or set the propagation schedule for each queue-to-queue propagation separately.

Propagations configured before Oracle Database 10g Release 2 are queue-to-dblink propagations. Also, any propagation that includes a queue in a database before Oracle Database 10g Release 2 must be a queue-to-dblink propagation. When queue-to-dblink propagations are used, propagation will not succeed if the database link no longer connects to the owning instance of the destination queue.

If you have queue-to-dblink propagations created in a prior release of Oracle Database, you can re-create these propagation during a maintenance window to use queue-to-queue propagation. To re-create a propagation, complete the following steps:

  1. Stop the propagation.

  2. Ensure that the source queue is empty.

  3. Ensure that the destination queue is empty and has no unapplied, spilled messages before you drop the propagation.

  4. Re-create the propagation with the queue_to_queue parameter set to TRUE in the creation procedure.

If you automate the configuration, as described in "Automate the Oracle Streams Replication Configuration", then each propagation uses queue-to-queue propagation automatically.


See Also:


Set the Propagation Latency for Each Propagation

Propagation latency is the maximum wait, in seconds, in the propagation window for a message to be propagated after it is enqueued. Set the propagation latency to an appropriate value for each propagation in your Oracle Streams replication environment. The default propagation latency value is 60.

The following scenarios describe how a propagation will behave given different propagation latency values:

  • If latency is set to 60, and there are no messages enqueued during the propagation window, then the queue will not be checked for 60 seconds for messages to be propagated to the specified destination. That is, messages enqueued into the queue for the propagation destination will not be propagated for at least 60 more seconds.

  • If the latency is set to 600, and there are no messages enqueued during the propagation window, then the queue will not be checked for 10 minutes for messages to be propagated to the specified destination. That is, messages enqueued into the queue for the propagation destination will not be propagated for at least 10 more minutes.

  • If the latency is set to 0, then a job slave will be waiting for messages to be enqueued for the destination and, as soon as a message is enqueued, it will be propagated. Setting latency to 0 is not recommended because it might affect the ability of the database to shut down in NORMAL mode.

You can set propagation parameters using the ALTER_PROPAGATION_SCHEDULE procedure from the DBMS_AQADM package. For example, to set the latency of a propagation from the q1 source queue owned by strmadmin to the destination queue q2 at the database with a global name of dbs2.example.com, log in as the Oracle Streams administrator, and run the following procedure:

BEGIN
  DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE(
   queue_name        => 'strmadmin.q1',
   destination       => 'dbs2.example.com',
   latency           => 5,
   destination_queue => 'strmadmin.q2'); 
END;
/

Note:

If the latency parameter is not specified, then propagation latency is set to the default value of 60.


See Also:

Oracle Streams Concepts and Administration

Increase the SDU in a Wide Area Network for Better Network Performance

When using Oracle Streams propagation in a Wide Area Network (WAN), increase the session data unit (SDU) to improve the propagation performance. The maximum value for SDU is 32K (32767). The SDU value for network transmission is negotiated between the sender and receiver sides of the connection, and the minimum SDU value of the two endpoints is used for any individual connection. To take advantage of an increased SDU for Oracle Streams propagation, the receiving side sqlnet.ora file must include the DEFAULT_SDU_SIZE parameter. The receiving side listener.ora file must indicate the SDU change for the system identifier (SID). The sending side tnsnames.ora file connect string must also include the SDU modification for the particular service.

In addition, the SEND_BUF_SIZE and RECV_BUF_SIZE parameters in the listener.ora and tnsnames.ora files increase the performance of propagation on your system. These parameters increase the size of the buffer used to send or receive the propagated messages. These parameters should only be increased after careful analysis of their overall impact on system performance.


See Also:

Oracle Database Net Services Administrator's Guide

Best Practices for Propagation Operation

The following section describes best practices for operating existing propagations.

Restart Broken Propagations

Sometimes, the propagation job for a propagation might become "broken" or fail to start after it encounters an error or after a database restart. Typically, stopping and restarting the propagation solves the problem. For example, to stop and restart a propagation named prop1, run the following procedures:

BEGIN
  DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
    propagation_name => 'prop1');
END;
/

BEGIN
  DBMS_PROPAGATION_ADM.START_PROPAGATION(
    propagation_name => 'prop1');
END;
/

If running these procedures does not correct the problem, then run the STOP_PROPAGATION procedure with the force parameter set to TRUE, and restart propagation. For example:

BEGIN
  DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
    propagation_name => 'prop1',
    force            => TRUE);
END;
/

BEGIN
  DBMS_PROPAGATION_ADM.START_PROPAGATION(
    propagation_name => 'prop1');
END;
/

When you stop a propagation with the force parameter set to TRUE, the statistics for the propagation are cleared.

PK*JM s1n1PK+AOEBPS/preface.htm> Preface

Preface

Oracle Streams Replication Administrator's Guide describes the features and functionality of Oracle Streams that can be used for data replication. This document contains conceptual information about Oracle Streams replication, along with information about configuring and managing an Oracle Streams replication environment.

This Preface contains these topics:

Audience

Oracle Streams Replication Administrator's Guide is intended for database administrators who create and maintain Oracle Streams replication environments. These administrators perform one or more of the following tasks

To use this document, you must be familiar with relational database concepts, SQL, distributed database administration, general Oracle Streams concepts, Advanced Queuing concepts, PL/SQL, and the operating systems under which you run an Oracle Streams environment.

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

For more information, see these Oracle resources:

Many of the examples in this book use the sample schemas of the sample database, which is installed by default when you install Oracle Database. Refer to Oracle Database Sample Schemas for information about how these schemas were created and how you can use them yourself.

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.

PKjeC>PK+AOEBPS/ccap.htm Configuring Implicit Capture

5 Configuring Implicit Capture

Implicit capture means that a capture process or a synchronous capture captures and enqueues database changes automatically. A capture process captures changes in the redo log, while a synchronous capture captures data manipulation language (DML) changes with an internal mechanism. Both capture processes and synchronous captures reformat the captured changes into logical change records (LCRs) and enqueue the LCRs into an ANYDATA queue.

The following topics describe configuring implicit capture:

Each task described in this chapter should be completed by an Oracle Streams administrator that has been granted the appropriate privileges, unless specified otherwise.


See Also:


Configuring a Capture Process

You can create a capture process that captures changes either locally at the source database or remotely at a downstream database. A downstream capture process runs on a downstream database, and redo data from the source database is copied to the downstream database. A downstream capture process captures changes in the copied redo data at the downstream database.

You can use any of the following procedures to create a local capture process:

Each of the procedures in the DBMS_STREAMS_ADM package creates a capture process with the specified name if it does not already exist, creates either a positive rule set or negative rule set for the capture process if the capture process does not have such a rule set, and can add table rules, schema rules, or global rules to the rule set.

The CREATE_CAPTURE procedure creates a capture process, but does not create a rule set or rules for the capture process. However, the CREATE_CAPTURE procedure enables you to specify an existing rule set to associate with the capture process, either as a positive or a negative rule set, a first SCN, and a start SCN for the capture process. Also, to create a capture process that performs downstream capture, you must use the CREATE_CAPTURE procedure.

The following sections describe configuring a capture process:


Caution:

When a capture process is started or restarted, it might need to scan redo log files with a FIRST_CHANGE# value that is lower than start SCN. Removing required redo log files before they are scanned by a capture process causes the capture process to abort. You can query the DBA_CAPTURE data dictionary view to determine the first SCN, start SCN, and required checkpoint SCN for a capture process. A capture process needs the redo log file that includes the required checkpoint SCN, and all subsequent redo log files. See Oracle Streams Concepts and Administration for more information about the first SCN and start SCN for a capture process.


Note:

  • You can configure an entire Oracle Streams environment, including capture processes, using procedures in the DBMS_STREAMS_ADM package or Oracle Enterprise Manager. See Chapter 2, "Simple Oracle Streams Replication Configuration".

  • After creating a capture process, avoid changing the DBID or global name of the source database for the capture process. If you change either the DBID or global name of the source database, then the capture process must be dropped and re-created. See "Changing the DBID or Global Name of a Source Database".

  • To configure downstream capture, the source database must be an Oracle Database 10g Release 1 or later database.


Preparing to Configure a Capture Process

The following tasks must be completed before you configure a capture process:

Configuring a Local Capture Process

The following sections describe using the DBMS_STREAMS_ADM package and the DBMS_CAPTURE_ADM package to create a local capture process.

This section contains the following examples:

Configuring a Local Capture Process Using DBMS_STREAMS_ADM

To configure a local capture process using the DBMS_STREAMS_ADM package, complete the following steps:

  1. Complete the tasks in "Preparing to Configure a Capture Process".

  2. In SQL*Plus, connect to the source database as the Oracle Streams administrator.

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.

  3. Run the ADD_TABLE_RULES procedure in the DBMS_STREAMS_ADM package to create a local capture process:

    BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name         => 'hr.employees',
    streams_type       => 'capture',
    streams_name       => 'strm01_capture',
    queue_name         => 'strmadmin.streams_queue',
    include_dml        => TRUE,
    include_ddl        => TRUE,
    include_tagged_lcr => FALSE,
    source_database    => NULL,
    inclusion_rule     => TRUE);
END;
/

    Running this procedure performs the following actions:

    • Creates a capture process named strm01_capture. The capture process is created only if it does not already exist. If a new capture process is created, then this procedure also sets the start SCN to the point in time of creation.

    • Associates the capture process with the existing queue strmadmin.streams_queue.

    • Creates a positive rule set and associates it with the capture process, if the capture process does not have a positive rule set. The rule set is a positive rule set because the inclusion_rule parameter is set to TRUE. The rule set uses the SYS.STREAMS$_EVALUATION_CONTEXT evaluation context. The rule set name is system generated.

    • Creates two rules. One rule evaluates to TRUE for data manipulation language (DML) changes to the hr.employees table, and the other rule evaluates to TRUE for data definition language (DDL) changes to the hr.employees table. The rule names are system generated.

    • Adds the two rules to the positive rule set associated with the capture process. The rules are added to the positive rule set because the inclusion_rule parameter is set to TRUE.

    • Specifies that the capture process captures a change in the redo log only if the change has a NULL tag, because the include_tagged_lcr parameter is set to FALSE. This behavior is accomplished through the system-created rules for the capture process.

    • Creates a capture process that captures local changes to the source database because the source_database parameter is set to NULL. For a local capture process, you can also specify the global name of the local database for this parameter.

    • Prepares the hr.employees table for instantiation.

    • Enables supplemental logging for any primary key, unique key, bitmap index, and foreign key columns in the hr.employees table.

  4. If necessary, complete the steps described in "After Configuring a Capture Process".


See Also:


Configuring a Local Capture Process Using DBMS_CAPTURE_ADM

To configure a local capture process using the DBMS_CAPTURE_ADM package, complete the following steps:

  1. Complete the tasks in "Preparing to Configure a Capture Process".

  2. In SQL*Plus, connect to the source database as the Oracle Streams administrator.

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.

  3. Create the rule set that will be used by the capture process if it does not exist. In this example, assume that the rule set is strmadmin.strm01_rule_set. Optionally, you can also add rules to the rule set. See Oracle Streams Concepts and Administration for instructions.

  4. Run the CREATE_CAPTURE procedure in the DBMS_CAPTURE_ADM package to create a local capture process:

    BEGIN
  DBMS_CAPTURE_ADM.CREATE_CAPTURE(
    queue_name         => 'strmadmin.streams_queue',
    capture_name       => 'strm02_capture',
    rule_set_name      => 'strmadmin.strm01_rule_set',
    start_scn          => NULL,
    source_database    => NULL,
    first_scn          => NULL);
END;
/

    Running this procedure performs the following actions:

    • Creates a capture process named strm02_capture. A capture process with the same name must not exist.

    • Associates the capture process with the existing queue strmadmin.streams_queue.

    • Associates the capture process with the existing rule set strmadmin.strm01_rule_set. This rule set is the positive rule set for the capture process.

    • Creates a capture process that captures local changes to the source database because the source_database parameter is set to NULL. For a local capture process, you can also specify the global name of the local database for this parameter.

    • Specifies that the Oracle database determines the start SCN and first SCN for the capture process because both the start_scn parameter and the first_scn parameter are set to NULL.

    • If no other capture processes that capture local changes are running on the local database, then the BUILD procedure in the DBMS_CAPTURE_ADM package is run automatically. Running this procedure extracts the data dictionary to the redo log, and a LogMiner data dictionary is created when the capture process is started for the first time.

  5. If necessary, complete the steps described in "After Configuring a Capture Process".


See Also:

Oracle Streams Concepts and Administration for more information about rules

Configuring a Local Capture Process with Non-NULL Start SCN

This example runs the CREATE_CAPTURE procedure in the DBMS_CAPTURE_ADM package to create a local capture process with a start SCN set to 223525. This example assumes that there is at least one local capture process at the database, and that this capture process has taken at least one checkpoint. You can always specify a start SCN for a new capture process that is equal to or greater than the current SCN of the source database. To specify a start SCN that is lower than the current SCN of the database, the specified start SCN must be higher than the lowest first SCN for an existing local capture process that has been started successfully at least once and has taken at least one checkpoint.

You can determine the first SCN for existing capture processes, and whether these capture processes have taken a checkpoint, by running the following query:

SELECT CAPTURE_NAME, FIRST_SCN, MAX_CHECKPOINT_SCN FROM DBA_CAPTURE;

Your output looks similar to the following:

CAPTURE_NAME                    FIRST_SCN MAX_CHECKPOINT_SCN
------------------------------ ---------- ------------------
CAPTURE_SIMP                       223522             230825

These results show that the capture_simp capture process has a first SCN of 223522. Also, this capture process has taken a checkpoint because the MAX_CHECKPOINT_SCN value is non-NULL. Therefore, the start SCN for the new capture process can be set to 223522 or higher.

To configure a local capture process with a non-NULL start SCN, complete the following steps:

  1. Complete the tasks in "Preparing to Configure a Capture Process".

  2. In SQL*Plus, connect to the source database as the Oracle Streams administrator.

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.

  3. Create the rule set that will be used by the capture process if it does not exist. In this example, assume that the rule set is strmadmin.strm01_rule_set. Optionally, you can also add rules to the rule set. See Oracle Streams Concepts and Administration for instructions.

  4. Run the following procedure to create the capture process:

    BEGIN
  DBMS_CAPTURE_ADM.CREATE_CAPTURE(
    queue_name         => 'strmadmin.streams_queue',
    capture_name       => 'strm03_capture',
    rule_set_name      => 'strmadmin.strm01_rule_set',
    start_scn          => 223525,
    source_database    => NULL,
    first_scn          => NULL);
END;
/

    Running this procedure performs the following actions:

    • Creates a capture process named strm03_capture. A capture process with the same name must not exist.

    • Associates the capture process with the existing queue strmadmin.streams_queue.

    • Associates the capture process with the existing rule set strmadmin.strm01_rule_set. This rule set is the positive rule set for the capture process.

    • Specifies 223525 as the start SCN for the capture process. The new capture process uses the same LogMiner data dictionary as one of the existing capture processes. Oracle Streams automatically chooses which LogMiner data dictionary to share with the new capture process. Because the first_scn parameter was set to NULL, the first SCN for the new capture process is the same as the first SCN of the existing capture process whose LogMiner data dictionary was shared. In this example, the existing capture process is capture_simp.

    • Creates a capture process that captures local changes to the source database because the source_database parameter is set to NULL. For a local capture process, you can also specify the global name of the local database for this parameter.


    Note:

    If no local capture process exists when the procedure in this example is run, then the DBMS_CAPTURE_ADM.BUILD procedure is run automatically during capture process creation to extract the data dictionary into the redo log. The first time the new capture process is started, it uses this redo data to create a LogMiner data dictionary. In this case, a specified start_scn parameter value must be equal to or higher than the current database SCN.

  5. If necessary, complete the steps described in "After Configuring a Capture Process".


See Also:


Configuring a Downstream Capture Process

This section describes configuring a real-time or archived-log downstream capture process.

This section contains these topics:

Configuring a Real-Time Downstream Capture Process

To create a capture process that performs downstream capture, you must use the CREATE_CAPTURE procedure. The example in this section describes creating a real-time downstream capture process that uses a database link to the source database. However, a real-time downstream capture process might not use a database link.

This example assumes the following:

  • The source database is dbs1.example.com and the downstream database is dbs2.example.com.

  • The capture process that will be created at dbs2.example.com uses the strmadmin.streams_queue.

  • The capture process will capture DML changes to the hr.departments table.

This section contains an example that runs the CREATE_CAPTURE procedure in the DBMS_CAPTURE_ADM package to create a real-time downstream capture process at the dbs2.example.com downstream database that captures changes made to the dbs1.example.com source database. The capture process in this example uses a database link to dbs1.example.com for administrative purposes. The name of the database link must match the global name of the source database.


Note:

You can configure multiple real-time downstream capture processes that captures changes from the same source database, but you cannot configure real-time downstream capture for multiple source databases at one downstream database.


See Also:

Oracle Streams Concepts and Administration for conceptual information about real-time downstream capture

Complete the following steps:

  1. Complete the tasks in "Preparing to Configure a Capture Process". Ensure that you complete the tasks "Configuring Log File Transfer to a Downstream Capture Database" and "Adding Standby Redo Logs for Real-Time Downstream Capture".

  2. In SQL*Plus, connect to the downstream database dbs2.example.com as the Oracle Streams administrator.

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.

  3. Create the database link from dbs2.example.com to dbs1.example.com. For example, if the user strmadmin is the Oracle Streams administrator on both databases, then create the following database link:

    CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password
   USING 'dbs1.example.com';

    This example assumes that an Oracle Streams administrator exists at the source database dbs1.example.com. If no Oracle Streams administrator exists at the source database, then the Oracle Streams administrator at the downstream database should connect to a user who allows remote access by an Oracle Streams administrator. You can enable remote access for a user by specifying the user as the grantee when you run the GRANT_REMOTE_ADMIN_ACCESS procedure in the DBMS_STREAMS_AUTH package at the source database.

  4. Run the CREATE_CAPTURE procedure to create the capture process:

    BEGIN
  DBMS_CAPTURE_ADM.CREATE_CAPTURE(
    queue_name         => 'strmadmin.streams_queue',
    capture_name       => 'real_time_capture',
    rule_set_name      => NULL,
    start_scn          => NULL,
    source_database    => 'dbs1.example.com',
    use_database_link  => TRUE,
    first_scn          => NULL,
    logfile_assignment => 'implicit');
END;
/

    Running this procedure performs the following actions:

    • Creates a capture process named real_time_capture at the downstream database dbs2.example.com. A capture process with the same name must not exist.

    • Associates the capture process with an existing queue on dbs2.example.com named streams_queue and owned by strmadmin.

    • Specifies that the source database of the changes that the capture process will capture is dbs1.example.com.

    • Specifies that the capture process uses a database link with the same name as the source database global name to perform administrative actions at the source database.

    • Specifies that the capture process accepts redo data implicitly from dbs1.example.com. Therefore, the capture process scans the standby redo log at dbs2.example.com for changes that it must capture. If the capture process falls behind, then it scans the archived redo log files written from the standby redo log.

    This step does not associate the capture process real_time_capture with any rule set. A rule set will be created and associated with the capture process in a later step.

    If no other capture process at dbs2.example.com is capturing changes from the dbs1.example.com source database, then the DBMS_CAPTURE_ADM.BUILD procedure is run automatically at dbs1.example.com using the database link. Running this procedure extracts the data dictionary at dbs1.example.com to the redo log, and a LogMiner data dictionary for dbs1.example.com is created at dbs2.example.com when the capture process real_time_capture is started for the first time at dbs2.example.com.

    If multiple capture processes at dbs2.example.com are capturing changes from the dbs1.example.com source database, then the new capture process real_time_capture uses the same LogMiner data dictionary for dbs1.example.com as one of the existing archived-log capture process. Oracle Streams automatically chooses which LogMiner data dictionary to share with the new capture process.


    Note:

    During the creation of a downstream capture process, if the first_scn parameter is set to NULL in the CREATE_CAPTURE procedure, then the use_database_link parameter must be set to TRUE. Otherwise, an error is raised.


    See Also:

    Oracle Streams Concepts and Administration for more information about SCN values related to a capture process

  5. Set the downstream_real_time_mine capture process parameter to Y:

    BEGIN
  DBMS_CAPTURE_ADM.SET_PARAMETER(
    capture_name => 'real_time_capture',
    parameter    => 'downstream_real_time_mine',
    value        => 'Y');
END;
/

  6. Create the positive rule set for the capture process and add a rule to it:

    BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name          =>  'hr.departments',
    streams_type        =>  'capture',
    streams_name        =>  'real_time_capture',
    queue_name          =>  'strmadmin.streams_queue',
    include_dml         =>  TRUE,
    include_ddl         =>  FALSE,
    include_tagged_lcr  =>  FALSE,
    source_database     =>  'dbs1.example.com',
    inclusion_rule      =>  TRUE);
END;
/

    Running this procedure performs the following actions:

    • Creates a rule set at dbs2.example.com for capture process real_time_capture. The rule set has a system-generated name. The rule set is the positive rule set for the capture process because the inclusion_rule parameter is set to TRUE.

    • Creates a rule that captures data manipulation language (DML) changes to the hr.departments table, and adds the rule to the positive rule set for the capture process. The rule has a system-generated name. The rule is added to the positive rule set for the capture process because the inclusion_rule parameter is set to TRUE.

    • Prepares the hr.departments table at dbs1.example.com for instantiation using the database link created in Step 3.

    • Enables supplemental logging for any primary key, unique key, bitmap index, and foreign key columns in the table at dbs1.example.com.

  7. Connect to the source database dbs1.example.com as an administrative user with the necessary privileges to switch log files.

  8. Archive the current log file at the source database:

    ALTER SYSTEM ARCHIVE LOG CURRENT;

    Archiving the current log file at the source database starts real time mining of the source database redo log.

    If the capture process appears to be waiting for redo data for an inordinately long time, then check the alert log for errors. See Oracle Streams Concepts and Administration for more information.

  9. If necessary, complete the steps described in "After Configuring a Capture Process".

Configuring an Archived-Log Downstream Capture Process

This section describes configuring an archived-log downstream capture process that either assigns log files implicitly or explicitly.

This section contains these topics:

Configuring an Archived-Log Downstream Capture Process that Assigns Logs Implicitly

To create a capture process that performs downstream capture, you must use the CREATE_CAPTURE procedure. The example in this section describes creating an archived-log downstream capture process that uses a database link to the source database for administrative purposes. The name of the database link must match the global name of the source database.

This example assumes the following:

  • The source database is dbs1.example.com and the downstream database is dbs2.example.com.

  • The capture process that will be created at dbs2.example.com uses the streams_queue owned by strmadmin.

  • The capture process will capture data manipulation language (DML) changes made to the hr.departments table at dbs1.example.com.

  • The capture process assigns log files implicitly. That is, the downstream capture process automatically scans all redo log files added by redo transport services or added manually from the source database to the downstream database.

Complete the following steps:

  1. Complete the tasks in "Preparing to Configure a Capture Process". Ensure that you complete the task "Configuring Log File Transfer to a Downstream Capture Database".

  2. In SQL*Plus, connect to the downstream database dbs2.example.com as the Oracle Streams administrator.

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.

  3. Create the database link from dbs2.example.com to dbs1.example.com. For example, if the user strmadmin is the Oracle Streams administrator on both databases, then create the following database link:

    CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
   IDENTIFIED BY password
   USING 'dbs1.example.com';

    This example assumes that an Oracle Streams administrator exists at the source database dbs1.example.com. If no Oracle Streams administrator exists at the source database, then the Oracle Streams administrator at the downstream database should connect to a user who allows remote access by an Oracle Streams administrator. You can enable remote access for a user by specifying the user as the grantee when you run the GRANT_REMOTE_ADMIN_ACCESS procedure in the DBMS_STREAMS_AUTH package at the source database.

  4. Run the CREATE_CAPTURE procedure to create the capture process:

    BEGIN
  DBMS_CAPTURE_ADM.CREATE_CAPTURE(
    queue_name         => 'strmadmin.streams_queue',
    capture_name       => 'strm04_capture',
    rule_set_name      => NULL,
    start_scn          => NULL,
    source_database    => 'dbs1.example.com',
    use_database_link  => TRUE,
    first_scn          => NULL,
    logfile_assignment => 'implicit');
END;
/

    Running this procedure performs the following actions:

    • Creates a capture process named strm04_capture at the downstream database dbs2.example.com. A capture process with the same name must not exist.

    • Associates the capture process with an existing queue on dbs2.example.com named streams_queue and owned by strmadmin.

    • Specifies that the source database of the changes that the capture process will capture is dbs1.example.com.

    • Specifies that the capture process accepts new redo log files implicitly from dbs1.example.com. Therefore, the capture process scans any new log files copied from dbs1.example.com to dbs2.example.com for changes that it must capture.

    This step does not associate the capture process strm04_capture with any rule set. A rule set will be created and associated with the capture process in the next step.

    If no other capture process at dbs2.example.com is capturing changes from the dbs1.example.com source database, then the DBMS_CAPTURE_ADM.BUILD procedure is run automatically at dbs1.example.com using the database link. Running this procedure extracts the data dictionary at dbs1.example.com to the redo log, and a LogMiner data dictionary for dbs1.example.com is created at dbs2.example.com when the capture process is started for the first time at dbs2.example.com.

    If multiple capture processes at dbs2.example.com are capturing changes from the dbs1.example.com source database, then the new capture process uses the same LogMiner data dictionary for dbs1.example.com as one of the existing capture process. Oracle Streams automatically chooses which LogMiner data dictionary to share with the new capture process.


    Note:

    During the creation of a downstream capture process, if the first_scn parameter is set to NULL in the CREATE_CAPTURE procedure, then the use_database_link parameter must be set to TRUE. Otherwise, an error is raised.


    See Also:


  5. Create the positive rule set for the capture process and add a rule to it:

    BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name          =>  'hr.departments',
    streams_type        =>  'capture',
    streams_name        =>  'strm04_capture',
    queue_name          =>  'strmadmin.streams_queue',
    include_dml         =>  TRUE,
    include_ddl         =>  FALSE,
    include_tagged_lcr  =>  FALSE,
    source_database     =>  'dbs1.example.com',
    inclusion_rule      =>  TRUE);
END;
/

    Running this procedure performs the following actions:

    • Creates a rule set at dbs2.example.com for capture process strm04_capture. The rule set has a system-generated name. The rule set is a positive rule set for the capture process because the inclusion_rule parameter is set to TRUE.

    • Creates a rule that captures DML changes to the hr.departments table, and adds the rule to the rule set for the capture process. The rule has a system-generated name. The rule is added to the positive rule set for the capture process because the inclusion_rule parameter is set to TRUE.

  6. If necessary, complete the steps described in "After Configuring a Capture Process".

Configuring an Archived-Log Downstream Capture Process that Assigns Logs Explicitly

To create a capture process that performs downstream capture, you must use the CREATE_CAPTURE procedure. This section describes creating an archived-log downstream capture process that assigns redo log files explicitly. That is, you must use the DBMS_FILE_TRANSFER package, FTP, or some other method to transfer redo log files from the source database to the downstream database, and then you must register these redo log files with the downstream capture process manually.

In this example, assume the following:

  • The source database is dbs1.example.com and the downstream database is dbs2.example.com.

  • The capture process that will be created at dbs2.example.com uses the streams_queue owned by strmadmin.

  • The capture process will capture data manipulation language (DML) changes made to the hr.departments table at dbs1.example.com.

  • The capture process does not use a database link to the source database for administrative actions.

Complete the following steps:

  1. Complete the tasks in "Preparing to Configure a Capture Process". Because in this example you are transferring and registering archived redo log files explicitly at the downstream database, you do not need to complete the task "Configuring Log File Transfer to a Downstream Capture Database".

  2. In SQL*Plus, connect to the source database dbs1.example.com as the Oracle Streams administrator.

    If you do not use a database link from the downstream database to the source database, then an Oracle Streams administrator must exist at the source database.

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.

  3. If there is no capture process at dbs2.example.com that captures changes from dbs1.example.com, then perform a build of the dbs1.example.com data dictionary in the redo log. This step is optional if a capture process at dbs2.example.com is already configured to capture changes from the dbs1.example.com source database.

    SET SERVEROUTPUT ON
DECLARE
  scn  NUMBER;
BEGIN
  DBMS_CAPTURE_ADM.BUILD(
    first_scn => scn);
  DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/
First SCN Value = 409391

    This procedure displays the valid first SCN value for the capture process that will be created at dbs2.example.com. Make a note of the SCN value returned because you will use it when you create the capture process at dbs2.example.com.

    If you run this procedure to build the data dictionary in the redo log, then when the capture process is first started at dbs2.example.com, it will create a LogMiner data dictionary using the data dictionary information in the redo log.

  4. Prepare the hr.departments table for instantiation:

    BEGIN
  DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
     table_name           =>  'hr.departments',
     supplemental_logging =>  'keys');
END;
/

    Primary key supplemental logging is required for the hr.departments table because this example creates a capture processes that captures changes to this table. Specifying keys for the supplemental_logging parameter in the PREPARE_TABLE_INSTANTIATION procedure enables supplemental logging for any primary key, unique key, bitmap index, and foreign key columns in the table.

  5. Determine the current SCN of the source database:

    SET SERVEROUTPUT ON SIZE 1000000

DECLARE
  iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_OUTPUT.PUT_LINE('Current SCN: ' || iscn);
END;
/

    You can use the returned SCN as the instantiation SCN for destination databases that will apply changes to the hr.departments table that were captured by the capture process being created. In this example, assume the returned SCN is 1001656.

  6. Connect to the downstream database dbs2.example.com as the Oracle Streams administrator.

  7. Run the CREATE_CAPTURE procedure to create the capture process and specify the value obtained in Step 3 for the first_scn parameter:

    BEGIN
  DBMS_CAPTURE_ADM.CREATE_CAPTURE(
    queue_name         => 'strmadmin.streams_queue',
    capture_name       => 'strm05_capture',
    rule_set_name      => NULL,
    start_scn          => NULL,
    source_database    => 'dbs1.example.com',
    use_database_link  => FALSE,
    first_scn          => 409391, -- Use value from Step 3
    logfile_assignment => 'explicit');
END;
/

    Running this procedure performs the following actions:

    • Creates a capture process named strm05_capture at the downstream database dbs2.example.com. A capture process with the same name must not exist.

    • Associates the capture process with an existing queue on dbs2.example.com named streams_queue and owned by strmadmin.

    • Specifies that the source database of the changes that the capture process will capture is dbs1.example.com.

    • Specifies that the first SCN for the capture process is 409391. This value was obtained in Step 3. The first SCN is the lowest SCN for which a capture process can capture changes. Because a first SCN is specified, the capture process creates a new LogMiner data dictionary when it is first started, regardless of whether there are existing LogMiner data dictionaries for the same source database.

    • Specifies that new redo log files from dbs1.example.com must be assigned to the capture process explicitly. After a redo log file has been transferred to the computer running the downstream database, you assign the log file to the capture process explicitly using the following statement:

      ALTER DATABASE REGISTER LOGICAL LOGFILE file_name FOR capture_process;

      Here, file_name is the name of the redo log file and capture_process is the name of the capture process that will use the redo log file at the downstream database. You must add redo log files manually if the logfile_assignment parameter is set to explicit.

    This step does not associate the capture process strm05_capture with any rule set. A rule set will be created and associated with the capture process in the next step.


    See Also:


  8. Create the positive rule set for the capture process and add a rule to it:

    BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name          =>  'hr.departments',
    streams_type        =>  'capture',
    streams_name        =>  'strm05_capture',
    queue_name          =>  'strmadmin.streams_queue',
    include_dml         =>  TRUE,
    include_ddl         =>  FALSE,
    include_tagged_lcr  =>  FALSE,
    source_database     =>  'dbs1.example.com',
    inclusion_rule      =>  TRUE);
END;
/

    Running this procedure performs the following actions:

    • Creates a rule set at dbs2.example.com for capture process strm05_capture. The rule set has a system-generated name. The rule set is a positive rule set for the capture process because the inclusion_rule parameter is set to TRUE.

    • Creates a rule that captures DML changes to the hr.departments table, and adds the rule to the rule set for the capture process. The rule has a system-generated name. The rule is added to the positive rule set for the capture process because the inclusion_rule parameter is set to TRUE.

  9. After the redo log file at the source database dbs1.example.com that contains the first SCN for the downstream capture process is archived, transfer the archived redo log file to the computer running the downstream database. The BUILD procedure in Step 3 determined the first SCN for the downstream capture process. If the redo log file is not yet archived, then you can run the ALTER SYSTEM SWITCH LOGFILE statement on the database to archive it.

    You can run the following query at dbs1.example.com to identify the archived redo log file that contains the first SCN for the downstream capture process:

    COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A50
COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999

SELECT NAME, FIRST_CHANGE# FROM V$ARCHIVED_LOG
  WHERE FIRST_CHANGE# IS NOT NULL AND DICTIONARY_BEGIN = 'YES';

    

    Transfer the archived redo log file with a FIRST_CHANGE# that matches the first SCN returned in Step 3 to the computer running the downstream capture process.
    

  10. 

    Connect to the downstream database dbs2.example.com as an administrative user.
    

  11. 

    Assign the transferred redo log file to the capture process. For example, if the redo log file is /oracle/logs_from_dbs1/1_10_486574859.dbf, then issue the following statement:
    

    ALTER DATABASE REGISTER LOGICAL LOGFILE 
   '/oracle/logs_from_dbs1/1_10_486574859.dbf' FOR 'strm05_capture';

  12. 

    If necessary, complete the steps described in "After Configuring a Capture Process".
    













After Configuring a Capture Process


If you plan to configure propagations and apply processes that process logical change records (LCRs) captured by the new capture process, then perform the configuration in the following order:


  1. 

    Create all of the queues that will be required propagations and apply processes in the replication environment. See "Creating an ANYDATA Queue".
    

  2. 

    Create all of the propagations that will propagate LCRs captured by the new capture process. See "Creating Oracle Streams Propagations Between ANYDATA Queues".
    

  3. 

    Create all of the apply processes that will dequeue and process LCRs captured by the new capture process. See Chapter 7, "Configuring Implicit Apply". Configure each apply process to apply captured LCRs.
    

  4. 

    Instantiate the tables for which the new capture process captures changes at all destination databases. See Chapter 8, "Instantiation and Oracle Streams Replication" for detailed information about instantiation.
    

  5. 

    Use the START_APPLY procedure in the DBMS_APPLY_ADM package to start the apply processes that will process LCRs captured by the new capture process, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about starting an apply process using Oracle Enterprise Manager.
    

  6. 

    Use the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package to start the new capture process, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about starting a capture process using Oracle Enterprise Manager.
    










Note:

Other configuration steps might be required for your Oracle Streams environment. For example, some Oracle Streams environments include transformations, apply handlers, and conflict resolution.














Configuring Synchronous Capture


You can use any of the following procedures to create a synchronous capture:



Both of the procedures in the DBMS_STREAMS_ADM package create a synchronous capture with the specified name if it does not already exist, create a positive rule set for the synchronous capture if it does not exist, and can add table rules or subset rules to the rule set.


The CREATE_SYNC_CAPTURE procedure creates a synchronous capture, but does not create a rule set or rules for the synchronous capture. However, the CREATE_SYNC_CAPTURE procedure enables you to specify an existing rule set to associate with the synchronous capture, and it enables you to specify a capture user other than the default capture user.


The following sections describe configuring a synchronous capture:










See Also:












Preparing to Configure a Synchronous Capture


The following tasks must be completed before you configure a synchronous capture:









Configuring a Synchronous Capture Using the DBMS_STREAMS_ADM Package


When you run the ADD_TABLE_RULES or ADD_SUBSET_RULES procedure to create a synchronous capture, set the streams_type parameter in these procedures to sync_capture. A rule created by the ADD_TABLE_RULES procedure instructs the synchronous capture to capture all data manipulation language (DML) changes to the table. A rule created by the ADD_SUBSET_RULES procedure instructs the synchronous capture to capture a subset of the DML changes to the table.


This example assumes the following:


  • 

    The source database is dbs1.example.com.
    

  • 

    The synchronous capture that will be created uses the strmadmin.streams_queue queue.
    

  • 

    The synchronous capture that will be created captures the results of DML changes made to the hr.departments table.
    

  • 

    The capture user for the synchronous capture that will be created is the Oracle Streams administrator strmadmin.
    



Complete the following steps to create a synchronous capture using the DBMS_STREAMS_ADM package:


  1. 

    Complete the tasks in "Preparing to Configure a Synchronous Capture".
    

  2. 

    In SQL*Plus, connect to the dbs1.example.com database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
    

  3. 

    Run the ADD_TABLE_RULES or ADD_SUBSET_RULES procedure to create a synchronous capture. For example:
    

    BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name   => 'hr.departments',
    streams_type => 'sync_capture',
    streams_name => 'sync_capture',
    queue_name   => 'strmadmin.streams_queue');
END;
/

    

    This procedure performs the following actions:
    

    • 

      Creates a synchronous capture named sync_capture at the source database.
      

    • 

      Enables the synchronous capture. A synchronous capture cannot be disabled.
      

    • 

      Associates the synchronous capture with the existing strmadmin.streams_queue queue.
      

    • 

      Creates a positive rule set for the synchronous capture. The rule set has a system-generated name.
      

    • 

      Creates a rule that captures DML changes to the hr.departments table, and adds the rule to the positive rule set for the synchronous capture. The rule has a system-generated name.
      

    • 

      Configures the user who runs the procedure as the capture user for the synchronous capture. In this case, this user is strmadmin.
      

    • 

      Prepares the specified table for instantiation by running the DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION function for the table automatically.
      

    

    


    

    

    Note:
    
When the ADD_TABLE_RULES or the ADD_SUBSET_RULES procedure adds rules to a synchronous capture rule set, the procedure must obtain an exclusive lock on the specified table. If there are outstanding transactions on the specified table, then the procedure waits until it can obtain a lock.
    

    

    

  4. 

    If necessary, complete the steps described in "After Configuring a Synchronous Capture".
    









Configuring a Synchronous Capture Using the DBMS_CAPTURE_ADM Package


This section contains an example that runs procedures in the DBMS_CAPTURE_ADM package and DBMS_STREAMS_ADM package to configure a synchronous capture.


This example assumes the following:


  • 

    The source database is dbs1.example.com.
    

  • 

    The synchronous capture that will be created uses the strmadmin.streams_queue queue.
    

  • 

    The synchronous capture that will be created uses an existing rule set named sync01_rule_set in the strmadmin schema.
    

  • 

    The synchronous capture that will be created captures the results of a subset of the DML changes made to the hr.departments table.
    

  • 

    The capture user for the synchronous capture that will be created is hr. The hr user must have privileges to enqueue into the streams_queue.
    



Complete the following steps to create a synchronous capture using the DBMS_CAPTURE_ADM package:


  1. 

    Complete the tasks in "Preparing to Configure a Synchronous Capture".
    

  2. 

    In SQL*Plus, connect to the dbs1.example.com database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
    

  3. 

    Create the rule set that will be used by the synchronous capture if it does not exist. In this example, assume that the rule set is strmadmin.sync01_rule_set. See Oracle Streams Concepts and Administration for instructions.
    

  4. 

    Run the CREATE_SYNC_CAPTURE procedure to create a synchronous capture. For example:
    

    BEGIN
  DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE(
    queue_name    => 'strmadmin.streams_queue',
    capture_name  => 'sync01_capture',
    rule_set_name => 'strmadmin.sync01_rule_set',
    capture_user  => 'hr');
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates a synchronous capture named sync01_capture. A synchronous capture with the same name must not exist.
      

    • 

      Enables the synchronous capture. A synchronous capture cannot be disabled.
      

    • 

      Associates the synchronous capture with the existing queue strmadmin.streams_queue.
      

    • 

      Associates the synchronous capture with the existing rule set strmadmin.sync01_rule_set.
      

    • 

      Configures hr as the capture user for the synchronous capture.
      

    

  5. 

    Run the ADD_TABLE_RULES or ADD_SUBSET_RULES procedure to add a rule to the synchronous capture rule set. For example, run the ADD_SUBSET_RULES procedure to instruct the synchronous capture to capture a subset of the DML changes to the hr.departments table:
    

    BEGIN 
  DBMS_STREAMS_ADM.ADD_SUBSET_RULES(
    table_name          => 'hr.departments',
    dml_condition       => 'department_id=1700',
    streams_type        => 'sync_capture',
    streams_name        => 'sync01_capture',
    queue_name          => 'strmadmin.streams_queue',
    include_tagged_lcr  =>  FALSE);
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Adds subset rules to the rule set for the synchronous capture named sync01_capture at the source database dbs1.example.com. The subset rules instruct the synchronous capture to capture changes to rows with department_id equal to 1700. The synchronous capture does not capture changes to other rows in the table.
      

    • 

      Prepares the hr.departments table for instantiation by running the DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION function for the table automatically.
      

    • 

      Specifies that the synchronous capture captures a change only if the session that makes the change has a NULL tag, because the include_tagged_lcr parameter is set to FALSE. This behavior is accomplished through the system-created rules for the synchronous capture.
      

    

    


    

    

    Note:
    
When the CREATE_SYNC_CAPTURE procedure creates a synchronous capture, the procedure must obtain an exclusive lock on each table for which it will capture changes. The rules in the specified rule set for the synchronous capture determine these tables. Similarly, when the ADD_TABLE_RULES or the ADD_SUBSET_RULES procedure adds rules to a synchronous capture rule set, the procedure must obtain an exclusive lock on the specified table. In these cases, if there are outstanding transactions on a table for which the synchronous capture will capture changes, then the procedure waits until it can obtain a lock.
    

    

    

  6. 

    If necessary, complete the steps described in "After Configuring a Synchronous Capture".
    









After Configuring a Synchronous Capture


If you configured propagations and apply processes that process logical change records (LCRs captured) by the new synchronous capture, then complete the following steps:


  1. 

    Instantiate the tables for which the new synchronous capture captures changes at all destination databases. See Chapter 8, "Instantiation and Oracle Streams Replication" for detailed information about instantiation.
    

  2. 

    Use the START_APPLY procedure in the DBMS_APPLY_ADM package to start the apply processes that will process LCRs captured by the new synchronous capture, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about starting an apply process using Oracle Enterprise Manager.
    










Note:

Other configuration steps might be required for your Oracle Streams environment. For example, some Oracle Streams environments include transformations, apply handlers, and conflict resolution.














PKʩUƏ..PK+AOEBPS/index.htm

Index



Index

A  B  C  D  E  F  G  H  I  L  M  N  O  P  Q  R  S  T  U  V  X 



A


ABORT_GLOBAL_INSTANTIATION procedure, 8.2.5
ABORT_SCHEMA_INSTANTIATION procedure, 8.2.5
ABORT_SYNC_INSTANTIATION procedure, 8.2.5
ABORT_TABLE_INSTANTIATION procedure, 8.2.5
ADD SUPPLEMENTAL LOG, 1.3.6.2
ADD SUPPLEMENTAL LOG DATA, 1.3.6.3
ADD SUPPLEMENTAL LOG DATA clause of ALTER DATABASE, 1.3.6.5
ADD SUPPLEMENTAL LOG GROUP clause of ALTER TABLE


conditional log groups, 1.3.6.3
unconditional log groups, 1.3.6.2


alert log


Streams best practices, 15.2.6


ALTER DATABASE statement


ADD SUPPLEMENTAL LOG DATA clause, 1.3.6.5
DROP SUPPLEMENTAL LOG DATA clause, 1.3.6.6


ALTER TABLE statement


ADD SUPPLEMENTAL LOG DATA clause


conditional log groups, 1.3.6.3
unconditional log groups, 1.3.6.2


ADD SUPPLEMENTAL LOG GROUP clause


conditional log groups, 1.3.6.3
unconditional log groups, 1.3.6.2


DROP SUPPLEMENTAL LOG GROUP clause, 1.3.6.4


ALTER_APPLY procedure


removing the tag value, 10.6.2.2
setting the tag value, 10.1, 10.4, 10.6.2.1


ANYDATA data type


queues


creating, 6.1




apply process


apply handlers, 1.2.5
apply user


best practices, 18.1.1


best practices


configuration, 18.2
operation, 18.3


conflict resolution, 9
creating, 7.1
data types applied


heterogeneous environments, 11.1.2.2


DML changes


heterogeneous environments, 11.1.2.3


DML handlers


heterogeneous environments, 11.1.2.1.5


error handlers


heterogeneous, 11.1.2.1.7


errors


best practices, 18.2.2, 18.3.1


heterogeneous environments, 11.1.2, 11.2.3


database links, 11.1.2.1.1
Oracle Database Gateways, 11.1.2.1.1


LOBs, 14.4.1
message handlers


heterogeneous environments, 11.1.2.1.6


oldest SCN


point-in-time recovery, 12.6.3


parallelism


best practices, 18.2.1


substitute key columns


heterogeneous environments, 11.1.2.1.3, 11.1.2.1.4, 11.1.2.1.5, 11.1.2.1.6, 11.1.2.1.7


tags, 10.4


monitoring, 10.7.2
removing, 10.6.2.2
setting, 10.6.2.1


update conflict handlers


monitoring, 9.8.2




ARCHIVELOG mode, 1.3.3


capture process, 5.1.1







B


backups


online


Streams, 10.3


Streams best practices, 15.2.4


batch processing


capture process best practices, 16.2.3


best practices


Streams replication, 14.5


alert log, 15.2.6
apply, 18
apply errors, 18.2.2, 18.3.1
apply process configuration, 18.2
apply process operation, 18.3
apply process parallelism, 18.2.1
apply user, 18.1.1
archive log threads, 15.3.1
automate configuration, 15.1.2
backups, 15.2.4
batch processing, 16.2.3
capture, 16
capture process configuration, 16.1
capture process operation, 16.2
capture process parallelism, 16.1.2
capture process's queue, 15.2.3
capture user, 16.1.1
checkpoint retention, 16.1.3
conflict resolution, 18.1.3
data dictionary build, 16.2.2
database configuration, 15.1
database operation, 15.2
DDL replication, 1.2.6
destination database, 18.1
global name, 15.2.1
heartbeat table, 16.2.1
instantiation SCN, 18.1.2
Oracle Real Application Clusters (Oracle RAC) databases, 15.3
performance, 15.2.2
prepare for instantiation, 16.2.2
propagation, 17
propagation latency, 17.1.2
queue-to-queue propagation, 17.1.1
removing, 15.2.7
restarting propagation, 17.2.1
SDU, 17.1.3
statistics collection, 15.2.5
synchronous capture configuration, 16.3




bi-directional replication, 1.2.3, 1.2.7





C


capture process


ARCHIVELOG mode, 5.1.1
best practices


batch processing, 16.2.3
configuration, 16.1
data dictionary build, 16.2.2
operation, 16.2
prepare for instantiation, 16.2.2


capture user


best practices, 16.1.1


configuring, 5
creating, 5.1
DBID, 5.1


changing, 12.4


downstream capture, 1.2.2, 2.2.2.1


creating, 5.1


global name, 5.1


changing, 12.4


heterogeneous environments, 11.1.1
local capture, 1.2.2, 2.2.2.1
log sequence number


resetting, 12.6.1


parallelism


best practices, 16.1.2


parameters


merge_threshold, 12.3.2.1
message_tracking_frequency, 12.2
split_threshold, 12.3.2.1


preparing for, 5.1.1
supplemental logging, 1.3.6, 8.2.3


change cycling


avoidance


tags, 10.5




checkpoint retention


best practices, 16.1.3


column lists, 9.6.1.2
COMPARE function, 13.5


perform_row_dif parameter, 13.5.2


COMPARE_OLD_VALUES procedure, 9.4.1, 9.7.4
comparing database objects, 13.5
COMPATIBLE initialization parameter, 1.3.4
conflict resolution, 9


best practices, 18.1.3
column lists, 9.6.1.2
conflict handlers, 9.3, 9.4, 9.5, 9.6


custom, 9.6.2
modifying, 9.7.2
prebuilt, 9.6.1
removing, 9.7.3
setting, 9.7.1


data convergence, 9.6.1.4
DISCARD handler, 9.6.1.1.2
MAXIMUM handler, 9.6.1.1.3


latest time, 9.6.1.1.3


MINIMUM handler, 9.6.1.1.4
OVERWRITE handler, 9.6.1.1.1
resolution columns, 9.6.1.3
time-based, 9.6.1.1.3


conflicts


avoidance, 9.5


delete, 9.5.2.2
primary database ownership, 9.5.1
sequences, 9.5.2.1
uniqueness, 9.5.2.1
update, 9.5.2.3


delete, 9.2.3
detection, 9.4


identifying rows, 9.4.2
monitoring, 9.8.1
stopping, 9.4.1, 9.7.4


DML conflicts, 9.1
foreign key, 9.2.4
transaction ordering, 9.3
types of, 9.2
uniqueness, 9.2.2
update, 9.2.1, 9.2.2, 9.2.3, 9.2.4


CONVERGE procedure, 13.7
CREATE_APPLY procedure, 7.1


tags, 10.1, 10.4


CREATE_CAPTURE procedure, 5.1, 5.1.2.2
CREATE_COMPARISON procedure, 13.5
CREATE_PROPAGATION procedure, 6.2
CREATE_SYNC_CAPTURE procedure, 5.2.3





D


data


comparing, 13.5


custom, 13.5.5
cyclic, 13.5.4
purging results, 13.9
random, 13.5.3
rechecking, 13.8
subset of columns, 13.5.1


converging, 13.7


session tags, 13.7.3




data types


heterogeneous environments, 11.1.2.2


database links, 1.3.2
databases


adding for replication, 4.2.2, 4.3.2, 4.3.4


DBA_APPLY view, 10.7.2
DBA_APPLY_CONFLICT_COLUMNS view, 9.8.2
DBA_APPLY_INSTANTIATED_OBJECTS view, 8.6.2
DBA_APPLY_TABLE_COLUMNS view, 9.8.1
DBA_CAPTURE_PREPARED_DATABASE view, 8.6.1
DBA_CAPTURE_PREPARED_SCHEMAS view, 8.6.1
DBA_CAPTURE_PREPARED_TABLES view, 8.6.1
DBA_COMPARISON view, 13.6, 13.6.5, 13.6.6
DBA_COMPARISON_COLUMNS view, 13.6.3
DBA_COMPARISON_SCAN view, 13.6.4, 13.6.5, 13.6.6
DBA_COMPARISON_SCAN_VALUES view, 13.6.7
DBA_RECOVERABLE_SCRIPT view, 12.8
DBA_RECOVERABLE_SCRIPT_BLOCKS view, 12.8
DBA_RECOVERABLE_SCRIPT_ERRORS view, 12.8
DBA_RECOVERABLE_SCRIPT_PARAMS view, 12.8
DBA_SYNC_CAPTURE_PREPARED_TABS view, 8.6.1
DBID (database identifier)


capture process, 5.1


changing, 12.4




DBMS_CAPTURE_ADM package, 5
DBMS_COMPARISON package


buckets, 13.1.2
comparing database objects, 13.5


custom, 13.5.5
cyclic, 13.5.4
purging results, 13.9
random, 13.5.3
rechecking, 13.8
subset of columns, 13.5.1


converging database objects, 13.7


session tags, 13.7.3


monitoring, 13.6
parent scans, 13.1.3
preparation, 13.3
root scans, 13.1.3
scans, 13.1.1
Streams replication, 13.11
using, 13


DBMS_PROPAGATION_ADM package, 6
DBMS_STREAMS package, 10.6
DBMS_STREAMS_ADM package, 1.1.2, 5, 6


creating a capture process, 5.1
creating a propagation, 6.2
creating an apply process, 7.1
preparation for instantiation, 8.2.1
tags, 10.2


DDL replication


best practices, 1.2.6


directory objects, 2.2.3


creating, 4.2.2


DISCARD conflict resolution handler, 9.6.1.1.2
DML handlers


LOB assembly, 14.4.2


downstream capture, 1.2.2, 2.2.2.1


archived-log, 1.2.2
configuring, 2.2.5
log file transfer, 1.3.7
real-time, 1.2.2, 1.3.8
standby redo logs, 1.3.8


DROP SUPPLEMENTAL LOG DATA clause of ALTER DATABASE, 1.3.6.6
DROP SUPPLEMENTAL LOG GROUP clause, 1.3.6.4
DROP_COMPARISON procedure, 13.10





E


ENQUEUE procedure, 14.2
error handlers


LOB assembly, 14.4.2


error queue


heterogeneous environments, 11.1.5


Export


Oracle Streams, 8.5.1







F


flashback queries


Streams replication, 12.7







G


GET_MESSAGE_TRACKING function, 12.2
GET_SCN_MAPPING procedure, 12.6.2, 12.7
GET_TAG function, 10.6.1.2, 10.7.1
global name


best practices, 15.2.1
capture process, 5.1


changing, 12.4




GLOBAL_NAMES initialization parameter, 1.3.4
GRANT_REMOTE_ADMIN_ACCESS procedure, 5.1.3.1, 5.1.3.2.1





H


heartbeat table


Streams best practices, 16.2.1


heterogeneous information sharing, 11


non-Oracle to non-Oracle, 11.3
non-Oracle to Oracle, 11.2


apply process, 11.2.3
capturing changes, 11.2.1
instantiation, 11.2.4
user application, 11.2.1


Oracle to non-Oracle, 11.1


apply process, 11.1.2
capture process, 11.1.1
data types applied, 11.1.2.2
database links, 11.1.2.1.1
DML changes, 11.1.2.3
DML handlers, 11.1.2.1.5
error handlers, 11.1.2.1.7
errors, 11.1.5
instantiation, 11.1.2.4
message handlers, 11.1.2.1.6
staging, 11.1.1
substitute key columns, 11.1.2.1.3, 11.1.2.1.4, 11.1.2.1.5, 11.1.2.1.6, 11.1.2.1.7
transformations, 11.1.3




hub-and-spoke replication, 1.2.3, 1.2.7, 10.5.2


configuring, 2.2.6







I


Import


Oracle Streams, 8.5.1
STREAMS_CONFIGURATION parameter, 8.3.2.3


initialization parameters


COMPATIBLE, 1.3.4
GLOBAL_NAMES, 1.3.4
LOG_ARCHIVE_CONFIG, 1.3.4
LOG_ARCHIVE_DEST_n, 1.3.4
LOG_ARCHIVE_DEST_STATE_n, 1.3.4
LOG_BUFFER, 1.3.4
MEMORY_MAX_TARGET, 1.3.4
MEMORY_TARGET, 1.3.4
OPEN_LINKS, 1.3.4
PROCESSES, 1.3.4
SESSIONS, 1.3.4
SGA_MAX_SIZE, 1.3.4
SGA_TARGET, 1.3.4
SHARED_POOL_SIZE, 1.3.4
STREAMS_POOL_SIZE, 1.3.4
TIMED_STATISTICS, 1.3.4
UNDO_RETENTION, 1.3.4


instantiation, 2.2.2.6, 8


aborting preparation, 8.2.5
Data Pump, 8.3
database, 8.4.2
example


Data Pump export/import, 8.3.3
RMAN CONVERT DATABASE, 8.4.2.2
RMAN DUPLICATE, 8.4.2.1
RMAN TRANSPORT TABLESPACE, 8.4.1
transportable tablespace, 8.4.1


heterogeneous environments


non-Oracle to Oracle, 11.2.4
Oracle to non-Oracle, 11.1.2.4


monitoring, 8.6
Oracle Streams, 8.5.1
preparation for, 8.2
preparing for, 8.1, 8.2.4
RMAN, 8.4
setting an SCN, 8.5


DDL LCRs, 8.5.2
export/import, 8.5.1


supplemental logging specifications, 8.1


instantiation SCN


best practices, 18.1.2







L


LCRs. See logical change records
LOB assembly, 14.4.2
LOBs


Oracle Streams, 14.4


apply process, 14.4.1




log sequence number


Streams capture process, 12.6.1


LOG_ARCHIVE_CONFIG initialization parameter, 1.3.4
LOG_ARCHIVE_DEST_n initialization parameter, 1.3.4
LOG_ARCHIVE_DEST_STATE_n initialization parameter, 1.3.4
LOG_BUFFER initialization parameter, 1.3.4
logical change records (LCRs)


constructing, 14.2
enqueuing, 14.2
executing, 14.3


DDL LCRs, 14.3.2
row LCRs, 14.3.1


LOB columns, 14.4, 14.5


apply process, 14.4.1
requirements, 14.4.3


LONG columns, 14.5


requirements, 14.5


LONG RAW columns, 14.5


requirements, 14.5


managing, 14
requirements, 14.1
tracking, 12.2
XMLType, 14.4


LONG data type


Oracle Streams, 14.5


LONG RAW data type


Oracle, 14.5







M


MAINTAIN_GLOBAL procedure, 2.2, 2.2.4.1
MAINTAIN_SCHEMAS procedure, 2.2, 2.2.4.2, 2.2.5.2, 2.2.5.3, 2.2.6
MAINTAIN_SIMPLE_TTS procedure, 2.2, 2.2.5.1, 2.2.5.1
MAINTAIN_TABLES procedure, 2.2, 2.2.4.3
MAINTAIN_TTS procedure, 2.2, 2.2.5.1, 2.2.5.1
MAXIMUM conflict resolution handler, 9.6.1.1.3


latest time, 9.6.1.1.3


MEMORY_MAX_TARGET initialization parameter, 1.3.4, 1.3.5.1
MEMORY_TARGET initialization parameter, 1.3.4, 1.3.5.1
merge streams, 12.3
MERGE_STREAMS procedure, 12.3.2.2
MERGE_STREAMS_JOB procedure, 12.3.2.2
message tracking, 12.2, 12.2
message_tracking_frequency capture process parameter, 12.2
MINIMUM conflict resolution handler, 9.6.1.1.4
monitoring


apply process


update conflict handlers, 9.8.2


comparisons, 13.6
conflict detection, 9.8.1
instantiation, 8.6
tags, 10.7


apply process value, 10.7.2
current session value, 10.7.1









N


n-way replication, 1.2.3, 1.2.7, 10.5.1





O


objects


adding for replication, 4.2.1, 4.3.1, 4.3.3


oldest SCN


point-in-time recovery, 12.6.3


one-way replication, 1.2.7
OPEN_LINKS initialization parameter, 1.3.4
optimizer


statistics collection


best practices, 15.2.5




Oracle Data Pump


Import utility


STREAMS_CONFIGURATION parameter, 8.3.2.3


instantiations, 8.3.3
Streams instantiation, 8.3


Oracle Database Gateways


Oracle Streams, 11.1.2.1.1


Oracle Real Application Clusters


Streams best practices, 15.3


archive log threads, 15.3.1
global name, 15.3.2
propagations, 15.3.3
queue ownership, 15.3.4




Oracle Streams


conflict resolution, 9
DBMS_COMPARISON package, 13.11
Export utility, 8.5.1
heterogeneous information sharing, 11
Import utility, 8.5.1
instantiation, 8.1, 8.5.1
LOBs, 14.4
logical change records (LCRs)


managing, 14


LONG data type, 14.5
migrating to from Advanced Replication, A
Oracle Database Gateways, 11.1.2.1.1
point-in-time recovery, 12.6
replication, 1


adding databases, 4.2.2, 4.3.2, 4.3.4
adding objects, 4.2.1, 4.3.1, 4.3.3
adding to, 4
best practices, 14.5
configuring, 2, 3
managing, 12
sequences, 9.5.2.1


rules, 1.1.2
sequences, 9.5.2.1
tags, 10
XMLType, 14.4


Oracle Streams Performance Advisor, 15.2.2
OVERWRITE conflict resolution handler, 9.6.1.1.1





P


performance


Oracle Streams, 15.2.2


point-in-time recovery


Oracle Streams, 12.6


POST_INSTANTIATION_SETUP procedure, 2.2, 2.2.4.1, 2.2.5.1, 2.2.5.1
PRE_INSTANTIATION_SETUP procedure, 2.2, 2.2.4.1, 2.2.5.1, 2.2.5.1
PREPARE_GLOBAL_INSTANTIATION procedure, 8.2, 8.2.4
PREPARE_SCHEMA_INSTANTIATION procedure, 8.2, 8.2.4
PREPARE_SYNC_INSTANTIATION function, 8.2, 8.2.4
PREPARE_TABLE_INSTANTIATION procedure, 8.2, 8.2.4
PROCESSES initialization parameter, 1.3.4
propagation


best practices, 17


broken propagations, 17.2.1
configuration, 17.1
propagation latency, 17.1.2
propagation operation, 17.2
queue-to-queue propagation, 17.1.1
restarting propagation, 17.2.1
SDU, 17.1.3




propagation jobs


managing, 6.2


propagations


creating, 6, 6.2
managing, 6.2


PURGE_COMPARISON procedure, 13.9





Q


queues


ANYDATA


creating, 6.1


commit-time, 11.2.2
creating, 6
size


best practices, 15.2.3


transactional, 11.2.2


queue-to-queue propagation


best practices, 17.1.1







R


RECHECK function, 13.8
RECOVER_OPERATION procedure, 12.8
Recovery Manager


CONVERT DATABASE command


Streams instantiation, 8.4.2.2


DUPLICATE command


Streams instantiation, 8.4.2.1


Streams instantiation, 8.4
TRANSPORT TABLESPACE command


Streams instantiation, 8.4.1




replication


adding databases, 4.2.2, 4.3.2, 4.3.4
adding objects, 4.2.1, 4.3.1, 4.3.3
adding to, 4
bi-directional, 1.2.1, 2.2.2.4
configuration errors


recovering, 12.8


configuring, 2, 3


apply handlers, 1.2.5
ARCHIVELOG mode, 1.3.3
bi-directional, 1.2.3, 1.2.7
database, 2.2.4.1
database links, 1.3.2
DBMS_STREAMS_ADM package, 2.2
DDL changes, 1.2.6, 2.2.2.5
directory objects, 2.2.3
downstream capture, 1.2.2, 2.2.2.1, 2.2.5
Enterprise Manager, 2.1
hub-and-spoke, 1.2.3, 1.2.7, 2.2.6
initialization parameters, 1.3.4
instantiation, 2.2.2.6
local capture, 1.2.2, 2.2.2.1
log file transfer, 1.3.7
multiple-source environment, 3.2
n-way, 1.2.3, 1.2.7
one-way, 1.2.7
Oracle Streams pool, 1.3.5
preparation, 1
schemas, 2.2.4.2, 2.2.5.2, 2.2.5.3, 2.2.6
scripts, 2.2.2.2
single-source environment, 3.1
standby redo logs, 1.3.8
supplemental logging, 1.3.6
tables, 2.2.4.3
tablespace, 2.2.5.1
tablespaces, 2.2.5.1
tags, 2.2.2.4.1


hub-and-spoke, 1.2.1, 10.5.2
managing, 12
migrating to Streams, A
n-way, 1.2.1, 10.5.1
one-way, 1.2.1, 2.2.2.4
Oracle Streams, 1


best practices, 14.5
managing, 12


sequences, 9.5.2.1
split and merge, 12.3


resolution columns, 9.6.1.3
rule-based transformations, 1.2.4
rules, 1.1.2


system-created


tags, 10.2









S


SDU


Streams best practices, 17.1.3


sequences, 9.5.2.1


replication, 9.5.2.1


SESSIONS initialization parameter, 1.3.4
SET_DML_HANDLER procedure, 9.6.2
SET_GLOBAL_INSTANTIATION_SCN procedure, 8.5, 8.5.2
SET_MESSAGE_TRACKING procedure, 12.2
SET_SCHEMA_INSTANTIATION_SCN procedure, 8.5, 8.5.2
SET_TABLE_INSTANTIATION_SCN procedure, 8.5
SET_TAG procedure, 10.1, 10.6.1.1
SET_UP_QUEUE procedure, 6.1
SET_UPDATE_CONFLICT_HANDLER procedure, 9.6.1


modifying an update conflict handler, 9.7.2
removing an update conflict handler, 9.7.3
setting an update conflict handler, 9.7.1


SGA_MAX_SIZE initialization parameter, 1.3.4
SGA_TARGET initialization parameter, 1.3.4, 1.3.5.2
SHARED_POOL_SIZE initialization parameter, 1.3.4
split streams, 12.3
SPLIT_STREAMS procedure, 12.3.2.2
staging


heterogeneous environments, 11.1.1


statistics


Oracle Streams, 15.2.2


Streams pool


MEMORY_MAX_TARGET initialization parameter, 1.3.5.1
MEMORY_TARGET initialization parameter, 1.3.5.1
SGA_TARGET initialization parameter, 1.3.5.2


STREAMS_CONFIGURATION parameter


Data Pump Import utility, 8.3.2.3
Import utility, 8.3.2.3


STREAMS_MIGRATION procedure, A
STREAMS_POOL_SIZE initialization parameter, 1.3.4
STRMMON, 15.2.2
supplemental logging, 1.3.6


column lists, 9.6.1.2
instantiation, 8.1
preparation for instantiation, 8.2.3, 8.2.4


synchronous capture


best practices


configuration, 16.3


configuring, 5.2
preparing for, 5.2.1


system change numbers (SCN)


oldest SCN for an apply process


point-in-time recovery, 12.6.3









T


tags, 2.2.2.4.1, 10


ALTER_APPLY procedure, 10.1, 10.4
apply process, 10.4
change cycling


avoidance, 10.5


CONVERGE procedure, 13.7.3
CREATE_APPLY procedure, 10.1, 10.4
examples, 10.5
getting value for current session, 10.6.1.2
hub-and-spoke replication, 10.5
managing, 10.6
monitoring, 10.7


apply process value, 10.7.2
current session value, 10.7.1


n-way replication, 10.5
online backups, 10.3
removing value for apply process, 10.6.2.2
rules, 10.2


include_tagged_lcr parameter, 10.2


SET_TAG procedure, 10.1
setting value for apply process, 10.6.2.1
setting value for current session, 10.6.1.1


TIMED_STATISTICS initialization parameter, 1.3.4
tracking LCRs, 12.2
transformations


heterogeneous environments


Oracle to non-Oracle, 11.1.3


rule-based, 1.2.4, 1.2.4


transportable tablespace


Streams instantiation, 8.4.1







U


UNDO_RETENTION initialization parameter, 1.3.4





V


V$STREAMS_MESSAGE_TRACKING view, 12.2
V$STREAMS_POOL_ADVICE view, 1.3.5.3
V$STREAMS_TRANSACTION view, 8.2.4





X


XMLType


logical change records (LCRs), 14.4








PK9]PK+AOEBPS/capply.htmu[

Configuring Implicit Apply



7 Configuring Implicit Apply


In a replication environment, Oracle Streams apply process dequeues logical change records (LCRs) from a specific queue and either applies each one directly or passes it as a parameter to a user-defined procedure called an apply handler.


The following topics describe configuring implicit apply:



Each task described in this chapter should be completed by an Oracle Streams administrator that has been granted the appropriate privileges, unless specified otherwise.









See Also:












Overview of Apply Process Creation


You can use any of the following procedures to configure an apply process:



Each of the procedures in the DBMS_STREAMS_ADM package creates an apply process with the specified name if it does not already exist, creates either a positive rule set or negative rule set for the apply process if the apply process does not have such a rule set, and can add table rules, schema rules, global rules, or a message rule to the rule set.


The CREATE_APPLY procedure in the DBMS_APPLY_ADM package creates an apply process, but does not create a rule set or rules for the apply process. However, the CREATE_APPLY procedure enables you to specify an existing rule set to associate with the apply process, either as a positive or a negative rule set, and several other options, such as apply handlers, an apply user, an apply tag, and whether to dequeue messages from a buffered queue or a persistent queue.


A single apply process must either dequeue messages from a buffered queue or a persistent queue. Logical change records that were captured by a capture process are called captured LCRs, and they are always in buffered queues. Therefore, if a single apply process applies LCRs that were captured by a capture process, then it cannot apply persistent LCRs or persistent user messages.


Alternatively, LCRs that were captured by a synchronous capture are persistent LCRs, and they are always in persistent queues. Therefore, if a single apply process applies LCRs that were captured by a synchronous capture, then it cannot apply LCRs captured by a capture process. However, a single apply process can apply both persistent LCRs and persistent user messages because both types of messages are staged in a persistent queue.


The examples in this chapter create apply processes that apply captured LCRs, persistent LCRs, and persistent user messages. Before you create an apply process, create an ANYDATA queue to associate with the apply process, if one does not exist.









Note:















Preparing to Create an Apply Process


The following tasks must be completed before you create an apply:









Creating an Apply Process for Captured LCRs Using DBMS_STREAMS_ADM


The following example runs the ADD_SCHEMA_RULES procedure in the DBMS_STREAMS_ADM package to create an apply process that applies captured logical change records (LCRs). This apply process can apply LCRs that were captured by a capture process.


Complete the following steps:


  1. 

    Complete the tasks in "Preparing to Create an Apply Process".
    

  2. 

    In SQL*Plus, connect to the database that will run the apply process as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Create the apply process:
    

    BEGIN
  DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
    schema_name        => 'hr',
    streams_type       => 'apply',
    streams_name       => 'strm01_apply',
    queue_name         => 'strmadmin.streams_queue',
    include_dml        => TRUE,
    include_ddl        => FALSE,
    include_tagged_lcr => FALSE,
    source_database    => 'dbs1.example.com',
    inclusion_rule     => TRUE);
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates an apply process named strm01_apply that applies captured LCRs to the local database. The apply process is created only if it does not already exist.
      

    • 

      Associates the apply process with the existing queue strmadmin.streams_queue. This queue must exist.
      

    • 

      Creates a positive rule set and associates it with the apply process, if the apply process does not have a positive rule set, because the inclusion_rule parameter is set to TRUE. The rule set uses the SYS.STREAMS$_EVALUATION_CONTEXT evaluation context. The rule set name is system generated.
      

    • 

      Creates one rule that evaluates to TRUE for row LCRs that contain the results of data manipulation language (DML) changes to database objects in the hr schema. The rule name is system generated.
      

    • 

      Adds the rule to the positive rule set associated with the apply process because the inclusion_rule parameter is set to TRUE.
      

    • 

      Sets the apply_tag for the apply process to a value that is the hexadecimal equivalent of '00' (double zero). This is the default apply tag value. Redo entries generated by the apply process have a tag with this value.
      

    • 

      Specifies that the apply process applies a row LCR only if it has a NULL tag, because the include_tagged_lcr parameter is set to FALSE. This behavior is accomplished through the system-created rule for the apply process.
      

    • 

      Specifies that the LCRs applied by the apply process originate at the dbs1.example.com source database. The rules in the apply process rule sets determine which LCRs are dequeued by the apply process. If the apply process dequeues an LCR with a source database other than dbs1.example.com, then an error is raised.
      

    









Creating an Apply Process Using DBMS_APPLY_ADM


This section contains the following examples that create an apply process using the DBMS_APPLY_ADM package:










See Also:












Creating an Apply Process for Captured LCRs with DBMS_APPLY_ADM


The following example runs the CREATE_APPLY procedure in the DBMS_APPLY_ADM package to create an apply process that applies captured logical change records (LCRs). This apply process can apply LCRs that were captured by a capture process.


Complete the following steps:


  1. 

    Complete the tasks in "Preparing to Create an Apply Process".
    

  2. 

    In SQL*Plus, connect to the database that will run the apply process as the Oracle Streams administrator.
    

    Ensure that the Oracle Streams administrator is granted DBA role. DBA role is required because this example sets the apply user to a user other than the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Create the rule set that will be used by the apply process if it does not exist. In this example, assume that the rule set is strmadmin.strm02_rule_set. Optionally, you can also add rules to the rule set. See Oracle Streams Concepts and Administration for instructions.
    

  4. 

    Create any apply handlers that will be used by the apply process if they do not exist. In this example, assume that the DDL handler is the strmadmin.history_ddl procedure. An example in the Oracle Streams Concepts and Administration creates this procedure.
    

  5. 

    Create the apply process:
    

    BEGIN
  DBMS_APPLY_ADM.CREATE_APPLY(
    queue_name             => 'strmadmin.streams_queue',
    apply_name             => 'strm02_apply',
    rule_set_name          => 'strmadmin.strm02_rule_set',
    message_handler        => NULL,     
    ddl_handler            => 'strmadmin.history_ddl',
    apply_user             => 'hr',
    apply_database_link    => NULL,
    apply_tag              => HEXTORAW('5'),
    apply_captured         => TRUE,
    precommit_handler      => NULL,
    negative_rule_set_name => NULL,
    source_database        => 'dbs1.example.com');
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates an apply process named strm02_apply. An apply process with the same name must not exist.
      

    • 

      Associates the apply process with the queue strmadmin.streams_queue. This queue must exist.
      

    • 

      Associates the apply process with the rule set strmadmin.strm02_rule_set. This rule set must exist. This rule set is the positive rule set for the apply process.
      

    • 

      Specifies that the apply process does not use a message handler.
      

    • 

      Specifies that the DDL handler is the history_ddl PL/SQL procedure in the strmadmin schema. This procedure must exist, and the user who runs the CREATE_APPLY procedure must have EXECUTE privilege on the history_ddl PL/SQL procedure.
      

    • 

      Specifies that the user who applies changes is hr, and not the user who is running the CREATE_APPLY procedure (the Oracle Streams administrator).
      

    • 

      Specifies that the apply process applies changes to the local database because the apply_database_link parameter is set to NULL.
      

    • 

      Specifies that each redo entry generated by the apply process has a tag that is the hexadecimal equivalent of '5'. See Chapter 10, "Oracle Streams Tags" for more information about tags.
      

    • 

      Specifies that the apply process applies captured LCRs, not persistent LCRs or persistent user messages. Therefore, if an LCR that was constructed by a synchronous capture or a user application, not by a capture process, and is staged in the queue for the apply process, then this apply process does not dequeue the LCR.
      

    • 

      Specifies that the apply process does not use a precommit handler.
      

    • 

      Specifies that the apply process does not use a negative rule set.
      

    • 

      Specifies that the LCRs applied by the apply process originate at the dbs1.example.com source database. The rules in the apply process rule sets determine which LCRs are dequeued by the apply process. If the apply process dequeues an LCR with a source database other than dbs1.example.com, then an error is raised.
      

    



After creating the apply process, run the ADD_TABLE_RULES or ADD_SUBSET_RULES procedure to add rules to the apply process rule set. These rules direct the apply process to apply LCRs for the specified tables.









See Also:

Oracle Streams Concepts and Administration for more information about rules












Creating an Apply Process for Persistent LCRs with DBMS_APPLY_ADM


The following example runs the CREATE_APPLY procedure in the DBMS_APPLY_ADM package to create an apply process that applies persistent logical change records (LCRs). This apply process can apply LCRs that were captured by a synchronous capture or constructed by an application.


Complete the following steps:


  1. 

    Complete the tasks in "Preparing to Create an Apply Process".
    

  2. 

    In SQL*Plus, connect to the database that will run the apply process as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Create the rule set that will be used by the apply process if it does not exist. In this example, assume that the rule set is strmadmin.strm03_rule_set. Optionally, you can also add rules to the rule set. See Oracle Streams Concepts and Administration for instructions.
    

  4. 

    Create any apply handlers that will be used by the apply process if they do not exist. The apply process created in this example does not used apply handlers.
    

  5. 

    Create the apply process:
    

    BEGIN
  DBMS_APPLY_ADM.CREATE_APPLY(
    queue_name             => 'strmadmin.streams_queue',
    apply_name             => 'strm03_apply',
    rule_set_name          => 'strmadmin.strm03_rule_set',
    message_handler        => NULL,
    ddl_handler            => NULL,
    apply_user             => NULL,
    apply_database_link    => NULL,
    apply_tag              => NULL,
    apply_captured         => FALSE,
    precommit_handler      => NULL,
    negative_rule_set_name => NULL);
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates an apply process named strm03_apply. An apply process with the same name must not exist.
      

    • 

      Associates the apply process with the queue named strmadmin.streams_queue. This queue must exist.
      

    • 

      Associates the apply process with the rule set strmadmin.strm03_rule_set. This rule set must exist. This rule set is the positive rule set for the apply process.
      

    • 

      Specifies that the apply process does not use a message handler.
      

    • 

      Specifies that the apply process does not use a DDL handler.
      

    • 

      Specifies that the user who applies the changes is the user who runs the CREATE_APPLY procedure, because the apply_user parameter is NULL.
      

    • 

      Specifies that the apply process applies changes to the local database, because the apply_database_link parameter is set to NULL.
      

    • 

      Specifies that each redo entry generated by the apply process has a NULL tag. See Chapter 10, "Oracle Streams Tags" for more information about tags.
      

    • 

      Specifies that the apply process does not apply captured LCRs. Therefore, the apply process can apply persistent LCRs or persistent user messages that are in the persistent queue portion of the apply process's queue.
      

    • 

      Specifies that the apply process does not use a precommit handler.
      

    • 

      Specifies that the apply process does not use a negative rule set.
      

    



After creating the apply process, run the ADD_TABLE_RULES or ADD_SUBSET_RULES procedure to add rules to the apply process rule set. These rules direct the apply process to apply LCRs for the specified tables.









See Also:

Oracle Streams Concepts and Administration for more information about rules














PKa8z[u[PK+AOEBPS/conflict.htm

Oracle Streams Conflict Resolution



9 Oracle Streams Conflict Resolution


Some Oracle Streams environments must use conflict handlers to resolve possible data conflicts that can result from sharing data between multiple databases.


This chapter contains these topics:






About DML Conflicts in an Oracle Streams Environment


A conflict is a mismatch between the old values in an LCR and the expected data in a table. Conflicts can occur in an Oracle Streams environment that permits concurrent data manipulation language (DML) operations on the same data at multiple databases. In an Oracle Streams environment, DML conflicts can occur only when an apply process is applying a message that contains a row change resulting from a DML operation. This type of message is called a row logical change record, or row LCR. An apply process automatically detects conflicts caused by row LCRs.


For example, when two transactions originating at different databases update the same row at nearly the same time, a conflict can occur. When you configure an Oracle Streams environment, you must consider whether conflicts can occur. You can configure conflict resolution to resolve conflicts automatically, if your system design permits conflicts.


In general, you should try to design an Oracle Streams environment that avoids the possibility of conflicts. Using the conflict avoidance techniques discussed later in this chapter, most system designs can avoid conflicts in all or a large percentage of the shared data. However, many applications require that some percentage of the shared data be updatable at multiple databases at any time. If this is the case, then you must address the possibility of conflicts.









Note:

An apply process does not detect DDL conflicts or conflicts resulting from user messages. Ensure that your environment avoids these types of conflicts.













See Also:

Oracle Streams Concepts and Administration for more information about row LCRs












Conflict Types in an Oracle Streams Environment


You can encounter these types of conflicts when you share data at multiple databases:






Update Conflicts in an Oracle Streams Environment


An update conflict occurs when the apply process applies a row LCR containing an update to a row that conflicts with another update to the same row. Update conflicts can happen when two transactions originating from different databases update the same row at nearly the same time.








Uniqueness Conflicts in an Oracle Streams Environment


A uniqueness conflict occurs when the apply process applies a row LCR containing a change to a row that violates a uniqueness integrity constraint, such as a PRIMARY KEY or UNIQUE constraint. For example, consider what happens when two transactions originate from two different databases, each inserting a row into a table with the same primary key value. In this case, the transactions cause a uniqueness conflict.








Delete Conflicts in an Oracle Streams Environment


A delete conflict occurs when two transactions originate at different databases, with one transaction deleting a row and another transaction updating or deleting the same row. In this case, the row referenced in the row LCR does not exist to be either updated or deleted.








Foreign Key Conflicts in an Oracle Streams Environment


A foreign key conflict occurs when the apply process applies a row LCR containing a change to a row that violates a foreign key constraint. For example, in the hr schema, the department_id column in the employees table is a foreign key of the department_id column in the departments table. Consider what can happen when the following changes originate at two different databases (A and B) and are propagated to a third database (C):


  • 

    At database A, a row is inserted into the departments table with a department_id of 271. This change is propagated to database B and applied there.
    

  • 

    At database B, a row is inserted into the employees table with an employee_id of 206 and a department_id of 271.
    



If the change that originated at database B is applied at database C before the change that originated at database A, then a foreign key conflict results because the row for the department with a department_id of 271 does not yet exist in the departments table at database C.










Conflicts and Transaction Ordering in an Oracle Streams Environment


Ordering conflicts can occur in an Oracle Streams environment when three or more databases share data and the data is updated at two or more of these databases. For example, consider a scenario in which three databases share information in the hr.departments table. The database names are mult1.example.com, mult2.example.com, and mult3.example.com. Suppose a change is made to a row in the hr.departments table at mult1.example.com that will be propagated to both mult2.example.com and mult3.example.com. The following series of actions might occur:


  1. 

    The change is propagated to mult2.example.com.
    

  2. 

    An apply process at mult2.example.com applies the change from mult1.example.com.
    

  3. 

    A different change to the same row is made at mult2.example.com.
    

  4. 

    The change at mult2.example.com is propagated to mult3.example.com.
    

  5. 

    An apply process at mult3.example.com attempts to apply the change from mult2.example.com before another apply process at mult3.example.com applies the change from mult1.example.com.
    



In this case, a conflict occurs because a column value for the row at mult3.example.com does not match the corresponding old value in the row LCR propagated from mult2.example.com.


In addition to causing a data conflict, transactions that are applied out of order might experience referential integrity problems at a remote database if supporting data has not been successfully propagated to that database. Consider the scenario where a new customer calls an order department. A customer record is created and an order is placed. If the order data is applied at a remote database before the customer data, then a referential integrity error is raised because the customer that the order references does not exist at the remote database.


If an ordering conflict is encountered, then you can resolve the conflict by reexecuting the transaction in the error queue after the required data has been propagated to the remote database and applied.








Conflict Detection in an Oracle Streams Environment


An apply process detects update, uniqueness, delete, and foreign key conflicts as follows:



A conflict can be detected when an apply process attempts to apply an LCR directly or when an apply process handler, such as a DML handler, runs the EXECUTE member procedure for an LCR. A conflict can also be detected when either the EXECUTE_ERROR or EXECUTE_ALL_ERRORS procedure in the DBMS_APPLY_ADM package is run.









Note:


  • 

    If a column is updated and the column's old value equals its new value, then Oracle never detects a conflict for this column update.
    

  • 

    Any old LOB values in update LCRs, delete LCRs, and LCRs dealing with piecewise updates to LOB columns are not used by conflict detection.
    












Control Over Conflict Detection for Nonkey Columns


By default, an apply process compares old values for all columns during conflict detection, but you can stop conflict detection for nonkey columns using the COMPARE_OLD_VALUES procedure in the DBMS_APPLY_ADM package. Conflict detection might not be needed for some nonkey columns.









See Also:















Rows Identification During Conflict Detection in an Oracle Streams Environment 


To detect conflicts accurately, Oracle must be able to identify and match corresponding rows at different databases uniquely. By default, Oracle uses the primary key of a table to identify rows in a table uniquely. When a table does not have a primary key, you should designate a substitute key. A substitute key is a column or set of columns that Oracle can use to identify uniquely rows in the table.









See Also:

Oracle Streams Concepts and Administration














Conflict Avoidance in an Oracle Streams Environment


This section describes ways to avoid data conflicts.





Use a Primary Database Ownership Model


You can avoid the possibility of conflicts by limiting the number of databases in the system that have simultaneous update access to the tables containing shared data. Primary ownership prevents all conflicts, because only a single database permits updates to a set of shared data. Applications can even use row and column subsetting to establish more granular ownership of data than at the table level. For example, applications might have update access to specific columns or rows in a shared table on a database-by-database basis.








Avoid Specific Types of Conflicts


If a primary database ownership model is too restrictive for your application requirements, then you can use a shared ownership data model, which means that conflicts might be possible. Even so, typically you can use some simple strategies to avoid specific types of conflicts.





Avoid Uniqueness Conflicts in an Oracle Streams Environment


You can avoid uniqueness conflicts by ensuring that each database uses unique identifiers for shared data. There are three ways to ensure unique identifiers at all databases in an Oracle Streams environment.


One way is to construct a unique identifier by executing the following select statement:


SELECT SYS_GUID() OID FROM DUAL;



This SQL operator returns a 16-byte globally unique identifier. This value is based on an algorithm that uses time, date, and the computer identifier to generate a globally unique identifier. The globally unique identifier appears in a format similar to the following:


A741C791252B3EA0E034080020AE3E0A



Another way to avoid uniqueness conflicts is to create a sequence at each of the databases that shares data and concatenate the database name (or other globally unique value) with the local sequence. This approach helps to avoid any duplicate sequence values and helps to prevent uniqueness conflicts.


Finally, you can create a customized sequence at each of the databases that shares data so that no two databases can generate the same value. You can accomplish this by using a combination of starting, incrementing, and maximum values in the CREATE SEQUENCE statement. For example, you might configure the following sequences:




Table 9-1 Customized Sequences for Oracle Streams Replication Environments


ParameterDatabase ADatabase BDatabase C


START WITH



1



3



5




INCREMENT BY



10



10



10




Range Example



1, 11, 21, 31, 41,...



3, 13, 23, 33, 43,...



5, 15, 25, 35, 45,...







Using a similar approach, you can define different ranges for each database by specifying a START WITH and MAXVALUE that would produce a unique range for each database.








Avoid Delete Conflicts in an Oracle Streams Environment


Always avoid delete conflicts in shared data environments. In general, applications that operate within a shared ownership data model should not delete rows using DELETE statements. Instead, applications should mark rows for deletion and then configure the system to purge logically deleted rows periodically.








Avoid Update Conflicts in an Oracle Streams Environment


After trying to eliminate the possibility of uniqueness and delete conflicts, you should also try to limit the number of possible update conflicts. However, in a shared ownership data model, update conflicts cannot be avoided in all cases. If you cannot avoid all update conflicts, then you must understand the types of conflicts possible and configure the system to resolve them if they occur.












Conflict Resolution in an Oracle Streams Environment


After an update conflict has been detected, a conflict handler can attempt to resolve it. Oracle Streams provides prebuilt conflict handlers to resolve update conflicts, but not uniqueness, delete, foreign key, or ordering conflicts. However, you can build your own custom conflict handler to resolve data conflicts specific to your business rules. Such a conflict handler can be part of a procedure DML handler or an error handler.


Whether you use prebuilt or custom conflict handlers, a conflict handler is applied as soon as a conflict is detected. If neither the specified conflict handler nor the relevant apply handler can resolve the conflict, then the conflict is logged in the error queue. You might want to use the relevant apply handler to notify the database administrator when a conflict occurs.


When a conflict causes a transaction to be moved to the error queue, sometimes it is possible to correct the condition that caused the conflict. In these cases, you can reexecute a transaction using the EXECUTE_ERROR procedure in the DBMS_APPLY_ADM package.









See Also:












Prebuilt Update Conflict Handlers


This section describes the types of prebuilt update conflict handlers available to you and how column lists and resolution columns are used in prebuilt update conflict handlers. A column list is a list of columns for which the update conflict handler is called when there is an update conflict. The resolution column is the column used to identify an update conflict handler. If you use a MAXIMUM or MINIMUM prebuilt update conflict handler, then the resolution column is also the column used to resolve the conflict. The resolution column must be one of the columns in the column list for the handler.


Use the SET_UPDATE_CONFLICT_HANDLER procedure in the DBMS_APPLY_ADM package to specify one or more update conflict handlers for a particular table. There are no prebuilt conflict handlers for uniqueness, delete, or foreign key conflicts.









See Also:












Types of Prebuilt Update Conflict Handlers


Oracle provides the following types of prebuilt update conflict handlers for an Oracle Streams environment: OVERWRITE, DISCARD, MAXIMUM, and MINIMUM.


The description for each type of handler later in this section refers to the following conflict scenario:


  1. 

    The following update is made at the dbs1.example.com source database:
    

    UPDATE hr.employees SET salary = 4900 WHERE employee_id = 200;
COMMIT;

    

    This update changes the salary for employee 200 from 4400 to 4900.
    

  2. 

    At nearly the same time, the following update is made at the dbs2.example.com destination database:
    

    UPDATE hr.employees SET salary = 5000 WHERE employee_id = 200;
COMMIT;

  3. 

    A capture process or synchronous capture captures the update at the dbs1.example.com source database and puts the resulting row LCR in a queue.
    

  4. 

    A propagation propagates the row LCR from the queue at dbs1.example.com to a queue at dbs2.example.com.
    

  5. 

    An apply process at dbs2.example.com attempts to apply the row LCR to the hr.employees table but encounters a conflict because the salary value at dbs2.example.com is 5000, which does not match the old value for the salary in the row LCR (4400).
    



The following sections describe each prebuilt conflict handler and explain how the handler resolves this conflict.





OVERWRITE


When a conflict occurs, the OVERWRITE handler replaces the current value at the destination database with the new value in the LCR from the source database.


If the OVERWRITE handler is used for the hr.employees table at the dbs2.example.com destination database in the conflict example, then the new value in the row LCR overwrites the value at dbs2.example.com. Therefore, after the conflict is resolved, the salary for employee 200 is 4900.








DISCARD


When a conflict occurs, the DISCARD handler ignores the values in the LCR from the source database and retains the value at the destination database.


If the DISCARD handler is used for the hr.employees table at the dbs2.example.com destination database in the conflict example, then the new value in the row LCR is discarded. Therefore, after the conflict is resolved, the salary for employee 200 is 5000 at dbs2.example.com.








MAXIMUM


When a conflict occurs, the MAXIMUM conflict handler compares the new value in the LCR from the source database with the current value in the destination database for a designated resolution column. If the new value of the resolution column in the LCR is greater than the current value of the column at the destination database, then the apply process resolves the conflict in favor of the LCR. If the new value of the resolution column in the LCR is less than the current value of the column at the destination database, then the apply process resolves the conflict in favor of the destination database.


If the MAXIMUM handler is used for the salary column in the hr.employees table at the dbs2.example.com destination database in the conflict example, then the apply process does not apply the row LCR, because the salary in the row LCR is less than the current salary in the table. Therefore, after the conflict is resolved, the salary for employee 200 is 5000 at dbs2.example.com.


If you want to resolve conflicts based on the time of the transactions involved, then one way to do this is to add a column to a shared table that automatically records the transaction time with a trigger. You can designate this column as a resolution column for a MAXIMUM conflict handler, and the transaction with the latest (or greater) time would be used automatically.


The following is an example of a trigger that records the time of a transaction for the hr.employees table. Assume that the job_id, salary, and commission_pct columns are part of the column list for the conflict resolution handler. The trigger should fire only when an UPDATE is performed on the columns in the column list or when an INSERT is performed.


ALTER TABLE hr.employees ADD (time TIMESTAMP WITH TIME ZONE);

CREATE OR REPLACE TRIGGER hr.insert_time_employees
BEFORE 
  INSERT OR UPDATE OF job_id, salary, commission_pct ON hr.employees
FOR EACH ROW
BEGIN
   -- Consider time synchronization problems. The previous update to this 
   -- row might have originated from a site with a clock time ahead of the 
   -- local clock time.
   IF :OLD.TIME IS NULL OR :OLD.TIME < SYSTIMESTAMP THEN
     :NEW.TIME := SYSTIMESTAMP;
   ELSE
     :NEW.TIME := :OLD.TIME + 1 / 86400;
   END IF;
END;
/



If you use such a trigger for conflict resolution, then ensure that the trigger's firing property is fire once, which is the default. Otherwise, a new time might be marked when transactions are applied by an apply process, resulting in the loss of the actual time of the transaction.









MINIMUM


When a conflict occurs, the MINIMUM conflict handler compares the new value in the LCR from the source database with the current value in the destination database for a designated resolution column. If the new value of the resolution column in the LCR is less than the current value of the column at the destination database, then the apply process resolves the conflict in favor of the LCR. If the new value of the resolution column in the LCR is greater than the current value of the column at the destination database, then the apply process resolves the conflict in favor of the destination database.


If the MINIMUM handler is used for the salary column in the hr.employees table at the dbs2.example.com destination database in the conflict example, then the apply process resolves the conflict in favor of the row LCR, because the salary in the row LCR is less than the current salary in the table. Therefore, after the conflict is resolved, the salary for employee 200 is 4900.










Column Lists


Each time you specify a prebuilt update conflict handler for a table, you must specify a column list. A column list is a list of columns for which the update conflict handler is called. If an update conflict occurs for one or more of the columns in the list when an apply process tries to apply a row LCR, then the update conflict handler is called to resolve the conflict. The update conflict handler is not called if a conflict occurs only in columns that are not in the list. The scope of conflict resolution is a single column list on a single row LCR.


You can specify multiple update conflict handlers for a particular table, but the same column cannot be in more than one column list. For example, suppose you specify two prebuilt update conflict handlers on hr.employees table:


  • 

    The first update conflict handler has the following columns in its column list: salary and commission_pct.
    

  • 

    The second update conflict handler has the following columns in its column list: job_id and department_id.
    



Also, assume that no other conflict handlers exist for this table. In this case, if a conflict occurs for the salary column when an apply process tries to apply a row LCR, then the first update conflict handler is called to resolve the conflict. If, however, a conflict occurs for the department_id column, then the second update conflict handler is called to resolve the conflict. If a conflict occurs for a column that is not in a column list for any conflict handler, then no conflict handler is called, and an error results. In this example, if a conflict occurs for the manager_id column in the hr.employees table, then an error results. If conflicts occur in more than one column list when a row LCR is being applied, and there are no conflicts in any columns that are not in a column list, then the appropriate update conflict handler is invoked for each column list with a conflict.


Column lists enable you to use different handlers to resolve conflicts for different types of data. For example, numeric data is often suited for a maximum or minimum conflict handler, while an overwrite or discard conflict handler might be preferred for character data.


If a conflict occurs in a column that is not in a column list, then the error handler for the specific operation on the table attempts to resolve the conflict. If the error handler cannot resolve the conflict, or if there is no such error handler, then the transaction that caused the conflict is moved to the error queue.


Also, if a conflict occurs for a column in a column list that uses either the OVERWRITE, MAXIMUM, or MINIMUM prebuilt handler, and the row LCR does not contain all of the columns in this column list, then the conflict cannot be resolved because all of the values are not available. In this case, the transaction that caused the conflict is moved to the error queue. If the column list uses the DISCARD prebuilt method, then the row LCR is discarded and no error results, even if the row LCR does not contain all of the columns in this column list.


A conditional supplemental log group must be specified for the columns specified in a column list if more than one column at the source database affects the column list at the destination database. Supplemental logging is specified at the source database and adds additional information to the LCR, which is needed to resolve conflicts properly. Typically, a conditional supplemental log group must be specified for the columns in a column list if there are multiple columns in the column list, but not if there is only one column in the column list.


However, in some cases, a conditional supplemental log group is required even if there is only one column in a column list. That is, an apply handler or custom rule-based transformation can combine multiple columns from the source database into a single column in the column list at the destination database. For example, a custom rule-based transformation can take three columns that store street, state, and postal code data from a source database and combine the data into a single address column at a destination database.


Also, in some cases, no conditional supplemental log group is required even if there are multiple columns in a column list. For example, an apply handler or custom rule-based transformation can separate one address column from the source database into multiple columns that are in a column list at the destination database. A custom rule-based transformation can take an address that includes street, state, and postal code data in one address column at a source database and separate the data into three columns at a destination database.









Note:

Prebuilt update conflict handlers do not support LOB, LONG, LONG RAW, user-defined type, and Oracle-supplied type columns. Therefore, you should not include these types of columns in the column_list parameter when running the SET_UPDATE_CONFLICT_HANDLER procedure.













See Also:















Resolution Columns


The resolution column is the column used to identify a prebuilt update conflict handler. If you use a MAXIMUM or MINIMUM prebuilt update conflict handler, then the resolution column is also the column used to resolve the conflict. The resolution column must be one of the columns in the column list for the handler.


For example, if the salary column in the hr.employees table is specified as the resolution column for a maximum or minimum conflict handler, then the salary column is evaluated to determine whether column list values in the row LCR are applied or the destination database values for the column list are retained.


In either of the following situations involving a resolution column for a conflict, the apply process moves the transaction containing the row LCR that caused the conflict to the error queue, if the error handler cannot resolve the problem. In these cases, the conflict cannot be resolved and the values of the columns at the destination database remain unchanged:


  • 

    The new LCR value and the destination row value for the resolution column are the same (for example, if the resolution column was not the column causing the conflict).
    

  • 

    Either the new LCR value of the resolution column or the current value of the resolution column at the destination database is NULL.
    










Note:

Although the resolution column is not used for OVERWRITE and DISCARD conflict handlers, a resolution column must be specified for these conflict handlers.












Data Convergence


When you share data between multiple databases, and you want the data to be the same at all of these databases, then ensure that you use conflict resolution handlers that cause the data to converge at all databases. If you allow changes to shared data at all of your databases, then data convergence for a table is possible only if all databases that are sharing data capture changes to the shared data and propagate these changes to all of the other databases that are sharing the data.


In such an environment, the MAXIMUM conflict resolution method can guarantee convergence only if the values in the resolution column are always increasing. A time-based resolution column meets this requirement, if successive time stamps on a row are distinct. The MINIMUM conflict resolution method can guarantee convergence in such an environment only if the values in the resolution column are always decreasing.










Custom Conflict Handlers


You can create a PL/SQL procedure to use as a custom conflict handler. You use the SET_DML_HANDLER procedure in the DBMS_APPLY_ADM package to designate one or more custom conflict handlers for a particular table. Specifically, set the following parameters when you run this procedure to specify a custom conflict handler:


  • 

    Set the object_name parameter to the fully qualified name of the table for which you want to perform conflict resolution.
    

  • 

    Set the object_type parameter to TABLE.
    

  • 

    Set the operation_name parameter to the type of operation for which the custom conflict handler is called. The possible operations are the following: INSERT, UPDATE, DELETE, and LOB_UPDATE. You can also set the operation_name parameter to DEFAULT so that the handler is used by default for all operations.
    

  • 

    If you want an error handler to perform conflict resolution when an error is raised, then set the error_handler parameter to TRUE. Or, if you want to include conflict resolution in your procedure DML handler, then set the error_handler parameter to FALSE.
    

    If you specify FALSE for this parameter, then, when you execute a row LCR using the EXECUTE member procedure for the LCR, the conflict resolution within the procedure DML handler is performed for the specified object and operation(s).
    

  • 

    Specify the procedure to resolve a conflict by setting the user_procedure parameter. This user procedure is called to resolve any conflicts on the specified table resulting from the specified type of operation.
    



If the custom conflict handler cannot resolve the conflict, then the apply process moves the transaction containing the conflict to the error queue and does not apply the transaction.


If both a prebuilt update conflict handler and a custom conflict handler exist for a particular object, then the prebuilt update conflict handler is invoked only if both of the following conditions are met:


  • 

    The custom conflict handler executes the row LCR using the EXECUTE member procedure for the LCR.
    

  • 

    The conflict_resolution parameter in the EXECUTE member procedure for the row LCR is set to TRUE.
    










See Also:

















Managing Oracle Streams Conflict Detection and Resolution


This section describes the following tasks:










See Also:

"Displaying Information About Update Conflict Handlers"









Setting an Update Conflict Handler


Set an update conflict handler using the SET_UPDATE_CONFLICT_HANDLER procedure in the DBMS_APPLY_ADM package. You can use one of the following prebuilt methods when you create an update conflict resolution handler:


  • 

    OVERWRITE
    

  • 

    DISCARD
    

  • 

    MAXIMUM
    

  • 

    MINIMUM
    



For example, suppose an Oracle Streams environment captures changes to the hr.jobs table at dbs1.example.com and propagates these changes to the dbs2.example.com destination database, where they are applied. In this environment, applications can perform DML changes on the hr.jobs table at both databases, but, if there is a conflict for a particular DML change, then the change at the dbs1.example.com database should always overwrite the change at the dbs2.example.com database. In this environment, you can accomplish this goal by specifying an OVERWRITE handler at the dbs2.example.com database.


To specify an update conflict handler for the hr.jobs table in the hr schema at the dbs2.example.com database, run the following procedure at dbs2.example.com:


DECLARE
  cols DBMS_UTILITY.NAME_ARRAY;
  BEGIN
    cols(1) := 'job_title';
    cols(2) := 'min_salary';
    cols(3) := 'max_salary';
    DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
      object_name       => 'hr.jobs',
      method_name       => 'OVERWRITE',
      resolution_column => 'job_title',
      column_list       => cols);
END;
/



All apply processes running on a database that apply changes to the specified table locally use the specified update conflict handler.









Note:


  • 

    The resolution_column is not used for OVERWRITE and DISCARD methods, but one of the columns in the column_list still must be specified.
    

  • 

    You must specify a conditional supplemental log group at the source database for all of the columns in the column_list at the destination database. In this example, you would specify a conditional supplemental log group including the job_title, min_salary, and max_salary columns in the hr.jobs table at the dbs1.example.com database.
    

  • 

    Prebuilt update conflict handlers do not support LOB, LONG, LONG RAW, user-defined type, and Oracle-supplied type columns. Therefore, you should not include these types of columns in the column_list parameter when running the procedure SET_UPDATE_CONFLICT_HANDLER.
    
















See Also:















Modifying an Existing Update Conflict Handler


You can modify an existing update conflict handler by running the SET_UPDATE_CONFLICT_HANDLER procedure in the DBMS_APPLY_ADM package. To update an existing conflict handler, specify the same table and resolution column as the existing conflict handler.


To modify the update conflict handler created in "Setting an Update Conflict Handler", you specify the hr.jobs table and the job_title column as the resolution column. You can modify this update conflict handler by specifying a different type of prebuilt method or a different column list, or both. However, to change the resolution column for an update conflict handler, you must remove and re-create the handler.


For example, suppose the environment changes, and you want changes from dbs1.example.com to be discarded in the event of a conflict, whereas previously changes from dbs1.example.com overwrote changes at dbs2.example.com. You can accomplish this goal by specifying a DISCARD handler at the dbs2.example.com database.


To modify the existing update conflict handler for the hr.jobs table in the hr schema at the dbs2.example.com database, run the following procedure:


DECLARE
  cols DBMS_UTILITY.NAME_ARRAY;
  BEGIN
    cols(1) := 'job_title';
    cols(2) := 'min_salary';
    cols(3) := 'max_salary';
    DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
      object_name       => 'hr.jobs',
      method_name       => 'DISCARD',
      resolution_column => 'job_title',
      column_list       => cols);
END;
/







Removing an Existing Update Conflict Handler


You can remove an existing update conflict handler by running the SET_UPDATE_CONFLICT_HANDLER procedure in the DBMS_APPLY_ADM package. To remove a an existing conflict handler, specify NULL for the method, and specify the same table, column list, and resolution column as the existing conflict handler.


For example, suppose you want to remove the update conflict handler created in "Setting an Update Conflict Handler" and then modified in "Modifying an Existing Update Conflict Handler". To remove this update conflict handler, run the following procedure:


DECLARE
  cols DBMS_UTILITY.NAME_ARRAY;
  BEGIN
    cols(1) := 'job_title';
    cols(2) := 'min_salary';
    cols(3) := 'max_salary';
    DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
      object_name       => 'hr.jobs',
      method_name       => NULL,
      resolution_column => 'job_title',
      column_list       => cols);
END;
/







Stopping Conflict Detection for Nonkey Columns


You can stop conflict detection for nonkey columns using the COMPARE_OLD_VALUES procedure in the DBMS_APPLY_ADM package.


For example, suppose you configure a time column for conflict resolution for the hr.employees table, as described in "MAXIMUM". In this case, you can decide to stop conflict detection for the other nonkey columns in the table. After adding the time column and creating the trigger as described in that section, add the columns in the hr.employees table to the column list for an update conflict handler:


DECLARE
  cols  DBMS_UTILITY.NAME_ARRAY;
BEGIN
  cols(1)  := 'first_name';
  cols(2)  := 'last_name';
  cols(3)  := 'email';
  cols(4)  := 'phone_number';
  cols(5)  := 'hire_date';
  cols(6)  := 'job_id';
  cols(7)  := 'salary';
  cols(8)  := 'commission_pct';
  cols(9)  := 'manager_id';
  cols(10) := 'department_id';
  cols(11) := 'time';
  DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
    object_name       => 'hr.employees',
    method_name       => 'MAXIMUM',
    resolution_column => 'time',
    column_list       => cols);
END;
/



This example does not include the primary key for the table in the column list because it assumes that the primary key is never updated. However, other key columns are included in the column list.


To stop conflict detection for all nonkey columns in the table for both UPDATE and DELETE operations at a destination database, run the following procedure:


DECLARE
  cols DBMS_UTILITY.LNAME_ARRAY;
  BEGIN
    cols(1) := 'first_name';
    cols(2) := 'last_name';
    cols(3) := 'email';
    cols(4) := 'phone_number';
    cols(5) := 'hire_date';
    cols(6) := 'job_id';
    cols(7) := 'salary';
    cols(8) := 'commission_pct';  
  DBMS_APPLY_ADM.COMPARE_OLD_VALUES(
    object_name  => 'hr.employees',
    column_table => cols, 
    operation    => '*',
    compare      => FALSE);
END;
/



The asterisk (*) specified for the operation parameter means that conflict detection is stopped for both UPDATE and DELETE operations. After you run this procedure, all apply processes running on the database that apply changes to the specified table locally do not detect conflicts on the specified columns. Therefore, in this example, the time column is the only column used for conflict detection.









Note:

The example in this section sets an update conflict handler before stopping conflict detection for nonkey columns. However, an update conflict handler is not required before you stop conflict detection for nonkey columns.













See Also:

















Monitoring Conflict Detection and Update Conflict Handlers


The following sections contain queries that you can run to monitor an apply process in a Stream replication environment:










See Also:

Oracle Streams Concepts and Administration









Displaying Information About Conflict Detection


You can stop conflict detection for nonkey columns using the COMPARE_OLD_VALUES procedure in the DBMS_APPLY_ADM package. When you use this procedure, conflict detection is stopped for updates and deletes on the specified columns for all apply processes at a destination database. To display each column for which conflict detection has been stopped, run the following query:


COLUMN OBJECT_OWNER HEADING 'Table Owner' FORMAT A15
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A20
COLUMN COMPARE_OLD_ON_DELETE HEADING 'Compare|Old On|Delete' FORMAT A7
COLUMN COMPARE_OLD_ON_UPDATE HEADING 'Compare|Old On|Update' FORMAT A7

SELECT OBJECT_OWNER, 
       OBJECT_NAME, 
       COLUMN_NAME, 
       COMPARE_OLD_ON_DELETE, 
       COMPARE_OLD_ON_UPDATE 
  FROM DBA_APPLY_TABLE_COLUMNS
  WHERE APPLY_DATABASE_LINK IS NULL;



Your output should look similar to the following:


                                                          Compare Compare
                                                          Old On  Old On
Table Owner     Table Name           Column Name          Delete  Update
--------------- -------------------- -------------------- ------- -------
HR              EMPLOYEES            COMMISSION_PCT       NO      NO
HR              EMPLOYEES            EMAIL                NO      NO
HR              EMPLOYEES            FIRST_NAME           NO      NO
HR              EMPLOYEES            HIRE_DATE            NO      NO
HR              EMPLOYEES            JOB_ID               NO      NO
HR              EMPLOYEES            LAST_NAME            NO      NO
HR              EMPLOYEES            PHONE_NUMBER         NO      NO
HR              EMPLOYEES            SALARY               NO      NO











Note:

You can also stop conflict detection for changes that are applied to remote non-Oracle databases. This query does not display such specifications because it lists a specification only if the APPLY_DATABASE_LINK column is NULL.













See Also:















Displaying Information About Update Conflict Handlers


When you specify an update conflict handler using the SET_UPDATE_CONFLICT_HANDLER procedure in the DBMS_APPLY_ADM package, the update conflict handler is run for all apply processes in the database, when a relevant conflict occurs.


The query in this section displays all of the columns for which conflict resolution has been specified using a prebuilt update conflict handler. That is, it shows the columns in all of the column lists specified in the database. This query also shows the type of prebuilt conflict handler specified and the resolution column specified for the column list.


To display information about all of the update conflict handlers in a database, run the following query:


COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A12
COLUMN METHOD_NAME HEADING 'Method' FORMAT A12
COLUMN RESOLUTION_COLUMN HEADING 'Resolution|Column' FORMAT A13
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A30

SELECT OBJECT_OWNER, 
       OBJECT_NAME, 
       METHOD_NAME, 
       RESOLUTION_COLUMN, 
       COLUMN_NAME
  FROM DBA_APPLY_CONFLICT_COLUMNS
  ORDER BY OBJECT_OWNER, OBJECT_NAME, RESOLUTION_COLUMN;



Your output looks similar to the following:


Table                           Resolution
Owner Table Name   Method       Column        Column Name
----- ------------ ------------ ------------- ------------------------------
HR    COUNTRIES    MAXIMUM      TIME          COUNTRY_NAME
HR    COUNTRIES    MAXIMUM      TIME          REGION_ID
HR    COUNTRIES    MAXIMUM      TIME          TIME
HR    DEPARTMENTS  MAXIMUM      TIME          DEPARTMENT_NAME
HR    DEPARTMENTS  MAXIMUM      TIME          LOCATION_ID
HR    DEPARTMENTS  MAXIMUM      TIME          MANAGER_ID
HR    DEPARTMENTS  MAXIMUM      TIME          TIME










See Also:

"Managing Oracle Streams Conflict Detection and Resolution"














PK&7PK+AOEBPS/img/strep504.gifGIF89a岲@@@???000   ```999ppprrrPPP///___oooOOOѾ;;;ܱ,,,vvv333yyy888


wwwXXXqqq+++555Ȣgggsss***666nnn[[[lll)))JJJtttYYYccc:::iii777---œmmm˻ddd(((VVV<<>>EEELLL...QQQzzz&&&'''ƩNNNjjjWWWfffBBBCCCDDD===RRR\\\222!,	AÊ
/6ѡF-.8ACM&DP@]
YP8lԙdϕ?_9fѝ>[&fӜOy*:UhUWfEJiW_UаC	.D;PA+Nnv-7m߶;8/ߵ&۰qƑC>fre"1OrfΗAkkiIc5ukZYv=6Re~ڽmn㾑G9`炡nb댱]]^Ã]
R4YGϛ)ه?V oo*7FJXajߕqXs"yفX'v(vg-\,4
<@)DiH&L6PF)TV	waI\v`)dihip)tikx|矀*y8衈&袌6Zg[:*餔Vj饖-`駠*ꨤjꩨꪬ꫰*무j뭸뮼Zz^z?.$,#4@VkZx@ηDlc8AH@8\k
i|xH{n^@n /כW美=N	80<+x@xP,p	,м\s(+@3)Ls@++@
@Ol\w#
-nC8ms@2;-Il.:<(v,h<7ȊSvBiзh[[v8 ,̺8:7kOSGln;.@gS|{Wui7qnS//nЬ@k,˻@r:_k [_8g:Wc(+t;ovh[@hp,`[W'1
v\
qPWKȼަmLYB/nGvbô7%^V<:;yhL0ů:T5]! 5mYsX+֫{aT
R`w;k}T&7*N p,WpDʒY!%1+
	ǸD[uH$JN@0l {&@q+j,clfPX@3f3@&b:bXU+@PNU+'j4dzJЂTIٲІ:!s^&]zF7IJpQ!AR(i5YYʲ>1G
L-,tqE@wMd6bk!M.oZ$@
=pZ}k]5
Ҁ{e1oy Q4FS/
8/lKu1\KYKY/)Q =ϥ1c}KYGU]lwޯ.5[76Mn:26@-]<5y'w1 鮘!m1HU/8>&Ղ)+wCpkƍ3
bY80YO[ɘw	32ba6[ǼRu)y6Dcbs\;W=_c=K=q{LQ,68nɌXeQ0ԭ-@,@7wifX逢M dX[iȿ~-PƊ9"z`k,~ovlBLUo5x`Z⏆v$opOi堷-f=SLY9xM3@і!{qnx*Q
H=twFoӣskmسeS9i6<+,j>+r@[A5G%uT|${m;>xi i^≥vu@G{iuwQ\dGo
Gx[]۫]=}`*
p_-ǎ^+i3T6-t{~~9,^Xo, oX@م2buߓ*yY*mF4ʒ<7*1pqsYd3U.W/d5;2M5#BZp !("P6u&\)+7'rrc0Q 	:G{sOw69븏1AT#@$FT5/ZS@؏WI+YɇhhAy^7}}wd7Nm<3sOtSK}I:˜cO@C,Cs0:y.cRZ&CI+0*$7OsSod7LJU"sq'Dlv96fi},'.0l6МɕI9+ $Wv{;&<~LDv;DpnI虗$o1Jrs\9ԏ[#VI0Y2{9%0&`PeBڠA$^35rj,Vsu;(0*uO$3S&)=Њ}i}DS2yCM3+1%QQڨAcAq]Qrw#0GM:
ʠcrԉL6(Z@/}	'?Y6aY>Ҭ<bBZCr p0% L*p%P*!p0&0%`! J!*Ja:#T*b"[~ :˪dȫf(X
`:@vR	i*˪& Ҋ)
0Ѭ&8!P%ʩ$*'B;I-
.4:YT.ۚ`.+&pMzB"' Q{`bbOFH%i?@| &b;(cW{$20._h%*`[}[j့|ЪrCZ"J:M$O+(&Zk␶D`q[Ph$pz[R$}{@7K( ?{;k> 	ߒp)]0KS	
Dk&pWٶ˚)@{ۻ8{:TB+%Kk#ɻ	A(=+֛Y
UܪMҚ"@:z'Ш*([A
1BFǟM E
ٰRSQSQ St-`p
p5$
G0)li4,2t#~L
0/-0pW$&6-ɚ${{<@X-}(sm6JvS/)gShWP0Ͷ䜰ÚlƾH][[yڲc˭A-îU|3\׌=(Yy6.< [t$32$jW3@q7S׏,x2xv.~8-hgnmZЀ,30)>q@^ \P`ACћ@:2Q/5mHn".;ghX7Kwݾ[ì+ru
K!VbQ9ªw+{۷{c-h7W{-˿l=jY/MZr%z(?p/&zg	y=ڥD HP.KMۺɿ@	$9v8M3zIO0uA  [;߱k?<|,LkJP%`AI;wz((}K˯3?#>5w6ƢSd)	-2N6:>B~۹}
¯M,n⁵gt	NҀ0I*!0ZrJz곀G[DFIyJM)[3C&4O6&-d,-W|:ٟ=^7;?CF #WGmQ	>a]*mEڕt?Ƙݣ2Rd*7&C<*@OTM[6m6IcѳW?[^qxk
WZX$5
<M n:P Lz/ka45(4F8{JMɧRgV>2mPO8Sa#obOF@|0Ic	l2Ǝ7j``pWѢGѢ*B!~"0 
^*7^PL8%Q2' TTSIU[ɱ!OZkK&g)@RH +V!pG9%,1,h!<[O8!TЭRl	w;FQ]T_qc5Tau[oW,ے.}@p"2#2
4ap֨,B(#Te?A
n6>ף*Z&w(4yũJ5`~E `V xj!cʂ۔*_;z*{l{Jt`
0P:p'bONYE!NDj!
l=$X̱5qPh'ry
,(Q
Dߤ]zv^S:&:+-U2[!L%bXvb	o(ljSȎ^\UM?XW|
h-!Z'k}[7O̱]G*@Jfb`t	0``6 oJpgP(E H[Ζ+/yLX^WzM=XB؁<FUI|56'bJ`.VLB0`s&;Q)`!0	"tw' J`3`xlɺ%J@&.]Bʱ"6$^C1yГa{S"DD'1KD)$6ʍMe1{BGq`Q)-"t'4$u Y݅5
^5Nv'*&)ѦP8]G!&@MhSUÄ#BJ3lrMrZӐlO`QtuDtc)㉼
̳CIDAQHDYJ+mP/ )HFUg 
A,PVBVD
H D*Eb5W00Hn:
2PġJO~!	hDʰĠ9l0V,djFULfdSR(9(P]g
ܨh:AEݐl
6BW5+r|GpUdi[S޶6pH;K<@0@?J(ћ@
@S?@|?LۿX@" ph%p!`
SA!B"T,`~-l.d;doo&oFfmmnض=m0mxisoNV
.*^pl'^,Y	Gp1	
pp_opn XBq	H%FsНMBr_qo+
Ӳwj2_a^s%_ jr&	>
)W*rPp>o*I f6Qi	!0:crj0afHOsqOs֤;M'9ژ/
!t:uU#y9sP\sM2!ܸ8
IsxF2
(3c]
W^uP`8nI:&aD0u&?
{ʣn^gn_?'lp@R'嘍qĮ8cD2D
3d#Js
/
w^>xSg*2l4O|_|o||ȏ|_| yp?h)Nh{B|#4dG|O}Շb՟}6?P*}}~~/~?~}w}	sz7}WX~r~}]J}cm^~Np2`8s !D
#BtH"ƌ7r#Ȑ"G,i@Vl%̘2gҬʜR <(Pt	F@@CUqFXh$@ ״jײ=e۸rҭkw+F	NQ*8դN|bر\ƷA.mt\zW_O	\Z\P~Z;.̎pzfʗ9!zXx_ZM`܊+nⳏU|:sʯo~s9[`nm8 @S TJ
T!~眆zFw]_KPm  E(@Ax,(xWIơM:YމNhڄ!>=\I_.AYfWVYH>yg\L'WL
9(4Y(g8ڵAJ:iGRz)$1(ELAk|)2t*mъꚨhA0J:+F@p8ebe6+Z[ڔUx-}{-P[ERUF&B1Ahgftխ.-EAT@DxWh1B9L]8V%$)PfI&dO;[h`iʃvE+am2lG8=%@=({D/g^:{65a-@z}IYwMeK6CJu"k}~x>???3>sQ?7㟒F2| -.G` 3An	U>G%Zw'Ҙ*$[fk:`8FUgutd] )@'!R=fd$aɜ\BHX>Ǚ4AM\dK D%SD:	`s9%CRXg>S"02y~3ܤ7p!p@Lt4FFCO'zJh)JRTe$I"ˁFT1K`cA1E3f2!	BZSh8DpVtN,A X hiJq\T!f
Q͕1 G+`ө*MbX"Ԭ~5C)b}Ӱ*;%T`	F[ڽH,ܤ)ejU"#.A MTFUnI6:e,Z3
d+8vftaX벶1be+5"`fNPu !@MWM_\!%@P$ {OX3Ӭ5fN$V*qn3<#3[L))z$BAcЊɡ/Gӄїr4+\)ZػR{"=c_iFxI__
"fR!7jd'W>
 ״x7Lpf/1`mC.%/IgPc	BHj[˥Gdr;oPۥtW[c7[n(<ypq(ۗ,@R(g%1D0v2m9s<"	rvfG^`ds7[	N֨*:'g:|/}nv8]7dNU/j^Td^&fffn&gfJ gh&gZVe2ij&k&iI kΦfzf7&ni¦8o&p&oZfpmfqnfr6sp
HuVu^'vfvnuJwxx@t2yz^z'|fyǔ|
qLK}}N|%lʔKi聾JP0he:胖Je\B^(XJ䇂(Djp%SF牢L~"JZh(I())	H,)()6	^XɔFifiH)z)6Jd))̑5X)Si%)D֩)DdF**Cj&j.j:XHB*ZP*Z"N>*Fꨊj^j~@j**ʪ*v*C*@+j)"D+k&@,iP+>^kf+nktz+N2i)Cikj+B+Sꩾ*ƪjj*Ҫ,fFnj.lN2,V,Rnj,vl,j+k+ʞ츦,˚V붜+ζlɾ,̪̮Ц)+k2ҊCF,*NJ,"l>jmr-؎ؖmÆْmښmƢ-,,έmޭl.
n疪頰
F.~L.^|d:	vt|.i㎮v.j.އ.iĮgn.}I(Mk(BOhqD).oƅSx>|IL	N|@t|ʕbP0M^CD˔H/Ro˼hV 4ȆN؈@
n@NCŰW
B3"/o/h;{PVx1KlTn>E\	O<GK0KNDq0DK^Q5R'R/5S7S?5TGT6L@h@L$qRW
l-GCШPlPrD0JW5XH 
et4FQDm53D\zGvsݨe_XJ؆wNTW?ȀKaopiDƊx4{	W7DGCtI6IsjG$POMx
efgv/f'
3sLpPXDc`uR\gkCFN8\I`qB7p-WrouH4HM:_wIDM8W[h6-kI!Ǵ@MKE,i÷n͊MDh@yS2n@nNŀۮJstUDmd8Է8O4FTF_6ݨxe 3sNDWdԴRPȉO7Bɛ//eN0BKIHx/~	yCΒ?Ok,@~RQv4@,Bho/27骥jnk6;lq.[N{ln鮛[o\"n"|"馼#׼r3|s;C7}tKs,gtS}Zuc}o}=w}x܋~vݓW`]~衟^zߗn)^^`O'|qG|g!?HG[`(<΁%AyPy`'ػ0(
?}+_7?~1ཾܐ}ӡ
kC шEb>׹60|I`bH)ҫ`ܢŠ;Kc34/X6gxcG?±c˱# HH7ѐzLd	ɶ=
]t#IHr
X!,YILzl%(%	IҔ\*%.V
\,7JZ.&.dK^&0Kb%BTpLg~ɘI2wE)P\Q4ij
f7nS&߼U8g@t39焧K	+vJd'dϽ|Zt?	yt#|@ljPB]( ؉&:FU+D#Q]Eԥ(&8$t{G}@imNTӠ 	=J'St$EA\&BTiq vRYSX`lph@At
H'9*X@8	HW=Q9t
:AuAlX@12ڒXdU—7BjZ2ƫ&
BC8ީ6YNja.ۦCnqbּ̊|>iP #Z{%ȀumO2 i(07LɁ?Xpz͉^kd
PD~OBp=B5)eZ*d)1K?ͺfM+(>iaU!C*fȍӣXʥuT\.V:u B	|4v}l(UʟEPFĤɁ,׸P+DvC2LJ6'[xk'.o4,xzem	OM4ܤ*1d:zrer_


2YsBP2̳;
eUK	pX?ЬUk Y)vQQIȺ,t=J'dHSq4\ɺ2h"Z[8i=|kE(Bsu$s͈BeNDY+chܥߔE1jsϬ?׹r>F2#sV)	cfK:WwTWwʖ,aw hbaN@Z:`R
VfԞN`kDNo!_ӏ@>lAyBvR}weܳ	{?د9G:j۸3s7-ę}{Ek\C4F\X,ꁏˇ%ao
|jLO}Gu*PZFGe5,c!f@i/~|h%_ݖL<.;~(NϨ@AJģT#Ϊ4D-z;z
C>"(c</b&<K1P/
*Ӡ
.42P+:T"nvk]&`dKhpnQPNLm*M$AlKӀ¡Aheڼv	P
u

.s0Ϥ0*j
222cbLPj
z""!vp>FLcͬ'pK!CjoCB*Ӥ#*qpkIO:LOϴ1pQq pP/XqKx.nꮾX*CDP:h.6@(#2Do6'"q c"L6O݃}N*rK
!uM"a#*"%#??rK!gKJ%_KB]m"`jEp0l'Y0Ƒ:Ut$(]2YR)cI죐*rE*c=*X-NnFF(L7
P# ,UD,R/R2$+ 4!#0=CD<ޤX8&+*e/'<A<:;,
jNIߞ11Ƕ";v6M6s- 6#/#e 9S999:S:s5//j9I7ES;!pLS9j:=S=s9o82R>>>?2,RS/2".@k*ذB"B#TB'4By[L
C;C?DCTDGDKDOEA5@3" +(0#">"+G!
P*H EITICK@d	CYV:宪JN.YI_)JSDދJJImbLLY)M(lJt$Oi %YT~NSIO۔YRG`6@)RPsPL)R@MQ-bO1"ZbB@#0`fuL`?$5T-\hSSCuTWNS"*Z" "=H@?pRF
&A:H-ТkntY@V]eX)XX#Y"B jTdH5Zšu`+@"̔L+¡P!aIVHa:V6@b!dc[@W%,<@B.GB  *2T,X't N^TT7uX#._u@V!`v"(!v`áYL1> jo1j/`fov[бP Ã)QҢ!65!q-/!V"pgfbURV]WVL?UTZ^7U"0pD`náq)LYaMx+j6Zg5xaly۔j+nPypguNWUU_q'5[Er}/!nJ4r4h48`:ܕ"e=6B@nlO j9tN	8Z?l^%_DY)IOc:@n;xQyUV`6WPbWd6Z$@V$86}s\:Dc,BGqP<$BS-JtAzY5wy1xcykwݓw"jj{?nEmI@x"pV^u
pC;B`Kb%w\dT"
k7n4e:DAw"W`xLU:<8IlMØ*X"
׃9oY
mnMIU'i9>Loaj7qE@tyL۶c+y7#W8dKF͂*h%,RbTPp+t`yXM?VXu[\!dƶL$V`)%-@jc- ^0ni$#L8.ҵ"؊X_tLllUKYT#pOe"&0 `'ZdZd
W֫Y}m"Pt79y"*ڶUCO@uYE@a՟%OQ/#@UĤ)">.O"l":U[Wv$e'}a]ʳyEeô#o=r~[۸{WjBIWr["
V[ۻcE$>)[כ#Ywb{>ID\Q@f\#:嶓/!O?C\GKOS\W|E%c\g<ƽzvkEw'{5z[W*Z.EX!M:dɭEWɇ*ߤNq72f@J5=̣+27dOaP"ת}^]CI`yDϝLSxe$lLZbMJ'~Z"(!Hlf=Z>v}esYN)փWS=gXdϼe8dA€<`8H1ĉ+Z1ƈ< P܀D)BJ).8A"D(G$f̄J`pJ_b@͘'`Ԡp1رd+@ٵlFD Z0zIT8 D	"Å0!\"(aBǐn2tX:լ'vٴ۷+]pQD 	mwY8T	!w~c

8a p`iy{"HBT}PmT@M5R^/.7AA0		v()YbHPxYry%~zjIX)(@EP6hVEheZ!jwgXYݙPgJ! V	TAW)*`	TPWXU}3S!]U@@&4^}B' e'!JKUZїZAFKAEj;޺wYpBk~%Ӧ륽eZQ_y |
{x_o1qY,4
Yl	\Q07Wulws/*VHSҦtB,G-Tce4W5]K@vfvjvn
S{m8"čwz d/u-8A`l,^@<yONyG^Zqy^y# .zꪯz뗇*郣5_Ǖ3!U|O
|.}OO;&tf^}/~7=~_S_ʿ
z@g@,alJЁ&j0/H 6p$`<(P[МVn2Si {	upP""@& @@En#+ӊ%dXE`,&@DqY@
@#aG@ޑՈHqlkV!pQ=bL@&ǃhp <@x4`E9z2F)E=ZZ#ȄDW,
RVҒ]A1"R8(L&R(p	Pџ)@F	Nz
hB5X4$)гH(f*DDl8@T20]LɠTZ‡`HeF%i3gvF`LFζbTl$e_˯DXkXǮy@S/pѥd&==*fV5/+ܨ?J6X({Mgd
G(=OrҲ 0Lն-s7[V?$QC}.ATչHt!W, 0XLv!'1*Noy=Hޥёj?IJ\g|өrJ,.Byy"V_mEW,&rWytc ;ዾ/(g\q( |)eIXC@PM2QȻ+UМdEt\xRS5u9]h_[ō>L^^QkeM_WGSf@GO7	\n* ^`A[irg*
DS&ռf?,-tXh1>@h$A_QPwe,
13;cPw{%Ԓ^9>فg]V+u<]DŽljlz F[7R,G`GM%hj`Qv2iMs^twjwmB#Vف7Uh|1ƙ],&ie0.4ݹyz<3BNF*z\'gNaͬUJycg։57N7&piQ1a;.sZ&DQW>0'~?B_GhN[ٽ6۞jr/j[ƚq|ؿ5?Fz	Fg@/m
lU5Gj#)A	[ 
f`FQQ:/|2vKi/;	k.@fK$VJ)WWWyr\K$_jćI]`!Q0R%.lDq`0'{N`duGTHZִDK$dEX6xd~
[\DtUzW4Q$GEt|b _gS0q"w0DFwFXeF'W`dotoWUR6p]	z\aȈeL_.8yBw33`rQREOs9D'pZ'׈Ȉ=0n^LFWG%v=!EB~€!5&u8fE2uQA[t|G _c88.eWl}%WܦczEEQ X-q81OEi	ɐ
̡qm$vQTbEbWlZh_hpaJKN^f]J-2r9;ɓ=?	>rdCGNDp4SWWYZepYivvNZ^AoeigiRqTzd\Qv`$E䏉]p)INjWT`Gf$M4$)IiUA$q@4nW\fa֌kj隯	Ac|2hs=dBQ}RPsR?mVs5[1F	nY.yQIÜR-W8	+-4yLmԂ}_'ɋU9CGhGLO7-D`rC&o.G6rӠ!\CIpQDX$JTG{C&ڝSRvas0I8ТdF`qCI1RBR)P2#3K,8
 v  *NҸZ[7(;:'[nsL¤c\GOi?n 0`
VvgQ%y}]0xh`p5වK 
J֯)Z"rֱ$p[: `[
p(Ҳ/!*;Ď"&.7'p.qPP%s=J5$ƨ^ɚ?j'{ "[pܸr,ǎ1[-*8bxO1&Q{\"@k7k7qKLP"P{	VLĦhTHBNKo+0/3`GPeyb0@`;!KT3ZGI6wQ$[4IvG/d+5e(Iա#<ѝ8,	'<=:BpqE,QEa|~g n"%Rk˦йUy$['(ӱÝ:4Pv>Έ|!+e?$X>1nj8WJ:=Л7}.LB{л!"%:${
) (ǜWR(\Pdٶ^EHVLQP4qPg\F|i5"]%`.!!N@ZPЀ(|8!C
@ h Pq  +U{!q"
b		&
0Zo[@(u]w߅7^ym7!`JeĴM;=")#8 b&V$4bp'u39d^*<	́`e_9fgfoYpP@F:/09\t鼺-p@0¡H
!!rڨfm.,1SD*`2ha!b1nW(qw;JRY p!~!ЯXe]~ߖ†JY8@yXЀ @BTp-/	>`j	VgU"Ƞ0O _C}]J{w˛. %OqʡvH9-QĢWE5MvxA  …݅mkZJ`\4|@ݯQT
%n3hDD@p#5gDk^d}D
b`hgҒeh+_5e3?57"~<ȐEeFuGHIJK}MuOU	P5SeC"dNuWUJAԼ;]^UYUSYjcEdm`U֥d1'؀Az
UelKfV6 Ѐn5sGnEW.{I)G h*4u؀"uXى{怀	=	+9&-؍ش!؎ݖv5h Xq	
WٜUàUe*Z58XiY٩Z
X_B.Gi%{.uex%UEUڷב[
xb%	kmpWu]ܴaw)øvւ5	ѵVݳU=eҭUޕhu]w5ZUgE݁Q}-
|^_`^X
x_%m^߭Yq@b`+9ZuM6-;q		ےxHٜ xY	f2.0>%>pP[V}xܣ^6|aXYa-0c]Zf{+ȉx=0$ԬeՐlb(w]wym_E^1>V2S
0HX7-[
]uYd@VA.SBNC&
\(
[sX6	U}ߠx8`0!ay&e#e%5eAehWhf/y">q>\a~HgXgF&Of{
Zs^ZD a	bz`|f[eNz--h	bxWގ5F}̓z4=q(wqzwޙis}߈	q
ژpaxڣH٫&?V4ߴkijO n^.VI^e頎xŮXU吐ɦldr6W^qf/e]M̎kX^\l֎m%VUVܞm.S.XͶK8]
)nxfPVҋ؀V?tU]U+
sᖽgL_-o<@{#5i"~n͒ 
cd~	,a0/ݨ
6n<~&훚0!㌔"S_]BӉze v_HqH	u&hNdU?J7
Q#!;?lӚrpp@@5 ۆ+&>䔵POac%혜Jp3+؂-qXs+FtJSr^ert"!5Bga+`?D#.yr-۶nE ..hR4Vxߚ_}(IJCl#Hɖ/WD@E”bpS`	AaAZ`ς^%+a.\4,kT!Š[0A_0ރSV}ISϋH
]:ycF8!ct*c"Qx	2)zy4}
^tn	^wݵ#AʈD{5'Y	@ى(Xd[,9܋<$4:Iލ9NxP4[r٥_cY#o9osYw♧C.WP	f
Zc1wSJA(YiAj'Aj.٤BpHa{JƩ8**zeS2t*NZ)brۭ߂>ۖ~,9Z*.$/fޭDoAŝH*Q
/0Đ+k1^5 [M$iiQCPR)_B'| °!jmI[stq'	─b $>y2A23t@R.uQP	U0BC}Recg&BP(t"	Qqu1T
0tu]AHNn?+, wtQx87ޔJOy5U!qmB%m(Ub)[w,}t󁕛(zZq<`ahUBp	D%t=V?^A 6.hG[L/!`e (A%MAJD9*QD/l͉8N>xSL(Dxck7 A*V	qBC_	55)%+	6$>M.?94P0<`~=fr)T2- "8q<mǚd9HpHJ 0h.bB;|ziD9C lD@?LިB|`#)7:')#f8-	 Ve˰E'ٴPI"$ˌXrdAJpD29bN(JN&N	`@(
]xYow@ć٦KeUİ$3)5
:X` =)[kƿ}%ʦ$butbr9k6p[+YZˍ^Wi!{ @R#2żQzS*\"1`ߊ	oxFF,Jx<Fasxy n1N1Vጸr0yL67NѶr{
yȗ)rَL$=q,\؆V+˦e'یPj^3%/2>q3lg0dR.3L`:p3m_7%Ғ4+mKc:ӚHp:Ԣ5K]i;sA mW:֦#[:הFU]Zպ6KMZ{^ym`_U̞6)lT[6HtK7CnA^x
>7뽘|$μ}H8pSvɚ58U&}7\2&#nqM8B" e8[
i.s$&*s7>F& }#*הԖdpr/cHN{=z8.\j;roޙy94{7Hxy7D~?5C7y~|-?zΟEyԿ^g]OҷQO#>o{q~MV:'u(~̿}k_G(p}{~Gi@!A_)_
 *`A`@ N fU^ fn 	vI 	 
~  
 8
  Ơ`AH`A$A, >F!NXav~!J!2 B  aa

2_b&b." 6 ވ"F"#N#V"$#f%'a!aa!)!R*Z)+"*!+bhaeb",֢,!//0b0B #2A@2*#3:,A43NcATc2^#Ad3Rc4n8t4D
Dc9Fc9#;A3#@c:$A8#2Bc?
?$D"dAN;&PdBcEJF.FzAHd4$AAdII:cJCKKd2jBLڤK$L&LPdMMOZ]1eSJe9TTbTT^eVzlSvWe%SeYݥZ%ܽe\%̥]e}evLG`V\eE8@	!t@f_B_bhG@C\@$B80XC0h@@gRU0abJH&A0`.lnNmgd&ufpqjfr:\TgB'@rpHg.w&s&DLf\'T'|ZynLw\|Jqf<@pVp&j"h{cҧ|L]'p>(A\ZLfU@h>jH \Dfk&թ(](tDh@١DgD@(0hA(R]8(w(jh&A諸ˑz])g҅j:ignЩ8(hk&hDBBlhzj)j)fMa<͇]&Gf>MAjxg2@]H٩jBg8flN*cz@uFfA:J]*Axaj\l*A@H<@rv*JŶvaDhj]D+ALkOiu>k>abυqii8h@D@q&v]ZxGt&pf:\cR)xcI&l(Tgى\z@ϑ&Il,kǝnlHv,ulѕ(խ,lAi$v\kܾ:kj:Mnuvijg&,
⩃VB0"vr*Jt]Dl^frʊz*mZbqޫ
l~njAߊZ*jn8"f*j\̢Df,k׹nDrÎ>kOv
%44K*DoƊ(Jziji*/RnBd:"j&Έԭ(j,D+J p(B@wFgv&fckf8<2#pr$2VVKAi'RDҝj,fۨ	'p"Dk'
_хp0h/kyld'f>
o:f2gykFqC1)wVvgx10yJ"kgm2o1m0b*D
@F-IPl62B1FB\~,H2(3{$7e%wEP*CL@`mp̲ϸK}^-/DZe3-ceXvhv_2Djr6g̥آ3s9Vj:~ƉsyjhnrrD5q93V
.\TDf
o\nb򧂊grtnd
Kf4p.h8g5E6g4KmA?(sKD4Sne\|)>iRݜ֩Itf2*i&*j:E'2h'[5B{zD(9Ϩ(v*)Shס)[˨gNt%,(ut^*>8ܪi`2FĊ/zgm2ӄ6s_+jjns`KlVj\*95d+mvnnvoowp6esq⛃hlJ싆nrob/*l6s3F7+lO,-^}w]j, nnA/57+.c7ŵ*dB/,g_IϹ[;8kovZKumeI~xiCvf,&`37"o/p../nܢ*ҩ!/^0oynTS* sWvzZ+/B/Nk[e$yyyhj苞/;sSuAh[{W*hlxgP7ou>pTSRn++0{0yT5'l4g2?f ?`e:'3"'u{t"1q#zdf\;h2';Yql9{Ir/{{Kˋ |J3<0;WoK<,|œc|]gG{||œ76=s/=_CFs$ׇCz}F=>R#o=Cڧ=H}G}؟}ܳ}=۽=}ReP%2
eQ$#+@#>QNS>/6>a!ơ郾8F>>Kb'>"j"R?%?%?'/?&#00c\S[_?""*跾~~?~7G'j?@@\4x06|1ĆRTE?dŒEvk{lr?'‡ & K@Yquڀ2Y耀sw](_&U^
.	 ^
Zb|-`=Vd)Cޓ|4p4xp
NJfq45zxTeNfu!d[V
`8VS[v(u|V
h;K3K

&X
xqV~@wR' [[a]xޠs*n25qq;ΰ.G5)'j\e)v`t6zk[h
vp
Tš dy.xdHxqx/w]73Q7Mu^ݿM[^VfijuOjUL*ͯY (~MTx]Av.Xhvke >VmҀ,kmP_Ͻ0gp)lS"4MkrS{,sQ;+sZ5̭~Z fMbsԹ^d'7Ҭzz*#$
g׿i C
UzTi,urT:ʠ@Um%5jeLx3O֊UJȕ
h$,֚
N)])(-Q9nT8qZ+˔썖B9Wk&τe{'+)ked,Z=r׊b}:ܩ;2E(1Z/Ve3V`$) g/ ڷ` WǬU3XR}.u`!H~'3Vֺ͒pa%^++wN)QCFŀq>MNpqJ[yynU.V(re@*8.1K4hbe*s}3kRm~B, K9יA׀
z"4S&? 6.έƯ^
SzWe-
lztgP^V"Q%y[FjBm۽dCfmTT[EeSl_kpqkne9e҅hR"/A|tDvELw`WHN&_]bgQLtګ36R\yt5t/MwӡщӨUձuo]uDT[!vmwwϝuo<*}m:@U1yoAzp5}>|%^=.ZyU{ȣ=,=sU{@Ha/~/w>NeOpP֯x$=#$O<	A8>D H P/D~OHOOF *D
/ @ LHD0ašOPI*pC=0>`QO&0f$"[0B 0 N@E	!
á$gCj!H !E@,,װ
H~n/bPb	P@+@
	H5B@`!N 0BPpp4Q8Q=8H0OpPmэP3D
"
+/6BQ0HRqFĎΈp?K@Qđ1B (--ae1Ge($==!K(C0!a!q!!DAQ"g0p3$p
p( %-5P*	
wpRO7p!n0+w;
1*?* +ae&%&1%[E "R))2P`/90AS	sq,FвQ4.#%}1͏lXm22-@0Q31SDs4	44id!Lp37us7n.[5)3C.'/9s9'!~8C1::3;s;;3;Q!dEWS:C+=3>3>p!3E"@3QS=6>Q$?k<5?>PtIR4R4AE85AIDH&BBR3/BPt> E8A1B5CCA>`F#xQ>BDdHO4=0tDpBݣD>/W+/=0-0
pDp4GNDEl42)4-x4-ST.P-At!
 @3EEFQs<1`q+2!CЍ<0`
@  <SO0SQEM!ڱ@ WQ wJUP@WPhrҏN1Sk!LU(
M[[ E1m@yw243ڴR.=>7.JMPtMU5r.AVk~"p_0WI*1!]ҍ) tP:H3Zo=  H$]2cpH_ERU3K0C^9VWk> 5:LH1`"PuPKӎPI Nbignx5d/O;uf}ThvO ScIQ6T-@V	+OidUK0jBU4J`/gkmtH+Lʖrlmt?rqv)vUN̰+.ms;<Ǒ)0jk9eIC`MSz6`30{awsyK_Mo3tcU_
F÷cgn3r%=Wc^
 F9PNyCtR[9>^PbYCf>PBNsy3ϵ37tlcd9YF
09h6@W&/xyY4_p
阳ٝ[a|9Nu>9
yd/z	
:zZ*2`)-1:5@)`A:EZ-!i{zY]ڡ!`:lzfPy:zZg q:t:ڧzZšzZm>+d:zٺ
z麮fȚlQ4"̯
#Eʰ5K(V&ٟʲ[>)+3P ,xbP肤};YDz.摆} {[jdHGgx7u$vbg&3;sVɹa*m *;P|{! ^*Ee{^)	Z%:°l~\*{:bf(KΜ"Ep`Ls3d^nƼ1Vܲqf< Uʥ`>:>EBV|FM{hV"\"`œ|Xq%ICTtVGh=N"3ڱ
ujMu|M|dGg$|3`P~Vd!
bX`z!NVZXR
xH:@Th:`;g`d݇*HN=Dm=<`"@@YF,+V ik,X+Ggzy}MBvZb#iHIhW=nTij}CD=ZelxQ<Y	GPڰ]mHJPT(*}fE֥0ݘy;L]ӡa:s$^_Z%E&|ҝ&g:?$sϾ0_m'_.ňfEc؛޹%W1DŽj  G
{A@p@ q3jȱǏ CIɓ(S( \	0cʜI͛8ssfpV
UBC*]ʴӧI
QW'p


\`F|{ݻx=޿y
LÈJĐ#Kܱ/?ƬQ)8=zfI^͚֓@4[TNS6nȣKhZ
@p9ǫ'^Tﾾ}7Z8p!t`Bk57m@+'!fugA8tA\8@mxZ[8"SֈY~ U&	6@HZ-aPF-] 4S)V%#^pal]䛉 BF$
3	p`QU	p

t**N(#!
U F$z
0	zEyZDTU8Z@RbtACg
]rcKbT(Zi !(D'T *	uZ BYOi@r
&3UZet}ɧX^R}ݗ2p]&,rSV[b#W	>ө8$|Qꗧ.ã"DSX(ҫ<(UFcBEX,AhZXǝ~0 \[8S(*-"@z.Q~Ex.&ӫAJ՟JTܠTBA^UثoxD]"YX2-3̂WAbF3F@c	mDʹ%|=&VQAЯЁ	q`Kj*6qOC4r淎Zn}+\ӑnD]v3>@[A	TGP<
ftM!`G2ܦtjs L{G$Ke
#aħMuN}
~t>%I4ۇCH;
[D/r@4qjs[′2mo}C
7Sqx@ja<*QI2LrVIT!^0Ib/#L	ٲФR3RX̦6nz65LIŠѬ3	V-L;%yҝXg)+iOub	K~t<<&@)Jsf}HQ(Bf2$քJH?Rv!hGЕ1ZMH42őQ$#23м41iK7ʘ 8IaD}.ǷAP
Lz^"8:8T@Uj	S1tjqZW(PL7;Mo]@ıVf#lVv5nd4`)h
B-@"p;Bφ$
A;x[9;pg7ʸG.$Of'NHOҋ~TaPԧs]a1:;XZ>O{:h@zb8ov -%'S'~We?\${3t{&C,_Z40aő	O>爛&r-thp]9x$R\dE
{qDAyV4px,sH03K ܮ1Ǥpps}s_
%K+pS:@X~=7
Dw+p!5s:!#!xw,wp
? G
l+Cz?W#x_B1sXX% 0pGA1W#`gW1S6Aux3~;AQpqrglQHSHQ}N҃q,?nq!,|P"0?_Ƈ/l0%vc'O@#!#+{!T"ϧ:iAG(br""'X}	1m12`!1Syb%kL_q?:0xX`jb6HQ%gqè8, cV&t\py~cy"'VX'X{\woSHx~U8PZj K(=,0sU)#i+߸qih|g{AyWP,3h;`h"MdCIysv#p1YIȢPKHU{ݡ]4fr(n3vxwm2#x'ixKIpYG #sXH1ڡA7q.+pav)TZSQ`	pQ S)HOK9?c[Q}qdQ??Q)c =&z(SpR1I\'F9a@7[1j6l!%P:a3ZuMީс@#iX]!%g'+d)Wmq!p"Cɒ Єc? Raǡ1Y+"GZڨ&1GY Q
+Y^a{04f4,GmqAQ&I Z*ș&xQH`񩰁{ҙW"{5ryS1jRY5z䚉Yh+q*MRP*::1{yMuIё?Tazy%u"Лŧ
6pFjq+? nR&f3BCjOT[V{X{1Y۵^_«'ݙ%!䇐V_erx6]pzNC#`y<;W8tb#aL;K\VAm۹;m0%y!z&@iky#ȶW~$RĨ{ۻjQkvN#$ N;M:¤}V(@@$qj$+ʝ{	!2f-NH;y~rA1#jU&gC+ru̻zɠl!15C57jLxjx&gx˴JudڋZlC<;/eS6+{)W

o 5a@j@H#!8%nܪfFt.#PQ	q
^@}F
0@/١=`w;lF? ꌩp3[ֲA'sne%8垒.(%2-?b9:>
uӍQ%@S8h1#~Cc47u=>#y}C*D'S<=6'ћz1%?(1^LD HP.KMO n@	JUVLy78G"AT4>R4$731H>擱$MN%#:[N8u%0S7>Boom)%@:cQ"+)[Z_9?C_GKO?~.N2n
$a6/fX`Aў68JEn?-T4?0a-\3Uy8XaNd6Z\Nh-bo	B*J"x@gd`|ʁ*  +ݣ./P1$Hll2+¹,:,J;-:nQ.6p +ݢ<( 8-* 
4x`
"tɒ(
G0X(ң(uQEϣdW]5KVcuYh+A*aĩ""	;*rIvKZ7q
x]JxvI`mN)\[+c@Jr L=IBN̺kAEBp6P,AldNt3D#4cP
rd,xIz:j:Un%{zG`{ua{enfooxlTpg̒#` #	636,OB!$.0Z>]LEv.ww
mX]</d4O'啓ap~Y%C"	G&a6E+
)g?Q#_f5  k'zEw	S|W@ox	D`9yFv&iM[PB j|!ah;rXbL#$)!@NIr@#&qn,	v6D(FQSbxE,fqk#ihC	Qc$cx0邍pMu@)/0HfEO/tfQd$QQDш)PZIPF]ld)MyJSv$^*]JFqS2)h1 as4pAC,R|dI&tpD&@
S$<T$ؗzx."Pg=
4JsiQg?O/2$hAC6=:Ζ-SD8`92(씆pX1 3hI	AAD^DGҠBd%8`=,|n$xDUSjUzUfժ8SԠ0LЌPt@N^$T|AЃW)w7D=LQN#jyGr5ލ6y|sKxNl>e c&X&t\vpvP\!9x9y6q9T7}؎dK|qct+F c80ph2w+B
4A ;9oSQnAѮtkqyUi{	iQo^ xH,.:/[;<
fIxr1H'@1	9\ܿ<Ł/58/(*BQһ(?A3U)@D?(H0V:<&pB	
.P=PMP]PmP}PUBPP	-P
P
Q
P@=QMQF,PQPuQeQr	R!R"-R#=R$MR%]R&mR#LR)5ܜR+R,һG0R/R0
I1-S3=S0%S4]S6m*uS9S:8S}TICTJTLSKTNT4zTQU7USR=UTMSNKXHxUXђX=
\m]YU_uU`Uq`UXE`
def=V0VxidVeVfVgVh-	iVpVoqst#"u5vExUyebuz{}~WqHV8
%X`X(؄=XU-	X]XmXX}X،XXX
XXXX
xUb՘V]Yٜٚ՛w|pV-W-Z=ڟeڠuڡMZ|ZUڦ]ZZ}ڬڭ5ٔEٕUY%ٓ۱۲eY-Y
[m[}۴۵[[[ۼہ5֙ٞ5[_Ee\a\Zʥڮܯ\̭\ܩ\~]]{%]\
س}]ݻ]][ݺݿ]݀;PKPK+AOEBPS/img/strep014.gif0EGIF89a\???///___@@@oooOOO999   000```pppPPPJJJÆrrr


;;;+++⥥YYYwwwhhhyyyUUU!,\@!"! ņ?͘.ʰN
L{ @S@i2Iɓ(
S4i`@%L킃N8$K٦5@Q 4Ojʵ+G v{ÚO!B`hU#":b]F>pLC*^̸ a@ !Q(!3<L.{X&bƷ|bM̺۲ w,fQdن FwD?T|M
 Xqc$?g]%UB'_y3	 (p
XW|`!,`aNS4DP
ŕ.U;	"uStaMĆdI* dlO~x𹰅s*̗{4*?!
@T0Wy9("}`56Cmv(&R"bBB($f(X7#AUA`!^XKcz@gxX}LJjȧ8@d!*1iD`/,Ac@y	|5Mws$<""/	2/,U-=Qbh^y>MBpSPk
R5a5GKV|K">:/Nd%!Lj́~*5G>q*{d3(HbT3LA;k%+?gjQ]ċ)!9ŁZlk(}S4q'QpѨ>uM
Jc+@U54(iД=
xE'Z-D$@
TNlk:1?UO5;Bα'N~
[*7R3`""GD`xSi4C5"P
-j[)ԣMi7*)DUilՌs͸O)>jfA|GaAfj,+1FQ_osb%֗ni@cl׉;(WPVyu
"_[tck~ :-HLzZ148M5ngclu.NL9_8`EۈUG#,J1Y4n⨿JAJ!.|Fkt,Z8&
1&:: lhK=F\ J,c\J!HܿTr]4;UDᮅU\BO݂72V+AbfSȚO;38JaJt]ޒjhÂ&=EoإvY	S!^:w̞MsF}Ak8>3+_Vs&ɚhFcjXiR\O@%_O79?|2E}U=TA
67J0bp*0e_IaU)Ik7&CQQhaxpڅd`l'h=@#<0\FFy-bz4ex)ypƆPX
،Pf8':Ȍ֘6؍GV(?(pXh
hKcIHXC(ce'x C3\{yXJ) Ls9PmYJ
	VӍ$%$9{&y
(Y>s(vT#/)keq1%y:'uC\A9T֐,	_͖JIPXlGbYOUYdGf])_Y2.2XX>cy?k;EQD5Mpp0  O]ڦ}ڨڨ}Le҆){){<۴m-DZ*ss
aE
 
?\V8SK|nryѴ` 2l3a8KL$LÃp-?mi!KbBM.^r*w
3Eqޮ&!<᫐RZB۽]#߸a> .~ ݛ$A&^$?+|!@	>Qa],0l(R7k=2뻗
y!<;n;Pfe o u$/(u0RHltH-@ 0+A#wɀ@.<7U0[&"}ª TI^YD,5a=4Dv$!	z|h8l}f#C4>^7qG ǁ#=30'P8r 88!0#"  l(.>jn|0nt'GS-(kaN>хEp~9ep?G;^%c<5{K-
D>>jվlюYkwD@@0:k@bW,^Q~A/C`+|`O'K
!4jnå?Dܪp|TV!֩>	a@`gC`0dE,a͇K_ONSXsPan䀰;wKZ`OϬL{	@@@?????@@@@@"@@?&ޕŇ  ڍc`$`?*1QN%ⶀ^M'W%@9Dz`.$8!1Pr
JѣbUp
!L	ᩆX&¡-m(@`|[Pmx/dox^K/-H𗡢#8!̔m|T$I^E-`P@B@0nn6NeϏN,L6xƁq7A!'BC"<@x\Iy8X[q^#EƤ( NHeZ.nm[IUv+  M)8%j	6 )%"zח9퇉@taq~#*Gf]TVi%& "A|(x00	Ȅm=w)B$dIJ8.0%!Fk{j|iJت{g覫nM4$4 :n 2tm ӛ
#`6ޔF,q)t@gwŬN.DRg]-wM=8+;.9K褗.cf;"NDmȋZgM@OҨ'xkG`N%7;`-c@9	2#)A` q/ ©z
;&,1DDsԗC2EYRԺBxjW@H@MJ xԍ #
aB%qz$4Q@oMb#"5M-Xp$R hnxNqZ/HF+eJ,J>0	<*~ID	M@:eH$F:򑐌$'IIIv`fm1b^DN =(G	J̈,~cwPgi\g3VIS`G 6z!
?riI2
:%e[`IXDo
P*K0q&hIN3'SʄhxFpLӀ)x#;׫ﴅnCU֬5M@UjBYAJ(DIQ ْJф$ŝ.±P$"$QLgqa@sW%R@C,+T\4Z-JXx5ĉy¦6
H\l&iMlTG4^RR.݊\}&816Ey*ND-XJֲ!}&鸷UQCGL+́iĵ~bx91B"RefٸBε!DӀt"JЀqo*FōHC\Ue`aeCVz{}x{.t@KnZIz(#G}:MUy^w@̰7fV8
	yCo.YwLc	VbRv(!;hrA(7
8p5]kLe,8b9ҎUc(A	;[}P:$*)eJx6E-*myb]ۗJneqWw&
(0sPZ;kgN'%kڨˉGMRԨNu,@om	mEcN{{Tg^Mb)kʺvoM\G$ζn{?zܲUXS6ilmh#^;nLy5n7MÛols`ϸ7{ 918v)8q.Wng8EV>gjeHOҗn D@Uw
sN80xM
۱z.Yn5/J|v^ewGbމw+S^,և?>۞_n5޼j4<-GWb=`;ʾ\.9po%{13|{2~|Z.rPB>/~n	/w=DG*IC?s(_srr'W5a8dvV31~瀰B~H%-gw|Tz(|gr(1['{4jG%1Xw׀@(-!؁;X$=H?8F(L+E*#ȃ%8}3XX)Qh)SUWbd]+I8KxWbpxixnG$m(o8T"|Hu((_a(*x~v!~8 1tEGvPW-ch
^(d׉0th`t H=ˆ䶆r`'=2(?4rs8iyD`,njUx5ΈwX)J0,r44<2pBTfX!Q\)Q2=S2a{b|v
c@Q6>TAyCq{	@
)$
R=薑xwvӆUbBwp(ؗdWMSD
P9HY5mH>r	iDnO3.g^Y!ҷ/+W!rzt-ȗ3YΒG! 9R&&X4̅8Jĉ&ǜ!dWL_+0
@,Q_C]onIVv:$Yx%JM+㰠_o#-;1)Z)㸚a|$P(QbGPTr9%4JMC邘Yۥc@-E5Ey5ꤽȒ臞$9u?I&Z;0C%!hM	jjP9ڒTJEpn,֧դm:jRJq
spQ6jʡW}HbE2&PJAj:PajcJ
=udmyrZ)>iE>諷	*)wlhJ'ɬ*n(IiHAm	تNe(zȭ)Hb 	7ʯ{('H4j∰Xɮ2
(AtȱA/ɰJhYĂ2;s*[".oU8suz9,K={vP[xFaʦS\x3Cv@5jIY0Mk]۶6DZY@@z|۷~;5NJjLHu${˄b+2{ggNi;pqJVعz:C
+JAKhʌ
[]˻NʺL&vuۼՋX0EbZj{}j+pIhrwOJB[:+Kx
xA>bV*I&`y&@8'G?K`'b.ebOl(AS$+ذ]}zVЮ0BfL 5Eh,s	ڽ71SNA->Er5AÝ}ݚ
T =7n.Ǿ" J}
.t^kN!^Q+~_7;LH6N1KHK9LEsO{}O.\y^I]+HewgikMa˺ZYXWO+AILh">C7*	@(BL'i7R4)+Hl(@-Hh넍(Nh셮(Gn+	.g'NhՇﵮ|(Gnsp.gHgӎd['NKOhL(GnC@/7H!b>lY)P$F|,rkp

@2gO`?ܼ;p;@]_pP,?@ZOMx%`VT@HTW2z
vO" &@&K^a`ʛYTGpI_N
"	>:		jd?!pߦ!	fơzWP@!??
? Ä
?Τ?؅?줉??"ʢ?
	h@@\Ȱ\"4@O!Le@< )x!]ȓ(i7Zʗa)'mkJ]>dpn'ӫtׯ@0HK
 ?4x6RKGv
.Q;|jm/L:jqJ9>MPz~] teĖEz`spk,{".i
Mӳauڙ)p0  zx`!;@ok|y
Fz=f d_Gu(
D څ,Al4HH(R?$t,Bb@
,ȡO.@"XiA	8!|O8@@cD@y):XPяLiw t`H)P!vee@#tt&|< “1>t!Epic9@t:x@@g]n*_Z"0]~@\G	>eZ@P 4*q@q=-A
$ڑ}x%Ѐ:@m!/ay0+[8App/
4i3*00/]g0h@*wz`m@* LTWmJX:]qFkv{p;'P+WmoC8վL6%jy
ڈ';xEN3+^MC;PK00PK+AOEBPS/img/strep042.gifhOGIF89a*???ϟ///___ooo@@@OOO𠠠```   ppp000PPP!,*'dihl~R$x~/|n8$rl:ШtJZE&a0%	pl#8$@Ck4`68	؈;X@rb٣A#uڂBAܒz8~_W~`$!KXP|A{t~``|,YQH
6,)P}"!
$Hl3e1f)x`)@ʗ,~1+g,Њ^#z݀h遨H_~Ajpl:60zpa~@.Ag{%Rh~@#z@1g!ଳPg1KhWP_t+k'}Ξ+$Ћmt.\i[
 pAǔ8#-qA$xr-p3p|=P/в-~FJ$*	xOCVg~X66@x
lgjWl*H6fj&Y\AC@~n/<8#0)(yp_&?̎[ a`BQv>kF@Q'JʎjOQhϣϡ(no=Ԭ>1HMe>izvNV+]mAo~3P@ byKMtԡ":$
	@0g$R;XF=!R܁!1dHj"6:az
!z숋)(2By$Dn{+!MD$B2]M"CK
,AP)T-򐱄B*O@H啹Zt.SpRL 91 4,2e4KTMn%+KȩmL!*:V	'tBQYGvK0aTN\2t>4(,C@Ez%PIz K CM}yX)NI4!_Dkʅ:@C\i?v8B0bJ=)SĎ]C,daqdU\MKa-[
@I
>6]cn`)=Ie"`&@
Dzw]!ylN$[! p6M9eC
G|#7
B/[r803	=	vraÇZ*sUgKd=ɾZ
5`6	NYغl뉺":Ͼ҇=@zvRu J4"
޺hqo/&Y|`(EؕąĐG?&޷$[)w%c[
<3MY.~lk6qunb'I%ֹs13qq9\GǞnmC<{%U4bh]\ZZ%czo5E47"@TT?v/+Ӕ?yki){K[՗r%D5)OX{̞Ǹ~wqs7	[?,#uy;I|=]?(A
t}TC#3N\<7IlXFx{ފ@.pQo	Px[4A1B[ b0UAtDp(XTo
e$р8#XiSGz\f
E&a+%Am+<6x`WrUV&a!z`>(DxBWX$ET
&bdd	dS`LQHgu$q`b7BdcS`d7m+flhW&!O3	&-g{$Pf]e-#*R uf fsVg4H{mFVofe{b6|xY6#x(!fFv+
AS(pn(p~2F>Fjk&$vXk&Blalk{'H4rr!'k$0ͦa1mlj?6>>~2>hØ&r'0Msiɸ
z%!w
3h):g2	phdqF-	>pŽ 7 wFP,"rFb:Rm{ra;y ӅF!#Ig2<aw/sU	?u:G~'d"xGwlw#gbparv@2y5c'/=@!~w!B&Gxv&1#x Ym3*"SHnS1xx>a}g}B|wf-{m
T|=W|93He+4g?
a Gm"P}b{
̇xGgۓ`Q0M-sfL)'@$A*F$rQw!ׁ@8!('U tV$ f(wRp11EGtZ:b5QĖ3a*pyl^8WcT(Qi<)aPpcd;/խAx7*!S.lcg~2y=iPoR4ôvYjwN;#T+B;\Dwz'(Xv"wT~#jg/#hQv6[fcxVbHn'*[H|:x7(x'>z&Cm=˖:e(ngEo}rzӇ(}S!"AIFV!GE Bg!#$01	0	G!SEWW{(c@;#ʙxJ’Ǎ\Cgdb+mkҰwK
Ẕ"w.Phr5nǕTD+yxIm$bk 99rձ֜/\Jpw1eRJz6kg(+umXJF!:0{9Gʾ~3MFRa.=HH'8<0(llܤN0|`J]=iaQ`"/y-\bLz``1B؛Jd}gxO/6
űQ+!xfgQ&h
m؝0_"AkS('u$
'ᚅ4|Y5)t,A1H!qxFq'|4q~5QI~KUywδ	ۘx}t4tٜ:<>tXdq3R/aK~|W/M?1Ǧz	vgkPݞlgi9d~b"n^Om۱TvZ@WE>	L`>ܔN3lxL|i.HgkM^
%|M7$(b>̪DV`&`{FhDeS$-:g8"oQ$ۗ9̊fTlʀ6txþZ!4gwS|@%`1|q*:ȽX"扮(.M
8n
/=Mi1
'-(XH2Am.c4"R^_M&pY3C/eoɹ0@x%9q,). Q9j=O/9;Vv.i?'hp v?[e~eXSUDue4BwϒWjAA%ue[d^sukni.wЫIܴC7udy=aU@1Ƅ4o!g2 vFU!|;c^ӬXב"*|}0 (}';9|!h<"J䂴$&:1G8<@Q|XmC-54 5 ~P5Mq	0@lD$\
L8@9ADDC8DiE)8h=UʃOq4-^^8/4%6Bvck*u~a:mz6ACcb޼vJ(p<;pE[TelVңf}M$ᶹA"
!Nӣ@1)Xs';0 6}޹c ^i_l?iahS'5xp:<)D."@uRt[WP	J#/@r#.R*0IIN4SU-DKa[.=K~(*:?`#IxhF)5_ٓb>$7qS'g1B$%x4ĝyS#96,`bKEX`
I+?|k#na@;{f`g0*Ӥ4"
)AC]Xʬڪa<1PɕF́J֊ )YBڅlf.l9VHB*J͠DaN
&-c%F_|a8d4JJ!X,i`yQ;1pp#CP VcXٻ!2a1GSEQ3]3VᇨI|c'ͬ@,}S$Z,hZtb '[rZAW Dp044$"֦&e̡ih#k	H  Qmq0C&Y؃I݅aV[vʁ".LƠC+WGbcMA|ا/9ARҜnCR2DxPds[&[22ʄ1>0
b]
9Jd1ƅ/_+}Izqv4.!=,|?PI/67
kD8pԃF8WEb %{F	z+7EHtteIY+T[vOA4euɜ{<Qo+RyksxAJRe(44cy"0OBEA}4/Q۽[CzJ	`V5#H
R4xqVfMtU"@Q`D)$*Bҁ1T|@C8Wx|R*PJ8`<vB%Xx4%jADu"Na2́=
W!`N)E<gÉćXHB4ؐ\Dޔ(D!H|۸I\PP!QR	:؄{aMD$D>D]!QY4M{CRx}V4lڹq-`k"L
yPb|^V"QhaT8
+Μ
XG٢_33^\d-f"A
ՁBg,%Qt7
82d${|
,6~Ơ"6##??	04}i> ]CX
)]FdA0JtSuۥd
!HC[xZx [v	\$FIQx"ÓX%#M+cő)@AiRԄN	\vD(TtqU[	QA͑NS:ePd1*5$
jtH4%ޱk *,D/6n֑*QDaf0jӍdyzr1f#@sFq-Pmj߅Ћ."d5Oq:83d.'	\IF	jDB®fK('18L+3
h$V0Ŧ(/`
h/
BQ j$􆛂TxD rŪ-,\(§ljsrB(j5	<'f^C@~u`P)t0ۜpڌF8z3!*
ĠR@>ΕC$Xnjc[KyY2qTqq\KOXZ`qi1aSFFzd#JQ:8e{)2dB0'1
%-C_oRe|MLhƉnn܉@V-Fu"228fuK"LA-غd+cʤ*#A{gh,SԮF^Q5n3M@w2"Fꄝ6ĺ..Õi
'6LP	9AFNMӄwMgo E(X>KN7bJIQ2/ZR+051*ULѝtTY.;j֕L+Y-6@c%H>V=MC0BBIäjڣe|uϽu׵AkL|,OG!]%|jܐoO6!#e<;~k$+O[`q vh+XϷO VKBBU`?4tU%(##Hp
=	wEȈxn,O]lH(Јw<5ť]ǂw:7j|6ͭFB-(b00_rwθA@/TJ
)2m]pxgG6uT1P/c#*)TdרK548EK3{M$i5jXWRIF`P*7QCnxFzՋn1;;:#{sR%3%]z,$o
1G.mg;<#G&uKA}cw]alyt(AQTw	HgC;͇x`x]SӠS=6O=T޷1Q7=jzz#ż'֫eTo֓!#`N!kR:QWXu#W](a^(<>;H1R[b8s7V~)|gC?뜿ItxG扦ʶLǏg$HL*̦e\Ԫ҂֮B"NO]`x~7pgxPAPؐWy)C5ZE`1[cXy ;LCРP8Z#qqq`	*\m.#A}p\P/c1
;Dy`3cXC5k<@P0&|9#F!hG0sH`V{,#؉,i3@`:"A>\e!*x'Ug  ָo=`렃Ѻ,UӾpj͉0xhEɷ-+9t	i'Ucq?72.ʱl]qnH+}%HN'̵@鶫ێ={vmcW޽*?*:~!uZx8ހrds}@RP|Ñ`ƕP!
6-AM`.bH}$UAy}`A/@I/xXӒ'Ȅ1
x@0T#l?f#teVلh	z|p%QP@ס}$(GFn݉z兙WjRiߐe2@}{Yf{h(&i
$
LX>6qJH	oT AGL
hBJCbL
D|$̲*)w.K{j𩗁k%ݰЬ?l=9g-,pA0WgA> FD$`S6}j5Ӽ}4KXP@3*ʡ_Z4U$|DЪWM9oG9=2^zA s^WvÜ-C"zdr+>	^-y}'V,ć41^[mG" ϝV|7~5hCҲײHs΅1˲Ձcj6OgA:Fm
+gu54a	vV	tš	9LPL0$łj]X9qvkE|y/s0WZ$lj;$L*2	1KZJ+Z
41m.+0kFnnԖWkŇ	dYk3L@0
*yؒ)6S5vr7$n|x#t)A.0(q@a8΢eL~&c`4K=}[wsҒ{z7	A	+a U0Q">Ms+7-=_F u-9.v<
W)?gd0N^>#Qcԣin~3m!+jHJՈK^!jFJYB0h#Ȳ՘q:3CX+g$[gs(5,`0*]4,lWZQ$2t&uR3C[HNc$eQ1G+"]l+KBR45Z\~	DuWU[Q
144,bshJEc!de	YS*R,I,{UUN$*/<
W5|1nln@7SyZ9Gj@w0)mxЇO?Ϯ)uk0j:-(Z|q+CgRȂP{	˥)ؽ׻qk.@iЂu!9XYe?K8%
=
}4_2Hj~AvO}|=9<`a$+^l{qxotV4P*,j7$׮	}f|pA!tLaFS-PGS}StF=ow$%lCPU>#^ڧ3;EB7D!&|${JSND:@b8v5_]^tw/)=C_@
VFX{}1-}WRZ}_CV++W5DI&PG!`ۤZ[6'aQJ)Xp16uu_@cuSp`ghv(zf:Fb#(=$,hd1"Rmp&3-N@IG1,NL(Di$;T0(u|U(`BFo!zU/܈>C3|
7CJc|3+`8{Bx|ρ10&Zuq;mF2ma#?"rB
 *2"q(67q11	@ђ᱑2ReAPQ!̡=y,R}/IKiZA
rT
i4Zax!EzAPMqS!{=\`}"8qIw(Aci!i><c5@Q =q*<'h	N~bp1(
$^YaPߐyG1	̐RGsP		zs0_@` @`Ja\1p!yU`jsWi
U^1У0 Z#Z	9A>d@\WҢbP\0$0 q
(@&ТjТ	&	J:uz&a$$@ q~Rr0Zx`Y	r9L*u:%0zFZzЦoZ`d
Pp
PPڣ*$AP@=z P?j
;ZPZeZ	P	dʫ@k`cͦ0
:ڢ ڥ[
%Pj-hڱ,
vc$ˮ`$!Q'`!P4k\-E
Ie0~G	&QIk 3Zp
j5K7ۮ3xa~kI+N۱
F~+ ik*yF	YKK:LFza%;!AP]꤀XkkAZz"e`A*
ڼ{Ƞ@tuzp4j;0
pjZ
`j ujJ=z{{u0芶=D~PN:ڻH[#̋~K9zQ0dsO6zuj
k++w3\u}{@0;z PZѱJs\;
\:ujo#JSlQn6LĆwL[k
@'j/pG|1+(ɰ̴l[3*7cN|F,l(*̉J
pA^uP	׬)Paߜdi.`v<8pk
@/pΕϪ
d@L!5p͕5
(!w!ыi-[&^%YњaƉ([*m	X{񔕉:-8<=@ Zq1^%\A_ԁ^ZS=qq,ZdzhV-ie3s&lX]`i?
rpdאqqqZ9/Ggm CyӨ)F`ض16ɑ5)۳rI;x!5Y1ܞ-.
ѭܷ=
)mݛ]}b
 sF}e}}Mm	,ߐ&!ڍv
N.Ꮍ)}M
)* ܢ\,Np4).8^^l9;r	6P9pL.1pn/륻PZp
YqlP<߽ʛ#@!j0!lK:*{m4_~pδsNԚS'1:
0Pz
:
!pwγ	̥&ڦN@l,ZaK\`
jdƞٮ$p$z~
.@!*$`9j̰rpE	ϴ>B+\	L9ڱanx1{=b=-!.aYF@_ o+n+^ o*WuRA@ҹ|@8$;B_p*i;oSp]K~`/^ޕr
o<;/ 
$@\B߯tMo\;Bۢk
@2Lʢߦ?x
؊pG~Bo: !*qLz۸N 
$<!C 	vaa'sq;>~ß a!IAVހVe$f
`A%W]]kыkgd
%l/G0qqq^BT4ucp5v/v77yyywB)/A4L~]7y
[;@@
u)VN-1V`"&ɨ`B?STWE`D@vJk@<#N롴EAN>Hp-YO&~o}tBļoh{E?<$wz`A~xyn	eK\^.\\Nqt/EAB-(C7!)Dc/vW\0!$0ghՈG[cX㚉4qk)HH@2, Hn!WIl0#0~r+ď+SGAL+l<~,:?ݔF6(?ۄ@s$/ĉL4ѝ@} Af$xHúTvP冒/0@0idJBFWPE.Xgg!QmH8@BdDav5*YX#÷hd.)=*+-AJ#8QDHtըhT6o2	Zp*MMU]aVs#AvZQOm{j
;tRa9!L"*JzբYdEKj4aոg"*ݡ]O:U_Z
}HRq[Ez4jaZ1ᵂ yd$CkQ͒ϓ\(Q7Tiv_˄bB7qP	0}`*P°	~	S_X+%!6O["Z8\ы/٢xg'ǐK4C¦z`LΨ "Q|LQ1&>[<֤8.!VVƤâ.=< f1 C?!f	l"h8,t(I8TK7CRidL*P9 B)H
jНP:so.
ϯ^M3Mp1@&=̥82^t(Tn7e@PJAnL3PNu@ԒzHxW+O}Ʀtch-	3p0<~7vAX'ݬqYڂw-j7%۩K0#T~3.Ublc]ͽ>w,F8i"/]ji/pC$/u'So3;m{!#/
|KA#垌eσb![Cucſ>t&mQwXk	T@)T=4ՇoD9݅}M \LvT:^J(AUh8H #<] Bt}|셠I\
 :P( 
>J][YlO	%!Ba(=rYtǝGм	؀Cˑ		T!!Z%ŀW-W4yxWXEyƄVWe"eb5u'((6W1E+RK&&2((6 TC}"B P݂I6щ(Mn1uBl8Tc}#4\>'tALc>9,deV.(JG3TERMBMsnAP	z@$Z	YDa@o0vHȕ͗]%,|$,AS(52\'NFTH0!K$	\T[H@	jG[.Mu#MPT`L}AȄɼP&TS	nG)&!RlC=x@aI9ԳJ-4ǑSoR>dAGq@3	6cԠōk"_HXɫfTT/k5C!`9T&"UxdA$AJEءgJmEXq}qEf$NmmAiPGzmf	/	'%e$*'oOAysۇHto
v]ȭlED!g9m
ѣl˝CGXLd"h(&APc"/,eO@`hYH01сp{ؒd96h$DZpF*,Lq)i$QZ)
q8oh]ԘI~#
a^xɗ+Fa|P)H8W+*%.[b,܂q#_+|
5lN&|0TP2#NlgnkX+aDAX"-^Lh_M@λR5ý^&bN0\xJ>, ,@H~vb	΍#.d,c!%=f%i~sa/ytbW%g}ZFGA+ڧżmpF8SU%kEVe/mF$ϡjo:H-威𨞘jm]nbs,)&uY`Rd.i/ܑqhzFK	j	Bʑ'/Ø&Ν
U	*0FH8**	d+k-z*EFŰ&EM"

%脬jzG,lʫ$."$4q～ iͱgq+,	-f0!WX1dlKH#!|'x+0
b%12rl?$Yr'&a^BXFtc<=1#_9*2fufRN

\mzAj
s$R`o$.7\uzDpF 4|)UpJf8ks޽;8%AiMƋHA80We*
n/RL<8߾[c\.G0I׋JuЁl feL.T4VJ<@e4MGܜi]ˈLBKK0[rBn
׬
˕Xkl6*/5&5HKBP痹gɂaYLƽYuAt.k]o4]_nrogi_'.]h`KI|zYAxg
Q4#cXk c6fdUz9/tvĨ4AP(%؆+3`wRx^ZYzSʐ^9vI\l*Ux$0o
T'Ky\ɚ)|K{/D`D~m])3@$LY$ɉvtZKM3BϪHJ*s
|	@'B!PMbM׮Hp>HBȧM'CTF%@IE
) n&|bҼuTôvYr^~}n"&iHN&&X% Xn\QuPxήK=UOc[߃ۻuڰo'&m*v5$>nw'gJh5w6]؀	v!fDh@ԑ{zRuBgax3)Mjq?;o\O#}'h|n?xvkK7xbv׷"&H4r7i<|Cj&i&}~3% `"x>G 
ǐ@hOc'&BDCVW4D8[:kH		C0	
;;	
.VKkYA&:6@3b


>RbR	
>
-	kî0I*\CpC:ZBՌ.A@"4~xŀ[`xD́E<`, E¬SsIȢ9_8b:  
U:F`sl0`ׇ̹KnAs#"E`18-}v&%'ϐgxDT1<+ G˚GPg45sMЬ'i"m@FsH
rϽn@Pi߄F1t0GoH8/-Hpsvx$`H!sc@~Z)
uLV
y]w"$?l91`!Vzf͠>F6Yos䬵,N!ks,h|,B Gb/h$pE
%dBО']?@@LJNZ0y͡	s:_j48n-%!/(*:̰Sw'=g%%Sm-5lxaCÊخu)À[Jty"] w|٠И#; )ٵuC 2\T@.У^؜.ĘT
bU!XcR;'lM]-] Lt/RbغQQ,CAٍ
M:6gwRzB%3	CT`O9+fÑ&wxQT’:aRå\.zzG=$@/%[]l@D^t6,{,hQYk)bEH$4>\5y
ta.\V2VlIJ@:p#23hMKl+]%hr|GYwFӐGAzn@K'd$$X2J44 km$WvUk6(xT%(I:Kv
M;at%P	CLbCJ'fKj$4zLPIBʧ,?P'f`lpP|u4D`OV(&B+<`-Y 
օOOB(_b0M"OJr[";Ys}-}`/5[":"U@ph]
F.PхV36.!ҊeXXuICFUUXWz$N+:3HCW'hFi$5g%%Urwq(t[uRHYe%U5XWYΈX6XXLq0gPrsqf^s7UX5shsMP3厶 VE.$iRRڒ]EtCU7@sD5%18p+h{牟Xc;c<Ўۢc%v}9Xu;P;p'`uvD97uWUC^PCUq^Fʳ9W3@|?~@e&BI&xEdD'Z@>2fxKFF>FeQ>ѱd?)vx]2d4c~cjh8=zԒ>(yiR|űzCrԹw\UYlۙwřDiKP#HGր2=ٝV";>X,4RytUQ
i4DnHe+B	?q&J	|
"0We%P$.24XJ-aEx$"U;9ꤗp6`A`@ĥ.tҕr	
G)@~),S	(v!`өZhWX&xyycgw0zjlڜ
z*rWxhʩ7Rf
uZdv/*brAgP z"(g)0ʊnrପr%  e9$:$m4j$躯?[0JX@ ˰dK`K$ɱV#S@`p
+FɲQ!ox6!$~?;.0㚴uAD+ScJ.O{뵟a0P$.h{8Lne{h pYUP	Z!`k
:$OP>۷A1{{p۵w8и!+0Ew+P3;B4,z;{kۺf;$E4>һD{{`Zh;[^-뫼fk+lܿ	P*;PKi\hhPK+AOEBPS/img/strep024.gifGIF87aX@?**?***UU?UUU????**?*******?*******U*U?*U*U*U**?*****?*****?*****?***UU?UUUU*U*?U*U*U*UUUU?UUUUUUUU?UUUUU?UUUUU?UUUUU?UUU?**?***UU?UUU?????**?***UU?UUU?????**?***UU?UUU?ժժ?ժժժ???**?***UU?UUU?????***UUU,X@	H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜI͛8sɳϟ@
JѣH*]ʴӧPJJիXjʵׯ`Ê	П@	H*\ȰÇ#JHŋ3jX?8`A&TaC!FП?~O@ӷ?8`A&TaÂO>}	H0>}?	4xaB6t?ӧO|ԧO>~O@
DPB
	o>}	H`>}?	4xaB6tbĄ0@Ǐ?Ǐ?~O@}O@
DPB0O@0O@
DPB
>؏>ԧo@~O>ǯ,h „
2<؏>Է?~8@~0@<0…:|1~˗O~$׏|ODۗ/_|O"Aӗ/_|I(QD˗/_>}'?˗/_}$J(`?~˧_?O_|'QD%JH|'Q~˷D%/_|_}OD%JO_|'~˷D#ۗ/_}I_|(QD%F/>~$J<菟|I(!|?	4xA˷_„	&L0a„	˗O?	&Lh?}K0a„	/_>~&L!?}0a„	&L0a„	&/_}&L0!Aۗ0a„	&/_}&L0!A~0a„	&L0aBۗ0a„	˗o	&L!|K0a„˧_„	&L0a„	&L_|&L0a0a„	/	&L_|&L0a„	&~	&L0!|%L0* <0aB~SPB
*TPBOB
/>
*TP_>}
*T!|)TPB
*O_}
*T|)TPBPB
˧OB
*TPB
OB
*/>
*TxP_>~
*TP|)TPB
*/_?
*T_|
*T`|*TPSPB
*TPBSPB
˷OB
ܗϟB
*T80_>
*TPBPB

/_>$XA	˷OB
*/>
*TPB
*
*TP!~)TPB)TPBPB
*TPBSPB

˷ϟB
*OB
*Thp_>
*TPBSPB

OB
OB
*4o?
*TPB
*$/B
*Tx0>
*TP`>~
*TP~SPB
*
*T|*TPB
*T`|
*TP|SPBSPB

ϟB
*TP~)TPBOB
˧PB
ܗϟ?
*TPB
*/?
*T|SPBSPB

ϟ?
*TP‚SPB

ϟ?
*D/?
*T`|)TPB
*TP@})TPBϟB
*/?
*T`|SPB
*T@<0„…O….T/_>-\p….\}-\pB…̧/.\P_|[p…"/.\0_|[pBӷp…˗O?.\p….\O}-\pBӷϟ.<_>}.\p}….\|[p…ϟ?.\H~-\pBۧϟ?.\p….?~O@
DP@o?.\x0?[p…_~-\p…_|.\p@~ϟ?.\Hp…˧>}[p….\p?}˗o.Lo_|ӷϟ.<ϟ}[pBϟ|[p…"o|-\pB_>-\p!A~˧…*/?….\p…G_|-\pa~̷ϟ??	4xaB
/_>~
*T|_~)TPB
 |SPBϟ?OB
G_|)TPaBϟ?OB
*TPB
g_|SP˗@'?	4xaB/_}*T`?~П	O@
DPB3O_|5lذ`}П@
O@
Dp ?}˗o_?
*_|'p>}8`A&TaCㇰ߾|"ā˗/>~	(P>	H}ϟB
ۗ/_>}8P`~8`A&TAۗ/_}5l}?7?	4xa!/_|SPaA˗O?O@$XA	.dC-/_|ăۧ/_|O@<0|/_|PA˗/_}8|'p "Lp!Ã-/_|aC˗/_}8`|8`A&O˗/_}S?~˗/>~	H>}8`A&TaC}	O@~o@}8p~	H}8`A&4ϟBO@}?	Ǐ>}	~	H`~8`A&TA
O|Ǐ~	H?~O@}'p A
O@
Dp ?}
O|ӷ ?7p>}	_?$Xp	H*\ȰÇHП?~O@ϟO@'?	4xaB)L}'p ߿'p <0…?~O@ǏO@<0@~*}'p A'p 
O@
DPB
>D'p <0|*LП8 A$X_~8`A&TA6$П8 A$X_	HOB

O@<0…:|(P?!O@'?	4xaB)TP	H|'p "Lp!Ã5lذ!@,/@$XA	ӧPB
'p 
O@
DPB
>D'p <0|*TP?$X_~8`A&TA6l?	o ,h „SPB8`}'p "Lp!Æ
"D8`A	O@
D`>
*T@,/_?	H*\|
6lП7?	4xa)TPB	H>}8`A&TaC"ā	H?}'p "Lh0?
*T?	@$XA	.dx_
6O@<0@~*TP@$Xp	H*\ȰÇ@$XП}8`A&4ϟB
*ПO ,h „
2	HOB
O@'?	4xaBaÆ
8`~'p "L8>
*T(?	ܧo ,h „
2l@}'P`?$X@8`A	O@
D`>
	'P`?$X@8`A	O@
DPBk(`>'p ;П7?	4xa),0@8`AO@<0…:|(P?	̗"|8`A	O@
D`>
	'0_>
	3ПO ,h „
2/BO@<0…:|(P?	̗O|	/>~	/>/_>~	H?}'p "Lh0?/}_>}/_}o_|8`A	O@
DPBk(0_>ۗ/?/O_|˗@,/@$XA	ӧ`|/_>~˧_>~˷|ۗ/?$Xp	H*\ȰÇs/|_>~߿|o>_}	H}8`A&4ϟB	̧߾|/_?_>~߾|П'?	4xaB|ӷ/?_>~	䗏߿}/?'p A
O@
Dp ?}
'0}_~O |/}˷?	ܧo ,h „
2l@}'P`'_/߿|П'?	4xaB)$0@_߿|O @,@$XA	.dx_(_>}	߿|O_>}	O@<0@~O~'_?/߿'?	ܧo ,h „
2l@}'P˗O߿|	/_O_|'p 	O@
D`>
	'P˗O߿|	/_O_|'p 	O@
DPBk(0_>ӗ/_>}	'0|O`>}П	7?	4xa),/@}˗/O`|'0|O@<0…:|(P?	ԧ>~O`>>}O>~	H}8`A&4ϟB	ԧ>~O`>>}O>~	H`~8`A&TA
̗O>}	_>/'P?'p A
O@
Dp ?}
'P>}/|	ܗ߿}@}8 }'p "Lp!Æ
a|O_|O`>O|?	o@$XA	
`|O_|O`>O|?	@$XA	.dx_/?}O`>˗O/_>~	H`|8`A&O‚	ܗϟ|	'0|˧?}ӗ/?$Xp	H*\ȰÇ@$XП}8`A&4ϟB
*ПO ,h „
2	HOB
O@'?	4xaBaÆ
8`~'p "L8>
*T(?	ܧo ,h „
2l@}˗/?O@'?	4xaB)TP	H|'p "Lp!Ã5lذ!@,/@$XA	wp_|)T_>	H>}8`A&TaCgP_~a	H?}'p "Lh0?OB!O@'?	4xaB|kذ`>	H`|8`A&OA}㗏B
!O@<0…:|(P?
߾|	/?'0|	ܗ/|O`>~/>o@$XA	
WP_~P|8`A	O@
DPB3/_kؐ`>	H`|8`A&O|o_|˗@~_|˗_'0|o@ۧo ,h „
2l@}˗o?/?~׏_>~?~|O`}/_?o@$Xp`|3/A+/@~˗@~/_}˗߿}'_|O_>O@	O@
DPB3/@~˗@~/_}˗߿}'_|O_>O~'p ̗|
,˷|/|O_'0>~뗯@ۧo ,h „
2l@}/_>~	̗/_>70߿|˗o`'0?ۗ?'?	/_|g |
˗o?/?~׏_>~?~O_>'0>~뗯@O ,h „
2}8P}8`A&4ϟ~/>'߿|o`|؏߾|/}8P`~8`A&TA/_>~	̗/_>70|70~ϟ?П<0@~70_|˧/_>
/|_}	ϟ?}O@
O@
DPB
>A~O>~ӗ߿|o/_>/_~	(P>	H篠?˧/_|#/|
̗/|O`>ӧo@
O ,h „
2/@$XA	g_>ӧ@}/}ۧ_߾|O`>˗@
ܧo ,h „
2l@}˗/߾?}/_>}O|/>}_|	8P>	H |˧O?_>~O|߾|O`>˗@
O ,h „
2~ӗ߿|o>ۗ߿}/|/_?/@$XA	w_|/_>~˗o}/|˷O?}ϟ?O
O@
DPB
>D'P`}ԷO ,h „3/_|ӗ/˷O|o`ۧO|	ϟ?'p|'p "Lp!Ã/_}˗?'p_|	70?}'P_}ϟ|8P`|8`A&OB
*ϟ?'p}'p "Lp!Æ
"D/_>$o@$XA	
PB
'P`}O ,h „
2
*T?П<0…װaÆ/@o ,h „SPB?	ۧo ,h „
2l@}˗/?	o@$XA	
0_|!0ƒ?	O ,h „
2}8`A&TaC0_Ca>8`A	O@
D`>
/Sx?	@$XA	.dx_|	5$П7?	4xa)̗|CO!B$Xp	H*\ȰÇS/|˗?}/_?7_|˗o?П'?	4xaB)̗O`>}|/_?'_|˗o}O@<0…˷0_>/__|O@~/_}˷?	o ,h „S/|˗?}/_~˧o |	/>П7?	4xaB6tP>~
/@}O	̷_}O`>ۗ_|8}8`A&4ϟ|O?|o?}ϟ|/>$/_?	H*\|/?}o	̷_}O`>ۗ_|8`|8`A&$O|'P?|o@}ϟ|/>$O@$XA	.dÁ)̗O`|ۗO`>'0|/|O?'p A}'p "Lx0?	̗_?~	7}/߿~O?/_>$/_?	H*\|/߿~o`?~	'0_'0>~_|	H_>	HOa|؏߾|
o_'}߿|˗?	?	4xaB6t>~
O|O`}	'0_>'߾|ӗ/_>}	HP>$XA	0_>˷_>/|o|˗o_>}П<0…˷0_>˷_>/|o|˗o_>}П<0aA~'0>'0|O`|O`}˧/_|8>}	H*\ȰÇS/?~	_>/|'0߿~'0_>}?	<0!|_~O`'0?_	̗O>O@O@
DPB	[/?~_>/|/߿~'0_>}?	<0A~_~O`/?	_	̗O>O@'p "Lp!ÆOa|/>}/>}˗ϟ@}O_|ӗ/>$O?$XA	0_|	ԗo>/>}˗?}O_|ӗ/>$(0?$XA	.d_O|	ԗ?}O_|˷O?ϟ|'p A'p "Lh>o|	ԗ?}O_|˷O?ϟ|'p A'p "Lp!Æ"D8`A'p "L0?
*T?	,h „
2L/_Æ
'p 'p "Lh>
*T(?	ܧ?	4xaB6t>~!BП?	4xaB)TP	H|8`A&TaB6l?	?	4xaB)TPB	H>}	H*\Ç@$XП>~	H"OB
O@<0…װaÆ	H`|	HOB

O@O@
DPB
>,D'p O@
Da>
*T@,/?$XA	.d_
6O@O@
D ?}
*TP @,O,h 
2laA} B8?	,h „SPB8`A'p "Lp!Ä5lذ!@,/,h „SPB8`}8`A&TaC"ā	H|8`A&DB
*П?	4xaB&_Æ
'p 'p "Lh_>
*T(?	ԧ?	4xaB6t`| B(?	,h „SPB8`}8`A&T|6l?	ԧ?	4xaƒ)TP	H`>~	H*\ȰÇ@$X0_>$XA	OB
'p AO@
DPBװaÅ	H |8`A&T/_>~!:O@?˧?$XA	ӗoB
O@?	4xaB6/_>~:,П˧,h „	/?
*<П?	4xaB6t|A?˗o
0'p "L/_>~	&L?˗,h „
2lh_|:t8?˗,h „Ǐ |)TPaAO_>}8`A&TaC˗/?'p}'p~	Hӗ/߾	&<П˧,h „
2lП|9t@ۗ/>	HO_|+O_|*Tp @˗/?$XA	.dC˗O?#_}(0'p "L8p_|SPaB/_}*TPB
*o_|SPaBۧ/_}
*T>˗O?	$H A珟|O@
DPB
>x>}_D˗/>~˗_B̷?	4xaB˗o_?
*,o_|SPB
*T0!?}OBۗ/_>}*TP?}	(p| A	$H~˧?$XA	.dC/_|_Dۧ/_|+/_|O@	H"o_|ϟ?
O_|PB
*TPӗ/_|P!A˗/_}*TPaA}	
/_>}O}O@
Ǐ|?	4xaB6tbO|ӧO}	O>}80>~8|#8|<0aBۧ`>O@~
ԧ`>?	4xaB6tП~O@}8O@}'p "L>O@˧o?ӧ`>ӧo@~ӧO|ǯ,h „
2l!Ĉ	_?~'P |'P ?~'p ˗ۗ/_|4hРA
ϟ~ӧO|,_?	H*\ȰÇ	}0ȯ?$XA	&08|#H?۷>˗o@~<0:|1D$X,h|3/߾˗/+VXb|UXQ|/_>˧bŊ+VXbŊ˗/_?˗_ŊA/+VXb|UX|O_AWbŊ+VXbŊ˗Bbň=/+VX!?}WbEWAWbŊ+VXbŊ˗BbŇ{/_>}+VX"|=̗/_Ŋ˗/>$/_|8`A&TaC!F8bE˗BE_|.^x}{/_˗/>˧ŋ/^xŋ	˗BE˗ϡ|]xEa|.^t/_|˗//^xŋ/.ܗ/_~
˗/'P ?$8_|8`A&TaC!O@$H0_|,X`$/_|
/_>}	H*\ȰÇ#JHņO|wbA~	˗O,h „
2lC	?	̗/_,X`˗/˗O,h „
2l!Ĉ'Rh|S/_|]H`>O@˧?	4xaB6t>˗`,X`˗O_˧?	4xaB6tbD)Vq_|)/_|.^`>'p A<0…:||
˗`,X`˗O_˧?	4xaB6tbD)V8q_|)/_|.^0'p <0…:|P|O@W`,X`AW|O@
DPB
>QD-Vܗ/_~
˗/ӧ/_|ӷ_|.^xDӗ/_>}[/_˗/>˧ŋ/^xŋ˗BE_|.^xE{/_˗/>˧ŋ/^xŋ˗/_?˗ŋϡ|]xE0_|//_>}
˗Oŋ/^xŋ/ܗ/_~
˗/ϡ|'p "Lp!ÆB/_>~1bDӧ_|E1bĈ#F1bĈ#*ܗ/_~
˗/˗ϟC1bĈ#F/_>~1"Dӧ_|E1bĈ#F1bĈ#2ܗ/_~
˗/˗ϟC1bĈ#F/_>~1Cӧ_|E1bĈ#F1bĈ#:ܗ/_~
˗/˗ϟC1bĈ#F/_>~1Cӧ_|O@
DPB
>QD-^d/_|˗/_>%˗ϟCÈ#Fa|0^/_>}
˗OF1bĈ#F1
ܗ/_~
˗/?ϡ|aĈ#ƈ0_|-˗/>˧#F1bĈ#F	˗/_?˗F_|0bĈcD{/_>˗OBӇ#F1bĈ#F˗BC~s/_>}1bĈ1|=̗/F̗O/_>}	H*\ȰÇ#JHŋ˗BC~s/_>}1bĈ1|=̗/Ɖ˧O|È#F1bĈ#FO|!|9/>1b_|˗Dӧ_|aĈ#F1bĈ#}_|Ȑ_|˗OF1b/_>~ˇ1|S/_|0bĈ#F1bĈ|S/_|a\/_>˧#F1F/_>O@˧?	4xaB6tbD)Vx#}_|˘_|o_|/cƌ3"//_>~˨_|)/_>}3f̘1cƌ3fhp_|)/_|2"/	H,h „
2laC[`>O@
4/_|
/_>}	H*\ȰÇ#JHŋ˗/_?˗_ƃ|
<0…:|_|'p@$XA˧@<0…:|1ĉ+ZQ|S/_|e4/_>'p`>	H*\ȰÇǏ!??	4x|C(_|'p "Lp!ÆB(q"Ŋ/bd/_|˗/_>˗C	?	4xaB6t|5O|	H˗OB˧?	4xaB6tbD)Vx}_|H_|O@	H*\ȰÇǯa?
}˗/>$XA	.dC%NXE˗B/@~s/_|3f̘|9/_~
˗/>˧/cƌ3f̘1cƌ)˗/_?˗_0_}3f̘|=ԗ/_F˧O|˘1cƌ3f̘1cFO|_|˗1cƌ˗Ce,/_|˗/3f̘1cƌ3fĸ/_|˗/_>"3f_| X_|)/|8`A&TaC!F8bE1f/_|˗/_>OF5f/?˗OBӧQF5jԨQF˗B篢}ӧ`>	
ԧO?~'p "Lp!Æ6/_|'p Aǯ?$X@wp|O@
DPB
>QD-^Ę|S/_|=O|O|,h „
2l?O@}8 A}8P~8`A˧ A<0…:|1ĉ+Z1}_|So_|ϟӗ/_|iԨQ~˗O~0O_|_|)/_>}5jԨQF5jhq_|)/_|ۗ/_}iL؏_|ӨQƂ˗o_?/_|%/_>}
˗OF5jԨQF5bܗ/_~
˗/ϟƈ˷ϟF3ۗ/>~4BO_|/_>}
˗OF5jԨFiF/_|8|/_}8`A&$/_>}*TPB
&/_>~
*Tp_|	/_>}
˗O,h „
2l!Ĉ'Rh"ƌ˗~
O@~	H&/?
*TPBOB
/?W߾˧?	4xaB6tbD)Vxcƈ_|˗oFOFOFO}/_>}5jԨQF5jԨ|˗/_Ө?}iԨa|4jD/_>}˷/_|4jԨQF5jԨQ#}	߿<0B-\p…ԗ….8P,h „
2l!Ĉ'Rh"ƌ'p<0„p….\/.\_}'p ,h „
2l!Ĉ'Rh"ƌ'p`~<0…[p….̷o….ܗA̷?	4xaB6tbD)VxcƊ8PO@
DP~[p…*o….ϟ?8P>$XA	.dC%NXE)'p O@
DPB[p…&엯….\/?'p~	H*\ȰÇ#JHŋ3V`>˧?	4xaB….\|.\p}O|<0…:|1ĉ+Z1~_|4jl/_?4jx_|4jd/_>˗/>~4jԨQF5jԨQ~˧/?˗?5j5&ԗ_~iԨ|Ө1?}ϟF5jԨQF5jH0?Ө |ϟ?5_|ih_|ϟF5jԨQF5jH0?Q@O`~8`A&TA˧_Æ

/>,h „
2l!Ĉ'Rh"ƌ#7_|mO_|/_?6nH_>oE~ϟ~qƍ7nܸqƍ#WП|߾|O|'p "Lp!Ã/_}6lX߾|O~'p "Lp!ÆB(q"Ŋ/b̨1b>˗O?/_|'p|'p "Lp!Ã!/_|kP?~˷@o ,h „
2l!Ĉ'Rh"ƌ#?}ӷ?ӗ/_|'p A	O@
DPB[菟|_Æӗ/_>}'p ~'p "Lp!ÆB(q"Ŋ/b̨1b>0Ǐ@
Ǐ}'P>~8`|'p "Lp!Ã5؏>Է?~8P`?~0O@<0…:|1ĉ+Z1ƈM׏?}8`|߿'p <0…~0ӧ~?	o ,h „
2l!Ĉ'Rh"ƌ#q @'p 	H|'p "Lp!Ã5lX?8`A$X_	H*\ȰÇ#JHŋ3jF	H|'p "Lp!Ã5lذ!@,/@$XA	.dC%NXE5Fo#F$X_~8`A&TA6l?	o ,h „
2l!Ĉ'Rh"ƌ##@,/_?	H*\|
6lП7?	4xaB6tbD)VxcFۈ?	@$XA	.dx_
6O@<0…:|1ĉ+Z1ƈmПO ,h „
2QD-^ĘQc|6bO@'?	4xaBaÆ
8`~'p "Lp!ÆB(q"Ŋ/b̨1b>1'p <0…װaÆ	H`|8`A&TaC!F8bE1f18`A	O@
DPBkذaC$X_	H*\ȰÇ#JHŋ3jF	H|'p "Lp!Ã5lذ!@,/@$XA	.dC%NXE5Fo#F$X_~8`A&TA6l?	o ,h „
2l!Ĉ'Rh"ƌ##@,/_?	H*\|
6lП7?	4xaB6tbD)VxcF3/_|6̇?	@$XA	.dx_>ǯaÂ'p 
O@
DPB
>QD-^ĘQc|
|6̇?	@$XA	.dx_/
	;П7?	4xaB6tbD)VxcF+/@~˗@~/_}˗߿}'_|O_>O@	O@
DPB;/@~˗?~/_}˗߿}'_|/|П@
O@
DPB
>QD-^ĘQc|
˗o?/?~׏_>~?~O_>'0>~뗯@O ,h „
2o_>~|Ǐ_~O~'p "Lp!ÆB(q"Ŋ/b̨1b>ӗ/|˗/@O`O`?~	ϟ|O@	O@
DPBC؏|˧O`|/|
̗/|ۗ|o_>o ,h „
2l!Ĉ'Rh"ƌ#WПӗ/_>}̗o`>˗o`>'0?ӷ?'?	4xaB?O|/߿/߿_>ӧo@7?	4xaB6tbD)VxcF+/O~߾|'0|/|ϟ?П<0…w_>O?/}ۧO`o_>_>˗@7?	4xaB6tbD)VxcF3/_|ӗ/˷O|o`ۧO|	ϟ?'p|'p "Lp!Ã!/_}˗?}/_>}|/>}ϟ|8_|8`A&TaC!F8bE1f1(0߾'?	4xaBaÆ
80߾7?	4xaB6tbD)VxcFۈџ?O@	O@
DPBkذaC
̗o@
O@
DPB
>QD-^ĘQc|6bϟ~	H_~8`A&TA6l?
8_	H*\ȰÇ#JHŋ3jϟ|_|8`A	O@
DPBc/_|C@$X_	H*\ȰÇ#JHŋ3jϟ|`"'p <0…0_Ca8`~'p "Lp!ÆB(q"Ŋ/b̨1b>
O?~/_>O`>~	/_?'p_|8|'p "Lp!Ã1̗O`>}|˗|/_~˷߾|'p ~'p "Lp!ÆB(q"Ŋ/b̨1b>
/?}o	̷_}O`>ۗ_|8|'p "Lp!Ã1̗O`|O`>'0߾	_>˗/_~'p~'p "Lp!ÆB(q"Ŋ/b̨1b>
/߿~o`?~	'0_'0>~_|	H_~8`A&TA'0_>'0~O`|ۗO`>}_|	8_	H*\ȰÇ#JHŋ3jϟ|/>~o|	̗_}	/_}˗O@@$XA	.dx_>	̧O`}	'0>~/|o_|˗O@o ,h „
2l!Ĉ'Rh"ƌ#0__|
_>˷_O`|@@$XA	.dx_>㗯|O`	_}}ϟ>~	8_	H*\ȰÇ#JHŋ3jϟ|'P_}|	ԧ/_>ۧ?}O_|8|'p "Lp!Ã1̗/_>~ۧO|ۧO>}/>}˗O?}O@
O@
DPB
>QD-^ĘQc|6bO@?	4xaB"aÆ
8`~'p "Lp!ÆB(q"Ŋ/b̨Qb>1'p <0…װaÆ	H`|8`A&TaC!F8bE1f818`A'p "Lp!Ä5lذ!@,/?$XA	.dC%NXE5No#F$X_>	H*\0|
6lП<0…:|1ĉ+Z1FmП?	4xaB&aÆ
8`~8`A&TaC!F8bE1fH18`A'p "Lp!Ä5lذ!@,/,h „
2l!Ĉ'Rh"ƌ)#@,/?$XA	.d_
6O@O@
DPB
>QD-^ĘQ#|6bO@<0…װaÆ	H`|	H*\ȰÇ#JHŋ3jF	H|8`A&TaB6l?	?	4xaB6tbD)VxcFۈ?	,h „
2L/_Æ
'p 'p "Lp!ÆB(q"Ŋ/b̨b>~1'p O@
DPB	װaC	H|	H*\ȰÇ#JHŋ3jOF	H|	H*\pa}
6dП<0…:|1ĉ+Z1Fx?	o,h „
2\/
.O@<0…:|1ĉ+Z1Ɗh?	O,h „
2l/
*O@<0…:|1ĉ+Z1ƋX?	
/?$XA	.d_|6l?	
O,h „
2l!Ĉ'Rh"ƌ3˷o#E$o_|8`A&TaCСÂ	HП|'p "Lp!ÆB(q"Ŋ/b̨Q#|mП?	4xaB64/_>~:П?	4xaB6tbD)VxcF˗o?8߾|O@
DPB
ӗ/>O~<0…:|1ĉ+Z1ƍ˗?o|ȑDDžO_|8rȑ#G9rȑcF~˷?ۗ/_>}8r䘑|珣A˗O?9rȑ#G9r?~˗O>~Y?}˷G9
o_|ϟ?ۧ/_|ȑ#G9rȑ#G
>}	O>$(p>}	_?$XA	.dCۧ`>ӧ`><0…:|1ĉ+Z1ƍ_}ӧ`>	ӧo?~'p "Lp!Æ&ϟ~ӧO|̧O}<0…:|1ĉ+Z1ƍ'p A˧?	4xaB6t?	/_|
<0…:|1ĉ+Z1ƍ;/_>}ϣG˷o|ѣG=zѣG=j/_>}˗o_?=F/_|)/_|?	4xaB6L|
O@˗,h „
2l!Ĉ'Rh"ƌ7r_|)0'p "Lp!Æ'p@}	8_|O@
DPB
>QD-^ĘQF#˗/>	(p,h „
2lP|˗/?$XA	.dC%NXE5nq|K`>'p "Lp!Æ'p 
/_|8`A&TaC!F8bE1fԸcNJ˧!?<0…*08|<0…:|1ĉ+Z1ƍ;^/_>}80?$XA	.d??˗/?$XA	.dC%NXE5n1|;/_}ϣG˗/?}+/_|yѣG=zѣG˗/>/_|	H*\ȰÇ#JHŋ3jȱǃ˧o||_|Ǐ?~Ǐ?&/_>}˗Ǐ˗/˗Ǐ?~Ǐ?~q|[/_|>~/_|%/_|>~Ǐ?~Ǐ
˗OB}cD/|Ǐ?~Ǐ?~|/_|˗/˗/_>	˗/?~Ǐ?~cDӷP_>O@
DP„˗_B?	4xaB6tbD)VxcF9v8_|-ԗ/_>?./_|˗/_>?~Ǐ?~NJ˧o|1|_|Ǐ?~Ǐ?^/_>}Ǐ˗/˗Ǐ?~Ǐ?~1|[/_|>~,/_|%/_|>~Ǐ?~Ǐ˗OB}@/|Ǐ?~Ǐ?~/_|0_>	H*D/_|%/_|8`A&TaC!F8bE1fԸcG˗OB}ѣ|_|Ǐ?~Ǐ?~/_|˗/˗/˗Ǐ?~Ǐ?~#AӷP_|}/_|%/_|>~Ǐ?~Ǐ
˗/#F/|Ǐ?~Ǐ?~_|-ԗ/_>-˗/_>	˗/?~Ǐ?~G˧o|<0A/|<0…:|1ĉ+Z1ƍ;z_|
Ϡ|_|#O@$H A	$H A_|/?C |˗/_> A	$H A	$H˧/_|˗/?
˗/?ӗ/_|@	$H A	$H O|	(P_|'p "'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?R0'p@}Gp?0	ӷ?(_|8P><0…:|1ĉ+Z1ƍ;z8|O@?~8P>o}'P}
?'p@}	H*\ȰÇ#JHŋ3jȱǏ'p~	HP|ϟ?$XР@O~	8|<0…:|1ĉ+Z1ƍ;z8?˗/>~$H A/_|`><0…:|1ĉ+Z1ƍ;z|/_}@./_|˗o? A	$H A	$H/~ #ӗ/	$H A	$H A/_} -ӗO? A	$H A	$H2c|	$H A	$H AZܗȎ	$H A	$H A/?$H A	$H A91> $H A	$H A	2"| A
엏H A	H H HO,h „
˷,h „
2l!Ĉ'Rh"ƌ7r#|@o? A	$H A	$H	R|	$H A	$H A|/? ˷ϟ? A	$H A	$ȇ|$H A	$H AP}/>}	$H A	$H A|?}O_}$H A	$H A	>~}O>@	$H A	$H Gp_||ϟ}'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~|r?~П	O@
DPB
>QD-^ĘQF=~B~˷Ȃ˗O?o@$XA	.dC%NXE5nǏ-/_|/~˗/>~	HП}8`A&TaC!F8bE1fԸcG?_?~(P>~Пo>}	~	H}8`A&TaC!F8bE1fԸcG?7џ?~O@ӷ?ПӷO ,h „
2l!Ĉ'Rh"ƌ7rG}>'P ,ПӷO ,h „
2l!Ĉ'Rh"ƌ7rG}@NO@'?	4xaB6tbD)VxcF9v>~ ''p <0…:|1ĉ+Z1ƍ;zQ?8`A	O@
DPB
>QD-^ĘQF=~ȉ	H?}'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~D$XП}8`A&TaC!F8bE1fԸcG?r"@,O>	H*\ȰÇ#JHŋ3jȱǏ9?	o@$XA	.dC%NXE5nǏПӷO ,h „
2l!Ĉ'Rh"ƌ7rG}@NO@'?	4xaB6tbD)VxcF9v>~ ''p <0…:|1ĉ+Z1ƍ;zQ?8`A	O@
DPB
>QD-^ĘQF=~|`	H?}'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~a|ПӷO ,h „
2l!Ĉ'Rh"ƌ7rG}'0_O`>~o |	/߾|O@<0…:|1ĉ+Z1ƍ;zQ?/߿|'0_?7P?ׯ_>O@<0…:|1ĉ+Z1ƍ;zQ?˧߿|	'0|ۗO`П'?	4xaB6tbD)VxcF9v>~+o`>o`}	7p>}8`A}'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~a|
'0|
_>˗@,o@$XA	.dC%NXE5nǏ9̗`O`'0|8`A	O@
DPB
>QD-^ĘQF=~Ȉ'p <0…:|1ĉ+Z1ƍ;zQ?ПӷO ,h „
2l!Ĉ'Rh"ƌ7rG}@B'?	o@$XA	.dC%NXE5nǏ)̗/_>~	!?	o@$XA	.dC%NXE5nǏ)̗|C/"@,O>	H*\ȰÇ#JHŋ3jȱǏS/|˗?}/_?7_|˗o?П'?	4xaB6tbD)VxcF9v>~
/@}O	̷_}O`>ۗ_|8}8`A&TaC!F8bE1fԸcG?0_>	o_>/|؏߾|_>}П<0…:|1ĉ+Z1ƍ;zQ?	̧O`}	'0>~/|o_|˗/>$o@$XA	.dC%NXE5nǏ)̗|/|O`>~_|/}П<0…:|1ĉ+Z1ƍ;zQ?o|	ԗϟ|	ԧ/_>ۧGT?}O_|8?}'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~D$XП}8`A&TaC!F8bE1fԸcG?r"@,O>	H*\ȰÇ#JHŋ3jȱǏ 9?	o,h „
2l!Ĉ'Rh"ƌ7r#П?	4xaB6tbD)VxcF9v?}BJO@<0…:|1ĉ+Z1ƍ;z>~!%'p O@
DPB
>QD-^ĘQF=~O8`A'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?_H	H?}8`A&TaC!F8bE1fԸcGA/D$XП>~	H*\ȰÇ#JHŋ3jȱǏ R"@,O?$XA	.dC%NXE5nG)?	,h „
2l!Ĉ'Rh"ƌ7r#П?	4xaB6tbD)VxcF9v?П<0…:|1ĉ+Z1ƍ;zr |BBO@<0…:|1ĉ+Z1ƍ;z|B>O@<0…:|1ĉ+Z1ƍ;z |lП˗,h „
2l!Ĉ'Rh"ƌ7r#H/BO_>}	H*\ȰÇ#JHŋ3jȱǏ ˗O_	8߾|O@
DPB
>QD-^ĘQF=~_|iП?˗O_!C2dȐ!C2dȉ˗O?!ۗ/_>}B2dȐ!C2dȐ!1O_|ϟEӗ/_|2dȐ!C2dȐ!Cv_?~'p>}8 ?}'p>~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?IП?۷O>}8p>}<0…:|1ĉ+Z1ƍ;z2C$X߿˧?	4xaB6tbD)VxcF9vdH7rȑ#G9rȑ#G9?9rȑ#G9rȑ#G/|9rȑ#G9rȑ#GJ/9rȑ#G9rȑ#G/_|7rȑ#G9rȑ#Gq_|s/#G9rȑ#G9rȈ		˧?	4xaB6tbD)VxcF9vdȇ8p/>$XA	.dC%NXE5nG!O@	Hp`|8`A&TaC!F8bE1fԸcGAt`>O@<0…:|1ĉ+Z1ƍ;z2dC	H/>$XA	.dC%NXE5nG!#˗|)RH"E)RH"E/)RH"E)RH"E/_>~'RH"E)RH"E)_|˧OH"E)RH"E)R$|=̗OH"E)RH"E)RH~{/>"E)RH"E)RH0_>}"E)RH"E)RH"a|D)RH"E)RH"E˗|)RH"E)RHDI$?	̗O,h „
2l!Ĉ'Rh"ƌ7r#Ȑa|D)RH"E)RH"E˗|)RH"E)RH"E/)RH"E)RH"E/_>~'RH"E)RH"E)_|˧OH"E)RH"E)R$|-O@8`A&TaC!F8bE1fԸcGAl/_>~'p@$XA	.dC%NXE5nG!˗C}	o,h „
2l!Ĉ'Rh"ƌ7r#ȐǏ?<0…:|1ĉ+Z1ƍ;z2C~k`>'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?_|'P ,h „
2l!Ĉ'Rh"ƌ7r#Ȑ|)RH"E)RH"E/_>~'RH"E)RH"E)_|OH"E)RH"E)R$|A'RH"E)RH"E)|O@<0…:|1ĉ+Z1ƍ;z2dC0+X0>}O@
DPB
>QD-^ĘQF=~R`?~˗O>~{?~˗/>~D)RH"E)RH"/_|?}OH"E)RH"E)`|OdA˧H"E)RH"E)R?~'!|)RH"E)RH"E~/>"#ӗ/_?"E)RH"E)R$G}O_}"E)RH"E)RȌ'2#|D)RH"E)RḨ?	4xaB<0…:|1ĉ+Z1ƍ;z|BzO_!C2dȐ!C2d	_~!C2dȐ!C2dȐ_}B2dȐ!C2dȐ!_>}B2dȐ!C2dȐ!_>}2dȐ!C2dȐ!A/$~2dȐ!C2dȐ!C/_˷ϟ!C2dȐ!C2$H}1_>}2dȐ!C2dȐ!Cǯ_|Bj/_?}O@
DPB
>QD-^ĘQF=~?Q_>}H A	$H A	C}˗Hϟ?$H A	$H AP?˷ȇ˷?<0…:|1ĉ+Z1ƍ;zQ˷Ȅ˗@ӷO ,h „
2l!Ĉ'Rh"ƌ7rG}/_>}߾|?'?	4xaB6tbD)VxcF9v>~ۗ/_|_D0@'p 	O@
DPB
>QD-^ĘQF=~_DO	`>?$XП}8`A&TaC!F8bE1fԸcG?wџ~>(?ПӷO ,h „
2l!Ĉ'Rh"ƌ7rG}@NO@'?	4xaB6tbD)VxcF9v>~ ''p <0…:|1ĉ+Z1ƍ;zQ?8`A	O@
DPB
>QD-^ĘQF=~ȉ	H?}'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~D$XП}8`A&TaC!F8bE1fԸcG?r"@,O>	H*\ȰÇ#JHŋ3jȱǏ9?	o@$XA	.dC%NXE5nǏПӷO ,h „
2l!Ĉ'Rh"ƌ7rG}@NO@'?	4xaB6tbD)VxcF9v>~ ''p <0…:|1ĉ+Z1ƍ;zQ?8`A	O@
DPB
>QD-^ĘQF=~ȉ	H?}'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~|!@,O>	H*\ȰÇ#JHŋ3jȱǏ+/_!@,O><0…:|1ĉ+Z1ƍ;zQ
O|	/70|ۗ/|O`>~/>o˷,h „
2l!Ĉ'Rh"ƌ7r#F}
˗o?/?~˷/	|/@}o?~?'??	4xaB6tbD)VxcF9v>~ӗ/	̗/_>O`O`?~	ϟ|O@	O|
?	4xaB6tbD)VxcF9vQ>~/߿|˧/_
'0|
'0>~ϟ>}'p@}`>O@
DPB
>QD-^ĘQF=~_A~O?}/o>ۗ߿}/|/_?o'p`}	H*\ȰÇ#JHŋ3jȱǏ3/_|ӗ/˷߾|o`ۧO|	ϟ?'p@}O|'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?VD
̷o	?<0…:|1ĉ+Z1ƍ;zHQ?/_>$o˗/|O@
DPB
>QD-^ĘQF=~||@/˗o߿~<0…:|1ĉ+Z1ƍ;z(Q?|EO@˧߿߿~<0…:|1ĉ+Z1ƍ;zQ?	̧O |ӗ/?~_>}O |/_}	HП|'p ~<0…:|1ĉ+Z1ƍ;zQ?	̗O	'P?/>'0?ׯ_}	HP_|'p ~<0…:|1ĉ+Z1ƍ;zP?	̗O`?~	'}/~O?/_>$O_|'p ~<0…:|1ĉ+Z1ƍ;zP?	̧O`}	'0>~/|o_|˗/>$o|O@˷?	4xaB6tbD)VxcF9v>~
/_?'0||/?~˧o?'p A}˗/>$/_|8`A&TaC!F8bE1fԸcG0_|
ԗo>ӗo>O|/_>}˗o@o~˗o,h „
2l!Ĉ'Rh"ƌ7rB}@NO@'_|O@˷?	4xaB6tbD)VxcF9vQ>~ ''p ߿~˗o,h „
2l!Ĉ'Rh"ƌ7rcB}@NO@@˧o˗o,h „
2l!Ĉ'Rh"ƌ7r#B}@NO@˧o˗o,h „
2l!Ĉ'Rh"ƌ7rA}@NO@˗OA˗o,h „
2l!Ĉ'Rh"ƌ7rA}@NO@˗OA˗o,h „
2l!Ĉ'Rh"ƌ7rcA}@NO@˗OA˗o,h „
2l!Ĉ'Rh"ƌ7r#A}@NO@˗OA˗o,h „
2l!Ĉ'Rh"ƌ7r@}@NO@˗/˗o,h „
2l!Ĉ'Rh"ƌ7r@}@NO@˗/˗o,h „
2l!Ĉ'Rh"ƌ7r?}@NO@˗/˗o,h „
2l!Ĉ'Rh"ƌ7r|)'p O@˗O_˷?	4xaB6tbD)VxcF9v_>''p 'p ˗OA˷?	4xaB6tbD)VxcF9vQ_>%'p AO@˗/>˗o,h „
2l!Ĉ'Rh"ƌ7rc|%'p O@	˗/>˗o,h „
2l!Ĉ'Rh"ƌ7r豣|}П˧?	4/_|/_}	H*\ȰÇ#JHŋ3jȱG?	˗,hP`|;8_|'p "Lp!ÆB(q"Ŋ/b̨q#ǎ=˗O_8P |O@
/_>}˗/>$XA	.dC%NXE5n}Q!@ۗ/~	H˧~<0…:|1ĉ+Z1ƍ;z|?˗o˧Oa|	$H A	$H AJO_|篣?~˗o_?˗O~$H A	$H A}˗O}o?ۧ`>} +˗/>˷$H A	$H A_?i_|)/_} A	$H A	$ȌA̗Oȋ˧Oa|	$H A	$H A^/__|)/_} A	$H A	$H0_>} 3˗/>˷$H A	$H AI_|s/>˗O~$H A	$H A0	H`|
,X`,H_|,/_|8`A&TaC!F8bE1fԸcGO@~	Hp`|
,X`,X_|,/_|8`A&TaC!F8bE1fԸcG8P />$XA	/_>}
˗o,h „
2l!Ĉ'Rh"ƌ7r>?	
̗O,h „
˗/>˷?	4xaB6tbD)VxcF9v|O@<0B˧Oa|O@
DPB
>QD-^ĘQF=n߾|a|>~/_|˗/߾?~Ǐ?~cG~{/˗/>˷Ǐ?~Ǐ?~ȑ_|˧G˧Oa|Ǐ?~Ǐ?n/`|S/_|>~Ǐ?~Ǐa|>~4/_|˗/߾?~Ǐ?~cF~{/˗/>˷Ǐ?~裏>裏>#?	̗O,h „
/_>}
˗o,h „
2l!Ĉ'Rh"ƌ7r"|=̗OǏ	˗O~Ǐ?~Ǐ?~/_>~~ӧ_|}Ǐ?~Ǐ+˗|}_|)/_}?~Ǐ?~G0_>}?2/_>}
˗oǏ?~Ǐ?~q"|=̗OǏ
˗O~Ǐ?~Ǐ?~/_>~~ӧ_|}Ǐ?~G}@_|?	4xaB˗/>˷?	4xaB6tbD)VxcF9v_|O8`A&Ta|/_~<0…:|1ĉ+Z1ƍ;z|/_>~'p@$XA	.T/_|˗_~<0…:|1ĉ+Z1ƍ;zt/_>~'p`>~	H*\_|˗o~<0…:|1ĉ+Z1ƍ;zl/_>~'p`>$XA	.d|O?	4xaB6tbD)VxcF9vȐ_|O@~	H*\P ?˗o,h „
2l!Ĉ'Rh"ƌ7rq!|9O@$XA	.d(|˗o,h „
2l!Ĉ'Rh"ƌ7rQ!|9ܗ/_~?F08p`|O@
DPB
>QD-^ĘQF=&/Q>?˗/>$XA	.dC%NXE5n#B~{/_)08`|O@
DPB
>QD-^ĘQF=/?>~o_|-/_}?~Ǐ?~G@	@'p "Lp!Å[_|O@
,h „
2l!Ĉ'Rh"ƌ7r}8p @}O<0…O|O@}	8P>~8`A&TaC!F8bE1fԸcG˗/>}_?~'P~	H*\p`}	~8`AO_|?	4xaB6tbD)VxcF9j/_|Q?~˧/_|(}ǯ_ǎ;vرcǎ;vX_|Ȑ|qa|בa}ױcǎ;vرcǎ;B/_}:J/_>~;/~%ۗ/>;vرcǎ;vر#C~x߾|u8_|u/_>~;vرcǎ;vرcBQ_>};ӗO_Gױcǎ;vرcǎ;0_>	H*$/_>.\_|.\p!AO@
DPB
>QD-^ĘQFױ#AuԘ/	cǎ;vرcǎ;v/_ǎׯE}uh0_~;vرcǎ;vر~ux_~/ױAuرcǎ;vرcǎ1a}:V엯cDŽرcǎ;vرcǎ1a>}:VܗcDŽرcǎ;vرcǎ1a>}u/_ǎ;vرcǎ;v/_˷ϟױ~?	4xaB6tbD)VxcF7˗G˷ϟ?#G#G9rȑ#G9rlo_>}9O}qO|8r4/>}qȑ#G9rȑ#G
/_?˗ϟ}qO߿|q8_|#G9rȑ#G9rl@}qO_>}NJ	ܗO?>}qȑ#G9rȑ#G
/_}8^/_>~ӷϟ?/_>}8^p_|O?	H*\ȰÇ#JHŋ3jܸQ׏D~П@	O@
D ?}˗B
/_}	O@$XA	.dC%NXE5nܨ~Dž˗O?o@$XA		w|P„˗/?O@$XA	.dC%NXE5nܨ_B˗O~O_|O@	O@
D ?}
˗/>~)T?}ǯ@ܧO ,h „
2l!Ĉ'Rh"ƌ7nǯa}˗O>~{?~˗/}8@}'p "LH>ӗ/_|ϟ‚O_|?	ܧO ,h „
2l!Ĉ'Rh"ƌ7n/~O@$8P>~O@'?	4xaB)<?}8`>}
ԧ_?8`A	O@
DPB
>QD-^ĘQƍa@~ϟ?ПӷO ,h „S?8 A8P @,o>	H*\ȰÇ#JHŋ3jܸQ?8`A	O@
D ?}
*T@,o>	H*\ȰÇ#JHŋ3jܸQ?8`A	O@
D ?}
*T@,o>	H*\ȰÇ#JHŋ3jܸQ?8`A	O@
D ?}
*T@,o>	H*\ȰÇ#JHŋ3jܸQ?8`A	O@
D ?}
*T@,o>	H*\ȰÇ#JHŋ3jܸQ?8`A	O@
D ?}
*T@,o>	H*\ȰÇ#JHŋ3jܸQ?8`A	O@
D ?}
*T@,o>	H*\ȰÇ#JHŋ3jܸQ?	?	48ПA$XП}8`A&$OB	?	48ПA$X>}8`A&TaC!F8bE1fԸq>~/|8`A	O@
D ?}
	'0_>
	3ПۧO ,h „
2l!Ĉ'Rh"ƌ7na|/_>~˧_>~˷O|˗@,O>	HO!|'p_|O|˗o?}/_}	H>}8`A&TaC!F8bE1fԸq>~O߿}_~|'0߿}˷?	ԷO ,h „SH0_>ۗϟ|/߾}	ܗϟ|8 }'p "Lp!ÆB(q"Ŋ/b̨qF}'P`'_/߿|П'?	4xaB)$0@_/߿|@$Hp>	H*\ȰÇ#JHŋ3jܸQ?	ԧ_>}/|˗o`>ӗ/_>}	H}8`A&$OB	ԧ_>}/|	̗o`ӗ/_>}	H>}8`A&TaC!F8bE1fԸq>~O?}/|ۗ߿}@}8`A}'p "LH>O?}/|	ܗ߿}@}8 }'p "Lp!ÆB(q"Ŋ/b̨qF}'p_O`>/_>}O_|8`A	O@
D ?}
	'p_O`>/_>}ϟ|'p 	O@
DPB
>QD-^ĘQƍqПӷO ,h „SPB8`A	O@
DPB
>QD-^ĘQƍqПӷO ,h „SPB8`A	O@
DPB
>QD-^ĘQƍqПӷO ,h „SPB8`A	O@
DPB
>QD-^ĘQƍܗ/_>~CПӷO ,h „;/_|*T/A$X>}8`A&TaC!F8bE1fԸq>~_>~CПӷO ,h „3/_SPa	H}'p "Lp!ÆB(q"Ŋ/b̨qF}
7_?'_|˗o|o_|	/_?ӗϟ|8П}8`̗`|
`|/_>~O |	/_~/?~_>}˷?'?	4xaB6tbD)VxcF7Wp_|/?_}۷O`~ۗ?}/|ׯ_~	O>	H|
g0_>	gp_|/?_~o߿|o_>~|/_~'p}'p "Lp!ÆB(q"Ŋ/b̨qF}/_>~/_|70|70~ϟ?П<0!A~/_>~	̗/_>70߿|˗o`'0?ۗ?'?	4xaB6tbD)VxcF7WП˧/_|/|
̗/|O`>ӧo@
ԷO ,h „3|˗/|70߿|˗o`'0?ӷ?'?	4xaB6tbD)VxcF7W_>O?_>}ۧO`o_>'0??'?	4xaB?'P_?}o_>~o`/߿|ϟ?П<0…:|1ĉ+Z1ƍ3/_|ӗ/˷߾|o`ۧO|	ϟ?'p@}'p "LH?}O_|˗O/_}˷O|/@ܧO ,h „
2l!Ĉ'Rh"ƌ7nǏE
̷o	O@
D ?}
*T@7p}'p "Lp!ÆB(q"Ŋ/b̨qF}8^ϟ|8}8`A&$OB
*ϟ?'p }'p "Lp!ÆB(q"Ŋ/b̨qF}8^ϟ~	HП}8`A&$OB
*ϟ?8}'p "Lp!ÆB(q"Ŋ/b̨qF}˗/ПӷO ,h „S/_|COA$X>}8`A&TaC!F8bE1fԸq>~
/?ПӷO ,h „S/?!̇0ƒ	H}'p "Lp!ÆB(q"Ŋ/b̨qF}'0>O_|O`>~
/_?߾|'p A	O@
D ?}
O@~/_>'0|˗@~o_|8}'p "Lp!ÆB(q"Ŋ/b̨qF}'0_>'0@}o߿|/|۷/_~'p A}'p "LX>	̗O	'P?/>'0?ׯ_}	Hp>	H*\ȰÇ#JHŋ3jQ?	̗O`?~	'}/~O?/_>$o,h „S/|/|ۗO`>	o_>/>O@'p "Lp!ÆB(q"Ŋ/b̨q#)̗O`>}O`>'0|/~ۗO_|'p A}8`A&4O|'0>~o|	̗O`}	/_}˗O@ܧ?	4xaB6tbD)VxcF9Oa|'0߿~_|o|o|O?$,h „S/?~	_>/|'0߿~'0_>}?	<0…:|1ĉ+Z1ƍ0_|
ԗo>ӗo>O|/_>}˗o@,h „S/_|˷O@}˷O@}'P_}ӗ/>˷?	ۧ?	4xaB6tbD)VxcF9ǯE$XП>~	HOB
O@<0…:|1ĉ+Z1ƍ"@,O?$XA	
ӧPB
'p O@
DPB
>QD-^ĘQFh?	,h „SPB8`A'p "Lp!ÆB(q"Ŋ/b̨q#uП?	4xaB)TP	H}8`A&TaC!F8bE1fԸ?}:ZO@<0A~*TP?$XП>}	H*\ȰÇ#JHŋ3j|-'p O@
D`|*TP!@,/?$XA	.dC%NXE5n_>~+'p 'p "L0?
*TП?	4xaB6tbD)VxcF9
ԗ_G	H |8`A&D/_?
*LП	˧?	4xaB6tbD)VxcF9̗_lj	Hp |8`A&T/_?
*DП˧?	4xaB6tbD)VxcF9/8@}'p "LP|.\p @/_>$XA	.dC%NXE5np_>}:BO@<0Bp…8 |'p "Lp!ÆB(q"Ŋ/b̨q#GׯC/_>}	H*}ϟ?	ȏ>}˗O~	H*\P?ӗ/_|ϟ?_?~˗/_>}O@
DPB
>QD-^ĘQF	}'p ǯ?$XA	.dП?ۧO|,XP>~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ
8~۷o?O@
DPB
'p?
o>~O@
DPB
>QD-^ĘQF7'p A$XA	.dA$?	4xaB6tbD)VxcF9vdH#I4yeJ+YtfL3iִygN;yhPC5ziRK6ujTSVzkV[vlXcɖ5{mZkٶun\sֵ{o^{p`0;;PK즘PK+AOEBPS/img/strep064.gifM$GIF89aq@@@000   ```PPPppp!,q $dihlp,tmx|pH,Ȥrl:ШtJZ9`AzxL.
8|Ny(
$%w+	{"
		]	E
n"
"
	Ǝ$Oϙ#	
("
Hip@@` q3jȑ,8 	S˗0cʜIMTnɳg|
JT&ТH*
xtӧP5J;SjK֮`ÊMuٳhqM˶kʝk6.ݻx˷/ҽ~	xa*)^̸ǐ#KL˘3k̹rΠCMӎaװc˞M۸sͻNȁFN׫k'}n};>mۦ?ϾGl?C1`W`	n~UFh!V:aTη/|a!>b{(֋2=@*c&, Ɍt1@bF*@F
8&ex:@e&(D84& $	44
SvY.[b",1
@"AyœC1Z]񍖘`(,@% .<`@](>湥3"@ 4@*Ojq-AJ=0̞.
̲@#뱽V:KVv)t$.A%Œff@	f@Qd	{Д f5V⚵pM#qZ oXHagl`rw\|":ȳV>`,m!;8tUN?
+=p*0VL61U;ҵHS(X0Qm6Ό|]0g!w|6)yv߄7p;wP؊>w"8Ɏ	Ey/̪I0\<
IBbэ,;PO^!K
y(n.~:$90	{hn"Γ;2#Gԗ`R3Ld%,C$H@C3"S-8צ.!MEApPƔ`!REJjS$l7[>·Dž%~XQ~_eأ"*ʗ(B,CzUluLiL"*Jb&
Z=Dm%z8ǂ0LЍwd/CI[ 譸S"'YTVrR􄊱_P	\:=N|parV".&]>1KuUX3\iTKV/Ȝ\ܸb`
)~Q |(4'9$O)bM@āVr
jJr,qG[S ^&
A$&`U"E(WfgCZC$5DS	G-LhβFŊ(x~㮃P#)7In?4կZ7U%tLRB
S'4DA"1R.BJ9.mNPFo!"/}+r~ߐ2XecE#O:12l$FbK5eI[W*5'VFkF͊[jѭwX'l
5]т׮sʺ}7`KaUk:
\Gus[p5Ǣ/ϘnJgt`D_PHMO7	kXkRBSwI׀"UGwuox!p@~qAH]L 3bm&ZW
|#P?|I5d}iGgeJM\#s|]@zH^g@V[D7bE9^$CA6]P	 .wy/z!mbhIf"!dbCxXbH_Ha8hgvf%]p%hld7gpf$'t%JG"G0.`)rfQy臿}b^~cmK	H+)Arj"A:@eGr#aԖ,Hb)g1g8?&&`{rb&$1*dp&*qK&Gdܔ.:(}c/2#
#(q0pqWЋb8fNfyU#g2
JDwf'.E@NJUbH}B
a2S%D@`[@Xv$yP)dx	\|:$)nzR	j#B>88G5g"3tB+)9q#|XAF~It
UbI"@nPOI-	pZ؂xh@&dw|E|!Y"N	#/k40Hn0m[ɁSA^!zHX2@1Ƀ(1#Y"-G
vГ(r!C~ho}zX
ig*0awcfiiq['x%P	d&p}Ɉo|#hԨ;Hl1{П&	9Dy),09%Bqn#`Ǘ2.E"h&
޸P-g	Ќl`puؑLX(	#^س9X8(/.אd( \ (Y@,B$`#MbWy
P{iIy4'R%s_0DZ8wi	{xLP
x*(Q;GLhUwG\h4#Yi19#
ƀB[@FJ۴NR[VGZ۵^Ƶb[ fR@j۶knIr[sv@@z۷{~7[۸)@sF[4+mc]4ƹQV_:yۺvˡuS񺱛C.+ڻP1ț@Cм/K0$|"l!*w[@P2L#4(|8G@!BlDuF|
E;NQ!:߀^$H>cY'Ѕ_Tii_k/u_WrhJ^(w_vApoL:pW*Jx_Z,u>*l'BMȟ^ d'>xFl!Ø=ɧt|y\a^.ccF=a5<9<283`;3d')MpQ40&:M@AW?%*vt(:T$<̼#C[%wRlFvB"ゼ\G0	!͘.8*LL6+ˊKZC#,͙$E)"7w	ҧpЌ;2ҧ'{W
*+M?
 dAk1bEČѕ9*g=-Tm0'եIV&0Fpzg-VXml^b{:L&Bj} 7Rs؎ْؐnD}ٍؚ٘ٞ=ԬБkעy<&Q:zڦnsk, iV_'87b|L-`E2=*(;b})ʊiAPT"}HūۺVmEPT2tSr&1c(oI͘#jd'8WT7+q0GrSJr[bkE>=>H"Cc&;cBNM]F9W7@!Dz⣃l)=|R\,+4]#\䙰+|f]"*0Yzŕaݮ8ĴAy +
C\!={
Mո{8c1
.p.{uHg'ڴZYjll^E OiI|^x$ aQ-귮-]0{Xa.xg=G  ^rS>1i}<7[q;_	C}Zu[x^A	
F-tw-a
ggD#O\'Hg-0N
9qzno	fZdHz	b[ڤv~-Ah Z~欆2?mA19>tA=V/PFSд	kbH(]C䳢x,IjmW($)t>"1˲݁E"u
C٬}0ok?~t𹝐'c|:	^cE	)w/ven[i!¤cY
Whc|Y)Oh=a
Ok#j_U'32+௨	/	(2, +0<
3!h<"%|B)Z[YGA @T%>C2E4bD10a(14$
B8$4$4(@aܼu0 1nn:yjA n.0/218`_,,GWghcD(,KwOK8+k "LHW/$6C҂%EŋrZ))r$ɒ&OLIG,Cofr'Ϟ>
rI˃0Ę1MG1 ݊H$
+vءJFT6qZh` $oLv1ƎM`2I
V8B@CP:j&/~{7?" ;m겳FKdV
@lGpIx>6u^A.p!@H,?LFPxF9<>.] \vL
\HZ(D`y'
;qqa3XQÝ%y Hbr\HBUAp33i&GFʸcIFX,=ѝt#|MM%,Yd$ ^r2hgViye~Y|%т褳Z+:zP0^6@")I$j2X(!ƐNڭdJ-.YPU@,FN4;]GB4K3ݴd;SߚWcYs5[{"=gS\6k
mwP]߾}{7N߁^8O!!8S~ck޹7:駣թzź^;۞ݸ;ܼ_+߼;K_=[=XԽ߃q*s?_>>s\ϕgA?}
xn?2^g?b`	@d00"!:H0`	dAP\,q4l!* "Q;o'.jBhhIdEeT˸0.pvr4I`8fHܡX!\<@} !DA]t$%Q1%%M2"d'SdS,%QJ[`0_x,#GԑŒ§_H>aBs
2aS`4ɄbzO1dz3RBsO0:}[ !UӞ
?O@	#4{sJ53p˅t/AFKtَ]
iR@ò;Dg@_l
'iGoJ+l*"-H	 RB0`:U{Z߼t]H9i{As5kT	#*g00Іk#
uaY*
BaҶ
V*1,hU
("F*56/Cj-^[ɖMlho;HWs$@<,Wvrq\w𭏑\nQ*{g0*~_<>e8;xIag|a{kÄ41R;Xç;0lۨ =`)[ϸ2{%DLZj4>6`GrIUD
ujP%npx3Ns\ȁL>R@
P>Ɇh#'UHlayfN6y@yOkkLȎrPQxSJ
A8Dga(@ow;ы^c4"w,0'`x<-mp)Ph]|{xȄ;1tP7
.dx'"1؜9H)6á`{@}
 pu30>0e>f4ՃTIt
ozT=p	`GoDL҅;GqLAG	CcUI
@ǼIr
0 W`!]ܝ
Hqǖ>lǭ_zP2`9U`	
	 H]!O \cD{,ǯ_DŽK!{ԇx7_u@c^q|HE39tQX^-;2}	^_L
9 GZlGTI	___>OY%De\R.>B%`1`:z_L`?Lh V@@ V^rXC
ZbHv	|>>hhhCCCRRRWWWmmmĸtttEEEaaa)))uuuqqq[[[~~~lll^^^fffzzzł(((ZZZ|||eee...\\\'''}}}QQQjjjHHHYYYVVV]]]iii&&&333ccc!,l/T@*\ȰÇTF5	 jȱǏ C"LPmœ(S\rB"cʜIG&QVC`υ$XȲѣH*`"J	JJիX-(]ÊK,ŭ9OV`[B+uK7kӔPW*ھ*Lpſ:^P}5T/g-lر\Ȥ6UZAżc:uœe]6G+@LsmyוKΝpw/+ۭ9E;ϯf~xeUy6e1t6X}7~VlP׀͡ZpՔ@UQ*Ԕ	 5X"N`s2e#8JT@x]KUc
'A(!`hbzpRE5PRTR-
XR*uYIM٘Sx(fV:UDbJehZsYQ(ނ5YꥧJ	$TdRTթNVg٭"ժQ:晲"]њVG'$Tz&֒	XZL)\[NGp96ָ>{=gE@9{
 < ["%00E5Ԉ
T8ѯLRa춬+FwJMXlyh;	Z`KG&ُ#@.hI=BOrx̴-}cD[	pEa,~TB*)bJcFKRRiBA*{@w-ZVHrC	
b$kYBE' d"-*9t$9-`S&bIϔj@eV$*-aT邙$0y9\*1=[lnC&`g#*b
( z*LTErHȫ)Z@l |,)!~pixFSٞiHP "ljQa+[*a&)Y@J^NzXW}gENSteIgP]_R;NkQڻhԪ"b}Yfd_Wxjjlc$S$-@pL9!Pu	P"jhFBivqKKb)Fl|U
lֆ2ZalD
ح"fXWQ`Mi%Mڗ2vҚ[Vk@yfO83hUeyjێ_몰-BҐHdlrm5@ZP^yJ:whyu7KaE8-Ӧ#Oh<
H]!A
%"@zw)&̈&͆aM'TxMeѵ2ZA@/[lNdTNv@Pz%cQg{{.%t;ug9kHH\c\9x%kO!%uZWN*(twwr<%xf`9
xoyA7SE@6-KSo)qߵTgt՝Y't#C,>_hg4ӓ'zaBXBYY)!/dԓ.&w啁rv8)8#e=?6"Hq*\882Fq UK(P}%FKVAqqf!ӱU|3J>#C#%WAZG/hJLd&m#8A#q'$Tx4c(XTjjQUXS;(+(+Y)%p[rLU҉H1V&X6cHC 2f`16A}DRՐus/ǣ/4&T4#2Ĩu?K`Tb%bL$1!7Ax[b)/Sj`RvSp#x%(Bs>KkD09 K2DA2u40:D")~JgS%)[2@5P=CdvGXx}Fc̳B4"&X/M@dP2t`[QJ^(#eTPE
Z4@P4NUW5R4P!mTCr*}y&mTdJT[5w;Ocڤ=w6Q5EN"`EvSUK
~r3rPE/"):0Hxq4JLq39- Ze>'V+&\5{ӎ]bL?PeXX|y,x5I'9.O 7BZ7t)Sc*w:HI빔k)y3}Zʟz$p5ICpʣ{'wbuk=g&ҧ;}Wh7#tw3¾g#	V{!֚qTgH_xh*.uц1]a~C."tXaHW1L(>NtуF|"E,q2#L8SU'(EZ"(W\=l'\i'~3[a#a{H+ubawƦrEOY,R
V*Ȗ:+E[Y׼XH&,!ILm&r-+bã?|;ؓA<Ó|~&<""1W#@Cd,/%',g3$6'0sX/W=e2>+Y61#x32'5r27xk|fE#22$1wT5+:p|H9^96K63[#8z5"{,[HgL#`R282gj.*Ȱ˅#4GS*#2
N1&Rj&<%dOu 3Ҡ)LX|/_BHKDw$?C%Ր -ZA-tTCXyI&ĢEDBtE[јw|?9]Ѥz#n7)Q&ie3CK3?ٴvm-]Z!^PTHؑdجW:@!%	'iks?ݷ+Rz=VK^?Er5ԭqTQPt>2N:T4FNV:(rt|P%&	ƊrqcI4)Qք<2b`i$N#&UyS4#QIW -kx*Vä2yN\:F43.Þ=-鋟cw	ur,V;*6cfL'Mk1|܀2
c].1\>gRTʍG%T_f;}VVՓ&X`q2
x%KR#[ji1:uzNBjqEzPe}N+=qd;L>\ddY0u&㇮3-TFAG,U&T}Hb[R&
\YV!(I#`0r9%g%JVV
W'XG'-0
uxPu)bޘySX^6j~&$=Mqrxd+N>--XjfCZg:GIANp*=cdfP^ꮶ?-9"#5_s*'^`-%sxdVhnT2cp|+B~cGsKbfw&-ĶM+D_qťG$CpOAF#=(zϸ`Z@!
(hvXs0ڃ@(qk8Z@aċ0@`)&I
$cΘ3v@	
< `Ak-@
XVJ;jb20@Scuԟ4"Hѡu;x0F%?iə5gPWIJh2uڥlpLv0ܟ]%!ej;PjVsTݰ*J*zϒLQ=iu+f'|*ȩLtJ'
3A$"
Cβ01SP%+4
TT$16SMRL]r=SV\NSs][UIXXdUvYfuYh6YS[v[n[pw %w]vu]p]j^|eK3_	``6`Vxafj"6Z'`	pxc;cCa<N
Rxd[ve[.
 yg:hrh6hVzyRijzkœk{l>W#&ㅲv~{nǦ{o;|p¯&m.|fHh#?j`0%|)s>q]rA[wuc}vkvK˃w~x7^(=~yw㓷j<z쳧}a`5@B|WS=`}}>b7CgL?~_9{U~vP 2`03`N$a
"AP)Fl+a@$A
}Cj@)aPQd:SjpSbjo2Ib7DpRb'`L[4xF8NI xGF@+#@Py.T2^NsyN}t#SENKaHLjTZ2TJPDu	H_̑d}-Jh/%Z׻دJ`.ӻ*bf%m7X@f/P	@g7GL]rvM@&(.UL֯*(\%`z	ϦL;p7,hSʻ],y<ѱVuzZXr@:$Y5<"?Hli[zCR鈍s
OP.r
$Fx)5=6ϝ7n}o)Pv5.grQt}gR@HV] C|޽b,V+?߃P+P&S3xGJ)5}?W$y:*y)(@gi̤,(ӽ,$ 9s]zk
{Jp]/%n_ĆcDB`=}g|pW{T;#Vp7^f$P~~Mn#7Lv0Dgx2
p(cᲈa堉jaC5:$jP>0	AB4	X5Kdx?DpJ<ǘCᓈIXX6tCÆjD+z9VCHdh2`IRƩ`ɰ,A8Fr
I |BElH`KKkXPļ`
K%jד!|4tFiFFTU&t6jd
"¸ܬuXAB@)B猘ts'TǷMX́`!„BX>ʐ3Oք-͇$`ð̬Ē(`B]+@VSU՚(8tU%\ST(HTBӏ
˱1[5Z01Au0Zڱ͊\ۏ5A!Ê-{ژJT;>uۣۭ`15]35=/㍷lK"_)e$#==]`Buʬ4B_\۝%K^}DZ]^282^*-h ^Հ
_
	=_^zb
___'D+^`Vê8aPP``EMǚ`#j%ޑP`qS&߁P	8aO,~ގMa Ĉ"I	bNՋv=z^%b_)')Db+cYb]"2>c6tE0bIٌĸhc<PB9<.d cv,E6dI>йpF@I?Hbva
AdEeV~님X 9)(#VcX^LI>>ONQc~`>JNe]F<˻ug+f;ja0Xf-kDpƈel>t&M̲ivgSxnŃzupgKu-ebEgA}hv;رe&ĶΔ4nhӺxP	P;,Chfǃ9n;sVvvѠе~6#f܎⮭.oP10s/y~:omv"1-B>nn&3oHnn.:pyChk[Έܾl(B\l]2׈'qeC9fK35O/q'm4RdqPrn%e	Ƣrp-&hಭeogqr:.st;%nLnPwBuR?Q/uTSOuVwOouPuXOnYuҮu['l\u^/j_uvaWhb/vw>vdfe_]nvggehO&;Wy] D2o"lt
HOp]	Tq3rᛈCh}/0e{l#KO(.ߠ?9- '5UcH4r'qF5DŽ{OHo}wL?uoMʏݪ
 O3kOQJՒaOTC
gZDhtR{S(량Ŋىi1y̘_k,h „
2l!Ĉ'Rh"ƌ7r#H$  *4)@K
i&Μ:w^$0@@Y$H02~j*֬5	@` VXdehɐj	8`ךp
<
|!*ӊu{@ɾO&@
 \VZ]
6ܺ%km.t)S M0A4`/@ L
.Az4 	XF@zQcAЀp `,Рoi!XUa`5@55@5Q$"MThZ-&Ї@TW %X
<ȀS1WsYS) }{Ĕt󝔣fjZ:`fb%*%GyUӡ7}4@4`Gzג}J)T-zBߢnZ%'
ٝf
+Uu7UaGH{|9U	TڝC;@Rl}{5."DAȫIu
tRX@`\O9j^Q!u3ywMIPj{q&hhn}ZS8/5,niT-:
K3U0-I+4M;42P1D:^XQ=rWb9գ\pJn+Uksr1J|4p|@c)os}'@O8LYp`Km:뭻:wh7:}rxm{(5f~@x@ֵ,yu5qGw
@,z銷@b1X!|\	]MI~ӬsH1&
:*tр+{eD,eHXP.(k;$rv<```CVEɋ4P{8nԕae2bcp\o=qC6 Ll䕨ӽ~pIl LqT~dS-0Y{|#S6:RHЃ8#\F%-CR^V SMU^pYt
~CB} J_~yqa}BT0UA!q9і#[cmrϫ΃=(唖3R=w]YTR+՘hjeNTȪs3ȵ2%-ڨ"*^f;	$[$	2-Yb0pEaS@V\KAR>R	U]-ӮaOL,%V$*˦*+!>+`ى,\Oj4+O	g?<MkVpF$yp!VXdMÊ33CS'g#Go=/I1	+%v,8JV?gVX?|AO~BHpʲrܑ.{t`;-#YB!>VRf
{vW-aZ8;8I6r8C@
dPG1Z*rҪ’RZ[ށx 1Y'%zkAM\Qsԥ\:ܠt[Et\Q\߉?YAp܇P'j^"h	?*uLpE?NE-yF@PKpZ]DzDLjREiDBTKZC!EMT5)2~`Kc	 g!E@fJh	lp(EIz'T|J4kTIW=˖\Ə>]%V( l܈%)D *EIDiO!Kx 0lb(N^dAѰoLY
8{ȋ[lA|kƃ"Q.!uq J=-32nb,b4=b,pc
Y@IֽKcҬCb
8b#?~.bdbO׼#[EĞp K~dlFFVOG6r6BupL"E۰HCr&ǧyy(LbP6HaykSџF譣5zxӛ"U%Fe0V@dD0Wxu4fZ[%=jHnHI>w$9Iۖ<@`2[LKJYMۧ0T|lk݄V%CP)ױ!
dj>r&-
i|IR[Lŝ0
fWҲm$YVZ*2"Z|L#r
sfڥ"
D	|XOYj-阆U!ĩgɩ\^TTtz5QKnhAXO9e}AE<@ɝLTOc#iB>jB'8`{,劺PcXVh]jH^}&ċL9$^$e}Hćڄm,iڈphJ]"@@$E~itfcuŀHKt
RD|EpXpVUTC Ē٩nU'ё(D@̠̍Fk
XH*bz|љd NDͩ.~j9$dqȭnR%
UҘ!
~\!ʮhnċĠd2y+Dfea[CJ<+U\+8jC^AGBR(Mqث.,`fgGy]c	ų)2Ȏ/J
f+B
QSX]f]#lF+%xnkZV"VZ
{Bz`K'VE"ӔGP-AOrD ^Fπ֌nԭ..ʎd0[umb<]oMd~,Y41DۚIҸ!kA	L=nW"zJԥBkA\Vk5Tnlm=nB@M\I
&I@
i	ۖ\.A]W$JפJ4iWҪ@+lIĥ|DlEx$ZFI~/TxV5@zu4I,R/Pp.e^o	L |\(0nMD/]W8\DK]F+BЖ
o
ʔR4m풡	WPbJgAOi=
/r{_0lMKtЯcfM41!jq6=MOO@yjDF81?e*M%ׄ%_#&&g{rom5ͬKd/1(
Nʞ1h.{2$[/?Ds0O3 W.
,C]<ɱ.|4ŮkNQsL`o'ss0ssH#\ޞ;k;Yu(ʙ)Zf=`ZGO(|?p((u,zX,_mŴL4M״M4"3)8E˒ImzALL=9H3@3DJtEթXxGV:KC'sDk|Da	sSׯ84,oܜcf
T t;p65&D"JgDehf@61u\S@1S)E$06[(FKT,:k	osH855ߵ
Gh%v.YOT'?ѧ?GD?	4xaBYsbD)Vx"j8ZdH#I4yeJ+YXM@KHX
Lx)gPC5ziRKFBoM( %(3:,#̯M&)K"* `
039:tHO]Oz\"+)1u`>jT噧v({m@`Gs*t
ǝt#w;U^@H,k10+Ad*&ڑ~)Sû9kފI#IK9tAOA?̐&HtI8%Q&D!^/D=¯)1^[!
XFh+\Tג)}Q(CclgF;v\Q#(>Ұ7Mc;2+yaF$6`4(*"u@v8Wć2!HWEZaaE	Л%u>]>́bgIeTPT	)Jkr%Yej$@ޔuհZ@1\I^R_:JB&xp`#E
D>Ag gL*&q?GbS
?5^Qy5(9ӡ	=SR$ZhDҙX6NQ#y^L-fL':ɤ92VhRt6:P%Χyjׄ
4$m LF|LXTtkswj(-
"|0`|
>
Z[JV(iD&%iZDJXjYlWm°!VTY@sJx'8٨dZ#@<
jI8Fp4[luScHK ޲r@ eN	蘣8\slS63| (7ջQ{ܖw"E5XV渒ҷ&Yˉ>lUT0@F0{	hawؠ.&{\'(CdUWCJ.r%
<wLjA]H޲#Hjmj_%Iqg*II)4bYd'=u
RSB$+UQG4OPX\&ud
3d+
l:Z&.٭3f.WM{gkd}L,@*EL%A[/IaDkFX"8<.5Ej{ɰlZ5S|8!5T_Cr~TўIou)Kxǥ䛬%J	N)b>bg7U]6
3Z-ܸWu-ۥDЭ?+*'ly	x5݄_ގ)k#־{\xCRo?p˞P&0$P.݂_f|ưx*n
rG
LL8N
+)5`:IUF&L@gީF4xT#,k'050fV
oLnsHuЭP%$	sJko(KY?g'Ƒq?q%^
B1Mq%QT,p?0n$`(!(
jUc pr$C2$F
ݢ&TO!?¤'
*(R(r	 (cR.2%22l6;R>^e ++,R,ǒ,J3ʡL/$RkxBLRHFG!0S0'@"ap*QB***	2+2/33S3735n7q\4ML
43'@0w7
s[dnw $#A&39:'4Q`-!K4qfʃTa(6C. ~7>+`	
)8=S2@T@o4B:MB|)_(m;7 !8+d,E_FcTFgFkFoF56.(D@ǿ @b_+s.Ն6)B[C>pNE*G访BEm8{"7.OjRn!O{s!DDi)ET/X%6קJ1\ͳx&dD4"B'РOGu7`j`K5
#)PQm#(Rvt41_2[EI(
e(b>U"HZ2Dd1O1U/"Vf5V"oML"F$@®ԪAT^@KK
L[(\_CY@"VZ/"[^IOUUUq_)b_4&(4xO'0(Lo?(c]CGCuSe;4D9AfqfUf?BoBKsg{
36hw>a5H$#G(Qjq%jqB|@'
v('$\!
 llwk_Ө_[5c-'E)֎^':6l`'``
>!j`p2 i
ki9N)msLrrBzn} swna/r'Rky( )t uWPuL̶$dD,vB$Ǘ||(Xw0xf !Ġx
 "( X
N@^@z	&{D{I{11Q3|/kqZzw;}7h@Xh!
+La
@	
Xuruk,viEbY+893-K8}=~g G4F		 
Bn8wxz8l	AX芸f#MYpk
YyjWoe}IX؋X،X؍uVp7O#Չ_cy-7 UDr'ԗq$AX-yxxE9}z[AR#qlwŖ$2%wu9}w?؊i`(`29@yḇzYff8f6PBx}.ҋ 6O!ܹ@xOឳ7qhq1W\U:^7xC 	@)G`Șx޹䙔 _Abb{MzV@@Zcå)ٜ Ҡi`!!6N	թ"j',`3Ƞ{&T	,@WK zUqE.PQ$N{d/x9_ڜeZvҠ)v_NeY0feךESbжcyva
~ޙ剺"
Q?=Wf]݈d]Hw9v0M@z! 9a\")_$
5'<0…:|qjXh;z#$ @Ф1lGAh(`"L5FXZ5iM"RL3պQR	/TБF7MIbp@C=6ZT{$4e˰@ rbŋIrD9r*[\l5'dL6qju6Z5I5}ujիYv]҄̚/?<˒7g.bt6 ,p^p8;Tl1Hۇ$9~I>|sf͛9wyE5M$@5oQM8rTRQeVZq |na$"H!aEt
h-P@@A|g
D@t@ |6dtK
$5J
dAy4A[Be}]֐939ЕBGQzmbaIZ~wlTÌ
4MP̉@*:4b\*v"D)^jA$0  @d%ݒPu8`+Y#00x>KlA$ Pվ(.}Z&뙽>;I|.^cʰA! @j|bJ_iWPEMH5FSaoR
D@Ms>t4LmZj^ITͯ,@LЮY9@	Xsa	5J=5 $Ԁ4@_]sm78wԴz&Tt	個C1{E7*y]f5hdJ!DTC0<ч 郻I@̀fTEh-j(+A!ɍc֓ősc@cpkU?4W9֔\H+-3x0ZC.-Ly\J.!ؘN

B(&mRŬvd/HS1OV;b9ouX򖀤kVQ𵀻~dc$IN`+4{c#(^̲'UCAQW"ūEL105&D
'aUC!xt	HABx<bJh#2H[`EơDW81 F&
|\lc@Z߱C^
S,|!=N;\9AqhbfĦ
@;h^A`,	XIRZ1,S:jaC欒r%`Y.e"@qvU
oeXT
inxo]lk
jq؜Eŋ"*aR'IR9Vd	:R)]ZlF"p)X;އ"zml-cK1BTlC$GPKJ	!8|đ<0D-nX8ӀɩE$ssZ8IiI%:[d2A@#
I@LYH^9G[tRQ!
\{!|s@NKr(DI@>qPaʅ(+
a3#]D*4Aik\d#xqBl4˙!<$apBh$ a	
dp"Q@xthγJ!p>
PzԤ.OOյYc(4iy92&v
{.d+{n
mh~A \[ϒ	HIȨm:ܨd5X;!H
x{|{!	=ZrWg.I8ΐq#&xJ}Y/kw=>6ؓ;yX!No|4qz\궬Afp'DB_}~gcрK}Tկk}\zIRc:4'1wS>q7!,#YO_{>9yL0jf8rcTsSlPH@ݎ=L67-pETT'U,}=uUnzWd{a1}~w}{.25]L/|%.SBB0|GɄ-LC2zq% ]DMG>.8(,GFN@+#L705=hDZxyw,vէrz"tf
02?53"S)c/̂+p6B24?6a{T83~PFՃ-!",X%G||7H!%d|!yt1:̱>",FXh=ȗ#g>kdf~t5/8\|s1W?qK-<\h}hv-GBB"Fp8
P%	@MM5xX+Tx]S$Y'ѲXG37xcyh((tbxrxf*,rDbU2{	,Q'buB+$\-q"#Q.@0Q҂ʘƌA,7ɐs#?؉[ؔ]('g `$7m#7%FQC>R-+`?2fGX(9'4"$zoRFX~RcVvחYcS	rUpWɉY9KYzq6Fir_'h)"stÒY񙢙T	eHS91Os捬)vj3+iɉmx	XyHkpK;2ygi霦	h^0G!xKG/3V uKp(>RjՀؠx9xJnɛi
?S<41~V',I/##1JOKySAE0014R6j8Ss6gO$ n"y'm@n&-[#bO:E920чK#wh4vڏ8F&WZIV*p](:|!0q=91'CUM	I?34%猠F+1^z\ziY"ke'2,u
,_34psFCww7Yz!ިYZyO/E1Բ7X/>7ۗ(Yحs@0(;몭zkZʴOBBxԙ !֊@۳WDzUh{hGwGaX݈+fQ$hR
׶8KZ 1xAz3âsK$Uc"1@!ѵTt:w{]{$FYR,Yr2O9+?'x1r\7|x,6zWU&xKwNK7yMPPBL7z|Jwx[(Hj%X8s(k4V1T+Nb諾1zB,LlLR
+35GC&YDþ$Q(8ҕ5KEӹSzM
G$80||k-J*[]_a"HSAe
QQ1
9's#ǡ֢I*1FyƂ#$FCCL4?41h@&"q5DZul,x1,ʣLʥlʧLW`K"DtiA*RzɸJ=M2Y<|SꓪԹ-"Yr3<ћtbogxO8'"V0b;bZ̹̰'?kE9h>#}ۍw1Fϻ?ތ3<7oL\K4LRܺ׬)]|!Q%ѤŸL>SQU$h|
SG^S#Tў@rC㍷y/>l8Y56
5dTYl#aNPXcS7ZF}U97(M݂$qTo2#oD5~<8B041Raڡ?.yy929IiӇ‡sCkM916`s| 3,W#,azUr51g73sӤՏFs(NNn9U>R./N/d= VoTץ
齺ȥ*H1}7.C1mөPx#Քʳ-YTq{R7vdeu+^O!WNሽ:]hzKKk]q.+6:Ty
L]wE\
Nd8>T\Fa56@t؎|9xq+;S-Enwx,#6!"ɕ~Sac5f4-ȧ@_Au/gaNYc9#7@xQk
pk֪p!
QF=~@5	x`00Z N=}Z c5?}$2ьTd՚RiU0i֭bI3#LkTɢRǂTZ۷qY޵}96WqȠC+FرU$h#[Hװ.>
Ԇ2suhsFMqFcϦ90]wda9ކLW)h<8܀BtZ#`/oHMqy=;ξ'op"'B*L&Vҏ")"jnx
̪-r&>dL:AOh8
XE7rN,l:A*x4;@d3.(qGJ'J` 0@"q)<#|$s,C@%-.)
KӋDl7H9lULKCMQ4Iq0I3l!B:<Қ 3U,&>sBT`Kh聺z5h\{SvWd-kVk JxӎдK7|"v
]Emm6|?ȶQ׀ز.[waYg3`Tx(تR?4>+ ^+[^M/dx(8㕸 
&{[:e"@ǹꋭت 0T+1T,Z|;'Q532h4:̐S)s+egmKZ p}%Ԣsl:A|͢쾚K+f'-|GodWb&.='5$Qqo!K`0Z`C4eg%aiv!YBfcEFx^ĉgosz`R02V 9k<3\R5iIKMd2rkgGIKnvIuEc\'u!xDIӥiA+&37k	x6nsEgye3)Zɭ	dd/B+_,s.;nK򪴹(g۸%DًDBHZɴeE-a^-x˜$&/F;Qٮp˾m$b"NӍ8L^O
ʚTD	zCdڂ8Ok
ZGz;t@DyV36:?+K,%	x9'+ShՁf9,"pv_*$vRBEd;c] FD0:/Otl_x#slbd*kV,խ2L0J[wat˯Qs$K(+2	sg>t=hBYq!Xf49.5o}h \:HuE=jRԧFuUjVe8[㖑-QQ8[oe`1/Plf7φv=mjWR=߿-SjTJΑPf
VH%
nh(66
Yx>p';$ٶIkTˤۓl0ܙMot})ۄ.CN(H+߭JRI\ܫ{kb8As>x5Y{3I`…7 '9M4X5*"໴'$֐&zko{jgv{KY|@Kn
vR9-gv|ْ|*}!Dcƫ=WY#354D*>ӌ'ao~.3?}'[F=W@tiv5)mOQO9k/{I7y-
 Ya7S>Ґ0z@|
	"88)5_"AkxC#@p?
 	/	?LYBQjڛ#AB"	D7.!C?S "1Zb6lY15D.[cb8bBܕ(.#BB,:B0x@Ý0	E(C[
c5A#9j +E9s]@sQ	6iJ+FM,	H
1FFpJ$Y2~p@E-57xE#aڨ&T$Vi-ZˈUxZȁp@V	`HiA+.8 ɢaGϻb`Kv9**h{J{AuiB;5-|R%|	\ͳ	
'-~ *psK}i׾}Wlʵ@Mt&
PY Iu^^.B^t4	=2z!G~90[(dDɔ+15ċ_RYڥ:=n]h}i݉$4!;!ٓ?
j_p8)::qAar$7YF.Z'=&-DQ"^F̒+*
3.eæː*~a{҅ZGt\UO'-mXq8.ju#G&BY+ !-D,fXlE7۞`mǢ#I"H(ZX*@bx"]$`p	8aS婸On*C)-fdNOD)C|3f0	c\IL\'$<008b+anKO]qSxO\gULh#Y)ݱ]8Yg{h
#K֔~
?]aDD5[!@;NLnU||V8JuXeghB,w
%2l2]HZ(2F5Jm3Yծhp!+c:3BФd$~d0^4+Йh"jΈ
P܃8tjCI(.lݲGRSG5ß•"$@̌&lR	toakEdaIpIŞh}f2+QQbԧ8"ͮdwAYɓn4ƭ8R .5N`@3ЕoBbLL٨u\T
~,%i
 H*
c9Zl5"!3bx8_.y5šM1L6ǥ,]ډo?iߊL(]Y ~%BL3^X%bf	&L84&K_-Zξr+FT:0j %bVL6mo0yEoy:Fފ>T"	mTBZ1MZ6ߞ :aU	īSjkGɫa:2n{VoǦ\`w}GyźHj%Rߜu-
RYoqrZYI L
׸XAא[PکZsloI:梾ِRJ$v=_)6yЀyب+߸3 qBYmkmvuysԒCƏaW
,>䢪x׷=1?MܪP,$7L'k=ԎEG׌2t@;_k
6o)|{o&JXyKstyto;Q?ԧTikڿ
/KLkyoh-371t"Lk372zgsk&f`
4p4Xq$ɒ&OjPm%I#N" !52cM	&]*Ua5Sbͪu+׮J|x5O%ɖ)ТQ&xiv@Zkεl*Y|4i[jӧo'{y3R"W@  l=[
_M A >yXHr:Pc;={y֯cϮ};޿/~$Aj;zz?-vW@yW>\e5\X"2ؠBR(t=}^mD͇J}X"Q"]ёUՐ3X1xzY*V?Y"E"Y#JIBRMX=nF	Y$*X=9QRy^Wke}syֹFmn&zFV'{ʙןy`"`*2`:@(0Y%qL%EB	`

H`5P`Z i^i	`
!`"ƞqI
	z
(@jrazaaa!\ܴ-VҕGHR,	DT

-
Fa*bRN NX1@F 	5f"#֡#n
*.nFNVO9PX)]B^n^zXYX"@QE]dAC,O8YvpWH('X&ea*X&hf]fLbiN__ʩ&i^Zb[pQTpjATnEF4T49.g&u9'$ܑc6㦦İxk>*)iC>nA+o\X(HJ:k?kesfM-H֠@,K##a齆]VʾJ҉Pn$VRGb5ΛBOQ峀UcXlnR'MZZhDl4M!DiBEhÄJX B'*(+j%&eVаhVc&vC}f+ꂈIhh)%*詬l0'Y k|Dj x_n>H!&Tv
vn(Ɣ1Hn\ҪVH.Y$֧a|DM,@Z|MTAD/dum8%5\%M>l8Mn
D
j)/b*mz(<2oٰ-$=!.E&i.kPmL!	Iq;HO&]j16qICYbSf>qnwb	qj
1W[r!
p$21jTzz1&	OOb잊rI))P
WlI*,p )r^rahw*23s3;3Cs4K4Ss5[5cs6J6{7wR695km:33\\,>s??t@?H,sKrB+BCXt$#4CStE[84D4LE{Gsd|lvtHtJ{TKt JKNTβIDi`@#ī+t
nF2A"yQi?` \5paNfDfFw-D ec/LO6$xdZ`$UߨKTX<`Q
Mʨ|D@>^kmG|`,]PDFť/89|K3Ubm(P@d.MU;qBdď<݅陧7L;GSSSc:EC:y5S6OEex#uyvwx'K6z@{{s<"D_KS{_Xks{{{{g(@{Y{{{3kE{|+3|;||V[<"ks|{GWTɣ|ʫ|||GW[ыE*^+L߯?G=I'GG;vXOzc{iʰ#=S)%/ٗݫlCG}ݻ۷=>}A~
=p>5
~'/~?X'H'O_>1cS|.J~:XXpW>~-4ҏ=T?GO
]tgo}??'ڼѧ?@X8`A&TxZ!F8bE1f(@j49dIV{xeK)W9 L7qy#Bv:TMG[ERO
ypWbtG]n;,DP ,l۬bb\w>"!	x`&
V	>Xj$ڮvxk#>.)*oP3uw-\p[@{~|XG<U#@B
Aj`›2
H*jMî..EV@U=@
D`bU xd;+М5M?
Z*uS܆H@hwXb9v^l>.Rdݛb~LcrhR
`=o~2}1T8ꡮ!@UFJP
L`b8`e~hq:dXJ8lx [ְm9N	;!N	X<\'ϏH!<LN!09nMtkUwiNn3SǐNA+w/i"$0B|XĭF&ռ"|	lq_[Xo
Zv@Cp&4оOAxe.ȭYhà[>+%
d	#Bݐo{]J^h`| <蒪"]$pM"”0 X
SC=vlDPE%ECQSAZ!r&p"F?f%؏޳\/F(1R[LB0)L2!x$ L9`N: IG &%iM$R~c+?jˀ5k7S"Հcu˂z̴)BiIs]հTȿBVhS^uc!+*,,e)/&/Z䩢5mfY՞,k-^Zf7c;[݊*-~[Я-.l;\wL.n\6)n;]嶾n箻]~..A@kuf["^$ݵ|R_1c5_*TQeӠ@M.Sw`[cr1|sk8$ͭ3Sg'4rCL̊F0U#I-)t&L[>LʒO/F3\id@$h%PYڽLIVڮy-^_S&]me
P{U/үN~@AdTgLو.mƩ"ΊǺ6ǫ36-ǒy^F:Y	D6v9$rJ5M:p!d=|_\mdn[&M
(w6_l	nq/]	43saV
(
j]{VC="Qsw>֜G#CdYœ刴Q]%SkyۻS3<"B:9|V;#~B}p>PSo@GHKXI	!
N/0*!cK"4p'+٠x*O/ oOBz*¯SK1Bq
fPh'uPX*| 0y0	F!J8H`  %[	#\VeMU	0θ#0BZp!l
pnU
SBAG
;c	1NnCPo71IO<@-sWk°	aPUG&&lQFB1QZl+q1"+1Q,rIFIr.k!@!@Cq r͕>!C"˱"M2$M$Q2%Ur%YҴ
CPR"$! #0%}$I'2P$)"m/)r)Rv2!li4:*
xj"oBJ!+)r,(E*-r-ٲ--2.)B 2UF	ger0	0
ӧ,CZj.)b{L$() 'K!DQ>>J<311j444Q"Ts# lS3Dm6cs"f󝪡6o \`8Eb\@54%x7S"S"|foB7%bB=/B=C53p >>C
>
V	>`a><#"EB."GP 
 ,:A!DA3b;};!;#=a:.,=CK@$s>	??U>T?G]
FS 	~ @?@	3@9S:`I@9s>IPt!HT ȓ"
L !	MaLLմ"044tCW ~~@ZI
v W?@`?WWYWmTG{WYW~	tDb rAU !TUa\V5Uqr 
9PbPBzOT!8"ڧ4Dڇ b^1da>(
`]!Jc_-Q͔ @b4=uS=@2!~cYN%BPC"7]>3FXZ Y

B@	jjai[9:lYi6'$R=$Nbkv?@_}V ,f^Ov `n@giN`t=-JE I P(‡tfd$bJ>4n`%Nu=eg?FG L7xQwgՏڣnchghk>I?	T@@XW`XT l@96lizW@hX(wp2thL
 p_x׀v`E ~' =;+!v!LsRITM`܇g-C/4/BgJehDM=oAEV	`?uk`?և?Bԇ|VW	Fjl5Ui?#^p s_RsC%=͘^ B fyD$ (7bwcctvY /Vpo^viv SpRW-1Mő#xK%' t?WV??`k ?:x@uU|@n?a`۠hW\	DFY $#m8Y$DOAgBՎUwcWI ~N8C 9!=daKH$Wb@?L=HV0:sf'|DtzU=sY8B>tKqT?lgXB>W:t:U9`\iwԦ}8K>Uwõ"D.4bބ?Vf-sd^
C
HRv
G~g!`4.4DAZ=RyG8NsY|ڐ8t6.`z4IE:'b4ewe @8N]3
tI B]W%"­W"`%4. `VBtXX@~AG=}w- pWB`h4`/&+[#N᳕f;Yⵋ	?_9~c!\B;'̳L)$[+LqTBCy!:\":DfL"y"]=P=,$=`X~\Pa1Nh8>D<Bӵad+#Ud+"TK?rc)`KvnNw8[YƩ0oi-6g
o`4N?׫'#XeD}ׄyIYKCEvkډGb:GpLCK=˽_՝ D{/~]?Wf9iʙؓbILWɵ_)|׽  ޑ39!+:]w_RHz\5o?Y^c>NZb
 BC[eY4%{\MY{;(~%C/3U[)M^W;U9٧kR577Ԇ=Lz{/]~"t3I39^"s>L^;нr"_J7:`_]V15ߺ?OL^N\&cue%k[E"]#%_C @5kT3xJ$!|`@j
XkE
$ȰCJ|pk0Ay080ѣGETҧPJJjB$hЬ4Z0Ȟ?כq-Z͜]J)jLZ]̸ǐ#KL$ @ nB 
@ޙ`p300VfZ`{sg.	 x`_+`7w`PNkߎT,(mmd	`]ÖMFϣ\xk	Gq \!wF(VHe	5HuAb
`A^sZw0n5.l&IᦣDCaVuMYdcud1D<"nHF#T8VkQ>c]2$9@f޹@{4oCxk[^'E)V	`$Jm8E2@shpq[o:ZR:,r:&E),$4'0&zA?4ylgPB[Ys|AI5e$UsܜΧzftGjlvh8Uָ5'ߙrb7*)}X8gFO
@amzgA墒Fʞzvin⛫EdaC!X6g^A">F5;/p{hf;·~176SH׿aUcL@	lKi?fU+\7A
%OD "*>x&*TaTj8֩PFX
3I9H֌NN
W*Z1\gR4EqِU$ ڒYhW0`WL
h)xa=2yH.	H6RI4	iN
B,2V[E
**HZ^X&Us|eT(Z0fKXa\EZ6 7mZɣ4XxX43%H@l \
BYDʚfh7\-IOŬ@&zn6y&<"Wn$e񬕐N"7Q|5D.:pKGze!
;qxB# JW*R"!@"(HS<N9V
EHƢOYMx,ݍiMMEGAJqJո ¼RWq΄T5q\:2,hU[bd3ޔ85\q倒(kٜdRL=DIũ=JfpsTmVB@ЌVSFJY>vr-od- CGxL8׈ĈCI"ͅ5vi&JUJ^d/)qQfT7x͍5n,!:;Yl̀'X_	~~{X2jS\
/
!;0=;O6J(x8@V̘1%?tD-7ʌIOcDL2hN6gmLg9D|Dhjkkru>"
Dhk)h>9+ҲCf6֜3N2i{‹X05pD110f@@ɗ|(2L!]Cd0[ϣX̅u g-FC+Q
Sdꀜ

"ٷ/qbT/63
`$n`c
Q
.gȣ3G31l'a?w `Jɕ0x%6吣5R̥.a7$R\#"F'ݨIQTD-3L0Ǵb2!l.q̝7pn4,9SNspk	Oɳ|sF?oAЄfkCcQIt.Qhtyc>5IB!ZZ|f*y#ԣ~/H*4~.:-0*XQ@G0uNMqG$`Cpt
#ۨs~:
ux9UT8dr*ƫ4-[0X$׻&;T=PJYf&b,/ՓƎO
6\F
TQUgOyÀKWeI+^VEEwZm~(WAVQYQ0=..%$@)d	MEķgjR3Oa 0#j]Go+}DTYԃ|Cs-_%ȯճ9d$D
Sδ-V.Ki" Bu-xT
@Ưu4/u۰jQLiZaDJw!;{yS$o
0=[:4ܣ8cjB5]*XϧWd7WS)-%S:7Qp.K̞jhԯ	mP)Mw0m5$"03gBLW=>2@[Abf	Bt	P.Mk@T_0uB^Gs*YWk|//1<h4js"2NU.5|:gf)"204x:5xl#LOu}">r!n#̤2;5pBYB1K?VjW³ڀUQL{_ר	ǠYE:.
#bBsh_W➺snS(I3'&+cW[luU*t`]|+j
|?dg4ȇ=rLӫE:W\F3BzHf#5'!5XV)b^2n35_O΃|]A`H)u^^"aV0W%)iU	b6g!K%@_dKb=\=bo[A7ӆahZZ~Rr?(5 +pj(	CF8F,8`+0Y 3Wf!cWka}(bXd5jEv	88ǃ5.shU9"mW	:/SU3Nb#ffHxLpLe^~vS_t h_kS"`q)Hgc$'4*TTJekƋHUfZNOh&gE_Vx!^(EfU$&gir:Tm8ci^6m玸(bja (? k"Wh!j /
َ'CMH*TorZ6n0gU6WrقdaۦK>@aUxئmZo%&k
nH')?5b!|b(Lo"(VPS@R"\[3/qHss5%6''$96r1
uAeuܕtt:W/;Cu2#SW45;tX(8rF;JW0>#7W qv)y
ŃaG)pgiO)yA30h
vfUƹvat"w;"Qpr	y3VP4pjYV	R0&pXkQU$|u~%`~pXS4sU	v|#UՑ{7}Yv|]1{E"ķ$w[7VõXPyU_Cx``$p(+$R\_E%7{"w#5m<:#\_ULr#(/pDXP+ْzxi(&i 2UHœPg0[pj#Wǒ>
fUd*	bTKHQ_yyff5a.xmp0b<dH+j7#xgJEي3U^zNw6l)Rk(ʜHs0I֦g&j*<
xW'Tezos[)%!i}.CTܕd>	(媔JFmoV).rqnu'n[1[)R2jtUSq	ACEvGQQvS蹞
DGʜ*@4റDdgZgm{x*.ى\j;S?;A+J+`1P0[jWWW~W9YEiZY\"~g#}ֲ[/ZZ'1`҃L"*_q]K6`emA"]n_KT>X5SE+lZH"\ŷ,][|ò	e+S`H[P55qΛc	p+5q%*RSxZŬ\؎-\b$	$csx#
.:I"9څ(zi%	m(<8Y=d.0໨&xfxw:\G:FeV{){efjLHF-DeOgH@
!ғ(ZQxr
4:d^\iHsjfv{ۚ!+•2,L5{4jVKF%gʈ*i󫉘4.JIH"!5@+R+fh
nR#)\mTFQzg&plBPn%ж%<41fE92|%AT25HS,{;./'a27rIt,W)i!RT#yYr3~fuu1(acW R]wZL0tm49GHe[2eK%)˘*D/ԗAɴ
ՎQCr[*a\^]hV.ԑxUZ#i=FX广/B(~:ʹ⡭ոXM៬}}-uքQ-¦zV:B['%3|RfZՔmaAV)TuڝgURA"&ywʻ4{[ƹ
vhf8g8:ehzܸ\*w^i,=tgɚޞ-)Jx)Ҍcpln{`F2`U8`Yo'gVAewy=—)T
)Lǎ.	 ..Z9r+af{aweRzUG?U}Lah
fEkVKn>&oo;`
0j]mZ$ϵS3$yyjsALƢGR;\O
[ʄ?3˽,]TQuZ +k!܅	ԹsYi1Ҏ=->g#[%$5҈/@h4x1zFHe0
T٢)b-`,D)nZ~L=Im"&*by-=JNQ^b@evEzF
i2F9Z©9V80t9!jgpNR!)9vBKjw/0$88x@x$|88X2X|#
Xi~l5>}FxH`+0B|q4Ԡ`#~,TC0Kg:	,v~@	Rd
ЈS 3m(Z	7h
4p"h0nulSM74W%;@F!
ukslKw-,Y`fnm`m|Xh4 MQ[v@[f
A[AE/:"\%4!i8˓M=׉ƻŀ\1wK1(tpЀ gEǹ@6 BCWg2f=K!/W!v?U)^(RJA.S$ڎ"lPkppk	qcjDjD!!=@P"+$,Lj@Ԡ2[O:\^S|F<@W)/SP` w9u948rh^j*C{xKLYpe(DqmlUcX
DA	!BX2]%F0
{5+	~ybqND҂D7	3
Vc9I<År˟bF]c\]䄐90
9r[=+]/"&&
S(d<_v54!bx2b2NpG1Ι
nfHJGӴvV2knjJ
'R"bPEI5k,e`Le`X]<)Y$n"5  ͬ|gKȅ
)V7D[r:0
t@"
Lʕ2
`$,v4a`0]iZZ`H.,| 7Ѐ(0fBxI&/9HɏUq0PP[&0G9PxM2ID&#	(D>BߍqPzP6(w ؝@|_K.%bc<`璌X!ء
dp]f4Xa!䓙K%X
KA%ppNNG${ͲXU
yV':DٸI©_^d͇1V@>įqQu+5gO&rl;0MXR:=j>CT.4^\Ƞ:>5qT!HRҲ @	r^N`<`_Tw~}e~@>^F-A.NKNۖE[fCUAD’߆zliX`Ye
(g$buro9>_x=yK7O؎&9"4Q״Lޭ&3\"@OaMB>3c/cPuy?" u,U8/˓x*RWMTNt8+L4KWޟۀM_`/hWh@]sM]*q\WvU_|pr5WVA	AƋU\PWp`t}VEhp!i}u `ށ
ʔ*WᗓUalEpfYh:BpZ}llaQ~I@rq\@I	"R~Jp%Q%aq|Wva2b*r#~
Ijudy!l,XDY1Wqw׶}*b2rpMq@a jT4Z5b\L!P!)*:+"###c<:<.b=#

rF~Y5z22#lI4(@Ɓ>&$,`r~Q(CbDd#.]pڀ؁GR@Id䶁z8N(N2eE~Jnbe|8vVrD29e@%%s	UV^huN~%I|Iܕu~Wҽ%ׅ	cwա#F$[Ic:ZddRfYaff
fS2Rzf<&(ujmA&&%(MB#QZ,qadui$RZwf^,f]f^bV&'QfkkNB
dMrQA^"VZ$!s9'ttwe@kyfOvU0~kMu'}"$(فVU!iQ@~fYZgJ((#xi@'~"FaXY%hQ'
h"ƹdvh^.N/"ŗ`|b~zNF2b¤bV"la8R,ZZ9ztj!`?&
& T!$A *"(*NbLܣ>gؤfhft@zjjӀi6a+v*fߊj*^*i*9+^
+k+9
+-+E氒Fk4kQZzMͶrff븒ktR湢kzck+ī+ի+kevej&S
g"lI2l:,B!eINlNdĖi*ArlzcȊRlZlc־~Ze,ģl͒l2llʖ'!lih*lTPRӦMZ@+z
E$E\D-90Ƌ8Ţlaj-@-FF)`d݁ܗ!6Dm7P=9!"mX@@nO^M	"#	 >BH!PNb!n#!^8*^a&IKgU*cn˜ahvA|$D:.;ij/0p/ܮo8n8
XPXIoz7 zk9J`!^sQeޤnX$eH
Ƈbf@gkoҤkM .H
ajҧ4vMjv!h_}@{2}H/GgP+aqV+CR񇡈/!{!/J|rkq͎ji&ky'{rs(g
'; *	+r,;]R&){'sy,s03'WrjϘj2(v9]4K3eQ3(oϪ֩0es+K2(r993
r0Kr12qk5K9r0po1OV5Wr23.O/[2
:G"1ȲNVW7'p?:82OSC42>8
HL$KWMRIbq	+8=@
1UQWAq5 3EnoҴWJk.!
w%n.NZ5xNR'lzo:]CoiȲs]rV@,`H_RZ;vbtlFk̩݆fg:igBk`DƭjMR`FD	FlqA@IESJG,d!vr 'GM@L:8ĭV\
dX
KEP>N8=nۭ-@Ӡ9n}
p?@|N@lXdXjbD$
Yfx7d
\l$]$$݃-DF@$8hHwB؆
}XFy鸉y?nO\Ddh$lGaS&CdZ.k݇
E#w'-{pwRZSaPMxO|FP#?9xnJjv|y|!Nx77{z[PF{ݶm?ckùv爂s:C	t@uoAZtzy>xOZ
@gԃa0M "}ÌoHTحU=$wJ
;z'g4@۶P˺D1'xyv?H$mCdD?n[ƌ8sW4S@źAbӏnHqKx4AMLJ@EճNW	fz_8'ö(|Ld}[~D{iS!Bٽ.<> _TG'n@ʷK-/KAC~$~`rd}WjJpouW򾒰IB t,83Lw|
tGLgA|D5ͮiftGN|H~L׶	^A#`s@C 0I*|c1<m2(05(ŴpW$D0HIY)g)$ph6Ĵ	)XdG08z3KkY%{4
g*=M]mlzl4(J
=O_/
P,NҺE̱0\kq+Zx|0w)tЅ,p |/B|#pۀ	5h	>\
P{	!Luwrv+~@uq1`$:DWD9y]tВXi-!G!B$v[P6pwz)_@~zu=.(y
l~jyF񀖓q	At^Fjjb
	D!ުC
@h !K^P+$ѣh'lq۱A
@$	Va|(&r>k.qZ0h)t2ImewG
z{=;=*<@ꒂF(oޚ?W7Ȕ/,8?0MA
.jݙжCqFZmwَ,mn7Flj[RV$0
"{=6ݡú{;D@IIFAN9"{;ӜPi &
&
zTzUR>5Reے	#,6OBrCfm0&P	@A`u|@" pd#@]qfx!pRj=;,agVԁ"p`z*P\I	x}(=Fݪu_)S8Ae'0
pA.P
=֯n" "znu@Q~uy6IdCՒt?THLd`>@$ ׀ &@|~@`u'up@upyFA&6p@q;[0q&K'a&gT,Bfe0NNu `xW{Y7vG|W{Pcwy{ZywA@`A'B$j*Af Q=9#Ej1r5{Χr@}BxvhvXP8B_iXcRpn{_G7{hׄ<{A-`u
` 8qsQ"u@W@w@|`ox
|(^46@6le  vN(*grXPx-pf2nwCZc1kFRHT/Lv~42C$ԥ3 I t@Fr"UI.""2څI4t^d)b|donPpAm
pSwPipNz4'BB^P$,qI`5Z's'b4Urqy(CM#Nr$d֔a`	>"q%% 'P#fqSIPہpC)W{5x/Amr,B+s/)Ypp)P]ơs: !Tb7zc?2Yu\GgPC2@\22Jy3R;8יEGe0Vo!1D(|'2Rx2 w},VD!Fv3"Xrq^uv_
]1ӹ30w7mq'y7>yWfc"Ub
Gh&0JB6#SgyVG
{0"r9vIyr؎)&x1[e4
5"E^z~`9>Q/TC6;Gn
-$@2vu\0=[[2K8[yⶆ3pyP7|׎GRg
`x|[E7 T|PwBJaı(``'#3%&ۗ}-6r3ǩz8a~!`dYY1TjqCs1f}g U	6Ȁx؀8v4wrr=}/)H@Cw834*r<#;rsց{%K%<#D:b:)Ngۍ☮ވxȎ؏wȎK1@w
vSQ6`sicDQ|29۪99nH4/iDFC!2bnJbLžWѡkRy[%wٕ0q8q^"7UBs2cyeonV4)WNpqTrIe0P U	Od-h%IJ*B7֟ds0V)S-Bhq2F$"!̟=fL8{y9uM:0SF6"|Gfb	341کJJfwjҜ!\ Ӓq̐5HL<1x-sh$J)#ll{2zvK!G|œ|H	!Kj
,biЧ`%)мL6qe٥"nʧ{Q7#{upZF0(<7C9}S\PG3|58~"RMYl8cԲ<0juՈJJ`8~8{ＨO=s;Da"{Am</Aǹ@·-ur7:~P_dN1&k㷋LQ;im+e@?eHSHA;#έmxRBݤ=;shu{
1{n|`[u0J{(Y*M{۳\x5kxMO;XH48Ub|X(Np1
,0
Npq\un&WN>.ٖ"iL]n "ɓ5$CR.P2jd_
KSywMNNMt(2)+̙	<6DW,o +ɉȩȦlʉq>ht08=^c$\RS#fv+j731WVٱH)h(n@4c:31)bA28:i竪E8]
P}2R-`^@gdyÒfC5{.Oj;AQIϮryA~i2汵]|ݹ6݉^qn]<>4/OO%؆/!`A[opol0]Q_Fo
m_ xW'+ۺ/3	4;?0#hK2'4#JVr+3:.-Ӆ:~~ݟޠ!Y ac"d_$&]&Z稩Yjek,-"l,n-oSqYrr34s3u6Ͷ^xyU9u:{z{
96}~~J?HKHp!vBnaܧq㷎>&ɒNK2y._6	o&d69l'>M't订"Ӧ*oVm+Q^
i,f7v+{f/;O
p%x0`]fa_qx7LHS3CƔ-Dd\!	=x@u xpA0\}@ܠ.	 8i(&
٢Uygqh))5 f২NY6zɮ*l,RHZ,^DOj{(	Z{.骻AjK殜zKG;PKvOEEPK+AOEBPS/img/strep062.gif`sGIF89a????߀@@@///___oooOOO999𫫫JJJ```ࠠ000   


PPPppp񥥥;;;+++wwwYYYhhhקǷ:::rrrGGG>>>uuu!,?F)&	!E% Ň
ή# "
֢uskV
)\ȰÇ3ـ&C_
\S\ɲKIR,k/0AD0ѣH**V h	>%.Cկ`Êm)VH00!x;E@(亮>l-ǐ#'qT%kb0!@xLs>phV	Os&Ͼ=)	~u8(Ͽ6/T4cpzv!$AaSPlX,b0Ԗ"3(4 Dv	X9JKFD@L	8b%__@@YcQYlP&igUHy9gc{REP!B"0ؐfNE[p$`rK!
JL
p#*D#|jjl/:kk$)Hjĩ`
z,;j6y6hDEjі qD409/[4Px8Tzm"˦<ધ5H	
Q1bb.˸.J;;|n#A7q F˫
Gz^+ؐ3)؞?PDeh@XNJI,aނզ ⲟE+fJ3
@ʅu!LVƈO_ZX>50u}0QWJ%Lp"1h-)BlsV׊EnuOf]EƇi_?x4c,Є};lQ\R|\Lx!)*[K!!S/I"`Q	eD~ULXvhU\'IUYac$gi-|I7^	KGɒi_"p$A2Ӓo>RhFCQVf6SPS@"MБi'F6'Ovi?0:6fiC{:#"Mvr䐭`ŎW
b((SPbKNjJss"h=KQxF+ZEpKudtKRpҖ4ԄF4n*'CtXwp&黇(JN}3S44RL{<59ƾ*XQ +K=ˑr+ǣ|.Bl$\Ā>I@IbTަFL0İb{BLmD)X	xWp܎+%FwM}DK6Fu]uqPaH(BRy	ALjftL77J%YLؼwH&D}u~|)…|fcaľ= So-M
}l]C`NI	*h2'>fcULdF@9%M6ñXr$-=	xMH,%H)]~ė!1zJRjx%Z'+1hB?ЍVD- LϞ̣@^3LL -3YԲL=['y>!RqZ
Pkb+|栰fmY_@;6& \g$l[f5QB0b
t{wk=z1<\n4|;Νy'I"*\%+hIw1qSng &F9('N/`#'G@2Ɣ]o^	Xї\)j_@h^͙T!mpaZ]vsyKNvݘI5
wwݰ]6oGv'KfO!z~)=DOowN˾-?n^,gIhKWTUlI̎+ɯUTKUE}FY
?Gɜm!OtdCa
4LCTqB9DY}H		 $Cْ p1􏑣44i	
PFܨc%yCPI`ViU 
[Y	]ie<`Vri$kYgma/z,2XMP)7'a>
i		I	òE6`'O,

LՎ`VVLȂ?-(hiO C1.F29b}or%恟睑	H8Ej۩	֠pƇZj#	:
#:qR5-1jRR`T7h|Jy1FJLڤN`GV01E2%o1,!5ؑ&JzFnp
)r>YWz
2Ȃ8PBZjڀF[ON]t	+/p
@~=C?4-ܩZ)--9px2h'JZ0J5[h䂀`P*LqڬwR3c0O$XD+ӑ+]hZFhɊ* r#]4I)~7hZpOXJ*HF)sc۪ڢ@d
64ZרHQ`2ұT[6${Cj`Gwj0+o Я8*{	Ѡw0s`vIK<	*~0DbbJTq0w 7llVdX*Ѵ`E!2>p"l.Z.$oX8%KJ"z]Qs~7P`#kQ#qKesKK+TpW5$@ F5룱cKFỻa)3IDU>9]2TJЫW+L۹`(3<4B{-e+ׄiaY:{ˬ,ʠҊp<
*B6H6}sM'$`~9 +ZP&~(*,'Pr*^4 
?C}9~]pF~HJLNG.1R1u|^ۈھ7Z\\jꚽVg~\iv~G-,
2•O^~L.<~+o^}u7ѻX{xi
j~Bɻ\9f^}w/;[轅ꏡ96%1'!dD-Bndg(
׷Br|AOehWLk@..epNN7}.N&g︇r
u}o
w͹Q
>yʞ/p|%o'خ+O-n/!?3N71/;/5m?_)OCE/lGϨ9#OyOAK=LWr*?	A^_M	4Pm
l'%V,A8X$"xJ!h""dZt'-Ƙ"M)cNq7HS	
y1eBF4ydo)ɤ=X$MV%Bb0˜!~	9#!D馆j	 /& YS*
74pߡtR"AFE`B
jS@* $ZD	Z9*dS<`\	Ay*Pjl(*\> q%~blGE<`踊0pVZ~ʪ‘R@Ep nb;`P
L	|~j-8RwJGZD8(XEL2*#&;B2 Ǚ=t46	K
s	gN-c7zͪ(u2PfZ}vhB	8+0[c6%PFV
H@rC.f	|0]$9	BޢwIp@	Y=V@]!p-p:5H$]	8BWJ}nBW0Sv$#@'͉~Epˠ7Av 9W&8U0ap%4	s&b>b("FL萨&Nb(*ZVbѦ.
^(2bfL#Ш6zn(:^vG9z@ I2Mxy:B:rTaHL4_6&" o-r8ʼ	׳z
~x@к1]`"=$ahJYz`x]B|]٥w0`ߘIO[2Y.LΒKr1@hL&Ѐ"!;æN4R0U$bG:Ϡ$I *g`4$L~\%iGQ.zQִ)*PbQF$RAJ"=({<ϨrjWÀ	.cUHSMuƘr}Jf; TJDmkd	@IFp
ne8ñ%!	
;%ucZV
IJml75H]t49@ՐZ`[0W71`/#=PKeEe=YT3nA3Ӻm1جa쾌bXJ 4pȗHk-w9v}K#Y$̶Rv+3Սpo󁬩kjRc^X`\V@ЬK0.d]	00
%3_2{L3zenx`ΡOx TU✉u%pN"2WLRh.5?67&X~ȻҦL\Vx&< t˪-h'߸I 6:1U<}I
-V0 rT6&$Di^m酨3^aD
<_9¯9]uA\|㵚Eրuco/EM#1bq`qpZes#D.6yhGR)2-EEiG/<`8<#fbzA8":j@e"9vhLҫ
R"!_,jAg":#DǀexE |"m/{1[r
7
}u3(Diw6Bz({EP!h/h19u73*b1H#  
`yp)5zc'Tq7T|v}VW&w2AӒta6018tr=E8v}\8D2FnXRrwF1S(UXXyM7gAfua̢M0S5p8{x)% <8:׈zx	#0|W~Z"=)bB>Gχ{P׋ȉF@,|:"qȇ~:hyE ؇~Xh@pP&<'*.,S7VqÄ`GHhSЖ#"xx~6~1- P#z7~x
PXU.LPDxX'zXwЏC! *!&sfn:8r"(1B(z*0.Y``q?0vOhwiEe_WĐZY8v$A$# ء#ה}4ո
"h9:b){
	AިTg"q!@۳5Ƙ/xg)9$1Us_99ڀv!179}ptsQfAKst-Qsv!F~sa_9I>aW	:i&ш;8{W}':z	[HQ'Fxq{	a&8Fy2'8z&
o'xfW9=y=ZgZX+|O.j&~8]PV3O"B<ZQF|#}1i 	H28[
.~wg#{Bd*
ʅ@˙&-f̭}W
[̺yTv	L	ۺsd9ѭih.f[BLewL	ͩ/L2A5̦Lper/-rfόΗ ܦ!0Bϸʘ@WͲaГыіa
0Wd[Ab*`ɠd9^3usc ӊ@ӕ`ӗ%Ԝr]]Ҡ@bn2.;M-zģ*a
^SY,З :`m$b6n}
NCR]-[	C*p,=	,
{5H&=/mȵ$1ؕؕ-4P[D
62^׽(T*5M[uCڼحZ&PSu\}PM		E7|]E@[S[}ھ\6S 5~-]	m=	
m6ZRY5]UwjWnw@ѐޅ+5Mݱό։U&[c*?6߰@@*68ZĀ!#\5:Z.$88
R:SLSu=X07Ap*?o[;nL9xyqn>u!=MTc!LAS~`	\Mq}t
EG!]yBD~oG_Dz&uL}rRAZ$qDOaYAHAPn '2o <P:o톰\2)K#ۘKqGb
4O3}/ mG˥Y920O	K38'*,{}Q&9>??na
r+NOJ!31֙QIn7}(`8KSѿS^a\ČnMOz"䳕@kq!刚g+܉Of+2{j_O	և[LNwuFEEEFFF
EEE	ՖEȇɃFFFF7A":=`tBP 
&=@ B6#N\L@9F>ƲMBɳKr(5I#2J@hImoܚk ,\#g*xЉA" c02fgJ#EE;s5\h,\U":{d"}}M;jkty7E1C[xNȏZ)ʎN[}pg}\Ӷww~݃E&v-p]QVy'%W
WZr!@ЀXgE9xwM
Ԟ$xbMb
4A}A/nlE" D
P/\!W) [Fw2J1b[ѥ_c
PCqN/x4fOG"+*蠄j衂RȒn5(?='AR"2 cEdqO8W5(g@e
lڧjj<z+2鏍F[4fvglrH
"=^IHA$0o'ډqFr)*b4
f2N[E굯ۣZ$!fʔvlH]Vc 	H9##鉶:ʖW!k/2
Y$Rk_"LJ4Ht8ߒR3Ԍ̌͘l!e ZJi
bV lJjXW5^M946q!i?$WԀQ4ۼN(MX
;(9@mӪv؟B6%o]=ŧaa{fԃ[.ɝא!n^%@!ҋZW"dsކ8$^;Pcq2URujkP"%U8)d?QQTF"By#̀GM,xQLaeZ4#(i
8a$`*f"瀨IMEUa%uGDAa%?BHCzc$ւž,aN!D@3d3Cx!ԷHL찗jؘV."rTDW2>cLc9Xx%u*q?-S1>G_l&1"֭H,/@]|&H6LaPe	N)wE/qv*,ԘhyMmsk8ꥡy{5g̎ b]@a-U\ɰDnyBm2S2ui[E	RtJmDGYΣ.
h3ё|ԇ'Q
H)?Ÿ7Dpyxc2䦺"FfUPNS	'BIMaTUtQ]TͤZel_lY*(BSDDAZș4E@VP?s4@,tf"<`fj6Udd6
s1zUɄVB+xᙘvxm&j2<)]Evۺ*spxqݹjt,S0`
ւeۈ@jm4A] [
[{QnE'\$CsoW@VHѪBd!|	78P֐G#kXe>SL~&-PS~U脅.X*Fl"er"\9/!U#@쏶M^(>M*#*ܔ

UX§jnyn<%'VjeDj4MI&5%M`-
aָ'w-kjDnƒ-V3}l!5[iUc}	Һ6	iNPt>IQBVq|=^Z	ˆ';DoW\ً&e^1	\&<+^n;sPvu$}ur"W2(ogK֮cas1ò4?4y>on_e[ʿz`&ꅘ֪^)ݰ4ѿ2);HNp@-
T0ޭ0Ͷ}n[bL.{n/#rruΊwIYY*FЕ0FPE#i.1 2 `''IPn9(1@@I9aiWL)y29xsrIn- :t7-$0x/p1FɗIHmiMO
Q)S)&W@i$/ٝ+yi1Gٖc	p3@3pОYY3@P(8UIiy699ɝ`*@:,p[IiZY\ˉtɒz!գ5 XZJɞ~-j,,铠zI.:iqzfjX@ꉰ<|kk@lGs+RT@ԦLaBNDݯ"M*5Z<}E]J-Xf^-*-,$-La}4km=
O5=C||V։dmϦ,+\q}(uÌ֎zmb=]
ϗmיםYSU؄][Lѯٱdϓţm٥
ڧrt}+ۤDŽ׍ګ{&gB]ڊ|]]>|-ܡf=_3=Lըځٝאɝ5ЍqM֍.]0]k2
Ǘ].ۑMۿ-).}p\
.G.aPq|ޣiz<}^wny0APN
[.b.镞薽{={ꨮiF]	γ. ҄걾˷扠^&%<˷f@ОF0_T~.A"I
aP^@E>
PF.LLhi	m.1>L7zME@ NrPc~a%,?]6a#?#P"?U	E:Lpui)p&PP
 5.wc!`"u[L5'fSo\aEox?&O	0pt"<2_v_	oQ*EP0ϰnQ{#޶o X4qi/ho\<1/"1]{^!@ؗ/ %003tk~\KFE)&E
E!#EE	%E

#	ˈֺ̅ "EE" ފԮEe9cu C|\0
Z
GaX=``GAēcS@*yȸ[̛D'ZLB"%\ڃI}6>hO&0ӯiS#ڷ@ @4˷RxLNj/|!VŌO.kf6~2Z0==0jSr`s/aj>̈9xO;6KVܺ2m.k>Aj=?%#4a@+`00A`C!2#It!.e%G^u#v@5ad	-6(x<5"8|0d0و#_;R-6A8hʅ9I@
FIE%	’pu2+ gQJc~HpJHpb-QN@_&2'm6&`jh&Y'^fH*%ljR!~ §	)PߪZCYۘڙVY*9}~ZxrJl20.yԢ+@0u4&+"B&.	|++P;0(&,:qjbN;ǰ"*2-)-/	t:qבm-pqFv@s['`tJ
TW~u~kvS	7#?.ygyJo砃y褗n,Cz~n{߮{od'/o5$}gw/O>,M.~?_ZwLt&z(R`9И3%І	@3

TAZ(%d@)D ЌgT>PL, "&0WڐI4DNN!StDJZ:ʗbC=O!4}L `U0
U-5?MUeRpV@PZ!&+
B0*X;BS{4Db0+@1X#u\sUd5z5	v!
;#zX+j)%0j	\(p-+"?F`֚ZP@?r[UmP۝V%;)h'MBSI  &"`%E	#ضo-Q@n`N@QmH
;ҮExkv;E v'0p"<@f[ZE
6mP\Fxo?"u
TL
.0DUola,>8}݆LrL!3#@@Ja'8"[cJβ%"wػ0c-W2E4 T6x[l`HYtk"b-ǹϖ[<
w3|ES5FPطK/saZg"y=RʇB)qR☢
*,~͒kջ5fˠ$DFlkm/'%hQʐ8.AHxڋP:L7,Tm
XkAK$ODrd|qBy_U	xvlVns/9_G:xZ/VwcJѭFO7Dؽ$"y2La({m;MHBgT"QH}x¿gG'Ԏ!y;ra}[aN"µJes=Ղ;_'
0xN0x_$%`dt`%(F8bګt [!	ڬo_%h=IB>ˊ/K|簠5	l
!/+G1z^ m^Wad0Sgz&7x^ $2?ev:vlBuqYbBZfp&klhGM`
PvWsh4Hmbs]yV_*fW{WV\|f)fePkFDPx6{S ,VֆXYR
Yme2W]+5nSu`hbd(
.o 02)	dGfX,JoT&r
xkX8zxxcX(i_a(Z0a0xxk6(d0 bzH(E%E:
a8}hX#t"uPe`H٘8]e[]~xM0_AE}*ɐ@W
 !G	鑄я
1E!Ԓ.I ")vQA~00
5\=ِHAi
EqMwq0O	2	
UQQNJW+&0\I^W#A
<t
vy	0_d_Q	{	
	2IN[e$r9
09	4#p=G!\:R `.$$/T#D) s(H'i>
Y"6p$^	)gz*u될Р0GuFRS'+`d$yi7((4B4Pt+H	2j
"A@c/D)/0Bb42(-zC	E<4Wr0203^(AzY	[AiJA_#4/ӧj?sb0-qzs	uz.'2~bVd:0Pz:P*	Ozz	N:
	*N
jMLZzK:jŪi8*}Z˚!X8zJwv_,l\n!R](+jWz:ߪh@1W0
zg0&
٪x**XgWlnK[pejǰk"hڲ..p&XZ
kX)+|ڍfU!gaJӴNPR4`F(RXZ+|ooѰh"W`P`d?v
0vfZBqqc%{'kHk_񶅀0c0
pSF^@*;̅(ۤ@zm+1#]enza\'}UKl;``G;k`KB@ !Urי_Q
/̇Wa0~؊"KWyhdD\5
r\h44|q/,^o܋	:L/B+2403"j(/ޡ+/lKV
Abx|l$]<{Ye.Xh
 8[n;)
ٻ,l^RP`2.ɻV2tE
fV3qY[F(tLhjXk4ʆUȱ0ȷۍf3aW\|Ƴ	LrNԾ‰%o%a c+2hxl3Ȭ[ʦ&\"C!ppЏ&%ϧi{Ϸݸ=րϘ Ŝ\],j$}	Èҗ
Ǹ)T1ӱ_˵*^R%|Ե,Ѷwѻq0d]f`԰М\ox"j%	Z
t--^]F\E^~ꨞꢎB#dh
gߕI*Pʾ7]t^-E2>K+K@bXU|:0T2{6Gޖ➶
ցZ`[][eUN.?Q-2>Rۮ0`Rp,
ޝp.	20'6 X7-pF(	/(0COEoa0/F'@w/`.c+`2P2`'1pVo=o*p(30F~eHj߽2[O'/CO,/`2p0F-10q0P-((p^1@?O߼
l/(bo$.F0'@0FF3'F'3F'$FFEEIJEE	1+F'0,ԓF*-ׅ֒⥙r*\x,2JIlT4RF8A'ZX.],$^b5O
id@@
JѣHHu+W];x"V_bŋF7"Ur7_I-U%^zVhy=_1pWTrB]Dޅ0Ƙ^,hQ(.l}<^⍢8Մ26$HF)i9NIK&ܣbVJddTe`Y Рd~Tbi睴%j"@[9{*Tg&*IC"裐F*餔Vj饘ffZrdށhBj
qꪬ꫕
pϧz*Oݪ+DB+:L6F+e
hyl:v}	EZݹn-~m+oi}*0 =KmhG,/$e'ck )
}!SPb)4(B
*2Z?(@a0,PNsi$P|@@zSN @OX(c@LUmL-@8PU]HhWZ4XrKZG$PhD*`n'*0R/%(B$C RD#;AĮɜ,jQn!P,)T{H,E)'@8ds+`?,0
y@jzW1[I!is[Sr78.2"Pޮ)BJ{^\
Em/$"`!A7W|k]su4pR`
6L 	azFF'@a@	>@u)(~0H3 qn_a(`(ŀ% E,e .2H`ˊ"@^d9.3w	$`i@\cOIe0| z.3PY&|@LA8*	re
H}
ηcBatlxGZp֖fG=ζ{Hjfg*R6;PK՟0``PK+AOEBPS/img/strep038.gif:DŻGIF89a???///@@@ooo___OOO```000   PPPppp!,'dihlp,tNH\I3 C,Ȥr_CHlجvzpq h\޾#nn
jEA>:b"d;?@LswxsnLPS9%d=iImqv-urnJ	Ұ9Gu[qIQ'	Hm8a`Meaz "(b:⤙ C ."" e~H1A˛*bpCJ8NArE0Xp&i$zx˩u	CtW֘].",d¶xݿKz x	p| <0A[JH3G
F[L逃ЪcòMH#U],
BakޕF\c3R,j_7Ԁg^k#>=p謧
\B譋Az	G^dDľ:	'p1ll,+<ȫd9E֞oC-e>iӉao.ӿL_T1Q"͠`
pC>+S
`] JF=1'"2@/xpg> 1B|1	>eHPDCGP+"(h‐؆5I`C`xV\)Т0D@le	R<#@B$VQo	䘏2C# DF?tbu8
Ih$3=$LR:!7,gBR_P09Ĥ?IL?te/ɴeO3ETJs"dl&8{M8rs+'ωXSlxʓ==|p?7Ѐf,AEP*ti
H~.yόj.U=y1E$GiOb ,piJRtQ(@DJdJ?HPs1|SMT5M EmQSYt|YнdSvN5J*ZOFDzH֕>ӲZVtNZ미Z(OHT!;~S3锱x6v1*$0k<~  dT_	IdZHwMX(NjXH岡>ŒUZ\+vANMoC$ JeK3uqkd/K360ljYO#W	P>5gEI(0b0Ou+\A#(dƔ1tHS{E|dή|i{-ڇnAB[bs=ڟd> EcVU^8D`=IPVE@i	;d^]#0."-CLtKgetCU`@`=pLuu_(_cIB}}u^U{/JW	c:݁V.y.1y\de=VyXë$ LE(
Bxj)$LGc36QТ4AGPk~d`4"2"zuArP0~{'To?˚rZV6}bqe: #3'`{|G^inz2Y2j7)ݳ XEVF ]{vgp~Xuf&2VZ:26op%d$*gbVy!$*ڀp2)`UgjfU15(R$5Vp%\ЁXRqu/-(E.AcmU2XgU]n(	bW
]hc042F{U%
6~5h8&\uX Vwn>Wn
[_
rWYmF (F(V>sf8RV%m2hfyHW&e-df$$pjXp53xHZp%χ6=j2!ڂdSፙSG:Tk9xu|axW
+E'χ[T	)xRqE+=[؏es29t'8UQeVF3'^0d[!@'˵&v,()`Kq0u^vsw,Tvi,^vDYe]sdvgǐ8]2U"-cdvk1-lPwvi"35]CU)v͡ޘg\DiGLxJ6^x'^Gx8xT^ {1YE/$@''^\cyhypMd!hwa* SGc7yڳeeP5S}ˤ_8RiayRCbaBydJVeH,92A.7;ԧ1c	d
~bڡGT1)
)
}9J_/S} ѱ/ܱ 'HJ遄o) YEMgFgZE&7V0[]ԑi&0#|)͑|s8G1j=ňFT x2]ğѤ%$lv[Z6)Dv,r/H꣐42f6¦8o%:61wr@wT6fes:WǏ:Z5h/ɑjMgV$[uj
F"d3))e3|->W((T	gZ֒چLK;Y啻E-ɝ۴,trG\xwOR,lYkR13g]tbv#bǐ2]Ci(0^G)!ɜiƶ?iRK9:7kN	j_%Utz\
Db Xl{2퐶˄^*J\7"wT9Ez"de;'de[~
,yDQET3&c+
	g8Q>؂
ە+rVQr,AB\Q!Vѳh>;0YUKrضs)”JjX[05]ͻy3Q_VGȝԆmv8XXN*hwX	G-nk)r,Z
ckp"Ux%ǪS5U^eqv0H/6vf!LdkHRg$\B1™pi$8\OŜzÛ/)@b~OK;ȬP*_Tw(5Trl?deDN^ZFddh~
XlB9-"Hz&Dj^%H
+_EgzFksNvq)s[A[.ۆQtHř"‰ҰUN*m6k^ŨdUK.[+Mg\ʜ^4aXN]xUym"}\0ֵAYU
V~9Ѻ(*y='ܑT]!N>(w3aq&r1R!T]s]."[(:YMYr\2:ŤEW&l3ivevva.hRT}~<;v`z2|LWZNސ=/bAd_ߥM}(/R(65D䮠Iq1X $2@⚃z@
F/U k;baNqW]_`y(xÑG%Iz_| w}KWz_6'JK̸h:[Y]/,-0u»F
'f"ZQjowBZ")C-W=ji6!	+b6hOUFV,"MZV^.hGͰk}KhXeYgj)rJr{WtZnxlX0I
բ(=,3$U#u8:ⓞ:0B7	n8y6 ĩ\[#jE<k7Fj&X*
KB<ӈ
hK⋏wgx)h
<@qt@@
`!Zll9C3UD
4@ K@wF6b:P
3
0mE [ԇ3q;0l405ʥ&[\3Ahk!6[@vDFIm2E$@p!Yk@Z]DG,/A
!eHK{ӀHo8A@w8C%|7cm4	p+÷-=X(peN1x+(<3=&L@ưLrD=М#@D"j#wd>{}h8fEHU\8*EH"@ŬDèMG>6D$3BJ$~19Al'	ЊM268V0ZrѽhE
 "1xg/#Nܼ0	3a	#cw=\%R=tnq,nQPZC&ucdNjU񊀘ZYwL@z!
& !(%|ȈG	4TG<#JjD=x6XF+hr#jXnYͧqᑐ1wdw`tO`
0@w@񆖆Q'!H,rS<:F;ҏf7m4X@3|^p	$`}?7OӫSk[q?xn^G
"ɲr=&^*,l^buG6)aVY;W3H@
 rVmyKc4ZiYӁV!=4T]6	j2H˜
^l,٥iͦA,.[u048)4aOY5(Be	o/{[e ( fPm1GVW."0YqL'4(~,=%	:߭N&xŨ_\qo4_V%+]Y$ ~@7r	uгB=tUwѲg
@οH_^\b؅Y
o_qBoq!]q3rV1̑y낮D/FD:,bGBbZ@AIbxI(&QXbxV1e扷qVP0&zr\Ia.M@IEQS%_s7Ȟ<[<@%Ըlnjl=XD{'4ANMtz>e!G69Lx@﬇X٭
]V`@i˼`PGԐЈGTJPTM	@z` 	hM_ځAxՋxL؀1!oHhQkBY]1X_mN!X,@	sBs!>Ta\]!w1Tܕke@lRapP!JW*X"BRy^km@a=p`,ؐ|-YA#4"*\Ic!	@#!t"tY(Ɂ$^\܈hK
c(Jc*U+F"Pn@V-ZcZ hcP(:>!3B*:"4nX bb&҃7͌y  &)bDv>2R,ICW}ݖaJvcG"#6p:t`OE@FF+y":PLLHQ()^N^1O~PQaQbeD!o(hxP$l%je[IBAYH#&G;M,d	%\["&	p@UmotenF5	h5tFg

.fV@\liU&!j
<~f]Ffgf(x-zY`ac`TpVA_LaQ@C!2@#emjgh}іࡉ,lmn] &EV~R$x+gvgܦS%ҕ&UuU{\@|"pٙXgrghYi-(z׈Xbp}& CYٌf(tgyV1+6nXlř,^z~(gb|Lblncn۴I@]d)Al,՗VR9Vjh(y@$@dQW$iu̵\̑hJ
B&m!adz)CdmW~ƖIBcXX[ot*jBkj"+*iB+JRkin.+fif+(n'v+֦R@kgvk"fll
b.,6,>,\FNVV^,fnQv~G,ɖ,,3ʮ,*,Ƭ"֬ެ&,,–*-ll*"lҶҎk>-JRmZm>Dmf΂rׂbhmٞQ-۶-*ŭ֭--mnPe.f!mCx)6vjx@].p !ځl`ZjLblh]9-oIVT..3Zbf_9-iԣ.*Nf~^mW!_-/6Q׮kn,uTvo\D\v@UmV/poId/orl
6C**0/ȩגH𕐈|p˫oBTmA<|OWpRni
W
TCzznZ&|=-L	[m$jWl]O,qi_AVTJa+=qj@#bZԷh!;V6A0_U&C/9&T]؄~!tU+.r/Q2=UT,_.h:]S4sW+ s&3B}1j:qǵwW0A1936AV8.#r+(3:6T>q>sA3-?;s2839_1:O5+4r4KD1D#&W?s;wrA/72BH?:FtJ/r283BpCr13gC89}RPS1r,r^t'[2$rcSmP+"+=hѰjAS+Z&pzUKW}WU$K*߬q?B
PRBW߲,}^5X4t5C46QMqaQqeC[7q8|'[C$=8EHhP\#ln0V/o;1rkofqs/u|qVb7Ki~x
/b^VVuׁ묬Lbnl҆*}е(Du
,04Pt->>x\f,	(\cH8L} 4
eD,
+	1`m]-B0_GR/6H5_.186[
q[xYhp9YI$^x,8|Ux@tx	i>ZC|Bx|(08#D¡9B\DH|.cC"8L\yy$MT'ĞϞ{zO-岺$Ƹ:FxFP>pV)0@QApQP*	p-RgN(/23979#P{&0ya68{&z/()n.D4J-~MSl>{DL|'txw9#<8 xmA/[
櫗u	0$B~׽؈|MzxuG~4ˋΔ?@LRl̹8(([0BeQ'
$z:H|RM+W3|t
ID	EyJ8>W?xN,KqL`P*N$9
~Hw{CْsD':sh)פ,p
oD<D85M6ov(ʒ?qa=PpHʶLlc<TL*&<@ PήVᘼz:
+@J7ePap``')36PqW%0Z`w!	(ZgC+ʛG@P:X
kg]}H[\zm>ﵝ
MJ݈$qfլuAPEpWثX"`,	,dxɟ8gHɍ$TCb"Ν1.!JcRb=4i4n,RiLAZz
kM(i*ִl6ڸtkܼ|@.l0q3nd'sl93ʚar>>j4j7Wk+SmIܼ5f7wm<9ioKSN9ַS]a/?;zѫ_?}{'O~͟wZF@B7h&#. @Q~ ~bF#rԁ(q!Bq@2FGJ((cx |,FQJ4ݜ$TIBdc_\8O
Ѐv4%txÊ&9†ȑ@Ѐ[.ZQ=Z^~+C4`r*ZJ2#$evj**#8|DM᠎C
29*7`\2Fq`	;o.`6/q+X@1`
p.8
9@37s%`p$`$:"i+W&(2c0$$h$9*f9"HOzHw8TLzt2,*ʵ܀Xn	$ˍ5	P$<+|W^j	9,0>뚋^߮`H;t(mXBNFONp?CIKWh>#hxQFo"

yb"A8#cz8-C-(U{ʐP&D~5j	أ?]dA< ,)	LjdFNI޻=}P߳phU{PTV"eO@԰'Xy1h10Y>p/K(0:
ʐxtJ
ss(Ģ9_r*A]"ȆLsuHPRst!F.^`񆗭@8JЭ`u3BM	8١rh@\A2g2}5GDBe4@|C>Lې3#CZt4m0`'ڼJbN$Adq9L2`AnR!IT(q%5F6G4cw#ɒA |oG[Nw6jS'#CTGXEU38D7=Eԑ_6Z+=61mw*%mR)&}+AlJ-TX:U wsP_:@#lXJn=:%kVBPf7I)`Ma4``!KW5BXu:.rٹ]8jOut-/<%Qb)!30¯T{.pS%XY l	D(.A$
\@@* 	P&l*?--H@>g\Ztu倊npYiAw:D;a@
p b !&dU˚bVZL*@G|"d,m538#8.6%#NE1BJƤg:HYn8
`@,ddp$`\@b1O`	@}
@Rq&ୀKGJJ "quk
00Ȃ.Զ
 ;2D#Ҥ	`[jLSN,w{/i&ѽA	NEȵ]
x
O5\f  @#P3p tf+3LZs`$_@uKf;'
|`KSQL
Tsˏp3<_v0o@fN_HM%D\;WU_~3/<\GN͞t
P8@%	Iet}@\/9zns]:yJ2ГNfΤGdMie0Γy»nq{ UI*Z&H=`u3LE*Hm?j2,Kkư.vk6kblfl' bxvWre\&1x3HM%9k_)eOKAN`%Laa:lW	Q2Bu*/i+K;[v'@c.4EWe%0cB'f2u1gE?6f6ȡ,r8(%4+(^7$(5ivG`a-WbƗa	8savbflր# p&q1 KVn$TEK9JRG-7!"ۂ-'J1toLhT u1w}@y{qqj V_׀d'zpF$	4^8+ zTk6sgB'sA7tEwt|uy8r‡PE4P$0f0V"&}bGv%V)`vfO""Wi
x!r?ypk@vaZG`Gxf֔wQw3	#Q_P0=Z91ܧPNZ`iha19p	jƖH	v'.rvkm21c!74/חW67'{'"/R`dcQeKBٛc{{9v&e*#{X+	aQfedfG}WsBt9zI45ZsTC5S{7~{0bVtTET17:1\>2E86GYE7JZ1-FFw8h$U)#w:<W3Ud5~f7tOzC3%3dU
+uS/0iha؀֋$ Az8@
xIYHBX:slbZ $R@c@3	ZBRU`p' Zt9{BDAXؒ#n$ZBZ%K&c㥫:Ȃ(cr6"Y+6PZ;${c>TMu_9 xL)~CFr]b(V]ͥ0Q^΅?B,|f4D9 BL$EZ-q5khK8:6)BTNH7r6s;'+"Y3e.,T3@rddl(EO%MuL-4"`/U6+thdi-`% /E/*GRGÊ3I>
вO'L6e4Hhi!Z|''|FBH%i'e4=ri'g)y$h
JGp1wj%8ҡxl˨l@(w`$@bkI4"7`9.)/MvQ`EI/H輆%oՓ5Cd!8EF0.mпlvmXjay)gq	a˷FdqȏTwwx-JLGtzz8Pt;Wqv @9r"96d1c0IŧeGw5B|8@uF8pʻQnb\G5xWxiysYt\w
zyX|Y@e5wNJyO^z'dw5khr[t2Ïj1|1P$`|R=(')eV/)'9I""OM&p;I©8&Ŝia@)or3^tYaܓg^0Hk4'#=i#T
ʡ%@*4HcTbS!R38WFcBOF=t}YSuYmjxCʀb$Vak{aHl:
vAN$3*82js%5H^"{Pruiv2Ut8<6+ԛDǺ\|P٦^5 ^9]Z*^RM:5Ư&B_h]"`+`]'M`jٚ
5J[\'t>A{DKȑcr7":FP&-wbR)S"1.0XT@WSºYw4I=
"-^{\Sv%x1Z==-'p[FiZ2πYQlJvn2狎/{>!}".~鼀	XXf9MQ''u:qXv
:G0:`뭼~n4z^N.瀎&wێNa>#N AN%ɰ~(>*Pq	*,BoN?_/!O/ oo+.(0*n0Q3_-Ԣ;022]Pr(C0@߱HO'=f/SUoP~Y`^_[a/dgƞʹonOwq/Ps*@ψ|oOic(qb^?ϞZXh0\pzyQY:w?\twoL0SlglViS?fQOr1sY^`x/d|Bk`tp Y'+ۺ/3]7.?0(*Q 2'48x4ݮǰq3y54<p(c)ƒ!JAY$eJF%("Ʀ^*E'DA@pLÃfEFB†/sm&&C69nFu@y{A7llxG}Dt:+#
!MfA#Sj=W
"l	
ADR]Vҙ$Ú00లϤ`^HpВMndÚR&H)ִ*|JM(RvyVt`-lDr߸%K[W'f80pr[(ԪmELE6jӖ]iԫk	;PK
?D:DPK+AOEBPS/img/strep050.gifGIF89a@@@???ٿ   000ppp```ŰPPPrrr999ooo///OOO___;;;vvv333,,,XXXJJJ


[[[:::888ggg666sss---tttiiiqqq777dddeee]]]<<>>AAAaaafffbbbjjjkkk{{{^^^œuuu\\\VVVmmmUUU(((GGG}}}555YYYyyy222111444...)))QQQNNNBBBxxxzzz|||+++EEELLLKKKFFFCCC===TTTRRR!,	\A	,pB
.l8MP1aƍ1>9RD=TyeJ+abHiL59jDS(ɟFŹTgSEo:=T*ԧIR}Jׯ`ÊKٳhft+Vk۶VlW.^{KចFnj!;\3˘3kL61ɠJt跣QV}n`ϭ6Mum׃ߖ۶o܂rNȓ+_μУKNlسkνËO|ӫ_ϾE/>(&6r>(VXZ^vrv.0(ȟ*~H#'5;NPX@X7Hb)ONPXhXTZ	VL)&{K)D048 ͏1fِ^
@tٕ	&
Оg6@v
Thi楘jVf͹(BHPV2:nJ`^3
+L4L*[*:z?2+VkW^{iRӐ*I@0M2J`94wʭ@Xjhe4)@)/jCSR(~/
t+Cr+^h%
#R4zrʀ([2vlX1uC/?/uI266T\@L0@E
rӄ庭:`gvֈ'u2	q_뚮ܕ8*Lpϖ7_
6p#xfъ;ס+14/(Y#/K@"KT<
`,FKl*C2|^צԫyAO<-S1BdNư(oU쇿IL1`,yA%eÀ_kMãشꕣaH',enMzU7I#OrBӬ$%CCIR2XFN_bԕIѐPLc?6"H:Gṿ<֑rHSY؝#+!"'IIE"IV򓠴
`Rh(h⤤%!	`*J^P"`$	\ G40FLz
>9UCnf:%e,Fz'Y*xͦa(t&*3bgf4~SzS4?(iW'Ʋ=t77QTkV̛TdCRHۑ@Y`K'e*zRUeK@,@-T[@
TQ6al(1^6W1pMU5Q:PRjPUk襽N^"
ULΓ
dRD@?uʄNWNh"_JZM-UXGjj!eUu"ne粔!lm,f٪Y!VZu񄭯hWVUW@mSDZm]ʖEξ
4f6
o?wMA9jg=(Mn_Qݩj7v1KmCCк.u<|_-s벞eU-f6XV#"3
ૃW
GԉqȸR%
1)[c\rw.{Y^1)3f娹pX+:ǵz|=[
|4~,BיІN4Fю!-J[jM{CQz>mTҮ_MkĺָNs;S
HnHptuGޱ2,
P*(yFX\N GSK|QlC@D|n7B:'`TIHYM.91k=UE`~\16񖞂^yKidՐr*4Y)Bрr.4&;'dkJ#S
V?-MI#f5Pgal}-	!T*=	D9.oY6fib6O[)ǹeJ0&ETM$jz]11ډYJX8SJRizIafQ&ө6oʢl	)YxcaHz((#q(帇:u*"[*
!dQK!`&Ћ܈*|(ʢŠG*&P)pZ;3$pՌBPD(r^!(̺1( "k*i3K*_a	19 5[7iC 11I EKGhM K-¡3Z\۵^`bXbeH}c۶np+Y"L< z|۷~XB[{z	f+$i1	B=Z{%N{dfQk 1ۺۺ\zh"[ 1+[ۻek!j
A5F;[{%۽[=Х[k;y%,M]Q)ڍeگ(y v]8M &Fɩ2	z[ӀI:ܴ͑!RS$ai<ȘÜ|\I<ܦa¡‰KhX隧j绐YzAܼSEVi1ʼn=|ҳjc?BJ\< ^\h`̉o9iڏZ)
Yܣ5ǖdG|͸د*d,ɛ[|Ȓ
v+XaqH
ux-lqIuIʅ	1˕TˮxՑRJ{LILL; 'Bda$?FvJDDDw+N25$qr׷Au=`7YpO9r?U(/2W3rS7TVF= &%%wiP92Ari6E$%Y

 FgC5j]}+s;'#@#8v(튝%]iS17w{.s45ýv{ӈ/72$@TWg7N|$jq#Ra<҆V
AA~\`$I,oGםk>-J
7\֍ISS7N*#S=5mBX/W#q&ASS6S#6Se>:ej`<;$sn5vWiY $"a.5 i^Ø+"F(;@:]4`(Gi4BP
1WpD7V#rD
Haa
`4ũ,	J`;)ӠL-!r(h5mH$f1Ym&1#t=hA/Hi
qzם'NI#BVrp!!
鐐7$RI^ėL%I~N(&b ZCPFT|Pb,n G8g:8>HCF8H58aHkvÖ3'yVd=``l|@E#.$ `*.zbA
r dtmae0!
s(
zVTJ_N##SՔ\7[#?

`IXA\ '8h`UjV5QtvU]$	01R:ԳxիO*Կv=lbFvVŪV1Qi"h$ڒqVjJܻ>3kO
[
EbXJ,W]97@>m'
lVAπ\D<(6[pDȬ\l+Og@߶%24#jv_fzcYxsuM
l7+
[31qyO:QWa,Y	8F坙;"&p=oo,OR-swXvuO,}˙Ź3el@0A"@!}F0P4>%C6}71t\\=z[VU]]@i$L:	HK|zCnwW:
D	
8 7PRaL0:Һxb2%&SLV4UL4-m.kI}?|U#1u[sZtv{tixA	&"H}Tձg^r֚̀KDvi?DaL?9Z|:ǻ5;5i$ྠP8	0{#
=hS?ANAt=/Ao 2@B@S@+28҉h߀ȱiX6s6	3/T3惦{>ƓA~ȳ,B(%&,)98~#:ɻA01ĕ645|.8l-DCDW|EXEYEZ(DD÷O5E<ͺ6Bɒ1\EyflFg|FhFiFjFf>l<7Ql@ۃ0 
ۺiCkGyGzGlE,<@P/tG."0*)=PT\zlH|HyG+t6G_"	cL$xVt
\HH\I\MNE6HC/DcZAb;DIJF-njI<wD:)0v$ʭ!
\bIPG?K>2)P͡˚($]ʣH$E'+r4+K1DuLPŠE@FVZ!0p:JK S͙P@,GL3?JppKPؼܺP?;NALSMn0(,6pNh<䞐	,O \@Oδ`$A=X`O8O)$(IM}(U05DЄhOxIO(Qu	؀Ki2؅XhLpCH/0:PIң(q@Qh'Y&G 2089x*:.`
P!p
R`8q,/@0)/%SE S0;ayA
?e@MTGEMFYKITΨTNM
TURQMQTVUU0~BUZuUUUU^YM8_`
VU8Vl)VKVe=	f,WVj=lEj-k]VpngWtՈr]o@yWxWׇyWWzWWWiXe؂׆M؇׉
X؈P}؋؏؎ؐ=ؒٔم%ّ5ٕEٗUٙeY=وٖٚٞUY٘YYuYY=WdAP΂ک}5uڈZi[%ۯڰ=[U[e[Z-۸u۴Q0ڹ۵۶ۼڽ۾%ܿ5eu5[[ĥ\ȵ\m}[͕ʕ]\ѽ\=]֍]ӕҭ]؝]ܵĽۂܽ]E}]^=^[e^^MEYMڡU]eZ-=ߣ
_-M_u_m_%__X_נ-`>uU\MhWTu}p`	v`kVf``a
/aU	@ԋh

+̈a1PR
fU{
a3uH?p"-8b^(3HHG5
>DbhPO9GhER>3CxH
H8	H+@
"OyMsdL6VYU%xji/cAr
ȼбSud m88V
<Ӧu܍	c	X m6iPbcg~c gOn&	(g:Sm
rFԱ?>hZUMGR&
/촶΍@(l@sދl.
pm/ZmM$ifh`YN/z> DXn
Bh3Vh |gV%^Gg""ݾ؍
"4#
"OYa[ 6On`O<Zߘ'Xb1UYbgl/n~5~hl	f.+rrX$!s s6s(ڰ/9V#Thk6o(7a8hFzHk gkBWC'a^hGen
XG8
c̖k	0x+9PGe9M06mE`?m'w軀6
frm|i Hungb\v
)oL7gi'7O[m~OQxA)hs_hg䃣%jlF2PZ%ٰvS@ziXxv$	dm̤lxV
c	༼۶c^O_QM틇E8(R#h{hڸhxjhnbOc^o*z8FzFNjNqb0g&loз!akAobFpnkHh@8{t]UG
X
xs0nz`f7~YuLw_r@짻!'0qMhCN+h „
2l!Ĉ'Rh"F	Lh$ʔ*Wl%̃	Ƭi&Μ7v9
>-j(Қ3%miJPRj*֌KrzTװbǒ-qٴj/]-ܸCz] _
λ},0bKXeÐg~q ̈́#wLz3fԢYg֯]zrkٵu߶lޱq'۸vm{sG7;uثsߎ}chŻ^Xd' J`v
8!򷠅aHny(FY!0%NӖ)G-*5zo89EAN5dB#T=YK:$!QvդYjNUUX9&-vik&\gIfsygWre{&~"'W
@xWCYvrA@h9~8!K$^OG1/i(@}`WymU'CT'1Et֢" csޱ*LCZ\H:vlkFP6I@(xN'jH&h0.PSeŠݭ5D T
RBU27b
U7 J(j<dž)2RPU
66bOn/ڣ>v4N5lc_6bUFXSᯀwH,Ei0KXS'AyE6vz$Uj%D!fEg-DAAJhrЗY5l߾m>,\‰Ӝykg	O`wĔT (Nd\	o!
ѵ!
AP-5YNzDQXC=u/)	;1"{T!ɼ`4T/DER4FRL+S@X`pJiNZQU!L$}=@lXɘ\nKc2
`Z(m= nrMhTU@z ulg€*"^!WbK1M[GT%m}+lW*0_2T
r:Q
0[
RvL =!ܭVN3T`g@V	&-z2ۗ`S!-@z5c9 ?iShp5yZA
D!/\nyӫa(iڀXYBti'os.p@}TE9iP'n',®M醓%vM
"ԾdzWg8ęOj
UL'h+.ʱN*\ cJvK{W
xƮ{Em\
Ĥfo1s\.fX8vfa"m|`f#qH
lNj6iK[{ght{	d܈RlȤI[cNp]u*Au-ւC~IgZCa@5M7"tHԽlX|&`uj-.S(?Q-΀D])8\eq87~7վ-V&x#%qW1GPH]S.9T`3Ғb9΃g$ϱyl.Lw[T?F|uݺM"u7獴:[X'IF;ؕc{IzHҝJvG/)b!b'rx(챸
/k8Y<}lP.#h
M
dO(4
YTI_xC{Z@߾@,m",4Ȫ:
.ASrkehޙRfk>NBPD^JR^.m>olέV/PDu/.Q4mo&kRBTD?]&ܧ6-/A(ĬCPLNd/-pQ$gԴbBlM8)Ҷî,/!-
JbT"sedHذ@6+3Zf@,JHDd`ؘ;00,۳32|1,IvFtr֥Yqc~U& 3;3@sJVfNf*/Y;R!P<քJoаҎ+;oKCKS4Xq ,
PXM%2Ŕ42BG2K,xjdQ x57		gn!Q%XOu;Y_҈ZrB0
,@,8kY,K{{ԣN@@G8I?ʁO<3EMe\M猭(8"QxJ;+ij'X̍ǘ|P|3;Hϼr}aU25֙J|SbrV!3D
W=}GRa7;;:g7At.ELdiuTc 
}WMXٳS$*}JODQ%!-
x	WgNxKn+V@8ۄC_ׄԵQX)V44_J~;SB\Ԕrʷ'~AX_Vqi?ɏ[p|G489j?RPiL3xaBHaD)VxcF9vdH/8aBF*89i+GV0PZMhP	t(
PK6uNP#̓RNc֦7FHYk1ehRsֵ{A$oIjJH,C 'dlNYukakٳif!VZ*´Umo2ڠfJs
x>U&Lm}zwUZTpBb
" X5⋥h*I+	Fk
.*ą؃+M<ѣ@Q#`LP@ۋ`fCSCDoĚܛ,yIˉ;3$`ݦ@'4
fiP<*GDATQхӭ@n(*H
b"S	
6m	cNPQ	\}_j@b4HͰ:92M&,29kHðe	**Ә$@Kag5^ݝ`齋=(J׵fD
^V+˪]x.xAb&6Q܏~g,z(]]NTdH~(唄`i4i6''˘[h,ix$ch>Ϧvgib>^~l	{[FK{
?q-j	kQN5ߜszf͊\.bZ:+;_YKٱim׈o˓}j+ba/jvv3 jx!ҝ{pH0_?>zg4dCH
|Z&P|-%
|\X}&/8`3&ɤ/ SP$`1sN"<"e`(aHiQ4B)"TAtg8JIqXG;1uWKp\UQ~L)M~aP(~9Ȇ
ń$>7B WUDHIIAn/)	VN×A80ip\Bс<ji6Mo~$DऐM2t@n"u2P9!@XiG"oV,F|I@/Q#8H
_h*0@e	rbx,͖4HKJcZiMAʁ`@rf>3ѬOT+=*!v 	Xh JXLO+&R
T˄TLFK
hjHQ9p	Yf@h	B@J(=ݥ
JiYxaR
@%B
MѩijlNd-!⣆/[͑nRbJB&a	p2UvMB@ҽJCe]E
ҜR&+*E2AA8{Zվ{-cI0NC)YLN#E
̔&ǷaVWPl$h	-:lBypB"{
̒$caI׼lo)JT=ApluM=ʕ8Ip`.˘A&+3.A.T83)}dMnnB&<
HWGoc\xDnyWԀcY"zSZT/
赲venYWmh;Z5*hWtt *Xf9	Ij4$渡9	N	T&܁YO%WݦF+D*+mq~WMfhI/`@.JSCT@LAڇ_~
Td镑k "
ivd'cD%.
i\1j?Ad8!2]@ 9ݓk(ఴLA	Ny={^q^l{cQA	J_
|=>@
~]!2_s)4GYJiT+7Aw@*E..%+؎Y#y^M*g^!5gZs[sEZϢ>d_Uf9d6N
Lh64

E&Z3l|Kx~pOʘVJ.Of	b	ʯ|&@@L4FFb0l,)^ fhJ.*pXJnIKVh*I. bVL<9#b[DOe64b4l/Ѐ
//PTӦȌ,ɟr )!hDOcRSv;B)@C\)@^D
/>q#VoVn,쎩kL`B`q!OK ВBA4R/ 'c0IADO/}Beq)h|,I#!`g_;~0'E@MI(1eg/BpXcNcäX;:.(lĖ;&dQ$,Q8Q(R!`? HL/h͘MIr?cNR(?%5BRoEL/B.bG`+R++rt	Wr|
h!M8

:,;N"7\982]C0&7fr,DKC6op6V@bVj@FkFgT(<;4BC]CMDCTFICQ4!0GfTbIHG )T#B7G2H;[HUHIILbb%`Vd4H*:6N8F{MAMߔ4dFŸHI[
fB	gbU1Jd2@"@$-\J&N4!@H'4H1S/"TE+G3j2	@؉F5;QPAGCB+1);uZH`B9$0%4DHCY[DKVҖ2$u-SIR*u$&2.qFH5"Ga$],E3^'bCb/S&6l!ɣl1iLddeGS^_6"b#2eV*-VvLB%+prPW*(,#VĄB%lO wV@.|nno?)T'Vr#$ev!¢"n&yTqk,Y:ز0;o| 0DH9[yAh9ĝd@<%!ܡgwOǯ\@(|c]2%%U)Y9ֽ+ΒZWZ)6P .3X@	>r?b1O"5u\5B2bZ)",FEƦ"7b8U]	ձ\;4"R|0PvOʁ,طd/4ٕ!á	tUE2`2V4Z95g1]lÉg@SBT%MdR[£5FBm,{å;U:'Ɖ} ~v.2].nb-8pr&#g0D}]b#|*,(#V$:^ &sz _"$c(Qr@ɸ

` !	`K_&i>@\0(j8jGCA)LF@ZB
81ĉ
 ƍ;z2ȑ$E* eŕ,[|	3̙4kR -͝6	4СA1ŋb1,g-MD%+fK-R})ȑ%H0DڄD!(hiȵ(M4&i0pႴ&<̒+L0@iD&
 8 zpشkǼl;ݼ[;OmR1da3[p='b{AAl•˧4%_tN	6E=ό%ǣ⣬I('r7	V
rջf/Љpl4Ci&"&DM)9cL`
@Kk_48}4)~X&1Lr>ɵ;(s('
UBT@2%t+EB%IDSy\T5!l>OT{K\Y	Ava;>	ՇX'@+ϏH#f^7)w2ad,'dyNԦҡXgHOZ6&hHPJMS4A/ddQyԦ"Mb=SU~z4
04+
l|_

v-,_#ֲ.YI4n'B28F3qj͐2c,iXv|"P>aHIO(]jIնr:H<7Kg쒹2qJ_җ@)J]@
(R݈Kk*yTFҷwR]'a="PatDREҸF4>	8p9SF?9k7$A"g&_@/q\,s@̀Rk"`?hXҠ{Ȅ[gA^c	.]/M|0!-{hfҰylټ44?$<0#Rh@K2)hZ҅O3"SJ6I8y*%d\UJYctM9Lm!^<Ո@\v^05 ClM3]kI
bFm"!k٤k+i%z ANx}T4YWa.M~zQ֐N#G6M5pV>d@$ ,ArH`!v/Clce g,` l`<ڬ4Jn@@qҕ;i%x[
(n%JC	H	Cn놳l\agf(mr"@#tp\<(weỵ@XrŽIB:.N:	cWpKQ[R;r
ηCBeIp5{IMA2rKSea-&&0y7z5Wzr>$3C4;DCC'
W7˗l#
#3w?ŗ62D+C3^W{|~c}mo'p-@PIOMhpu\'B9:#&Z:}%^&mbqU%=9Ur"%'&_oV%6g{WDzC.;DsChD"3s!zb3+A2u`D}2(w!%"
#89}5U5O-ɢ[2tSنDn 3@n	PgDnBo;:6C6$nQ;Di6
+LH"	vI:}x`rY`- Ŋ;Qu)/2cK)Wt*@; K69'y)`
&pN4+v"(2W88PMRo 
 +cl3S-A7;;<h:%)%i!$vn-i`	`60}?YD	>ǡi,0ddaTIg:\cCsbhzfq*VjJ}1(owDB5FJz:L
ʨ*
ڨJaکZzڪ
zʪ
*:Š0jڬjzAJz̚ڭjz؊몮ʭZ:
UʯzJzJ;	;

+K+*gD)˲ԧ-y
3k1xeЈ9bBk
cc9!%{abFac"bU
,^6:$ vh|U!sl6pcB :!tfyvTMo{\-_0b5ר|bZ
s4EB֚#p}c],a2 =س}
vQ޷ ]m_}\ m9kޟQg*3:v	!fm0qcE~mQaH%/H%0 `#B>):c9a=ڔ]ٮP b>|1#a}S
0Pm0ntea]Pcb8qK%C'ARb!ARbRQb^R|Ef^$:Mlb'C'%cZr:3mY]㬞^8~x'svuNZ%4&~0CCqN"˾,2 "rk!ٮ4~4 ,T8	rf7fN뮳Yp+^`j-ʆm;ww&u6Tm&rN
r'#FS%>
Srϰ.ao[0n^x~?bJ	F?FFrB~8=%EOlc
!e
G/kNz8:Vl$vbuknRJ[gĆ&B*~)4~ola7/A}/gpJq9~c}pc#q21^lw%ה1bFN)bE6-1k#QOG!mڴN 0!Bi
88P@6&M"@rj`(ˋ>?;OD1S1Zd,lJ`yG	vʂ* @	`@`29#Q-.p!,ɧk3RMJN;&E>T)7@[sPCE4DTPAPH'RKcR;mT0:5TQG(SRONRTWeMMqOWUuV[oE5;k5Xaa
o\aEaUvYgHYT]'halZmTjMvY52rۅTvCUwbMS|eu^PWw&Q;`\Va+KVbbR)ָc_N9d#
yO^d_8eV$k٦{o2sf~J{h&iǠiFfLk:쁼^t:w[%ӾlDfĵ&C;ߓ{[W_o+p5|wxW߽rkm-C!矇>z駧zǾ{Ö3Y50Z?CO}RwG:ht槱j487m_ErnPT`"ت	рrT 

L}eT0@R"K)$PA5Pňd
I:z49mjڊ lϊX<+\IښvRmZ]VIMpg.H	U쬬[0J
{u7tEx	SuT_U<`Fp|\2!0@%C ܈8ڸ% B!EHN!̷4(v4Pa9%a\F>RD޳X^;D!f~v0Kēx0oT6ROi?h$FZIމ9PHdhC4Ջ@l=`!)AFR *{\m1Z|\t)
22rL::	T+֡W'wȳ&Ȝg<'S]JD@	ttD4ۗZGD	Ry/⓬81?Sl_IpG˿߬wG
@$*>#A
шJ>=:_A((LzՀJR(J		ձ?"A؝*9֘(!i`|2
2)@$/x[.ד=_,ۓ=:ደXz6t.:k*e3+#+|[2ƏIJka2jCÉ1ĈAKi	7tP+
PZ`P&IJ2Уxq',Nl4$:Ɛ_R,c_
i5*r;,G8F;	3&
	cO[OO(K!	xò9|Ύ'iPpEJ̋(KDPxTvHi̖84{M҃)ԏ4TI$tΏ
	OQQ>4R	0!AQpAaNћP9ǟP@i"?cⰋi,==(j3Ք4FGUjK
):@H
@REaCTKg)J9CSԈP˕hM$NQ5]UN`Vu)xD%	,9
|vUCyklmnopn5b%j]qUuvq-Wb
O×J-iU""؂5؃E؄U؅e؆%؏q؈uXp؋UVX@0@2q1[
t	,@0NLMkٝY؞Yڡ}X"qPCDl`Cو2ĮZE4	(C94=YC	e۶ٟuۉm۷5ڑ;$ K#)ҘU5̋hUۛ]%E8uץXuدJ,GQJدPʝTqdD5,Ϟ|οݏ8
? κ,Pċh^Gf}_x^\2Ph
#PxtE$@:%EāxD}=G?
`^
߆H/<	=D_ y#Ѳ\D(_RGQ  ݗ_HK]Zb@^AvUS%dBm;e1LћcaeQ&
R>B~UN1M/1N޴[nɈe]X=FNHlVD	P>g:\]#.āPN"a 
1y^
P\H
'XLnae
%|V@D(Ũe7O`c"MufLiÀ阐vhi虐Nh&ꈀid
;j1gSߖ~ꕀ=Ϋ f:!cf"v$[`GTO~]
.H@)E.ӔӔb.	4
TO6Kl
kskݍ] Qնhq[)%g-b.c|cPix=+k)/"&D^@x	V`HT;K~Ky%(kminqk^')nPaXnЌ'Afy#(QCk9&=H^KfAӱ]j7αtVBկ=^#ndڰpvz~G|l]/bu!;].CVn Z7(O~.D8dDϐZf!:hmh3ϜV]@
,K3B%
_-q>_d	heA3)\3󜰿	tP/uĨoxUKuV?Rب(^uUo\Gh,:'g9:
caVwlTI,. &\)
R4\'ua^wGPawTO4TNȮ`^bkUc?y나@WH/%Pm{ʍgj^NJ$pՉ4x(oI`!7N
Ny@q b:ϙ	(n0'@˱*yA5F|C8>hK?D?9.=$P<,Yٞ=-ϡң?N$ߒ:g\wyؐ{	Xë`>x[
oď@`=) yһ1A/6g}i
}ߨuX
ߦ05j̍VtJBP\{wd^|W$G(i)bEa@m[xuG@|Dt?P`	L;8m!C&p@`+*h!ǎ?Q"Ot @._Œ)s&͚6k&Ϟ>
*t(Oi
60J&V\(EQbeAW
^`B"0PҦOVeP#Q$MAں~l3N#N#.'L`h!
*aXNcʋ_^ma $Dc˙FRt!J-|8qℋ#Oyc.1Cx=h	a	hnu<	abǻ207î
xa"-נ8߃=-PL
4ՐJ!HׇR(a93X7☣9aأ#O
Y_D0dBOBSRYWbWܒ_$1!94)I	^Y_b	RyО=e5(#&BLvAf79EEx)ci:i$M%zOA4o}^SE\e* (6'bЩ'2;
Xڬ
*{=XTb=@i(lV ..]Wh|{ҭiAN#dRYӜ9؜ @72Zfv4m58`6EPex\o˛GGx4sP캐	ҘBO3u$t&МOΩB	p4ЯH]ve`B$p;ߖ>lR!1m	@U@G	$3@Q6e5CHOCK4"8[R<
)p%=M<@O#	l݃
>MTsePDPլi^DL v.۬dt
W"T/8s24Jڮv	4`vZ% % AxW_&(4 쨶Aq/|˔{(<*嘵
L$dIr_EW:7,w7p&K*1?Bt=Ν
/wLAgYAb-uj*#*7<EKҋtTp[mЬ::`2'uy\/pDi.iX0K/Fx`Kp۴;z3<~}s7q.@W)>z,>ɇ=Q"O{lG[k;d8֙}![ƕ
vwyMU@
K@eMOӥM3@
h҈E_-qM`^քu`]`

	ҠL`RJ
K=H*!M^&FZ!H8!r2EbY!>Jab 
 b!!¡j^1!!5pM%Z%bb&j&rb'zb%."<"FO!L|*b++bN"r!b.b/b,D*)PKl@2*22c3:3Bc4J4R#5I|Z5Y.#&H81cIڌ:8
<>:㕝>Ңs`>ccA	1A*}cNܢ)~cr8C^ľE*!C:<DءF|HH.KD4NdONZ$$KGzG
d,2MXITD@AHTReULA`X	V,MYEDpdx@U[¥\pWP$^rHDea[
<Ջ_:&scj4TebTp^>&ÌEh4g@=dfkf&x_%jN
Ifnn m@<fqbJy]F(⼌`Gu,jYڈhَlFE%}|RaN@
ǜ|
YZa6ArilAGOtN-Ļ|\T4
gX!Ze{`EPA$MXVIC)gYTqph%=Lx!L圅4XfHҀ{VlWȇk8WaEp
8hx%܏AXDFڄ4P
0K(N52RυBPOTTKdKluw樮*bq0DZk:rEpX렐rIʟ*<La[lUQP[Pņ=!2VQ]l@ؑ$@hU
Ӷo{<]k쇻>YG{QZxtGHuJۼɨPD1yohG{܅|Ӽ9cwfK%}H40WpE_įyKZJrPHS4Q
Q-_d`	@Gо_$~\dtzǡ>q>]-Gad|{K>hﲁƥ?J=DN}OIKT|Gf@VbZAH;aC0qecG
T`Adž%hƒ0@Di!dy@n.idS
H8iUWfպkW1E1dacƆ
2( Ɋ-\lj4p`CG!R$J0 E
Q,i
U @F8m@jZg̨+Ë$(J@!Di*J@6](iD;P
)J(J(!Ł@FZqKn:r(U.0P4E8iF/FiJ !=
!O

9A\,2-r./031s2ɤH˦l3@r<5@,z>i&+R-K+1z%
a(bf́9Ll	;s($ p`Ji"G! Tk딆;i`JANM/D0YiGZ⚫ګ[",%l"i>ݦ!h`	*pȽEmwwh	G2A	4W;*2 pL
 Nii[a35q\.unr	S6zյǞPnHJ9ΎnQ)__p5c"48Ɉ~]d`8C.`/'&lNb*/rd\ЃX%45D@W{65NOkcI(FZfةv
2*@<. d=rql/򙻲V0@QjNj1UQ23`6hE/эvt]aNҕ1iMoӝn_,泪+
p	QaʵݰP,H
9,p׽WHL+@
	
8_t}m6!6
Y$vVWDE+k˫aTɘ4*`ݶݔogJ.7@?bl	}1ogVO-h<%?nhw25asao\n|u@E7:i~t/MwӡuOUձuo]7uNzўvy\O9{Wt=~{m'w=xOq|1yo	P~7Iozԧ^w}A`O}_?=uz#7_|?ǽK߾}kW??oo#r>>zzz~~~{{{YYYxxx}}}|||...WWW111TTTCCC222RRRSSS---LLL!,y;``4ha>Сˆ.4"lj8bɏCJLD-_|3L4g&fϜ8wӠO@

JtFMtҦL:jĖ^1l±b˒ehV ڳj;Wu+ogW/6oaLJ)/[ogƬPsfΧ=ZtkMF=[umַ]=Pvl&^ppOh8rʓ]q`#Cn|]{w'^}ryս7]oqwߛ||ׇ_~~ȟ!`
 6sFt͵@rHVF$d(]t)-z$3X#7ʸSYUVWiWRDU@(dDiH.dP>dT^iXne\pAm%[g)fZkI9ќtix|矀*蠄j衈&袌6裐F*餔Vj饘f:v駠*ꨤz܆ꪬ꫅rp2p
뭸뮼: *k,{6쳃&Vk
d+k*Jn\`A:P@{[/'CtSoJ@tS;q7+,,6	YPDL,M's8'2{s|q,01mIlՒ*LtA7M\W s_0qB--Pjlkܱ߁2}Æc-jgx03^@]7,_p}mzzwӵy7@7o4{ö]A.;WZnp7U{cb].XPӬ>d@>~4-˜w1e_?9s׽yClI[@
M~{XF;v74A㸗?ꍅT`E%'/! 
8	
`?-':
8!ӡ,$~Ђ],7M(9"wKA>OK7ƾkB#HŮb\`
-|m|"HJmXnЭB&@tbeЫ{+7<βJ昇9Bxi>݁^N/Xn.l]f	=^NŜiL| X2N]e1uạ9N}i,r$70p
jxٜv'ɢu4QNLDВ(MJ	Eւ"Lg@44ͩlj/W_,_+hw@M`p
/E(hr4j2(ätb]V&Tmkթ\yZMO+׸iQs*A;V`3Y,ԙ2vl(l209Eo!Y*m6bdչRy˘?6`q}ʺlV`~{K ͮDU5h4@rte+,ֳLBobYjByvF@T0͂M'j8-21:mcX	kOoΙbP2}j_V{F:m|
?ҳ)6k)X
dVp̲"b::Orj-`S^&Io4,gl&B`)-_*{kPE7bP
 2l'Mi$2ɾ[tGGM`n F;uvv	|f*kj!@'`jn-]eNhA|{]iQ7;0j=?{|7owzq 'pC;^oXPOKΘ[
~˻+iV Og@A_,Ώ0(rO:	oq+<@P#7rNgؠ>
Se~WbUC7,48
0/Ux{
VD@7P 
 [0(8ZpME0OZ?!/5hg(pwW|W	8{y^	#X%#NZN5c/*$P8}FT;xy"04
Yp}Ev 0ypCM('FEm@09!'FL
dXvWqoXVS4Huf?0H49cS^x؊|&.@h.k
8V&h5Z
 1T
Gu39U~)Fi8Xxtܒx>~@^R
)P((%<+2@7'7!4Gp0~R19ّ "9$Y&y(9Mx{9pj0P+L0()I9V,y'.s02eh*\@H!
" (CioFY=IM	SI-BV1ZO Q xf_px=	`0#0v-oٙݰrYx	? ON`ftHy00	7@$&`9)Ih0(]/7xAh,ՙ t'
`”ةnםvY10+G0/%PE30K
 ٟI)IipP@ro#~TNXV=Ti+Aօ[h9ti~z)|	F	i.
2J6:ʣ>
BJFʟ)JjǨWȝ57>;43:7>BmqtDc])\^+6$Ko
L`L
LeXMJcA{xꔋ'^~:*Zʮ*ZG:kjx'ZNX+B
p0@Ios1BKo	c[qz۬c[jKҲuю?ح*ڧ'Z69K{>ۋKvm	I/E[.cnϘ8͵dE@_+:Z)˿Iy+fj˶`I
PF,*ܒ1읂{ջ˽ʤ
x
I>(̺o5@0 04 	@šJkjҋ;k=۸{B{x2Ӎ2:*r@ʬ\6*m*,˷ƣ#|p)ْ*ܽvZpG

P7~q]P@w`09NEM?~'ALRizVMkQ^4DpWll^^N^Ƒ]s
GpkPk@znj	BlD– zpJI	`~ͻ&;fYn^[.)_^!fn%7G
Pf%
p럝pBJ=n v'.웉4@$k1:0FWnۺؗO^;7GS@
%P03}c)𛠙+Ӽ\׉	׃͙ܶ͜Fz]Ӈݩ
'
G 
Pc
0ݐ
mԕ`{ piG#/і-|pQ}I@
:~z0	B=?Ǖ	wO=
/Z|\`=ڿ>`{xoz'2 .N=ݜsO}#1#٧OցnC"}>ٺϼ,կ0]acn~N8Ƌ8\)"@z|@Ҡ n Ä	'N1(PHACeM9uOA
:I.eT'n
z @W8W`$fą,Xp@E! Qǃ2,#@_ԭ`5&-Ō;~9ɔ+[9AEi)iԩBլ]۶ױeϦ]mܹu
uk
9a1F=I$J,]”'E՛V^4멯0}sE[./{
8J(an>81Ȳ;˾L<J=S
>~
+cvϷ#np0nȥ%>C$ۮ20o3)fԲr/,z3и{΀.&Q^L;ʺ<x0sQU1LG#&4y7+8
4YYc1
a
àS'pJCe
&ݲQ[4W^53MxF
4f.
C*;cZ{UWqo۵\tUMLut8Gpp!XƒC)
9v0 e8sbFG658yM^Fh0B,jP$*83ryg{gzh湆JjKslsCVpȊ.P(`}*0@[m{nn{P'敁	j}y7hgH"mH0ܽB}tK7tSW}umcGcٕcb #rV
e; @Նd`@FP`-x>IӪwaK{z=	p[:0ЀP\/bq"+Cx;]n,c>`C$JIg^$~'3E06NC*BĊAT؆'D,abcȔ@7iZw;4B'ZᵡHHF+4,OR C[yJ$yLb,SKϏP&f'I]&$SC1iS$@vleΐnؓ0?-ړ~@7Y:;siHyl.	lT8(fH:7҄(
xFn
/MeJ
:)Ҳ%e!<,kAyJKT@TuC(:7TO#B14,hFZLal2fWi={%miĂPIܕ
J1lpdpim.%nq%lA'\B[&wC:4Uy!PAq^@:rPBo	:hC.6;SU>8E?8LВ0`c E	ADVtF?ZғI)}K[miOơ
I*a1#YgWձ#i
YߚuWrk09-D+V
lHڧ4U]ÜT0m_['&Smz;:yѶ٭w{;I={7~S\X
W7
p\8'+;׉;x< ljKN<([rǜMhn{޸us77ė[GO=pWYgԝu[}BnSf8G}r9׎z;{nnqk‡}W|u{]`n[߼%yw=inz\v_=˧n)ySÿ0G:ӏ}Y}qy㟔~5K믙~ǏWYSh!rXt/F(T@h	Љ=0
O
n	
th
ԉX&CXAhA@	,l̉ XXxAo24Ao(Ao	$%
P("6[/		B,@hC.C:<	Ȁ	Ǡ/@8P@B41d›79,:\	ID,DD@A(!Cs 	HÀbE
xBJ	Xn!
X	
tA(ohf	>4ZCX	hP@Uj<`A X_̉:=OGpś8BdFyDaXHWl>l;yXnC.D8E\F	hPFntF\!Iop)E|FIIf!ġCIMI@		qAGgTF!Cs\^솶!CĉJ:,TBlɶ¹Bo $
 -Lo8I	ǹ4Jt"$I[dw	JB,lxt@LKXTv̉D˜K,Lě	8Dśt%0|šԉo4L+ǭ˩<$fA2̑G5\B^4@@$N.<ɬHDNDftP۬NXDC$gTF0<Ѓ$mP
X
J	&$gFC@OpPRE‡G`̩Ld·"C	L“\*Elĉz8Q@,P$H\$$6'$J3e@+Q0QS-?rOC3D=\F
G݉T(TLRMTTOHP
L@R=դUT?U]kUW?XUZ}?[U]=?^U]=(#bcd5eUf}VVvVdMVi%Vl	hօɉnmVnqWp%s5Wd-vMw]W2w-z{VyUכ`W{xWt؀%X~qka9md}XoͶ؉b؏ؑؒ;:99Ms٘<aV^>uN۾
U^}e5b

Bl
PKHzF6n@AI0/*Lbhg}/~4EcN:wdd@NSi0eLeg@VdI96jNXi(V@b6+.)6c`Dg>4FGfCadHjJBBdJhFK
։?N`	h8EnB/)vƉ:ǮBE\sREED4`G@`3ayc.lm$rQ
Fif
&
gHiHc&чN6mKy|dٜ A	8I)ˀC|$$oF;]6|L>LZUTvbN&O1Q.DqƉfk"Nq
QJO7,
Dq5vnc qMdben.DLrk~t!t6F%grp{bHb2^u3v.'eŌbLwAMeo/	^uV>?AVD4bJ2iQ,r8DK^_hvtdDv,STUdhOYjWO
'3WԎǧ!NHLVEVf&D47D'rFaTO4KwOdk
/(|PhjWͶq,)&4d4qH"ef/]y}
P;mpE_-\nEi=}ef!$dH&%zdep\w7yd ^1oTr~|nSqp̷cY__@oӇ?Jb$^@;TgHpnKnߏ_>|ƒS-,߽\/-pw-hE|M@hn'Ȃ'x2,p)p
X$o,h „
2l!Ĉ'Rh0"Ȑ"GV:y"e2gҬisf)Yv!B-j(ҁ)Ԩ#=̛Zr	n,j,ڴjײmtݨx.^ |Yya.l0p%t"nȒi2E,Ě7s3BDlL/Z|5زC.mJiԺOK-Y2L:	:CfogS/Ȁ+.0Au*wX5[@O*oqF7 DI!=M{IY@q
`aᅁa8P\A
B]p7x@5 e
OhP? AYHAP(A荊TPB)	a+tC㎞ݘcqz@7_yg^N4CRkAeV@tekYFWr!(ЕM]Ѐ~ʹٛjF'\y1 iA+X䠭
"bY_EMެY²	*b~,LQ*ZuUsBp*!:*8X8P
H
P)GXKӴgqT˭pA-@(P!@7MfMѭƊoaK5Ert޿HEeVqY%{YPZZ,"=g$
>&x%qMef{B
u9jIC.zQ葵yI%|I{<+<;<71CʲΙF JOL]PD{VNԃI<

	@!P6Xt6A| #(	Rbi&{.pA* |Z38|r=Kr%3yI>{bC)+qј.p*.Hr)RV"-r^sP1lrK7
X0;$OL7PkªEN&U:yÈiR)mc^fؐ2~0\#XpB/dP>}[QɜBe.!P٤FY	kWZ
Aw$0fxb7e:pUz D @:Uр	WR8C shFf	rja\Bנ@cj1	5
jz'v
]뗃fhlm8ku6;q#B
YGDs-O	g3LFL[/p-Fp/p7썰c:NzB[.o &_7U~d˞knfhyly;Ƴл7=ӟ(D@,Pk
To@5#F?7\n`z뾿OnԀɼW]Lu8@ l}%LrAFH/¿\2p|hnvsەހt#_2(DPfUxE؞ɝ!M-_I1MQD=_͛UQai@̝+ABAeX1ͩ\ٙ?"tHҚr
\@TƈUuABm5_A]
 @Xv@ 
$5ya
`!@0-!z\@!@)t%Z'"jG]Xͱ\qz`H3!D
2G\8}\01!SaAJe
](e_
	%_	Z椚-bաZZ#'v@Dhzɉ"xJ)E*-͵__740Ax@Rڌ̚,5A

H@Aț=_Z٣DDL[ɛ!d#y)T^@6_m"QD2U@xȊt	G
Q`!2$T.>I:KnJ("Z	eZ#RR*aAS&,NeUX@DW
M`i5bYMVjUBt!AeCL\$]&]"
$S2A:,J%Maaց`WB4Z{IDHxf8#eiQ	R.A"TB!-lf&JA0A'zz'{{'|z!A(r)e*ajN^:%B>Bflf A$x*|>(FJ'i's•~J^"fTΟCV r((ƨ(֨ 'gB"ivh^bS6a,BRv^>)FZ{f(AaĐFg$"u(`CN))X(`@h閊D&e)kZ_f6$zU4\3*&.*6>3Ʌ
)H)^)ik&)v<(G6ȥzCjEp*&ue&2-ȁ*D2D
H*G~t)+~el*&
AE@U
8	DZiL~Ʋ%H5Pj~(
f7T쁂qKZb`Ve
`@y|&k\_		GmǬW!60Fppݦ]⭿V+v6i!(qm1qAK>O
K+-¬~_2[qFʦl֒N	qr1s1[mol@7m2'w'2((2)){r"_Rr恁@.J@`*+$qvbE4O35W5WsO5o37w50G2#	@73!7oso(;7yq~kVINC̿;$t#Y:#hi_BP,(kFlBx~
tz4$Ԡ@0ydRٻ䃮C'qR[O"Jp%#_PUf*F	~5KzeRL_NnCA7r} 
g?	MZr	MNN8bк0FR&IO56JUoth2H9B[w4!e
S
s;i&J&4@*xD; T.%_L(̺60iSdPVr8ˎͥ#=$#5h$઀$tP@0HzA鶣 0Nr@G-@YXsR=sCYHBA=SShw䢧 aBhP̎,	
:K:2m
ffrK		h
z&4!	
H[r 2v]&7ssVŹCCx^&7oC{_^2/C_B"h?y(\a_xga4'
!^)VYb1VqQ`XVqc&yWowȵIBN& c	GMhH.n"z){Ʉ~\8qǏ
GH]S"P6pevB>ۻuD@%tk, G{^@շMaItϺ	~CLoབྷŇrAsI,DňqB=d9ŭ΋m{nixm|WD|&vǯ&wGGN-rEܯ6cx㌫/.
\F	P#0!+/	 {!?"6PGKOPT*3kbTu-?3P(Z"07R*C5t*H,q"Sᶑ&R/.10)CBBƯK/|,T"4}I*PQUQM'b.Te3)L!s,<(ǖBUTG#"*PE5*
@]*ી$yHWsæ3
ʢ'LQcN!*jrA@ƞZUZpMSqX'hX=!TA-7Wyg.U1lNg"{2&J=Ihئ
UX5 {#2!1aw ]%y(:y?^s"B|=V:*h<@6!`!k!x#4#DVH""2~1&8ZJrGLb"4*6:+R*"ƶ\"L,lqbL=b8v€#dNtIƸNzj	f(M	譆X2#"@4o'XvW$W61n7i1A?2ؒ3;^¹p
N.v~	個FNN2MF.u؆	2‰
)!"&o#jknq/ɐw#"c2\bw.=xUE&,cHƒ\¹v)쩌אinP7ku'lzdki!*>8o8Ƭ`n9Yy5b ܂Sn22c!?pjlnjORǹj"Fm'ٙt7x䚠.-Wبu%+"$lF:"IWx!@Z'Lj)	Ȧxkv;xQ7In"tjh`V	h`6`bo99*#/xnk+sV,yB+`_#wr`;:°B_Jv5)$cϞV:#mm3"dψZM))wϸeb9XnDKܶw:4t%վ;QGČBom'Ž~)({PnSWT[r7ĨC\]~%sMl;zO3ts:@ xv'	ieD|	ɛÏh/B~7l+
bnȜv*r@&m0%ül#<نb8{'G\0[:DwLρj^`*ܨ
9r=_z	0,!2[foA!*t
yOzl]}وd0h:Fw%3f;7ɑ:͚I'goܙq(}0\leg}
b;6^_!6c͆~Wls{'Frm~;vle8㏻ȗ,N
[֮e__s(ϔ
i궍H&9X~#>N>Xw˜h2n*;{u6hn1@fmUߧ>dsތɭ{MmɦN[A[Ӓ`Lwᡫ	ČrK>!^ufn6>?Wy=rP?
ZA[_cwa/"HAEK{ӏ#ŭg/m_#1Fa[_t_͟
z_"$HC9|1ĉ+Z1r 2ȑ$K<2ʕ"st۰Pƙ4kڼ3Έ
, FСD=4ҥL:#fÝTVu-֭\z
6رd˂s}71ڽ7޽|w5xŌ;~9ɔ+[mZ20 ¤KHլ[+lk۾mB
˛?><'?u>tY``
8gȰ`NHafZ\a~b"Hb&b*b.c2Hc6V[7c'v~>Id6(J.ɤ~HdRNYړQeZd^~	D
zafIelfn	grQv	wigv&Z()`Nڨi(z*Cn
ꥢfZ*~jidFhk:+DkvͰ+,k*Bmksv델܆-ut߶n;m+/
lCK0pp
O̰I:7G42D%?t߆ 1<۲\+{;PKO0FZZPK+AOEBPS/img/strep059.gifeXGIF89a????߀@@@///___oooOOO999JJJ```񠠠   000


PPPpppҥ;;;+++wwwYYYhhh㸸׶!!!CCCrrr:::SSSGGGaaaqqquuuAAA>>>ccc111bbbӑ!,?i!-*	&h)'Ňή$'%
֢uskV!)\ȰÇ3
,Sџ2\S\ɲKIZ,k/`AJ:0ѣH**V$hQ
>%Bկ`Êm)VT80)x;hH0亮>lMѢǐ#'%T%kj`NxLsF|hƁ
Os(Ͽ.1*XT@*	`D ($p#T4szv"w`a"'Aa+cPX".X㏼$1Ԗ#8$K,iiRNYd$TW2餃dIdhFf7@BxIN@R!k({)|4y@b[
Xy>:
,J>jiXyNp):B
;0%jLAEp*jA++*$,쐹BFTɇ5<xJ-;83@0@P ୺.ЍL̳-5@=0hԛ9)ǿ-" 
(D ,Gc`M1D˃Eq`<$].8չ1#%sj3!ş2PaqmeV>_݊p1]&`mx'!lo#s iTZAy@ov
Xl!UNIL-׊UO7
>8:=W ucrzK2@վ֐/k3nG_==|}l#Vh
upiR(obֿX@Y/
b|DLjYm8Bb@7kp\PҰ=τ[G'}ux]@#h]rHFB
᱊
Do ݢ8O_Pd`mB+x[~x@X8`ŇQ]1
>-}0~6#]EGϐ4|_he0"YA+0A_.?H"2`#6L߅\#Y5Sf4>\+؉^Bj˦4QNNԆ&KLFvKh3щlDm*ž&9)`w|d'M
`ZTpRMEVf2NJbaPrhCAM4z⥕hE
R_\E's4pݞ=FVT2YDfznnQE9#"V:ֱqeZEL1vHTT
X6`\T[]vbno1C,
 P\A$oy6_Ӽ3b
eg]sS)Rͺzq:MC䲀hyCZY'/G	Ba{綆=,NdۜWuQ̓[>8C|ZboͮBceDm4Fרe$lctxpDAzAxKu7=p&ي͑[#lp8GQ.;89zUz#ְ@*pdDilH
T
"i2Ez<ƿr0|
b	Khxً,-\r-2il`w(=8_epE͌ g]Yj@.tIB\F7VRqB\fn#yӢ
 *	LEvAGv;<īa)YlA u&r=
.fYEEؖ26!h
\ݱYBiMlK5;t

nu݅hP*or}oDntND'{~-QPWv4!1qp#I
ڞfpy޿~熾y.6
U\Bbqa|$P5}xBVh\
CwWސP*hI=HR
2C> I3Wh7y0+*ޡ6YVyWhɎD)0_eTv/cɗ=!p>Hp)r)&<)
ȗH
s!xBk,V@vIvGᘏ	I]FTܢsR# ,Yp9B)!éizc2ѩӉSRrai4؂Aڹ؝(s'u)ox	"?#78	FEVrFŜCSIt%[4ʝ:B#61RP!(VB:p*@8V@	8QkSUku6iB@wcbkD<2pYxLŴ)+9Ƹ[ֻP%)f
	9$M!9^j{'ϛe2ѠY(d8+JEDྍAU.xwE>B9c?!/{x[ʮK|2B>F9QL=su3lp*Q[{*S¿
H2:¹co̼N{5,.A)Xő8W=dcֶlnpј$a,`O%h켁+˼=U]5K
g~,q\)1Q5
XW0\,+ǭyN v+4GL!Kѣ ҬǓ8P!W/D9 2BT7PRAD.C(4DtK۴iPmRs]JkʹFM61\kk$,AljѲ&tςϧ$$]_HʁL\K3c	tGt5Mp}|j ;},1ū4EDКgE:67|MK=M"}p,?D+4g-9ђg!/`qo|
DKEׂ B@]#BD|0Vݔ0ȸ+Pق@ILoiqm.",i0	6٘,{E<ۃ0-=M P- ڃ -M-݂0M5 6݆`۾ެn&{i0(0(33 (p6+`/i ڱm5(/Д/ۅ ,0#Ym@[N1`2 N߮=65P
.]ڱM:'( 5@%?&(ne=ri =M߃  1pnnݱM GNܰ-.u.( ބ˼ꜻ=Ǿ_߃`GnN10ni
{moNm= ~|\LՂ6-r.MM)Vn.~ii`-;>螞Q.U~[=륉~wL:a`1./3`?/nN܆~-ވ09`&oz۔	'2?4_689ž=Mن0 (0"_=>L=+ϝ* -B܇7KΞvlnp-׋05>K^dz\Uj_sOe"(u։oDCuLF
h(Wa	5
,ڹLfxp?_؟ڿӯ5ΐƿ*t_u.q0hi´ʋ
Ҝӝդh&-ИH*؀UXi
*+Q,Ǐ KcBfx退0cʜI͗4V=$M6;qѣHKLz4d
7K>)zJVѮ`Êt(RkWٴn
vZvo/#NFʶ[+΅34K/e[{ϏL0˦YeW3ƙ*Zhȩsޅz7w[
YnHfG^R旀Ly$FU{ޥT{ĸ׾ٻ໋4N؏gA7?w~%R`[67cBf?Xy$!sFR_90
`Eن ֘n% $=$#+嘑<褉@8%uX\zHYшOvYYBiy]Å_^NIEfcGRť|srrRؒ$'I[CyY(nhhU)9fj.)mybkUꩴjnf-iH*l'+azbRiǦqfv{myq3*j=Ӗvl1[0K3]жKZl$Kؒο+eՒӯ&GklV,2'S18s^)0_Rd'Orl+,1/̒<8)ѵP3@;&t0Hcq^Q}6ӿT}TAr
0OpL2 KR@Ќ4IjZFp2k|-VNX7W$j_ltIȩsJ= ((f+)`&(A
J"?r~(N>F&QKjh@GR)*SLiD!pS/4;<d&u!(Qst?'WҹHu6U%]~;a;z'5K/ØmUITT
ֽJhPBV(%,;'$u-4@fgX'04li8mhU2EA?h
H@*+n![?> (PPШb"-t/x`7H v]P7yvc[7:ECy{׫dsE{]9  -Jz	Pw*,(a$7-+FXT$"^-qiNˆE*EC	BX]wRZiA^X lq'C2<qEc׊k>-hX,ye
̬gLy7!!hB@g]ѧz4sHЂdy'`@
ZhPX#
r56Yõ p$ ˁN@pO#q
@&	Rx#HėH*B3KA$'86}oF*H	񀀫[=$6@s!Lpx*.,wN@:<0MqPϸΧNWP;boҼ`N|3h/杽pNw>ͽx/޽/Oxx&#OPO3]y
A`h^}s#QAN$&>o8!J`@S7{q 7rmq%xUu{ζq&p$/!~.gor{hn!
׀7oA|wwmrFr{qkЃamF-74e7O(}Ƅ!o
mvomip`\	$F|hy}&ijjrVo]i&pЇ`*pr tH+fjjc҆pdxn
8fazihr *mG$j-`0kd8:* 5(&k#qPsdh8Iq`fY#sHƍ-P3ie¨df(CSf؊(dDfI^VgɎCq_C##h.]挂 Ae_ (QJ0`7UIfE5ؘWGipEbF^I'!	#X\`qfu^!YX``k^%}v
ezY\M7!Rg՘c+╗Zpah ZqP3Lgm@c $S)!s)𘧑qiA_@]}OJ[bY>R	e
Q% ^Yp$XPv@]i$#v
`D&0Gv@c `~w\o#@`܉v]I%WuN

PgF#OEP\
tq%J$zyq_@VP&*(:*
Ԣv90RDZD:	9
Vڄ@N%0Fr	8SpX%HjmѠLڤ9Rhca6)p0wTN%zUiЀ3
e@ePVZ`	:"c>zVz	46Rr6#i@E
ꩳ/Z*vbR*	/5A]	k4֢}ԵI*7Dm
p&FOR鹛&਒gJ&_iPS`m 53 S(EOZEcZ		ưԵTQ}s@_/	5JpQ	UjhIQzUÐ$7{Wi@cymJ窱hOIJKDԲ@cZP˴fPd	%%	5^[芣絤I:Iv6pG	h
QoKg2Rn;&l۞˸1bQS6
걦ZB	:ps+_1amaD~i+
%#WJc\1	
4[/Nokdk(*嚱{Ú;	ˮrk/
f
<	K`rGFQʴ۸ܔo;XK[5[!`ˡ"Zgdi+dKkڮPKz["'೗1	=WgQl;+4K]PuZl+9)
dVp h?KtRT@qJ@:pJ;YͪØ;ii7z	$>Ħp	ɻkf	෾ ɳ`QS$ɋRоpČ'`')ZˌRxd%̜̈\s	/n˭l0̔r7hIʛ`#ʼJ,N$Ǿ񆼖}	dW*ʌl+aɼ(Ƽ	
cKѵȖЗɦNNy\	:5ZP\	`	_,dMlŧT!яR\59J-MK=<=ZFvZЭi1j	ԥnK=ҮZ4	_$,Kc\C+aD˭ި%`QEŒ>k`,k<,ŗmx(2LMial(%Z*jP$L^:MǠT6^ENk*Ƽ^F4#]`ȝ ʚЃ$G锣~ۚ!T]	#$-%wżR#Nu _(4wD" TYwP6(o,ѯ2eF0ҝe=]&
C$q=ɊMy	2
ie	G8/т#LiczU#:6oIO-ERaO͡>@/UJ癘	O[C2Yj	O<qz2')$hyO_폱YlP=.K3^p3A]yfY̏1NʕqZ6Q	)_Nۑhiihhihhh
hi	ɓҶ
ٗ
h
h̳
h*XHӃI 퀄rDCӊ;x11ie_Gh3eAIiZ2W
ҚXіgIEhVk$Fŭ
:j@GxsXQ֭h)0P[NoAMnjDh@o:{sEe=뷱EM\춃[r˰mik!0@oҞMӶ`Lu4pui.jwZH=msӉeG*ڲߦu
$^hIJUz/@w@'	~wa%ޥӀ-!C'R`9`A;>@@FR";9H69(ӌqtcG0JӔDg%%X
 @5)	
g@
Lmhf(U'C_2fx|bJU$'tzC.i
YA%
У`@kQzire};2@ f}Bڗ}MjT;("$ɱg&U6˫q"$e!/jgl,k~M	#zN碯钠~SzҎޟ|!ˣE3B+!З'}4!o5#!s}|ϷٮT,(P!JCoBC-n}htWBM`,*<a4XTDbŁIM
TMiEA!X`i W	[Qk#Q;Fh
!C*/Q
Pq-h[aMCPAl폀 sDC,Q Ff?Q,AipEJa!MPGbIVQЮCl̥.w4L-yIbQ%i93Ure(.&PL%4xUш("Q~eR
0*v3g̿	
|>ODD@iX,D:iP`BSأbjЀ^!HhG=vOk,Nҕ"(#%T,u_y$Ҕ)ЀªA\^؀RH@|iAQ񠂃@\ZX\MGւ~L|hXb4H +:՟d0g&:g"C6}
59@Y#P&	&[SL#7tECVˀ23\/D-ܩ-k]+ӸFk,h{[Z4@mM6I'b^Ls1ŭ$0+WrU.Q[hE]K='XCWnگR-ykM@Á`**!$d1	qQFL(&UP;~};	#"
]}܀PU	ko[QGq!9Tˆ@!HGNdpƖZ6x71bHpfITŀƇp8PVMZ*}*xiڞAЎ>ߔ}FJt6|DcFgJșθ^ZaB=cygty./8R;B
@	u¸Hr0M{ʼ
T6uMA@F `
X{.蟨bC⹙wT
8(!,0JB[)TX?	Z]ACq-P20Ln7
pF|a5mzûehrH]zM_{i	!YbxG	zʥGIGKyD\kuQ77ag\EzMzF>	kEæ
9/,O~j?xRJPgT^$St7iz0ﶋY{OMRU)-g7lOQJO5*WgS=ER"tɁh[øk7Ql!W&lU Xa$*ujs%يʕJ*f4(ZR #J+=ZY3&	_IJdHA@p`x51Uzl)vG{민
P_zRKj:E{RU&%T3-G'cb0pC,zE1r9f6f.)c5{Bkb9+*A3U/zkJ*lxE2X1P13x1ۦY=n:5[жp+p8Y^$CRgke:hꡈpxQw%kItҹqpAhP	к[>;;UG:a~7EK*ۚƵU=DI
~e(T`Qũ4Nvɽ+){U&f՛{Y$IB`H KizF	Kʦ\{&0?<k#>Rpb.02<.<2P0,9"+括
%ZtK
D3 P/\
(  c,	vSMO|wol*W̳ Ɔ2,`3pi0\5i 11 h\0Ʌ 0(` HLmuǵ0Nl[ L k}';~|.(05?< ɍ0dl,c,0P3~[<1`̡hӅЬή2,=Y&'X
YݽL,=3ib\?K]̆E҆pmܜe`-֊=Ud\Ap]ٖ}٘ٚEp@C#Fsց. "i``d`-J,IJ3Vܤ,w43ٛ]}ݘَ
œ==,l;mĉ@l61r=/20`/ip.6pͺ
=G,:MFʝ=ދ -ψ"~(.=gmM	e,&-(]&<$~;B+41 3#PVC`b>d^f~`hq}Ք<	phe鳦j[p@l|^?nNi2
ՑǾb3h>^~븾&P.#]E=~39.kbR^)NkN:¾[->nL=C|┮|B
腮Yܡ]z΢jz0/	%,.#~ur?/wѝNŌsw~Ն!@帋cϧ |,RȈa*{D(JM$_b(#rɳϟ@s^8SIT(kb	e!AJ:TQibO`B5ZN:܊_ʕJ֪YslntaHW	=o)&x98`S#oBLh2ʚAγʗKe& 5AV6zv72QE#ipWτԭF$Ťd9B;ގi]-&Ͽ;yJ`_}^F^yV` H'b a(߅XH4)0׊AXQ,x-'A8`g)cO.4d~AU!fcpyI~2MqeO~cIqwjv8jf)RjMyksR
}uz	cF]vhvh!3zROЙk(>*XL]ahni'Z%BpZ*VGx&_BBkAoijfH(l
flM\rj*^vJQJ,Ѫ;]!7G,;nn	S k0,0,4)Bݝ*Įs'QA2 	}}B
imoy,@X
-X
`
F /M`F)6Bob@1@Æ97ĭ(4t	p(&֤H#%Z&OD 1 ~%XT3~$cD;F1j`z$h:RP$H{
XF6pN@`"$qAJB|a4IvH
%ОR#eh0J@hp\
@6 A	9^Fhwl
 1Jl``i34*Q@ 7}Q%` 	uEƴG`إ=%2T#@:jF9<d'}f@5 	9&["U$i$8R#]LA,5PpT"xhDS@2S|5AC}&=JR@K^,Ԋ6`Ӏ\B$Ӂ@GQ:5Ӭ@RQق$	hnRE_M ue"T!=QT0Lg4`7>,X+n6
a!4-j="΢UJ_KUm
tnmmNwJmi[鷥u*0ܥU@;x|kX-
~Xlp[	`DJS}^#pLܻ)@ps a	/`1`|(V1VXl,8	傕̵|hP8/L.WSf"N*p,xx|8@9>.Oe_3(e23+Q6WzS$8Rp.‹I`@X
Z\sA,[)+iTy=_:V#FFg[+lӹ(A>h#AUk'LcVv1kZ٣wT
[@$03,N3
O8iq>u}Az.80	D\vxO.	0,7PnoFb?yJMshߋ]Zf'(@l~L[`{Cվ);Noxϻ7=
|~?e;ޞy[濘{>ћ?!ջ<~v)[@e>{'=3naq#r
(\\C@8czC6kۇD[nd6oAb|r6nfk@!j=idFgf.k#tH!W=u eBf $Vdo)#dPS'
`.e;_P6-D`>!adH"HfNhPUG?aL[]_@C
p[`-`g[
'kHF
_qH]ui!B}[J1/qYh[EJu$RYrS2jP?QZ]SHC%[UFwRi0QQwդx>"u4
D(R8M
py|pNSڸwO4JgɔC	0BGihpepap<)t=B04CEM@iwRЙ	g1ʖpYi-UI	0CI.)T [B`Þ˩p~b7y,G)I<>*`@0d1L4k
[	EĹΐLBty~@Ariة!hP"$(T-L	DKY?j>B)רF3
fásl@Y/ias0EɜA:pJLg癓eT::l*	I
	;pPgXVipf(l
Tk3kŤl
"cIzf49թ[x<yz
@Llp-Qk	gL	
'Ίnf#A&`ݪ\J3tlHi:$Ezaf8
0X8eYטLu?ѠFl]ɬ2qJ	<ʉB0:fYDv֘hE9TRPRT*Ϻ5ѱ
a)S4|}sC	sA#UZ	EN%y:˭8E*YkJhkk9
uiua*]$@f1U]+	c@
*j0mjkETK,5BQ~s3QTP2@Gyy?ZdI&U,:Dڷ A6UiYzyPԸPTjBf(ISz[qJ𫜻	2n;YTsd3dpd^t	EC	f>wf~ӛ[#ʳ2QoS(w$jF׆_9fc++ħ/EBEy,žK,GUd,|œС˅\dh5	؜ }P}Y/er8͍`I;Tk$M,	
f5Mi_@(bP΋љV_WҚ 'C&
$͓.	i5Upt_%_7]<П"X(cӌauƜ(
^PfZM=
o(GF֊*65X^MiM>\VVq
${va&`B
y,k9H5hkiT\Pivfr(jgנM|}06Vg^&vrk9rVpopm}vflXGs$'1-r}of~q;ܚ1X~G1
7}z=~z.Kَ~aߟ'KaជK{!Gl◧┑p3+02WpP>4yV\k/PBL
g
9;GI.HO9n^1	NNWR&`]51BdCl9b9"	Du>**|~阞#'#\;j~斱}i`9tAvΐ{."2խH]i~_鷜+.yyaX$6݆XtSY
h"Ϛo'e	
$(*/=
M&UX8*[
3iưvaL!@_BO(Pz?g`k]?XI^U>7t_vow]4I3ԡ.UR0"|.،poH隟l:[D_TEtpj"n0ܴwWD) WI3t'epEĤ Ncd](hy)~hm8P?~oџpmPqR
iihhhh	hh

ih
i
i
iѫЋ(D$
ZJa*zӪ]3AgA TGߦ6sI͛53?X5 @4,T8@A
Ji7"6I^fȪ]˶m!n]d$0n5b
'hL(
+&*8Ӄ2XLǠCNxtŊnYՀ&+$,p` Mp{  ٬P9{	u"ՆνËr~ML7$	x_3`S4
8ͷ
`Y&QgL +1TE(VhypG!B#mX@D$bR8:6b"!Z*8Ј7،@eL rg5'X\v^"!A	hifH.!bTbI@a:aIO
j6&!m&rX %fxIxJ蘆i:aD*ToņFԒƓVߤQ̦jN"F؞v8^zI꠬[-uCR)b$맻ZƫhYF(E?
|r.a
{r!hH.@*V]1t'KcHG$#4۬tƫ%/w2?,$p3+n)7
PH[yflKM\>crNւV|@/!Gò۔wrgcw砇.er^ osTs[Ҭ:f
'@.5A[
9IM>n
2@oYcM!¿o>>hTu"B!,>=4qn[u#}8ZO$PS
SwBmqpj#gR6H" 6S(@Ȱ]h"iA	 D
d *zZ1$41x`1x4XȢE|QQa DG1A@ E6Ҋ`$Xdx@@05 5Hf0NQQL
DHb6c<@Dg|ǿxq\D3`\9^.0cPhib032@4W,gMS-Cz'V 2 .cPEL3
hE(@(1gILDmlc,Ei28$湚z7'~ϖƁ6A:KFfi!hI3
$6oT =P]TJ[RsBIM+8C#*T.Q最N
.HSbTIf-Ib_T] i0@CI΁^l!סbm|C;+TœAM4E)y˭n9J>πMBЈe&wyxγ1J[Wh5#W£4GMK/h?
ʉ԰50Mbtw8W+o}=~5=8/`F

Mmظ6mYgn'HSmX/IB@cь|厷Q|޷o[x£Qp_;^-R8b=`}bٕfh7}~_!Wk=Z<=?So|6,_O$
>Sl}^߷><77Sj~?V`@ϿO!~jW|gwzwlF7|H'w8x=P~kg/ڷԁ5"8H$h4qy.aт0(F24,6xE1ӂ>c@;,=XtLx>NhPx*R8S! GZU:Xf8zŀa%kp(ť(mOe|؇9w	{臈c!$ E#	(FC}F&0)-h0mP%
ҋF!(Y*0Ux)0É
}RqmPX*ݦhxhnȉp XS5ȏd@gAho$X	f)cXv+
	w!~)*)q`)W%@3l#P7zO(+)g`F#- *g;P)K76I9p%0^yvGg >g>U'g2IwdVs	3w0`8hg
 q#~a24<x>##cI9)#𗶩$)0"Ka>E-	`/
&dYX-ai
'Н\@qi
iX#	 :I"İ	#y!)A*iCP)&*&g		"v-z
-Pڣ 	g'PyBPgg
C:@oFjhWZ
;PKGj%eePK+AOEBPS/img/strep051.gif-DһGIF89a9倀@@@???999000   rrr```pppPPPooo///___OOOgggvvv;;;


JJJnnn:::,,,yyy<<<777xxxͤ666UUUXXXsss***VVVlll888SSSwwwttt|||+++RRRFFF]]]'''˒CCCqqq~~~ccc¥uuuaaa[[[YYYfffTTT...IIIWWW^^^\\\EEEeee333HHH===mmm444NNN---!,9ȫ`A	0!>\0!Ċ

bxQbGyI4qdI$Td”Wlˁ0Is͚8o
)'ϟ>*@PB*PkA+Ԩgͺkی=Rn\s{b^K6%(ңJ2
LبĈ+xʘ'7>Xrd[^ZhӥٞVj׭þ-KWB'nDyQwo}wy3=Czs3_מ:…;=6꯵Ǧ'ɕ?ⳟ-$@54=LE3ѱ*'ZGSҌ47BM;N
8KO߲U-SW,b&MPIHBv'O®$QiͿ6@!(ζ38Abȭ翊
L[vk:nr7
fw-Zp}O;ڔ{Ct`A67q^%GN(OW
њº;NsA&4^|9}!I7\6;z<Hn-9Pw

"Nc;@<@v<[2uv$] "o<8~/ @Iwk\y[pqbÂX'(w""0'?*0z=Wx',@'${7~lL~guoZ`l30 \K#nOa3-5&#"wX($P78	1hsZ!'{Rn4>ɷg~)mߖ.hW e#+@qa]%?'vB6Fn*F7?E7Pa{4g+~ pzzpDz&Pu'L`5P&N0Op[&p	8nx8 s\--3^B/#3)c^1Rg[81QJ#Pۃ3D5PX&eb#Y;Yx zGMƇ	0T,`Swȅ.> 9?pkAfHsA@ƶiV`78Ũ ;r(&V-mF7b[z>6b8@553]*.iWw)wzħ`}+HxŠ!r'BXI= 0pI0mƑ6IЋ2X/$i.7`j .R93C;A"bԤUy8$%֢7;y41j2Y%3aQx'p*@g|+7}c؇}h{؅i~	-2P4;
`@lvrH^Py@c#.%).6`jLaPbM:(
?=TkٖoIֹ!0Q@EXV`p 
BP?`yɞ
)B5lAcV6DA*%`2(6./e,BU+I	?Ôѹy#ZE`LCM0*4j8;:*+
(R93sF䨢BQ晞)bzS9j:&|CGKgɜj
ɖm:o *$jvzʧ1:5zpx/tIUJ
&
g
*RQ}p}!!#J~ڐ)ɡ;`psZw{:915%xS6 1Y|8#횦ŦtW@+Īꂓd($tKz|'}gD|`}D+@Ǵ }
	WZ1 񪡴j Nuyf	Pepx`Ś!o>{`BRh=GXIxsGʧ\9!]! *ZgN`C0	`"0SP/<*	^j74kx,&Pz,HHIz)szXȏ2ⅵwp F`jwx"@	@@ 
;.?`+j9<\|xL޻!콬lY( %YK"d{
*oY*K^e01crNPR=]Aͣ0%s;13={
q :kVXZ
G{ʫRu!~*
M.Mfʪf
Q~ '[>\1 pP+[=@0=)z Q-B#vtH/p6ĻPøJ rɎ,iӔm|0V
(0
ڈ(tpS]}
خm˫ۻI,FPK
>
|J֭p ܭ@N.00N0`Nk	VǙ"0(>*mJ2P3NNu8ӀjFPR.b0r= Cnpr>t^v~xy^*?t-*}sZJ`zWp(y0C2PoNSϼ(`Tͯ-v0m	
L~J_M肝~=_?>
㰻{`Z'քݲZmm`;ʞ0>.pCp;]Ӆ۵imjP#6>Ls(`nt@n?|pT0+iWp rH&b`0vCQ]*P&rvr18nK
iAL2 0?ٴwv(%SdXE>c\sяbi_O]fg8ZoKfeCQlWePd*SF`X PBg"&Pa"o#Ka?HQ6_t`JD2'Iz#hߙZ*qu岟rr 3_#{hamVa@tA9,pD+0TnETexTTr4Q68%4=N4E1J	$XA	.dC%NXѢA/nLjD
 8
2@`C
ve p
x18JQI.e*0#QN(rWЪTn+a%*ևʮe-ȧo=[yQc_T7
c!O8
7y䵘gС]:ȁ4$).
#5!.쒠rm18pt/HsH8(J
%܎׀/ 	:G36	ϧ}Ki0xg h4x`7`	~2`CC&(H<p	4ijDhCK˯G,{p D4qۉu 9uM6cTH,A1K,,p#h`
EAD$0l.F.lK=!컓R:0FkE@JS>3OM#:SRR	TcS2Y*uW8u[>_*Xc5XeBYh'c6Z,kEv[;`Zn[l\4]$Wؕw-pww_w#ȍ_VWV`#"بS/>j7v !Dxd+9vs`5cvhew*f
`gv沁*6hVzivi}:Ooҁwzkkflj.X]NH`mvm{n8*$""+>pv8lH@7NyKM 7RX˝BGGz(h#WAIz9ÿd$@ZȂP6/xT#0	jVNd+qۅx
b1m	 
rg@
*$L" :݈|P 
b7]T,О*
HqXitĖ?Cxt158H`IPQv.1y;34=i"TWUU4PL}S%L:j'[uNC5"+FQ_QrzelcXFVle+[X2xjІV%miM{ZXEemk]K/,5	lV+W"r՜O75lMB>oRƮhS[O~6rѿs [@@2@@@
@@
<
	|,LA\AlnA>NyA<
YA?4ir]/ʯ"lA!"2%V̊Ž8¾HŽ0!H࠰Bb4d-ȿ)0^R"_zh婪CChC7m;*<+GTT;?5@EAUBCuDEFHIJuG$T8RQ% QRSUT}UVWR94]մ^6:=a5bE_eU3SN
T=hj=lVjOeopThrVtku=Wu5WPU^ՌWz
ZWSE}u~Ղ5؂5X-؃%UXM؆X؅%XX
؎؄-@ق5Y`Yuف
YYY^YٓMٗڙڛ%ڝ5Z
ږ٥UژeڧuښکZHXڂڂگZ%%XMؿ
$;][k[8[x[7c[*
{	ܾ55@H<lx2kK\tjxi2
JÍM#
B?i4h\[	\	x3=@c<5|30Hq8i>M͖sHNÉ؅Ӗ1̀4	޼
'	^
_:P]Khߤ3	^4%	ȳ3 `C0I:6d\`UU	xH`';`ɷ BcaZڅR7ÉNKaЉÉ!\Q<"6c^M[`'(.@赭Xz; @2#뽏+i{ Vc"+G7Q8e؅D
1*䗈3Е<(\M1@\8ĭM8݄ߝX5^O<<bfn[
7~f8W]kVd3K_Eԝr&g	nhiۺp252#"9 kg|Kcֵ݌XTkXIf?!h9]MfX\%aNlf>lhMŶn3lǞlll^Ͷ8P6m6XmRvSӆ>RQmmnpm>fv>V6emh-.oVo&vo~oWwtw
pnpeU~Eg
Lx{p

WpXqq'
B23wWq-ew.pr!/rvWppp&zM
%wr}
'Gq%r+.0,'Oq675W8gqHٶ>^?@A7nnHt.nInK/GRLGMWNgO?Xo^oIJuXuYuZu_g[ul&O86vFTv<`NЖv=fkMi_VuMk:`1w5Ik dBgf$
vڨfPp=wVeOvNf~w
[8ipXƶ'l	P__%+83@	;
'^"+]x=glh`?(s3
hC?G
~dwax(s~gAnHr[梘
%sxg/W0ڸmķPQ(q
؅Ⓤa(/	.GkǚY0ߗ'
ɛ`:k	<ڨweh~{P?q|!8gfQq|(G[w1kWqr
0@^v
`W.lXP.	.@!C
-d65acǏ#0aL'РwM)(ҤJ2m)ԨRR֬>1:vF$ʀI:D`a0SFpąBuCH])x5q@HVU3ТG.miV>9v&X]Jxfg	ggl4okU:X(;zڙ-q<@״-;Ǔ/4@` @@G#2@CLu/~5^	nE\^/WMwJ{dy-"1:5x7#=JU>
)cCy$I*UE2$QGTFwR䤖]zS)Q6ed c%m$@)&R8`A_Ũl'=)Q	Bx}AxI4^XŨbʡAtR[,X%S(ʀ~h6PZj꺫y:hA$)P8b$B
 D$KB
80ܱ_Iଲebw'bB;ŅK8[Y;Ri:0UO-HwQ4A\QW1}wY$8jfIY/l	}
/xUI7E'ٌW`,_K,iP$LmH54ݶ1j7k>R7=:fDd^6ՏO$6\GߠM-4Y3:)Ԉ7g?OFԒE:K@Nl	_\?OxWD_5M@|
aqNSHqX	KKܣB"JK!;.p$nS#-{CŽL|t)R1"D!2H80DRÀigHY|(A"	_!x"qhVE2G")Io$%3	%i¤&C$N<,%*u29+c"ɲ<%.C\疼%iv	LIq%VccO+Y_JJɠ5lr>7)Nрs5SUծ~5c-kPQa ]׾5
ΈA>6}Z--iS|ms{ڡn6`q>7mphwms˻^7]`7.3w~SuB"Y|PܳTwBB^?
yw+*<2e: rGL-Dp#>.S=LEgA$1jLSG4d5MCRdM1j$	
HR]I$JJ$/#Z$LƤLG$GJ[N$OOU	NP6d
eA98?BQJOh1s
<X>@s	U6%VDRPWkY2FDBXZJ

X.=@q!TDq[c%
Dl%/t
h	d(%E벵j6k(-ê[J-)ÖQd[:,q&Qlr[~n,R(ʦʮ,˶,vF,ͺ,
3R%ΎnTT(7,:#"0팰k(cP̟N_YDKLϭ|?^Dbq8HAOum@$^_|YP

@KmP8初0"Dt0.P,IHPn)F\@r.}H6^OLCPn]OK̷ܞa7c	iEOt
R .Z%fdrDa8n,{JvSLrIB\oG~6a`_|H_JKRNO{P4NT`@:֨]onlE:b@!ob+o0d!]LKb]	O^Nϲ$n"!OTRG_hBTt>`1_Q-4a{61@$=q#&h8bXG0q(}DOʬDф*1aTpM\vo6\-!w%2T5y2!1<ٯ*?D?"-I	>հ/%UX5_1י.@.<35C1ד4'O6
CTX7C(TMo9,KI:#E;KS3#N=ORR)@@4AA4B't@$YLFDO4Y#Hna!E3hqG
H_H!@(FӎJGOpfN'gH ܖG5('L(lO_P,5RP9?t۵fzhh~maVjyx1	yxH5i
u]"5Ss	<@l+QT&ca(@ljVjb(tuPuQXJ&q|~%srg
a'q\\0>SehDYfOEhpjSA+yvk74RQliVpjvApkyk*WFo_ywd;$d%w{Xa5sV+b6pvGRlVz*a"
`Nؕ*smZׁc6JUO|7xĶDK	˷&ٵ}#Xć#Ɇ&wOQBgV2O/p/+5IWwZ&S'~؋@s8|r@l!rƉk[uwl5m4w	XofXtg~y	8'x98Fw)z(sf5Wy6cx+
SF<]O{ieoYgh6yzqgTz<2lRe*ti:vey&o#J3֦z1orV+6;W(Y[űcLDkuAYW@s}xq@vF_d;|$708|6&{J8P2V5o4oc:ώ㥻	DSʯDy#DqAԼ<<<|2w#-&s[,!GO5O='}+<|=؇؏=ٟٗ=ڧگ=׿=}R@ST׽5q<331:3ѽ7?>GU0{SW~,=o~)u~&*RLJK@G~A̾>>~*uD#D(3D8'S[7ksG
@*DtD
^v8p@"<`C:|EG`“$MLIpˁ1[eM7iӦN08ItёH	*tӡER]j)֩Ir5+حMj6,ڱQ˲=6-\08Iwݑx	w߹ukX$'3l8(НBYJFIcsADTٱ˗0cʜI)?6s3ŵ@
usѣHMʴSTKJJUNԪXjruׯ`t
KYcϪ]Bڶpj}+]t3/߿a
L	È+^̸ǐ#KL˘3kiϠCMdzkXͺװc˞M۸sͻNŷE]92wN&ճ[vjY3@`Bs+
:T I"
te)Rn)k,.3 r7w0YfZfK2YC&of+]udX	
Qa\`]u22X/_s[315|Z9H +D/htlLWZeI=MV;4'p4>ˎ։]vjǝmbxAwvÝw6j%5:z7ލסz9c)\0,6l`+aLN`kXiMX&((\{҈Rx[&-vCˈ$Nۧ( o߄ 
<@~Ҁ$#@x/h4|~,oX#1[,@#?րu{"/uKP1D<Эy[cw9@W0v2|7$ %#ؒ,"EQn8
wDh
nbpecJU3jXRD`9L#)8+|?)SBPFsP^= :P%CzaYu/ҀbPgΨ@E"`ZaΫ<<_JtC%Wc}Tz
xKMz|KdYPֈ]A]0`\&(p	\51B:D	5
[š	>1{81GLҴzA):"~ųXPD^qUd|	saH?O+6~c]OsKT-Y+MʓI<1g[H
Y~Xnהc["D`}9+aʘuYD-Z	J3M·\l;?c%O4	LC>`btqS҇骀)&t;#Ջ;*tDZ>߱A*nJ^p"Sl@@ejlv1Fн:}zl16CmMQ1mFebXTʀbѲ
;MDy
R;X	Ԯik%KyZ@qC
@zj|GR1`Dppc ]J(Ò:0,WCou}_7Kpv/+mӅtyMՔa_;fK~PI8%c%F34ZM PZs!2yim)[4's	2E7C'7|p`Ij^gP$*m{/*d	@[7aLh
 "T@V HAe_%J,Hp,a%	+j,"%&sE)CxϠiSJX^'UHB16.'4q2`){E0R IHnWrrG(po
~03X)80#.~"
p{bD=;>	8hmvXx:8s rӈAHfBRa"tX"=WvO،‡bd'[VdaP @HdtY&1o(u|˘.%#$.C
!#)LW
*$%E{r$$P{W%W"X'L\@aK1~W
kc +i(}2'mb'x"
vAy%iG	I9*հ6r?L"B0
)
)KЖ6faf+.y>Eb"J7F**9*guلIy˨.=$n$h0,?f,ȲI	w"a)PQ=\-%2.P.ÙCqU~H0ex/mP

c0Si
{%Ch*
F깘9	7EFX
00QZ(J|'*,j1	XwX6.38ڣ-ȣDrJJFbפ;TRjyCZOXH:aS`bdtizg`On:[j|]ymZBYq2A|ʐ{:M!Z~jy|azMPzzGP^:
ڪC0zjf`ګºzĚ<`F!К
:z6ЭڰB:
Z0Ѭ.J
:*p縬Z&pP;q-Q˱	Rb(AQuEt,T/&;C7:{^*;@]={$A[; bJCۮKմ1@rP[녴("65ڵ/\)@r''${bX!RKdsk K$-;m~Qu;:j(9OyvʷCr>0>kK丬Px#˹9rƹ<źK!{˺1Mq3+fN+뺠ۻ+:p<қ,{*`/+̫˾K(0R`y{+߫6@r+7Hǣ[e|(*Q@,Ll$%-L:/L)#+1l3<8l
,A|U,vPT$)DZX9TP䑇4McΐC^\޻^>`n WPVr'dhL<^egnk>~\'=E26'pHZ)P׽%@}+~<mbnЂ3IHP$=0NF=#Y^
3
0
!v[R,E>;z6	>~'`AB߭z;],	7G@$o@?~_H7zo% 1dg$@G>QLNPQ?R_VMFX\Z`;doc_hlTmp0.wu~o40<@;_a)/Sx,/>,06B/l/S7Q,Iϭe#rg'BP? GJPf-LFƂR~v=2A>sS@IT.psy"1
<}40PhT=|:K݋~ @$?C)3 -YEP &1h=$IV\b, tE<XAu
@(-؍1m2it#8.4;o)EP+XŖaרѸe͚C(< _c[go#X5(K/$0@At>ՀK9:"D%K@,+]cI&&l2L3JPl	.H$GsTP/"YL(4q)qZcyd@m4+ v7Lpv[D&0`Ձw$&_!sذwWЈ-KejL-]`^z~\jG4*Nsxo|NMmЍ/<փ??ww}Q6˱/	hLOxa,wCj
tk	qNyMo.N •
wY)5ЀhEYhx3;)hH<&N
^caJ	)8@/`bW
e	aQxG!CZdM*ɡ
~Ơ}n"hxZdDm(+^
 @$.TJP@"%
Zm13	z+b&q7 VbP$
clG4c&DJV@,TrZ	RKVdk(@1Q-	
ܲ,k29J'v:,pzi>lǩte#TjnVh&lF
m	Ә+T&p	<0X
J(Ƙ0\HkߢWI3#;tCO2O:;p@tQcBqGTT?
+K7}WJ٦V,GT>GXSKG-
BdlBPЦj}%D.̌ɡa#'JJM-=I[b).: iH%2#$[y6	%,3!KвƔ1(IavD_.aM`%xWb*/x.-hB쵱QxzqM&"N5G<8t'%	|(EPqL+u@찖4!S:;ɫ@X*MG~u'0@JRfPN}I"PS
h 3F$
F*̓@˼PzsJ<$r~ͪTIPKI-Xס|7
W,shRx=^)-lԐUmWYذnVZjjYΑ`q)|n8haZ^"GX/%Du{~hLA}2nǠSZE_MG/"\FcFr2g1F_wM՜Cgʨ

gF7L
fJWZ҈tN]Hyвu4ӪȞͦ&2[;CџN5cm:s1qml={:i:OBce;ەеW{‚lm٥6lv{&6kt{Xb8K/=i<
pyNh[/<7MLjKuLkjs1ڱ\H|>x8]~wvnɋg{x0W?8
^)#/zϺz/t~}ƇUȸ;t>
2y -  _9`)`UrZaJR 	Z	 ` Չ`
]
_ aݠ*!y`Uu`Y"rjq!aa aJ\fa "U(b "	b!k"#B \$RbkTb$Ojdb$nQ'Vb€"$f"(B"!!&*.#+(ʢ ^b-&-.Jb)L0*cA2v,3'2-B#Ic2~b550cRԱP3":F
#2:ڎ;~WF7c8#Ar9Rp3%#b<.BbD#=d;.[G^H@
$8DA2*$!HHC$?ncARc~'Q^gf"'yb"epj'wr_fuCй'jx\zyF`evʧn~f瀪d}#}q2x~ijiFh{g]szd~QN(@hbbgҠT$֣Wz(&jd}%s~#bR(d3^|¨JV(xreq6d^|$h.(E"(joiƦ2de.#⧕ƨ&)2))>hJJ.it2eh+iL.(iF)_頲j:*n*iޥe6*BY⤞~jjwhJdhZ*vjV)uV+F~\**r+kJg:)BhRkƫB>깺
nkΫh2샚6v+¾)F6+k¶kjJl;z+&*Nʢ+VȒ,#+*h2騲h+~h>,e:A>Ӛ#.6-.kެͶlb#hƖB,kΎźmkr,,ʦ볪'!
EE=؃[\ ri	b)pAKV5 NS`	A@Sb
k g`(Gb) ~IYrcbM"p蒂[
"Ro [DE	A!*D`b碥vN	F. l. 7PD g\.oj) 2b(" ^( " Eo	R("vn &
5V .K	X Z0o_Q`	Ppb!0/ /wA!A!`P"q

60 Enp({A񞕱*qQ
h@ W
#sw0 j	BWpqq41"3p?m7
Iq*

$2gp(r
8@epEp#cQ!+	 sCP30kq+
D1#~sf
q G+_-3-33qs'{2@I?0O3/33@>3B3]6C=8sA0N:3
G
c3-C3;OP>3l
:r)_	&˴$;3;wH/_׳=sp-'u%9TLs3j
t\CqH4M CHt	H36G@ uM5:5tN햳erRu[4Q{{5	CdB83QVTu"NP6`{Aa))8rlO:&A@"É4vT@658v+svn^noc X.fk/\vvqP
Qsl_qKqiqo753)51
vX7}@zǀ&rwS|Gzn}W7A7
é?q/#vЀx/R17|ӕn58y8(l!Vd8낉
2g3{hO!zC7ؓ(
Hһ\(s
w
{H+vyNxBX91@Gn!Y	_z2P1DɡGwg96t7khro ZW#1n0DXâ6	hI$@?DE	DFK5V!'33OhnX;M3SLJs| %hiP	%U
37;x/G\8@g0@t/](|݅8|Mч3R{QVipuË%'4
35E:܃.$@-<+O<]|g=#3CMKG=tEXP|(@,p
K4;gy|S=}=!ܽ+NGߛԻ}Ͻ
l=(8|5(iHm>Ž'}ޛ/=w>~^}>;pdP	D3d%X~:>'׾>鳾'˾~裀ÕȧXA'ws>;?@HS&gO2]wA@(2"!JdxtFz"[s C  ?@cD,;
|	(8HXEsCCģY	#sʓZ
3[Sۘc:B@P&2Л\|2R2y͍I9Y#:nڮ
*Jߕ/0 <0!:4ÈhF7H#7Qɔ+C)פOFiΔ@Dy"'e&񥖡r`$pFa^`CN6َnPX\GVri!R@H*/OZF
+؃R=`
(/$kf
L2q%`Іvc,Fy36z/X;؊Os@^`׀~a	-Au\j]2 mHTТ`D	J/|\
.#c!DxFoIy
,q+<"13kV&OZcrX2%zXklE[A}:_knF"c`)xigۢ%?3C"%hDOs^\qBę&=0at BsE@Z)#E"ӳr}iqW"a~(!l[%VimZٸ#iHQ.r)U7C`JJ{ST}F6eT%Jvg&
kfI) H̉tәbzߤiƍYVFڌD@<ۜW[Q[gt7̫f",V,ѱkx	Y&РHXpmDYT~cGҮU`B^\@k³nlG-yM^捹]qEk3iKS3>[.Fa/-Lzϴ-Nk,
FbF{,Vc608gU5{`E^Han+}RAD7cf')+Ȃ&X4k@d BPe%e:؂A(CHEhGl?KȄMOHhjQHUhWYqfS|Z(cHehEER|goqxlR޳oZvDjv4Cm(hBVMDT^4Fb Otr4"A艟#tEZS:%=XF1r0ȠS&(UQVm8WfH5[TQIQm53UNX{Hh(@VUߥN5U~#͈ȏht(L0fcIbm0U#B(c$)y=d$e;!QF	!)e;PK5N?8:8PK+AOEBPS/img/strep060.gifgpGIF89a????߀@@@///___oooOOO999ζJJJ```


రrrr000   ХPPPppp+++;;;wwwhhhYYYצ!!!BBB:::ŢuuuȂRRRbbb>>>GGG,,,QQQړaaa111ddd!,?l%-/)k.&Ň"
ή+&*֢uskV%)\ȰÇ3	&KџJ	\S\ɲKIZ,k/0AT20ѣH*S*V"h
>%Bկ`Êmh)VP80RQ!x;싧kD0亮>luѢǐ#']T%kb0A"LxLsHhA
Os<ՂƲsm)VE!/_\U
 PhA*pS=okO)H&Ͼ=K-	~uD(Ͽ"	6%"T4sz !"Aa&cP|b)㎺Ң0V##GFY?
iH*ɠ"N>嘐Qb
^dCP)dH?xI@FH#LLҙ#	A&jN	~ JQ$P/A꒚lj@8>I*>dAE$Ё
	;l:Ķc*듫ƪb@!V+:oTɆIPn:*03
%2Fdk|ƻd{5@=ɲ!$AQʚ@7r"lr/Ü 	(V@ 4GC ID̓E"*G- :!)H|`wƍܬ1/x*OilJۭҮdw+0@
aGI	#9 KvlP:@ty@%vt!UήZbH%("{9+F>0p|D8kRͫMAॷ-l=:W^/?$Ih>7g`}PH
(5lP5-Y jǸCN!#\p-Hb06(ob=0Y@m
IˠQabm_QU˜AnXlT@	46V	v˝v׻9p~("#rׂ%Q$X(E`^Y,E#bC`jEF>R`(G{kml?x&/R4#[8yg[|I+<.T_P
$7=f9]@6@zv}W\pq:Ik8-Y+/{/4몮]YۇU3ɦH>s,aȑt a^q0%b6$(%n.>b	!LFK̔@@O.G lSÎ^؝`4kٖL'myN&DЧ$
˫Bm?8^mr޷1D1$h
ҞoC'ѳ>"1Cڻ+:G oc/
y
n̾	Ss/NjuVo\jMAzuٓ`Fd@$D5lrYAAi%Y}u>%A—ՄbĻGPw{&YHg8s3GU	֟|>yD">Du 81͇}*NceN2Ϸ%񌀤SzLl&p>y''H ){w$	
h1j#=~<"3RaWA!/X{ꐁe:w@(H;!N)-!
-Ps'2-@r[ՠPT1#GQ(BU/R
Gc_ޠ`5ؐ֠
wH2jqjkl}*u
wp=_(	X#nh
ȉh"/h+gXqxﱊ芗)Ch砋}xܑ(ь͇,!ŋah҈s-	X1>
V긆H52* +ȏڅ:32c8e
/$}v!_c4(u,
	&&>P.1B8Q;/#5s%i9)	w3uHJLٔNb 0xB6_pl	 Xs-Ⱥ0
9"vWi]ԄRg'nVuVZ
`_l9qQ
4TB6"hK*lG*MJ3#8,J9'@y쐬`u.b/AEbe:aP:S۲VU[ۏZ^𱏀CUJi[Xn%0\b1%ycm=csR˷}ҹ;P +-y~r?6rFS$(o6FnrEXph!zx9{
{d9IT7>O5@@Xp	@/{ī۾jۼgSD-HHA0@cL}:yj7f{[KLKQ9PKPu6_v;k|9ȶ1W[M
H!Ub*tik?arU{dYxcp5/Ӂ/)p^+P/l04@ο0`163  Aχ|{\N 4
HU"ғЉp)ф(pp(L3m@Aӧ#6!6SE0#l8^d33S&o1֕i4m]>M!= oĜ#ׂ ⾂McQz˲kXhj,%ѶREr[Gۚ̓G==}	 䨶}yz؉@M6:EӕGL*:v{n}o8llv5(o3 q4gwӽS^WFf	4bd}hĖ݂`,ɢ }-3p7ͽ<3 l9B_ݿJʓFZըs-zWZ͍ CZ#CkZ$ۉY;TL.^60
uFQU>Wk\
 PD	4 ̉ᶑ&Pa.c>ve>!0u
	Gs&My{NA}~-{]4l @nlo>(hnu
L\0t.Mq0鷦-*2#GmM">	M6#5L>
}
Ѕ1ݼko|؄GĞy=0vM"3Pݣ##$L࢜=A]1@0~~z	='5}(6}~=1}ݳ
2|ܭ# = (;=CR?TɛZ
+-/4݂ G]OԦMlڂj_l3:~Ǫ0U/	4`/Gjϙ2ݢ|o/~]>oح8ڃ _k@@uQ
P?_m`
A]h075ގˮ3?H{+?@tQ_ů
l!!46%&kl$;
ȧ#!742(ɜ*۝܂kbh`!͟Ik`An}WԹxaȱǏ !LFBH~WRiL#͛8s+Qϟ@
JѣH} BE)u~bIH0]&ׯ`nBٳhӪ]˶[
<U#^VL'ٷ+^KK H,H0ϠfLiN;G&LĚ59HʻF5	uuȓ+_μv
װ0:sm:@<Q> ˟O=L]Q6m{(X	7##
zF8eǑx!#|Zq
`"5!w޳iȢ +0I 6"ؙx9
݋@b3!W7_GcP5$E6DTI*)GMd`4U:RWYjG]ep4&e2Vjj&^Z9͹byWoCnHhHRG8'|裠)*bM*)Nir3ꅥbB@뮼>6l*rj3끵ҵE+ HK,`,;`]温J-"z.xmNnx+$O%kɼ{dG2/]40.$[+?X
	@*"KyQV}S|rY{(gq*;p
,cĀ,^*\͑XTKO41\{`5S0#Qz =?w|IP-sv0$}(8x{dk~eCG+0@rW~P͔
. PyV:GT:2+k8 9ty+@R
"5x6	m
P`LN`mk zUdVVbSwmwrjd@sYJŷu- naOD@hBbW,ՄzכTL<Ĺ%dHHB7=Jۏrb$ @R:FiZsI1@䰁Ʋ|'VɈ5pM'|-#Upu8ɓ09
I1U	gi,EfĀOd%~crÓsLne%fA\(`bD,X]Riss/dklJ'I4GYfãk-BjZNө=A<'S}4o_Ih
C qKZVK",g;ՂH$oߺ#;\f\Q"	9I;7)L	؟82}p(|
!c{;vs 7W5#TPԓqR@XϺַ%wvWQo$ҁv,ױiHxPձ.扶o7lGgs_lp[i̗bOpuhfg5(Xgc`2g7	s=@cvI=@&s茠%N+NXX,U2rmw	pILт{T	7	j!n$11ӌQҏg	(@!?FlOq(Xv8pf2G .c7$7GPw8qX։((I+ɒ-&fajzQ.#Fsx'ahkl|环'k
wkAgD]
PkX&(IerT9
}aF`pq)e'vfi`V#d3plPip)$hwT	wq&& G`;S-`|wI2ɔyzGTɗI{=14IוW{Ax-~DGa
g&	ةQ#	`45&FbFYOV8xY!9@:
GE1	)^)*q[)fyu$
'0$
/T	l	yc.1Yi$㱢,Ң=>Vp$f p0"e5SڟO*Fz)lPCXRk[*Xe
V\^zbNeQĦiW i	B*/Dz!_,P"=jN	G@0QPs.		*/P!

L*ֶG;e@Q		[@<9@}*		
_JJ TGZIIPfm>5	0Pz	+H
TGG	~*KVïra@P& n?9SȤ	$+$eY
A),	Zݚ @TPt2׳{.=QL01t
*<.`?0$Ǒ=|t?Ckb	y7Dy9zYCʱO<"[Ӄ⑷?*z	1YǔPe&>S$ 5z9& lRi9`@p8.3;n0t[Sz{l+Dʸ0f2k
=9Y;&з`C6E.E#ƻOlL4KN
v*e|9[AF4e$+Veuǐ$@0%;l!;,<24# #K%v+#?kj2>0l0Z
!!G<AJ`z{L 7+JcM4Ms ˙0206ūz0G#k02+VV}q]j!SYl	2,AB7"bL]ץv!30Tc7;l1/	ՎOx}!lICe#57{+U]EV[=
4!|4"]gDF}G1"?'y;4+ۅ&T)GSh,S$9&݃aJ-T;wt=\ r/͉uVxyB3]
!k;k@z	1܏RDE7f[-@\b/iɈ	"n$)TV޹]Hۻ7)<>@BÐl%Oґir{D{'aNI{s!@=噶{SN(C~hj2.Fr%
!j&9uI@6;:	ĺv/LJ2.$peΕqc{$dv`bR#F	5'єߺFldrse	QKcޯTp.šjסeʠs(^ꂎꚬM|:a5 	2F$ahk>Oq9nYn.1O̩?5P.K0$U&htse
71E蚠y%qJ*YYpNǡ IvT^'e|BަC	yeI17p¼r8O3EdĞy{$PxDbT@X2L)$h##,>#АJ,XǮ	qSdeX藯A|@1wfѧ2=6~>t5`Ge |(3ټ#>8I0m
pDĴ4$$ {+{Dercpg?GQ*#Ʉ486!B4PE+	X'>)j~d*UY##	)<("W=*}tSyH
l%`]YE]
اz~
bb!ZvM0e#Xc6UUT1~4j'YĪ5lBk.ej+HC(ſhQC6jaWΏ2pZ·ʈ*YP𸷸nZ.ճk4	N:\ZfBCIHg	U	"k#=4{+hۺWU#v%&p'#g
Q(i
ΤpX#X0.U@EtomELMoveQ:Kޙ.!d
-\3.{ټxMsk]QǍ0c~J[3^OoH*Xb{O,#oO8F;ѐ'MHCa
NR(tA]բRH(DdrRP<6A
=K`˩DvAbNfctbMj[ڒA5D)쳵tCȫ1x 0@?"ASߦYvN+;1sinvf>rNHAL#6ƒuY*oZ0̏pdxl틚Q8LFRŀnt9$ɕS8R&`	NhO%0#`5⵸ 5
D1h%C :|t3c|c)̘	G?z9>^Oݪ{nO%^ئ4M-1ܴ[~̱p<|ӦJO5OO8=WǾ~Ty"oӛ2|#gZ~~g7`p	s]]L׀	=G "8$X&wqǁ[E25TI[+x,{%jpP-p dcr\rF(2vVxXx)h+8|`P6E#>C;4^}DX`&E8xY`
^R䷀EHpp`&GwE>nA^xZ fBX6ǰ7]؊%d
hs(G3ȈL:ÆK 9XD	5%$\0(DdtȍE6R>s騄oȎxhsD3ow^Uor(	P"`	{6(؉: i@n%!ّzC:IHBx؊+9
:34	Ky˜C҆mR9צmՐia$
ɕa@)	PxW\Ly P4-LOÖ6r9{i)o0~)&	X	BEhYw٘z!ي6IEyyuY;gn@YY]xلnQ) Yiyș+i9!)̙M!rJUf"9Up^[dGAG&"tK5NIY(993\5%x)	9?y'j
XA|#%&')^;Vfv1jSC\ŢJ*]@Z9D:Fj23ʂ5:S;xk٠\JU^ʂ`bdZ7)nJp*r!tڀvz٦jJɦ"Y6	j6k{Z; !	J!}zHn$!#$Cy[C#s%q:ujA
:
 jha)j.z޸ؚ*	Oz髂j	 P6cZt:Zz:ǍȨQ:CqK"	Ɗ }Jڀ9$
p Z&aCgOl]WbWrxG:Q>[CqZ:d*Uq2 
ڳ{
";Q;4)jSi.{J_+B۵0
{w{y{+Ε]Xu^cZ+řu{J&@~};bg,@11'X~QT
pMډ;BJ	Ϛ|~kW#q/*0S'MrSPTʔʣiب
Ӫ;o==cL@ۋ	<62MW\sܮ{Q2ν)1CHlK݃ypxީQ
ݩ-	CQjTm
B
ߊmu*
%?!e5Э@j>lk4
4~v\f!/?䴰(N<.>@>c:E	]ј!j6nKlNC;NU+WYzpTЯA-t,C;Qq01oR.)^}r9I|5FYKT	'jܰю#r>;V~n@]
.1׊%T΃齞8MqrK`wncgN?'ntoX6cPW$a
Q@n:!nގ#6{|P!*ݛ0e#nr~
,0_6l,088YKDx{!ǥP~_
@!61lP0U5A@ck𙮁J'#WDgt>![	1PlP5lbO>846`!(0 0(0/,40 joln?eQ"I&۾Qт/3?0`WoT0#5O!3@40lO 0e)Jlkkkkll
kӋ#03#l388܄0,(#l4,4ll6 (77( ج346abCj#vz$D.jdDQ'K4m)qM%T`zpZb+S/,=hƳϟ|A(lĺ*|N-*0bШ[X|(#ݍq'yECs4AU(` 3hRIBε3'zMDH;ȂFYB20`ZF{Au!sdn#aӄiW
*_.TN|EW+G$|gCW3QCfB
2056[qC
ܠZ>F†4BlaVh(<\q7h8
huW%<ߴQISQR)ZiVDeM!$mZ35H`m~egqkpN[$OYlӷڕ.rZ}HD#',,l!
Ef9(} bMPxִF	eF{"WtR\	E0im`jBvyenGE$-aӬz׻yvqHI[\ޕp;KGed6S t,lD8xt^׾wQ.e\Uy( tM	@Fǐh(xx7؋.Y%Ih
'=1ay	T V	X	Ɋ
Y9[)P	}ce9HiJ3ɖRɑP0uJXn$nI,ihxI铃yٖ8&0	fdْGɘt阛*i<y:əN虊pV@V#9Y#IY))YXȜiXye@Yט$86% \ٜ]HpD	iii&Uܙ9H1IT"P9:ZzY١6H/fk0Y"\@!ٙiZd/Y+쩖-zI	|Tp=z8&A;S	TK\2"ZyЙEu6-0[jJ)zdjZShJЦ)uurP{ڣ`qjZ+eӴ:D|zCj:ejg2Ꞷ
JF|cz	er$
$V-ʜ
5nkTʫϵppz8&ŪVp̓ez4>++ꀍ:
_ b]:e~-T1kz&:g.YޚdBBJ{wﺪUf&q	Oꦝza*zw#\ײ~q̈́

!~+kZh3糙?#	3ۧ5%`+2pSp
<7]1d`	5dK
f{Yk9dq[N1Bwkyj[K$41$s{sjE{q#Q\yW/AkN3ukz'ĭʬJKh"1빤60L 1KLĹQ%KPֳz0b.@C;,{Nѻ{kD?J+GK+K+~_2[):K$k+`/<ྼq"[dFzY4z\#gk/`K$l	L"G
.`%Jv@ýP,+7 ;
<ALv+|83*@⛸S@+JsnôRH.l^͆s7j\x|;=l? 4MH&qGdc4g\Ȱ8cMڰr&s.ȑ^0K&rǞ"108)l9gPcqe<Ǣ.ړ~?($lGЉ\px٨}	%٣
*#h	E|oY]%mґk*P2]Nj7Ӊ><]-oQ?-6E-+yğ?mnAR
P֢UX>b7`eݲ:kmcimoGu=	 ;)0&]U#օ}1j¡ؐ=-0_/qs|]Zj}0pP֕ٻT/B<;-smLCl˽_T4L`or88˳^vc"O&8ĝsd91]֐ +ݲ̌|ݮ43Z"
m\2qs-uL޶ޤ-3vF/c7PnHSKZtl|%D6C:ոd|ۺM$(^Y̿ќ%A0 E5.AA+лkOkNrL2{X$p?kRK-jDYPrd" Ǿ9Uźj8T- YkwJ,0~Āal}8.
 Y@dTVcN[jcnYjO/@.ꅦ%O	a)N8 攊V$
B&Kz-+N&Ƞ3rfijUna.+8'yv.) $
ee&}`d\(a~IpnElZLlNSo-WNg"@s8QFO&"^IR+rLLP$vQk!EMltԵU>rC‚`/>$1zt8lMl%U_}s?/d#@lt,9qLmnFʝހ=.ȽC0vjQ
\ȱTش}b
% #H
1%`636Ѓxp.ROHT`@L	4De>Xʵm!Z+XKJ	
n@BB6\CͦAK`̘ʙja]g߿gt˘b^"EiB*$H]Nު0!C.G3rPO0q"ƭP>e2ZaB<؄۰}r"˟O-9}Q)O;1s%ldXpޥFLJBA%]sY0+ܧᆯ!&+D=EK0A;~5[s)`k0yh	@0]{‡H&JNDϽ_%/'pvR$3
ÒO1rjPSj'U8dqt&d,}P jZKU II'2#P:hX"y'U%o(iG)TWR$p;;+6U?lX"9,<
VƒNDծ'ڴӓ=J]*vL;ne&|
a4N>IӴ7)QJOf50.0X\S0/^2a͈$1flY5>j`ywq>ulQHZv>	(,h;SX>2:r||$]4^G0XsEBQ\9ӟ\&),QaGY%!&pNgk۪(p	8s04ie&'pΪ^+afӸYo(9WuD̦:ϸ3_1`6-HSC	SJtd?ЀSI׊ƸzZ}h"*LCDE1Rs2":0TC+Ui1m
QJ0QFahLԔ"eJ	D)X-QuK]MQ0㥢":ICwt5_jbB}0WCC`wEN<
A(K
D`Kd'kF沠(|
S|@ i2YP;=ُVpt+ޖ" @/.g\咊_q.*RWbrnޭx"^X0 X*E$\9$z/i]/3-9!f8	\i(X
l`%!+
%WP~$;e8aS9T!2FD3$aPpв.|q9a%I<.{g>)51n'"'8DreUPa6-mfOpG`
E9&}ت0(őXz+{#|\/#pG%Fkd#!+iī0gN-~O!EG0w	xmB ֡P_N|L[XϺ֯F$"B~q]"GbMӗEqb{3#
?ʀK2-XQCx=X95^w]Sz@P( O	ΏD8Yw?4(wX-}CFiB*
Q`z؟EҠ=рoe?
GC
FRWXӧ>N@뭢}Eu%C]+⿅E	!n7ݗv
da3wpuTbCRP[J0hqfsm0gD284X68PPV1PQ]@*d02D"G
$8r@]`oooG	>Vs\؅0Y;ȃ#ჷ/DD"pQ163t߷Kv88gjL'FWPc~Py롆8a?k:r%2SgVA*d%3#m/\1x|ب7^JND-1)#8W	)v	w	 )#dhfhy8Y@C)
E	Gv
e	Li	?EZ!9XWs˗
NZ葕o3!hnUHxXHR	TK–uYuôYvI	t;B!a	iktĘⅲ92瑔
֙ @a$PI.f)9i>yy
>z	mtx(PR (x	
W
Y'D{)	m 5`ˉ4323{xX	TJ˰Оǡ`)*PQ6%Ȁ
S(j	N	 @0&PHfHq	睋PQ<*E:i
&+	MDXYࣨű]dZxh*wSYRu9#dM␣Fy
jz
lz!p	D㕙~Ҁ:
WF}ׁ4o)wI&'hۇ:
j
wj
Y~B[x៽C)([ЗvXq:;
H*:Zj9`
n

fI))xXYU֊	zBZ
,˸mm;n![`;*	kOٰ)66`M7璻m3үp+Ы܀@i6WJJ
d߳?y
|:`@K9{Q5[ 	A mlk.Tj)8!
6P5(@	>{r8J.y;0ѐl,
3 ,5 +	kO[}08!KK1,P!k`l4@ȋxl(p pfӰѺ*5й# 20[# ;l`[ 3@7о3P10K5@ `j0 2@l0ܫ1@# [ۼ7ͻÈ g܀DgŠ4„{0;Ƅ)ClbLd=$[+
R
Tskŕ5d1@95@ybx22v!Ɉ@k{}
Dw&›:Ȅ$Lj,l-̼
…;˄Bܾ9jʼn{]k	[
P,':3f*ܣ|ȥ274P+0l27)eÊZKq
Ϋ\

P7ۚ1}|3*m{(ҘpҖĪxԐ B=-#X\
w,	,pmD}XF}VYғ˓&d9]Vn[ՠ2R
k@ꛫt
v͇״Gr}	vX:\1ם
*}ٜ٘ٚٞ٠"Pfim7@ή}!4
ۺ\ȱJن}g}ܤm9-lMܷ،}ZѤP݈#MQ]ܶpO:xOMp׾t%P<-m2ߵ?zc
.0;S.Qt
"n$m=>2[Zޣ>9ޖ&V>.8^E=mPbRNT;V~p^h`b-d^vڲljn~p~D>T(!zL|.wNH~]w[9r,F鄨;S>{\T0>㑞>,7\亾QZŽ~Ȟ_酭>V>~퓖k2κ+^zկp~@>5ꦞB&(o	>_E0aN-^ ?!|*%._135?0tS>?l,?n+_;}LoNo
ۮ"?FYpqZϞ9u
_f8BD1g^`k*o|
koP"	z/"*	;Y	֙9o-M3ϐa0*"QX{AbQ폓Aaj%Z>.	""G1B	_O Ϸ/)~HwU	k-l+k	k.k–kϪ&ם	➻k

k.%)*	H%*\	n#J((jdd`6Ir	Va	AIf,@esTIKD5p/իlJ\*KHXoEm@p<
سӛ6 kR\yZȹo,/@ԥp{O$ @B9~D0 }$h ʃ .,PXa3L8AW. a)B "libl')~9xT|)䟀J'@GT ;PKĝlpgpPK+AOEBPS/img/strep_setup.gifGIF87auRԚrrtԜԜttt֜ttttttԚtּtrrtܼtrr꼼t|trt4frtڴdllΌlldԴnl̖lĔlddnΌlnndlnάԴndlndt֜f4ftf4fƬtԮ4Լt4f̖dԴnl䶌tԼ4ļ4ĜtttftftĜftԮtĜ\$VԼlԼdlĤT{Ƭt꼜ԴΜ$$ʔҜ,$$$LLD<<4ޤTT¬̪4ԴּĴ¼tּĜt캜d2ܞdvv22t2td2d2t22tdԌ2vvľt꼬lrL<>dfDLV,лgt||\$vC^Fe{K)dY,m	f阝w/هehe矀لxn빉f]	]@gz&vf馜EڗvLi)]wj뭸6#ۡG)]!jjy&g655	VkmV^vSކ+ۂKia4+k,l'7G,fIb ,"lrԣ,0ǬN)l8L'sSDmH't
SKG-R7=?guC`?8uh=LXo*Ot#-=7]_6p.xp(MF=Tx҇8C3Sۃgym9HOn49璃>z밿:C.ъߎ5;ҶS쵇{n#H;{?S-z?SV3htBzSEO}[_~GBiPTM0lH\Ȗvp*,
Sm降x
]0:֡:	 ȡ2$'t8_+G:nbILN(G	r9q*[GRD.w^.1L2y5	
jZ̦6Mqd8IjzL:ui'GgZҔfƦqkNv9;T]sT'lv$f	C<{]hG֖*+?|K,ѹWN3sE^d_;}>6*?*IQߣpNT_5G7pYg_g`H}'hbeۧjgnSa#~
twwgn
~%ׁ'R7_0	q5}48YtG~q7 w69UPRGwXgI}TXe922k&y'{ye|you([o(z—je=WHx[z{ZXdv@z5XPok\ cuH^bqvvwS
ptʅdUuuV)xwxYgh2Q犭^P(bpwbr1wѸf\afR(VY~a(`e8X_UX]('nK(R6VvhwYhPd~ʨ8hf֨}h1яhIv8UECXd爹ivi7|7ih$	y~n֐|)YhƒPŒ(	8[Ƿ{:	{$!-XQr'HRy-XW	UR!xhJҋUHvj}g]egO$'N8YyVEsdhoH
Hs9YwɄ_H`~nٗnsn
"՗yH8Q)Rj
	]ifhX"	ȓB[w7')YsљɝbqTWe1urqn"VOYnvv׸wYIw)x`ysꉗtwMבiZ.rr^UVYSz	kEV&XGAG (vxynRǢhxb&g\ڐzDM MnJG/tr-M)GFH*p*ږ7h)zwTWy"9-qW/jz4ٝwIo|ti{ǝ}x{5`PEQP%
k6x혆hf`~tddU6/
r`%Rb.ahgo6/e^\
^Ze}cʊ
@֫0ze
Pje]ڪթ0檜)&_eR򚯩
w&1q\bUvg%:bEf6}eW7 T&j	-k*[S':Kk&lej0ll=Y `8VQKU+SZRNZYO<B6յPsiW+ShۛL!Ybsv{xz|۷~k`"kkVd{/wsqQQL;۹Q[;{mAẶ-4;ī[ǛR1;/ļn.۽H4p؛540껾۾[4@3ۿ34  iп-+4	l  "Ӎ*MSS|4K\4l̔X@}X7B=Y`}[a}hcMbip
kq}xsMԒ׀؂=؄4{by،-΢؍=ٔI
"ٕٜ7ٸٝ=ڤ}+0	P	0	ڛ"ڥ=۴M4{}			p	)]=s}		#0ܜ@	Tc50u\\=ޔ֒P	=	MU$
^ߎ;R#
-k=	ܶ@
@	RZfRqQ5/o֔@ 
@	zI`vFª0chQvc_zbfٺ*N	+e7 䴽֕0
,AvZbg?7\rA^xOwp5oK}U=xpvhgg|~">	


,,xƊr8Ah륊T	:{n	0

oHɗAHn혫Nވң^]	0IVf@>pɡx95,侘3h^|ܔ	+	q+?jt9]繮*.*n_Ʒ]	p	p	1ee=+ 

Vw6!j몮
9:@CLo4N_7Q5B09@KRS6a6U;g~1ګsO7aR5JSXC~Ia_L_btpDsH@Jq}o4U_׏P]?/7P?4_?|߯ۏCǎ8rpF
89 	),)d%1R;&,)RA<!LBdK!ɓW4y&CL9z,UV[iaXe͞EVZmݾW\uśW^}ڥU)
r%
~d2"M5H2%#s
9{&T!3i0Hkf8Ɏf	k̿
y6ȔowݲŁN.a6$a[8)/gYCK8b	ؿ0@$@Dc0!Î갳H;.Ü"3PpC4
#>bX	WnpLokQPGh*PҨ}#hH@G#t׬A?K0N9N;OFjB̤L4B	qIIFMOF-IVe-R)SGC1dM3[m[ooOj	B`JTYzq_7TUl*1w4ĜUMxGr8%V0ݐ_ŌRzEU
s5)|[W#"0Ĕglq,8fo9g}+Ì
K#*4vҲ3
tYW"t*^mVh܆<006"jؾFjA7`$;HNJnYg$J(D?=t9򞋘Xf:z1|.%ѭPGĄQr UVa@Ռ)Xgo(,s5+Ȳ*u@[ +tߧ(z)^/|>e%7KFwJlD'*q5Ё \J?
+d`9A@8…LND(<1Xx$/@X&
=\BÝ,.J`H	yȧn1]ⱒ[D%VB`n"wȖ,Eh g9Y{|8IJd INn
OΌ&XhZĂ 01B2D.h˴ 
ApȀ
d@d.m9FRɬd4yRVӚf6S:+-j!V%N&b 
"pb
0e
JF!;'`Gvas;Ѳ@
uH?9O'X	AF!l;RQs/iLe:S2vc!Y"`!@% ^T7ac:wGfnU"3'W+YHL{t1ո"QFM+K-ԯl`s.dE+\
U%3C;u*j=wHY\Ԯ~dkY&Վ%Sjզ: Oxja[b^,^ָEnrXX%*RUiϑSuxGF8nH
t=70jXzB!%d+E`7cnȉĒ,PP?P/K9ֶY ,vq~5;ގBdkCձJK&u*!dmmMI9F!%2qΰhb2̮$xzv1T/T5ȸjY
G p|ZVqsmɊUYl\
|C64%m$_UlMceP;'v12
+KX`Emȯ>T gxyY'!
lXs@9*cb`5aG{ڷ^k҇*[*mSsh
*7&ӝ dew4:gc+67$p_2F]J-hɿ`@s8^ɢSeɞ	#H@Q\^4])ˎ81Tt
?MғD!17yyHɻ}A̽;B9ABܚ<>Q[i)"Œ٘Q(|[A:?逛Qp?I=tC@̻4p[ķc4FÂĽʋ
D>䘳HD=$EĠ9[8١s8ށ
sځ	g\AK
꩹F0GƦ
lg,p`d: [2p~į@H 1==HȂLȵ@Ǹ`ȴȵ!H4ŪEm7I�(B!00$Hlt,H,IlI*ʒD+~Tx38;H0$Dx1ptJJ0˨ʪ˭H$K˳ʶZa =YG(kC;{=VAD+cR%	c̐!LA!LF@\S@ڋ@-*9%b	̉,sAfTbh4@ c^(9;+>ai{B>)(\CC^+ XB1>*$bFc*0!d!d
>Nd78n ڄOXOP 0[.ڷH,8J\]anUW=3}á8 D(Q
,II_i~0b_WX\=͖ 6!['h&=1hʋh#^-\cE7A-fdƋ\0#xGdhpFmtmhNbvDŽn^49|&yƓ4{v#;Knj> $Erja6Y0;x)Tg6z
:=kjjf=q;c}hkH7t2[*mut1tft*Su,WX$aY>Kw[\fT
hG1cG8e9v8ˍ݋dJсυ޸
;\xwÕwUvgwfS_}I=HEs|L
xu-1J!Km6ܺHX(oqBM4.
 d&z$A0a\\r{E@ﯳX@xץwf /gtt-`y!=
!`]N`߹_䕲A3&!|y}ؙx?."IB
7CIv%Yj%uv|9&ey&oT&4#FEYg{~G{H(bx/Rg.*F9i!9(GtBzQF7hg_d0bn:GFZ<~ddܭb)޳*eީYFB+n nZ&fi׼/YyP
|a=Lj@fT;ǁ
@`kl4bxfDlP#|ܦ1f13;3	k1Δ:]1_K5?·~\\u!\ |0Ani[k6q/A}wQt֜sRpCalu6q!MrDi&`΁WεP㙬sԕ"Ď9(۪IAZu.A5:.N@U`-6-ܻr;A*!_P[
zժpt1_qj
G"]KFE>\A2DS$$`
uůO
[<ɤy!(!z5?IjD%~@Ľ^X9.p@"PHfG⥼#FO8
Q!9ƌqs\v1q#Qj>U?QI]E?Q2NҔ|%,aiD$(!JCpi]~4_/&VƲ<&25K	)ILi-G$|:Dm&8)ι<':өuL[ۚOya&f&4mpY=S*8mv2}(D#w=/
&J?Th")V84RYDc*әҴT(,jR^^ʩJkSuZ)RRԦN}*TJS+Z@^Zȓ5bVJrբzI_#`5ja1]Y`ykaКe+l%,WrXVo[#cW.m[+`
Pv@WM,*ղ%Ut)[hI[ƒnf,q)w,enIk\]oQNW=jkܬu^yqkX7խRK"6mneE!i=sp^72m10BڙJb%&!RXlD}*-iv=_a3,
1@GRB]o7Z1d`O^qFr+=qWwBR`=ns-K/1+U%*O%.,9%i^K6LtIe?j,Rb#WJ_l7*6HeWz)]ތ_\ib^3@LL3t^ڥOO?ՇŒ\Vkbj59MZ*2_lٲ0I+._)-R}A|@kc_{tOOİ/r<m`*(X9TE0@`AT@I`V
DTEZ 

@ .`mnR`T_CU
_T2d@[Qt@ ):l)!B}^nB6aUj>aIn[ZaV *FO >a  "*2%x1qJ,@Dh:dBx"G &a虢j"'R*b'~+'bf*r-0`
!UU">n,b;MB'`
!t6VZ,v'b"%7b92Μ*,c%[.㶍`%#@M1B#AAj4q$&j!bb8RQdf)!9*բ+f/fGZ$(.~Fd@$A֤M$SM_&Cn²A@ܡ)FbJޡ}^Sr!\!G.a$RvbUfReTr̍LeO$N[&bBSa%!TbB	V^*l``_&&;f	
bcb`@a"&ΣLf%%h[&ie\S=X\MCfhfei֦m&Cl|XHݦqiʙorsS1`2'uN>'vf	H1V'xSrj'ySqgg]Wlؚ,ViU~x'D'dŀmxaع]axE~=Q~N'^(nI}ZT)V9Y
R(ƍTg
DG4D6ʌ6.Ň6O<č:Ď)B4e:OqZzm\eU~}Zݥ(͊иI~iIQiJ$eΑ*)lQ]ٵۢ5Å؉\^ilDH)eLPH)iQ	z,u5edQϑ@)
H$	|jv5	w$*&\의!h}2Vҝs5^}'>+DMň
Exˬ˲OLOxKKJ֐A$лVPP̨+$d+ެ
Ьˮ"dn1jĞnHkL.LɘŤtԔQxNˈͺz`Mzk܌p\4@L'^m^'M0m.pDn+yCqO~|OEOЯJ4
r~ڦ
OxP^ny5+k
ԉҐxP
Y->jmL@u-I\NH6R췌|(iL(UHf~b..BV؛g0DDp[V0m0rp	{00pCp3Ӱ
Rq
m!:1:o8O1?HU~	GE'("S+)F䝙|pP){TjB!TI=]\ZhЧzu5|V&%zffխ({FbW$3Z	WUV)_VfD_c51Ebr[էٞbsW\
sDٚٛ!gCRmdAdpZV]q9\_9h$}5hvX31W>ssy3h)S	#G&;z;f<?{#q)IKj;gB6@<`SD~d-ÛY{FΧ$I6&|̓#DFn)pAk.v~賾iۀ]<Z~3==1i
qr(#?;Oi`{r2=u-srZĊ?`U&h-hV%Xޭ7@0F
q$H
:4r P4h@;Qxe	HBx	J7qԹ'EhQG&UiSOF:jUWfպkWVi;'͂waŒ8As݄(iȣ%EldE"6[uo[EV.d70^$	Ewod΄ֻu]~O7j/Fz6xG{.Y{,:kuױg׾{w
|OLdM`#sd>!q7FF;8ӯ!ҫ?;h=Ά+P/c@(0(>Cj02f;hAqD	x$O:OHpB cA`R)%pRJpɫ\J /(3
s.2(4\NΥQOIpvAu4:	vxB(^I3GgSкТ$B46Koύ=k2hVc֊Pe4QM)rQ
%X#Sٝ~
;1ˌIm[n)oRLqϽ\j]|+P4
u혵^+XOMO҇Wg*H{s# 3d2L0ɒH1څv'#ꢏNċB`mϮV각҅&z>k[p@5څ3g;G޻o#'.p'n|rv.2pRH1Jqlc̹Mv('h;9
lM~[ܨud3m>܌k^yO#Zm1G%x〉~{cc?O#pl/B80+Lv}xٴߓ3F1ޫgTC^k*Ý-c	J)_'eg{_Ff/UCuVE2?8R߱=?dϕP҂Ϧ|T4E3c"<%%^%hnjHFDrFQ	e.BΗQ0VnYeEX"ڏPdQ<{6PeYXjVr]EVn:8-	2,cbb&0pDJfCMIeV߲
;ebg*/'>k
evBlOAF/PBQDO	pcgJ{Z}zt4fP0
|.(ϓGz~'Sh5uSQ^Đ(;}%uq'0d	1g>ÑqT"&1n3*{^PQd$ii;Dv O0)ܑ܃{1NrIRNlbI QO-"12(8#= em2r$I	7#Q2%gm2L$K%aNR%i&)%1%cr'yf&2(r*'('r))}(B&*&A2+)+g(.6V:.a+-+r.&u(.!>H`,8ڲm"*+H"-1B22I.2-R*a//-`22(
0(L(@r(*V3 +^;&$6g)jS2}:(,nj8/-`'W9	.'a/r0a6 qz(*s.5"<M<=3>"8939>
??ͦ3_G:?:	(aLP(7cp6_s5U` ;SL"ԃ3I&HA2f3.b&BOCbSDQTCY65F01TC_4,5 FgT1qS>t:r@BJ8>J92(*a:	*(&RC=Z.;E9D3sZ2#@2GUN!Iܴ=cD+UED-M#NGtD5;ߴ`^=I5(,_1U^մ;VD5<6)va^/a5OQTGb/-/!0O/-Rf`#8neY`#?Oz`v1o7no
d.Ah3Xq4LfgdVh6hk)1)&SA)H[cG@_Ca;K d^ATRUm5TDBVN(ppshc^kSpy4dtdUd O8Ge	)dD6r
uff4w2fsOusQA
FvvwoY28A]BD3(ڳ_/Vq#cn6q16ݴ^@`=4rN7^77%zb|5cPٗoez-rdPp]B-[CQp錥9z?7nuP5RW@UP%xw'	KA3Lw(}#RT~5uO Sm7uSP5PBwbT;4zq}9579OMN)HW~GU})%s˃f0Ct=)y
gefҐo
/?АE
AJ"&TX
!xsw.0(
"1+W=+wG6E7oWq[D6qeG_05\I``==FOs _m9Di7ӍɃ~p]"zף8k}I90Q{mq(1dg1GN1/f]y'|0ȧ3
:D(*r4Snqyvn߹ux. nUѝE r $"c`6+QZ[3$.pzn5qթEP*9e8[1;Mk+5;Eۦ8۳M;+A{U{BxLmBöEJԦ">-*kJ$%˸3)-丗;Rµ⹂˅·Bcě[*N+ۺ;mq)w&pt'8GLK@sv4Gxngjfp.'tM(tެZLqcL>|F8*Y\&&pisJ\n 'r\\|p,^'sfnHkNkd:lm w<¤H&ƍ<(qwx<±ʩcUhBWS3yD9oұc :{ȈȎ拼܉E$L`IʅZ軺ii:(U=<@%1tި=(2Ս(⻪̸j,ʱjʱ}΅
ȸi)+J+L|\8ŅXވ*!
\ꊬ%1^
&+p~kt~
J
eh
Hi
KD*,oJ
I3}ΎwXZV!`dꀉ"貮YZBّ\5Z?[ڦ,R.bOcVau9NVEI<048|É+Z|hL^Ȁs Bd,&@/>Y22g^jI$rR.0&e1AiJ,]ZP'OR@U`n>%!LXԪ :djwGd2Uѩ_f+Ֆy:,A,_doSjMȀ5L[ƞC jaw=&\?'(Ҵ[YJ^|>A`׳0ibɍ<бvǫoOH9^ wH_桧A'Py;ǟ7!X|߅eȡ A*(UzZ(rb@(#~&_ba_~!7+
1xMIeA
QtZ^.hd^đ}xG5R <5F"}֥5YHKf[o`az`¨Fj`q2&(nD{ve"1m:睭)^ޙr5Vf꣇Jctge)J>GF96]NZ鞁.ڨ(&,o~juYYih+uRntUeD|G<7#0,BLP`@Zm&װ15 	pWr-HI2Bq=\%Gt(.uQBM
WWCDL]GıG!C]H9ߐ3̚+ރ;N:GDk>г`1^:+2N2j9Kq
6$w
D|o}}6ޏO~_QϾ~[P-6,{Wp>߁ksdpdE3]^?x@Ÿ fKK4
osN`VUax:Ev9+\"p< 
o5u20Hځ
5e?Ex%0l@A!MDMi#LCSN瓴"+{Ę5''.+衏@0B\8GJވ"L
,nq'?	P}0E3#?"\"y+Rs-AyЄ֏$BЇ&E/ьjtG?
҈-HG!F_
ӘtzJo4iOKS9m)MԤ*6
S
ըJu4RլjuMW
ְUVݪYϊִҭcm[
׸Ut]~ԧq+PzRNG}\*vz-cF%hewYvgNJvJiJavahZoJI`$^*yJgV
QԀ΃H.":7c̥n.(-}~ۢ-7!{ąmw&nj9Np6na8 RiO|F^+lk+{U(Ȝ.EtR#"-n-$&,K{-
&Faly,& E⸉17bɑ;/ER؍GOpd]-58.*a/o8k2
agkeJfq P"%*AIHB6])mSz!lA;$!Y͉^@Id\.;=$c
!EС
	.ڵoC.QM|bD%.퐋O.<vKjIRTxrL@$s(J9Ǐdz.llPNdӼx 0RzD!C	H0X9Eh|&	d|yD@P#/VKnw5x;;4|Iy"&da\G8xtӢ߁6$CT
~"~Te-_Ʒ$6q} &&g*0w}0yw=ߗ	`}Qݗ~T~QRhr5PWXG	fp	؂'w`w1SG<15X}07 XH}yr3҃AFx~.X}]w5؅WHASAThPGR Ȇaq'@@ }WpW'/	1I|	x~ؑȀȑ!} p؍>Y}hIy}s1YYX,i&ikY=7	xvWׄWB鈥`9Bh7X9zW߸8~9yw)9șywgIÖy=w	q}R.	
p
y'ɌW!ِ(T؜6XX:89u!qS)~%Ň%vm}
f	9C.T癞yni	iAi
YE9`µ{,^,]%Mw!:V	ʠ%jSA&t&d#	c&b$E'G3d$;:U$j?(S$SgBtLe<
Ț@J'T:?wjĖQ*PUjg)e@@ 46q2Ba:uZTS
7}'dC%2Qy7j=}Xq7#7y-weQi5Xu0MFdQed`0~@7jJq݃q[ҫjڨzzW
S*NSzךP
{gb,%kbc0"'	ܒ*­{1'.͢q c~BxZJqŒ,/jin/`2/+[ &`2S.%z°[z26o2"!.)SR{!۳-:;9k,;[ʊ]{ʫE.ѯ+{Zjl
IA2-wXJ-V!lgKxuqswi{>Gn{h0cq1'{!aѭ+;{˷*9PṔv+^c
*%(&fP'˷A&;*&J(貫-ái.cb(&,!-ȻmBx-
2&/LFZL6˿k`,ܱkܿ1L2.kٻSkj;e(Q&&z(*ŮzZf{j{ǖz۪ܲj;"(QZEi,$|HœR١M٠>~
6J*D-ڳ]ڷ-rPr4A=2YR54Y)-86V"
Qaepm5ma-X bV&ݩZ=Q=mxFuۍz_m{D\{D^8`W]w]uBWe]8t0C&|g[EAjW]U\Yzuzy|<d	n0N5%E>[\{Dk5Hu.G# "dPH!"q6wbS#bb1V)7s6&p@҃sK0p#=<3h]!FcF(LJu6H>aVXnF]na_cFN鑦s0:\%q?iv
l}v">3Agqjv2QgmlZbSBDI6>1TIY3-t@ϖpLvtBA릮@>^ne*LHDskL>"v"jk&kޥ@s)~2iVK>gq Z/kt`fѽ@	oخ_[y,3-G@narroVpqjgpf[:.n	sMp\1p[9*hݤVs*/n>YYHJ.hrJu 
3gE@'dCRe4[1[_UrvF~/=gs_tjqtE5#l_tddFjl_n?XXM80⍷9y3zwᙷc^
CztytqDl FxDMe5,b#њᇾD$g#.B;4VN)WRevVTDTUUT$XA	.dC%NXE5nر"!E$YI)UdK1e<$L9uġcNAI0GI.eSQNRUYnWa4JYiծemBaΥ[]yU%X_&\i\/fرآG
O\eL/q"4UvS]]uWf]m܄75К7[;'q(}\εu]u-xV%9^yq^Եϧ_~mu $H'N0
bqa@FIBz+?:Cl0
,EA(l?A/AAMDOLkD'B:lrĐL1$%pydPGSl2MJ 4¼$(oO>Ӭ0IdH/́Bw8Q͂AƤmRDGlGe4Q$	5DUdFG5>Sy2QceU\5M4BcEQUT[KMNo0IeM{pU""C:|e]x/BÅ7?6@
*$Ł&ިbE"58(S!\:3
dPJ^hNSfl"mXw@HMb8m>W}YI9͈o:b\RvH^z'2wm%
_h`>n1Kx.>F՜okC-~HY7;-=|'rL
:,o,r^YlHZE`Hc[HOYs4J㝷ވ._w">olo4yvBF?)0~;{7sy}T~Ҥ
,B4xvf5
t
p=k';`Pk~`
)/2`؞'{)ʦ6i@x
.6F[0^8!j/Yц_fi:ԡי2zjR5G;6T6xM#-6ֱ_+gUiK-']Pj$K.M$c_	$<(Fь#H	N(\P(=S0(lYM
-6:/i(CSPP1%0w8jk_f7=F&q$\RjV(ӟMSBzq5YY	4vFOTP7N?݄в"ϴeP̀]5ܚH^py`K:W
%zAŜ!%YzPUf(j1i
£ҫɤfկznez~wkM_}>1GNh9#:Ѫ
]SBo]gɷQv$➚/|9bsnRsݜ^*{Oi>W7:hwfJyг
$#HwJ
}\)MoA;[,IG)ۇXC߀	-$E  'T}|_)b~7~nEoS:AkJ$=$4:N	G?<Ri>%ᙊ?2*I㟊$`$N$	磈?(sA 4؀&!>%D
$|ŒHB LBFc'-A)fSB)/(A"	/#)60
iAxy@_̀E@0F#$PDYdEpdFXn,KEHFFiT#GgDuDGa$F~F
huG	EЀozF>;Gt<Tz$.EKHsg例pxfHvID
(HTHMGlFXɑŇ4IvDŸLjIHGQԿY()ŧ
MGPG|\t`BDD\ǮǝӾKPKK KdKxyKlAe˽Ŷ,̴,L$LL['$[KˤGTL`$\Ǿ,Lt䀲d͒|N`J<4YJŨEL~)
K,GD>mȶl>IDd?lK#pe'DOTlKKMDP$Ekx?>$mН4B
B
=`OP$Q4BO<]QhQmP=΃RsI\N&mJ@DH^$?_LFIʄXgRDK¹˚O
.EL"Un3R5JMu<[4ҬTS=S%TSS҆SS-4]KyԚT"S:R=SF=TOӦ%uRVmUχоMUR9%ԶPDRvdh5gIJP#OLӁR5^eQeMU7P
US]NCuOnjuq>qsK}eVvmLW{
FOTUuU-XՇldL<֯UDLVxRu2WxynETeN̶XΔV`MilOّUQX?T<)]PO=xQDLEhL=BУ=oד
4QreΦMZYXM[/(d\?"G$z>P	[4Z3i,>2F	JGגStn L\RD[[۽
uȡ|BTlݾΕPJ?T-G\C]؂;\<݁]%Tlu܀]ŵ^eRUMH^%U6=9N}[0Њ
؆ P_r^uJ_<sY?%h}}ň΅hA``R,I~N.`Nh:6A4bCk#HzY7"-	K73D6CsbtS6`Ctx;1<69*v%YQA.Π26X`nc7&-!N̂@$V;n>9T_3F#@$$9BfGdG c:P#pS¸N8eYb7Fۄ
;	_9U$=
<,1#濃#ffdyɫgc[=af>Qez3A[3`a6Z=mI9#Yh!;2d>;y"+胮*ÀY#~ފPKg
>⋽8y=;iYf	e^N 	[=f˻OfV]myjZӻ=4eΉNGęi֎8:J9e#gdC8Bk<d3I9R9YK<>N=C^fc9Q%TnFe<抴VJӗ>ptɐvHȤ|k޶8^ߦb&'7\C*bgȨg	4$'w(-d#1tK
v@<($6bg;aÔYƉ^OUMd%MST	mߞ^ Nf[x}pQelp_MdpW)C7XċFUJGVYmqJ˿.q)#q}aHgАwp	ۿOt_oHp-ƨpxY\LIur1o(r3wv^]s4E	eptns;W2?s=־s?ϛsC/@tE׳B?tGߓD?_EWFtNH	tNtFeVouWuXuYuZu[u\u]u^u_u`uYTc7Gu4WueNhGb/V!qo6d#'r5cAhᇢ65f&t[hwXMET9eNlF>9?r89YVYd?wjn=hsl+O:f_wgކ_y0:A膞vs@C؉hxCx?3y
O
,g3:V_Nj;u/'k
o`l$LB*.	̤A^󐿎_.Cn6iNd5yf({{V{ʨ{|US{ɛtFږsʋU̷ˆo|gR|h,KrMcD0΄}?{ˀ-}!W`іQQ#e_~'t鿌PݢmqT'0JO?p"
2ؐx!CÇHp1F&̀QȎ!Lʖ._Œ)s&͚6o̩s'ϛ,{Qc(ѢF"Mt)ӦNB*u*ժVbͪu+W4Rt,ٙ`ACǎ!*,)7`qoa,+x0†#8qK]C,y2ʖ/ceXƞo|!,j$ rW@s޾oǙ#O|9·nY8<[Ϯ};w{.~rC'HĔL%1Jg	|$TR%'@J¶Ո%Ӥi9YdJæHpSrd)GIdgwo!QԒOY(٬dq437ǰ!b(Lw
ϜI,
.HBRԤJ;NRJ#,KF/^HПɠ@BPğDBfm/q)KEA6tAۚUrri(u>S
@도,0ҨՔ/`3m29A=9ral;9z3?:Ђ4mC#:ъ^4GC:Ғ4+mKcZ;PKZPK+AOEBPS/img/strep066.gifGIF89a忿???߀///@@@___oooOOO𠠠000999```rrr   pppPPPUSTǀ*()GEFcbc878㹸qpq>>>:::UUUGGGuuu|||***<<<!,G"F!Ż$#ϧ
	Х"Ü@@=`R#>YTŋ3jȱ!M>boUiA豘-MH вϟ@
%LفQ%QIJn(sV6M)ׯ`òCL*+f@+mWB
`Ã
aHpEL˕J%ʨC'wUT"Oͺ,-`^>T q4p@D1H5?y'؈pk]PΞJ`A*C	˟F8MHX&ؓ}𧠂0*%X0]	D0P$d0:$"/b&^h,㏏   7cugXrQv F0Feg/`bEq ~bf!8 AGiNyOBH@T@nh>
S6J()
h-"0g[* N	4t^`%
lXF<۳5`)9(ӆKisal]hw4F4⪯[օI~H2;(
dn֢)-E3-ZpKY"nk[=+|lhPeQj'sM<y)Ph˷ev%?0@7 (F;<-e6v(%,ЃwVVv[t&Ŗ
fJ|BGnDN8O	@e5ZMeLwQ	,+TsC;D9h~"ê+w@{8[/OI)$/,JԮfK^CI aK#f"mb@]ycW
bJ&jc[HA	nD!BDp̧
:2.4x
8 BOic	M̢EDT	x8ƖiU"	6q(e,t4?(Xh5:"LOH4
َ`JHJzr#17ԅb.H:d*gYPZ7{bpJRHB JTBL;lKS'n<(F$BVJVd*`/VMVLkނ
17IO`hbN^bcqRn6)1z:tKHSw=$g@y3'+ЧlM-"^Gmєl,No8H@^Zj8dhR,G	oP:?8JէFP
ӗH*fXqj@t^u~K3"C5zm0jn.&ۗr:Q嚽p0NpJכ#$`Dq ˰y6A0> `姻->jUPfc@R6X	Zh P?My	|ۀxdKv@&%3yF`[7ZBIpm4Dhں܉OiZ7NsZQKZb;0fVWRjS'ՇPeנiS+給5ڒs[\ִnx_Ghଁ(tkF) ۽ijJi8df{kChW"`AxHwdX7=nB}6FFS!^R",_wgƅaj(
_"[6L	vl[9 )PA2E*͈m=#,cK.`{֫ʏZіC4.HBe6mKHLj#
c͊#}F+cY\/eADʷ~2o}ɦ=ߴ-0dpֿIuGo6;"C6NYgC#PbtµN`.4
@xzx?z:cwt?P
2X_7/R/eDSΨ?oԈͷU_#G;5ճ+?3xuTt~YrC
(d0V85;ჅpewdH\V{BpyՃmLo7'4@'i$g.d4hc|]~4jDB2prl+zMd
&s
a&xob8jKk"s򄈬mf{TB#Ɛq\IZ}\`"kKg
臡DQR$҉˘=
j'\@`0H
/.B1aX8SFsqVZ?*%.|FH@ EVtYwqfv5_tB]m-\`/h"wK1\[ųvB[ w]t7kq'%Zh,FIIwz&ؔycrY_KH3[|3cR#;ev5zWo򠓋@Q \?]B?HWe''#rۧ$Gq \$YUq)W5Wf}Q/YcBF02cR5%0Y}iHjڨ&
r_ڦ=q"&٩^-ڪ:YiƧCz
ګeFl:&jjyjʺ!ꬺa0pJ̊
۱zV꺮S{筆
pi:	犓L%'z(QF⪯ï
Ȉz&֗q/dYXzmIu#1x˦0S,if,
6:`]5H'[i&bq$fIBDk*hB8L/Nzyeq
#3p6gvwgCE;&ptk[z
i9ڢ|5TḩU
~+}PgFPFwtOԶ]=f*QGZKuVc^ٍ^۹%>n@놋[iqIpޥ]U.Gf:DS;_;{BF04hiq=71A=ۺϫnChLA{vD$g!y};$KIF['Yk ?)E˿j_Q  h&Ń_gMr;cb}̻䴓 ^AL@=s0AwTX<%N?*ЦEBH)̸A3f0zSÅE=fctǙ/Bc\{.) zC@8ŀPiCY!泖e|Y}l4}x:0,-kΨ Gs@@%2</v}/Ƣ
\O0"K
Y#h.AhBԷ0ᬂxLa3ҰF߶YE@zL`>Htmڧ}x}
89
vcf"pgmDW/mwK@+
p@6L$o.]}+JnǞ&
7،tBw"ЗEw3(L׼ਝҫ
pێ]8/F=H'218nvv%޿
d
֌A@AQ8hWᬆ-XMPd䓵:,\R
0^&mיFm(+%s?6d]>}Q{'5F'nTgbաCG7.z> $_-+#N>%I:MȤ3L낞TӮޮ%q쓬 CN$bϚ>0w'."i~J^	w?__pLɹp䘀0,!Le&0]]	&(*B?1?!mqf \rcc}q"L+	* );W-Q-|}&I9卒歳sn뒠0t_vxzu~8וH\I=${@.$; ~.]([͠ـb\E`Kp耏GU8bŀz;
e3H[(:o_($E7!0((_@dK
70;Ray%}I[WXGFFG
	G	GGFG

G

G،FFF퐒㖂-<@4t0j44F
HȂaH:x@@IUnoųQH*]ʴӧTP+P
Xc$,`ɡJe$*pZH Fz-(A֫
NLE>64Gk̹ϝz	tIw[<Ӝy۸s,ziC@	Nȓ7s	n
ؗͽ˯ӫ_Ͼ)I7M
aVn6`Y߁&`|V=7~Vh3o- gs{i_,"Ț|/^3d奞6(FjpgNKB
wV驨j(ꋢ(_n銴kx9IںYkgbr.
;/J&'4iX*;@
p
_H).t2,0[#W9!$F
40	'rm "lɢ'w.rPt@$bLnkH,譚i/Uph0-C (OnEVFٝ9 @iYX(&w4PM5tV`QK{'I(mɉwj9ԈQC
@M$`ʍ;@AzPq>z*%YU*i5<K ǡ@_.+tCk^&OzdHI&+T3>NKv:>0cKqd+/p)
#*qX GQX*.7zdp0č8̡wP
7-_0NFH "Ѐ
b@"=T3`DQ@JhP,BH$ |H`$'=zY!(]&H?|3WJZXPF纞AwJb`܋B'rT2
xe EW%=fK 藌TZX/Nb$s_xWӊ@u. '"f	hLP\0qIXQ,cJ9j	F@ f(X":\=!:Cd=v6b}O:bĸΒ
`]%peR~zI-5	{
-eA@.ejLA,"!uAL lY7\@/ yV
qfiGprmb>pt`|A{}<it$XzN6DIXM7à-Vh7|7cPUgV|q4iV3{X
Z{7`{X
3q/Xڇt(iPu衅\CSF&k!SRkq@a.Fg0%S񊦣3
13n1}6R-caA12*U艮(5Ap~"oU}P1qF۲jЏHIcH	"%؊%@	h,u!yXF%EV$tW+ْ.i<0)ϱLٔNPR9Ǒ(@9B9S)4Y$@BjlٖUk;Ycy]u	l# *q$609Yy٘9@	Cp4Цp1×}upr) @	&FY
49bxٚ9i&YyIN)0ɛX>řڹ
ǙlVh'3iО9Yyٟ)PƙP0虞g'철JJK 9iPJ-
4A@4A A	#+%jhlj86jF^5
{pE!j\٣?z,0	QELG1*Vg.
psNj=S;K5XT=Psuz
t0#o }ASRTVz^Y
*[&W԰U%T`*a)bb}rOmTW*/	}~C+DBtFӫbjQV
{	,1@E'{pE
ʜ:*"ҩJQiEV_VxH	&P,7w{XJW%VDUZp2ED{ä#ڢZ:):	N7҇7s;@M7G^z328=XQ0~{%K,S׀'˱_c؃3QH]"}ÀA6/{qaC^^nPk+QSgxq=HjxJAjIK(M3P
8FidcI.xbU`kc{m@DF}ԷJ}AҷbE{%;SŽLdAuDu:U&ٛ/DFwdq|pE<נ{m/M]6PN]
Eڦڭ`B-ۓA^~
.}b폞m ޾\a.,NP}k*.^1~&N`j8:޾A=57^pH~]6n¡`I2	$@b8*}Q.@UGܒ7ݶ1	0$2fja:5o3JTr^265ޢn%FsWzr}OD>k^Kr
P
ceP0I,b1/cȦ	*
>.ED	jGWN~N`Q{F
aFFP3(_nT3cDabv7(&ǚ`bn{N}ºq(9Nl>_0倝 k	4(@|4\/F1˶^n/o/$07^3_a[-$
g:`LӐ@3OE;?=P/r[_8ɼ)r=R~qx-?`̰{.Cn=eo; 
1]t5tJFLj@_jbat1[_
:Q`5H2*\RZFR/S0GӇ'淏2_ Kq mj2oGFFFFFĄу۟#$G

ۭ32#f8%DlCK
3jѓS@Fl=Z'*0?A
fP@Fn
)И=d aBDe-BMzRAY&XcȔaH" 1LOv˷oƏFb@QP#0p$
G5~⊣&`i`!!A:hEX#A%; tv,6t	Є
`t)ZryۜGHARUX9oܝtbP@04A0,Flg@]	A+
Bim Al)T GA\$hA"dYK:Д0! qɉ,f(HgGT %p Zx!
F;xM^140Up4 0DŽj?7u	`ʘ\<5'WEi*VI	կ5"jĻ{/	
+T>T^k^ܦ_~[*h	Bd7IrAA]BۆV'+˴I &!qGC
 o(ชA Sb
Z%*dD
* -rwI+TZxEK|h$Yى"BGp6aXʺvmEy|n9ryZ!ݭrf8vBPh¦Un{7YmW*FZ|5%t~=mADd} ]d+qAtR#p0mMnsݯ3_|[{ S?("#v~#z"$A"㑒Gh J?.@HOҗ;PԧPBO8Q5nZ6.$HD7b"Y&M>ƱbC-/ra@VNxK9ol#Zr
;j
~\Tx>؆7`v67jbJ"	68@k=̵f?ٷ$&;)@**ubg
{m@8[q{VT$A͑(Nhj*յ/-S}ML?+:G*͌t~ BLpv0^|@K$0S7c\;*02a1P<3( s|C  "'ˡ@C(04'tCWg	u%T%`^zh]V ylPx
b	 `hlx!
#@@&13&HyXH ićq7XJ5A@3Qk(eE	G]\P!!.+{u6v%E . !!$. (
(DFӨAh)":w@p)";(*/25#4R2I'Ba13g0Bt8C
t~c)Y	x%\F…AQ! !!X3h
Geeg}&mHcF5r#r.2_
Pp
r*H<8%0 )F9C(:s;#@z8'+W#y-<L| +%1,&!vr)m`FЖ$X#i/~s/7\86pÌJprÙ٘2d*t30*(439@((XB0^'pDggi_‘5/rpT7N$Aq~9sep o^%gF1lc
v3WF w5%`xAēQ0'㔺9ǡ@@ 9bb00xbP9jBp	ۓlE)7=C}*G	Ý`.fDh}fbNdrb()P0Tz`a`
@(E*#*&uX(%
ЦU;Q+F(Y%/"K;l>/k´}:-<:~ّ
FNbc'-FZMZx	)bZٖS [Bg7iM#aD8Db
dFRF
JEUBy!$q$T]aN!豈3iPIH@JpxUM`3O$OdU ^XT	.yU)b01QB4壯>ᯏd [X:@`)K
uV0,psnx
Z֛0x0[L\"Nh
1
R;>)/8&q\42'#[ u%P)Hu
2Cxf-aٯF5N>7O*7!!cgNep!8"
s6(ӘBpWHpT`щ(F(x{{9	
(3Ƶq	`s1?2raB>;1}aZi_T(t9~{3T3;G&·=8<Rk8
E|va[:V[o?vCiӿ^>4;t\;;(
$BBAA2 ca;c3PaWg8sg,{˖LVV%MO?^~)o\^cA-~]\ቐ4XLu(	P 1N۩gK仅9	;KAfK寅IKNCP@2=7ޯ[5t` ~+l28E3~𙟧C#BqQv(nSeEj%Nbr29Xb;ˮH595D30XgBƑYdd(˞3-"ɜku{z>W>숰+&7Qꐣ1@`΂R#>$O&V(D{' 3z6Q28S.4p21u"Ɯ2a³TE	7#E^&J[kx)Tsx(y{0 '"S53&cͷx‡p(ObQoxWcMY8)^>Yb*(a)/@ 2ӌ!A@3XB
K	w/_`㎟-D19UHqTGGGFFGFŞFFܫ
⼦ҶGծeG +*@tdj*y,jԕ/ƏGMp6(S-Q̙m,(4L6FѣH*]ʴӧPJJj>tkȝk1Xz
@Q"ʝKݻx˷߿Vt\JImA+lOmcAs}hȹϠCMӨS^ͺᗉˤ2}o6Nȓa^g{ֹlfËOF86al0d‘A(h&6bem_a.G}Ĉ|R%*SFd B3"-ax#)#TR4_1A>	,.*;,UzhS#>:=c2gi	^~"$6DJdPD),P%79K	pcX'$L{ܐ	̘bRSf	DL'`V*Eh4 A (D A=魠e2j8%i@@LKknA	"`PPm\,:a`
UmZJP9iMk" g(}.,s1'CS*{|<迨:"5eJ[̄45C*%X,Jp@	& t;ں '@/p	,nk@'5Ybփ`NWFEmBG"U4_U98"A4-b0@Іն۳\$-҇2+"#뱫8;"(3n[~y-AΟ'#-7ϤxEYΞ#07tmДbݕF'Bd
BaJ	p3iX*Q\rd
kߌua8h8v6*Uv+<xܨMLU
/	OkRJ..F`Ĵ=0`#4gـ%G=
 wf_;)yaSZ 7S{Wy1b,//JF7g:wR0vih?vt{ݜt?BN_:Pl0{ԛ}6=BxE, 3=	YcNQ8pmGV:E0
Pg
W9Pׇgg|}F}G	>	|S'0~~!)W|g+|Grl`
gCI0u6ŀA}8hR|po+~6k2u	d|kFupy/8)D3{vЀ%|͗uV9EH%hwqu:hY6
#Z0'aWP-6)FC耶2)}Wg-AG2~Hl3K
QF
4P
OqRxq^自uGFwF1]h4p/]x9('zh8`4'FF+t!{rHڲ1jHg=g)7)X!f + H pЄЊЍX"8%g+͑9-	xƎ8Xa-
h~GXDSgs^iCkSp zW&qIN*ԉo"[y0AyuHoC7:&bIk(Sg	C	Np!#.RJuF!
0eDsI	jCIIcK)y6UYXgٕC9-`9gmj"#74m0gpH!qw2YzֵmJ
`
Hɐ)B@)Tmx;pA/a/*UZ-e6UO
%Y5[ҥ
"=B.
9zZBZ4P\(c(g1jì>q@cAJMʠ`z
Uܺު4B5

UpZWd9G1Jj%%@:N*𰯇)Xu2;;ZHUdEP]%IICVUڭ䚩n谂Z!{C#Qt1{N$<,\?+
z[`kxyE#@=ShJ7>XKK$<'Mq*IJ0SML{3Lq
?Ś Q2Ag#+J`p56xQZO,kc=S
t677 È 3S(kl'/Uu։
ƣ01Ǎr#,eǃYǣ`@F	W$@n6	jȈ0v/CeWȄ9xg8͎͙a
PtyӌÉp2,m̿l̻[3r"/2˴|E$cϘ"|ݡƕ"
xKA
pf?hs
	MM -Q-յL 	
		Ւ0s)|$!]wqWe˷>=)t	Ku2=cشf
0ˬ"L-jٹPYل0Y4ՀT
z,-{́,,+=,wִ&gݸ UXy,STqgl4@AϬB]Epp cWu
IJ
)#]EE(	c,ɂt91ʨ
`+mM۞Cͅ#mXl1)Բ"Q劀	(CM? ]	`GR~ɠi%
*1ǟ}ձ5rl7)U	3g9{gU-Qn;g,P	1|f7r碐՞sQ2,.
y=}N
߆m0	qkvG
> <i\Y鰾X귰M:
ޭ.Nk%k܎zxI\^w~B-[o>P"ퟐ%|׃2-F
_\	p-U+BZY/G@D"V €7aq	U Ƚ%n,TO1h
m+AU~63-^IwN
>*n֘R$=NΨLgʜ<-PI=h+uȧvt	iv" a
=_`pSt8~z:-
Lȳ
W#@7p)ojW'0pߎp	ZlOLobO
OH)l:O+PȈGmh5X|TShSJW
+KCkGk!Vgzq@x
DB(>X-o/2P&J\
r
>w$
Fs)aR܍8%B;%p/$!8!
-^#$`OOÄ@h:"+0ń?$pj 7O@~8Qu*?R%m(๒ށP0UnM`F &5#[.A[)' E@|ֹH/Ɏ|^	bjܙ 
$k&#w[8Fo/D@@&HQY̡@Gtti8H4OWd@TGLcP>qk#,48]`./C=%
mѼ"*e=^Q"O1TCH
*K16
iZu+-[(~UNlIb
#UcOpdIDx\P(Ey&Li!&@ FYZñlEhKT5Jڰp4$aO~\&64̀ɈECP6GCPYZVjV! 	AFd\7%7^}۠(]Lgr\FVhD:ᛅ*
415JC]MK諔`:6@Cj'C1~D8GHg4"[$
N'4qO@z/$ЌS%'פ)aI Tb8җ?Hؔ1mTek
SAHڪ7|7dg"œhMe[d69,^Œ@3/h9"sC%<5ǥ'˻B*KV8"4ĸD9rii΄f.*|a\c1RL@SF1Ɔ6ŗf)R֔\{(9J	C_lhu:ݛcXKߦ:RugS#v+KHHFmFMB,m2@,rQ~n21eV7!Fl8ȷlq|_|JCЗ
[`-@$h*i'@T$"UsY~j&̠HM̡Q
u۫J:39%ƏRIrKBHcQ5`UrPDҚגO3Wg0{eڣ+!C3lgG|(I\t_TqX2'kej
JBq:'p
!!n=)b_fFgV?lɊ~f^Ze
{-,0j32p/(3K,𲅛+й =hud+j/`кB#gׯ;|RWX[h]{Z#mfhoLkvڅV
1v;!0U%b
*-@۬C۸(0Kz+&p9	RK8AAr;jK붡as;~Vxk
ZGF0gEz$
6(W8Le
"9,s1&TZ
yZ9Vh+;1*oj^p
pj,0hp/k^ &(</tnk+)Q
2;v2w弳*MsUxTHqtkL軳Wp!Ks
z0az
1pƊ {mZ	m;|[ǔC
7";iJg`*0L-)K͞;W
h\lAud2D8?7˫~/4
)y2܀&~pD<ݟP/̒V8ht3S/%%5oA&4<0p2pC-& f
)`3@-3ۺ}۷ν-܅m|@PG6#=.$f#@
>6R-d~ؽtbrRCS(`
Яtsx$m:M(9Ӌ0čCpf


#f%$<Ü-`mڰm:Pg=XY㘝JA>	9!dWWĩȀ PkB+HnԳKq™ēs
N#-bw1jGxA+epT,6zŁmQMh8ЭYP,e)CܩlA_\ɑ)Gn^)nGjB#vk7eF^H;mw~+m^LX"8*WP"mMr .(;}.W*SipDha@')X5納~ʳ|ޖ"Rst$W0]D&Y;!V2-Qrxr+m}	n3$Tazzu
/,^.3º	R
		~$`p,^Q5b'~펝+z0.r#"@/#v(Ac^,	3=.$1dR2rD",3cd뵭RSHXU#X+Y#jp,,	RxqaWIEJdjؗA&AfzC>Uʟ!OQA4BJ1?7o1ŰJ)
GF		
GFF
FF	
G

ʲՅӸF AGFD)i$H(G
,{AVHTix$ƒG$r$@#%]Hf)aN""	D	@+=9@@T`1CȈK[ŶKK,Jb%$`yv,eRAJ%#- Uk֓ײjGeR
[S
3B(>R
(tZ(HMIiZB#֓
p	sR]Um	"˳6[|є$dV5QH
YH.P&6ݮj\b-{ZIԗǦMp|̊, ә>{%l*އ
~!.ZuDEDu?j)9"%z.#w[(~ys)R\,@u\z6`O4R
.Ղ(q"p {7@$"3qṳQ I2mb)[/A! .
Gk@`\pc_M)X:3jN2 H@@8 ڜ7"O'9D׊&8TYTCt܋D*-LU	QtDZk儑9(|L۴V
lpԌ(:R@%<5W(ºp^y89B2˺QkS,wՓwZh3&Ï"Bƈ&֮QN7$A="gPB|xaJImpXMHjܤ3NӖs}
x_{TCA	nREa4/PMљFqjeOc#8Kкd{Dلv$`8!^xk?^LjQ4;^NI\пK!:rqTLlf╎]WERD( =(+!
 OD*wKuMr&wDκSpDUtJwD4.i{iE~EgOOQGi6ԁ-{+R_,aWn#g.4ρ7@Ї{R|0;PԧN|޹ݮT'1($NtPyRHPS͉xG|OZwڔ)y{
hi5#+&yϱw{Ea-ֻ6-N͏Ͻ	/{(~}k?3}[rQsO~@26['?"9Pt~3_XgHf'~2 -Gw(w"av	H7~~p&
`t%T+47$XNc{U"xz8@&X6xH	
.7pq7XFX(
\1GGXVN;x	F
%A9qdXI9*8
.2"XthYx[X	=
?X,aGap,7X6q'0h.PPhX(|G|G.xi}F
dWx`x}r8'gzB7PCX>WuhЇ򈱸	+xys%	gHxy|(x$f(X~@ ԘhIp!Y%x	85֏HY	H;2ӵ'*iii	$,(xْ1b(^89ȓR0r8u95iE*MZI]R	qBJchƕ@+5WaِY	ÖEqktv	~4z
n95x": qe:bQu	g??rIJL	 7iI29=
r`<3VY}m8'sD5+hq)b4JHn3&p -ǛPY}k(woI%p&pbf@~ XB+&|9hY>|6	F-@L%-Ԃhi	I-#i\"Pe#Bm		r1O:m$U"
10yj~ݨ
)-G[gapeziN
5sVqHB:ҐqY(cJC53cVK4UX)cXyw*,9)QeS?
	Ҧ'**Hj3ﰩuD6
MNRUr.cO79I(ԁAD;boë9	ڛ`Jr9)&C1lT-pDFeKC00j#h:uqU&/bnSOɐJ6	zׅ8
G'h	KݱH'@qdBК4O^Z1bSI;Ӹ%ԧV,kZw)+sWX*I@KY
)qhY#IK?JNiSxx1S'[
9Nnr;7htuam;Kpt;4BodX;[
P*3:+S+ rr:+C+Roc;[{@CZ갤1S'.+''yNjgȳ'c$'ځ1
-2	C˸[UJ"
&RF?j8CKӫ U(qV	+jOrdA") 1U$PE1'{Pdd UF
UKs; }p.Q^"O&bO4)$'Mz*ךUsnը.8l1 (}enQP4o+9P3
9ް
puO:W,rʩYVƺC:T"ƭ9		
|GFw<;z|kbnʳ*CzT
UBEQqTStb ?%;*fī!MVd;B aBxaL.K;AO˫dVgȦ`K{O@]PG`m-L,iOqϘ0zMMT\Bx2nj	
kkL62aK0p±4+ru+H"@6HbS ɊDtI:e
g$D#IE9<0ɥO0#p-<	x|@H
Z@V#;S qj=STI5׮Bw)>U#渑8gaat
Mr/#l{ŠJ
I׻\	 !	}ސޒ}ޏMߓؔޙ3߿}f&qEaUIh=:sH2`M?j?}mĉٽ]Z+

0caUWP&	apq;՜WW۰@]6*Q/=MPސP!pMWm}ZNصGpXރm؏ }!@G@G0$D
F@NTu#ű4Fv1a]L'^)U'gQ(͸*Ŵ֎5zqUb0h>-@
=I/MM挭#la%"PPGP"p|~!"PpG	u	!0mn-j %$	3N&>0
F1DчUB.^ ӳn`59h@I 1,56Z-0?=+]/$|Wt~!^=0"p}P^0"$p%~0T48j)5Fx0Ӽ]c	;/V򫞉uҾ}/	DQ#Mfh79"]v(5y)M|BK~	߿?0R h_#LcNhOg#`"@p$_vSH&hcv:(b
GG

GGFFF•˱Ϙڰ"#$%G""GGG!G$H@:p R
4`wAG;CJI锑l@n#5XI]
sԬPGȈrMg4qώ"ꧨ|fӧPY>}	^
F.Ĉ*TpAJ*\D# |t ,87a	r(ob>
!8ɣ"z&SѨSI#VJUQ*QGd㎴$V[5ZHU ƒ#$DA
!yHG[w 
™$Yj	YpEk;֓&+EaHoXrUeUFcĀ7Md	NhQ
"*#-&&@lQk]cgA¡822#HS	UX͊=̋F%d`D	xO^n`H-1
 ])Lf&3 D/48FA.THRʩ"r
~ۤ*'+Gz#Zȯ"Uc.8JzZp	 0X!O#hPPڋ@z0{jﻹ
*$DHJ0 HbRAMM|u	!>BiEa"t<D+F1M:k@yۨdS/iPLBE-NO\4k-% <ȧуZX2
O0Xg?0@'pÛ𮅻*1?0	nb"6F}t&Զb]7XzۑGsj%0oiC⟉>_#N
a28d{y	ı>-@FdCE=J\)Bk(:)h;՝d1;x8-d>N-EB<y󒿙M*RI}TopG?xDQxGP~Q(żJw>/	Ű8 x~!׷RE8XxVdaM1ZՁ,؂.02OG>(!
U<؃>@B8DXFxHJh7-/_	V.TXVxXZ\؅Uȡb8dXfxh	5n`S60r8tXvxxz|؇~vȄMh_O~i؈P2aS$ xp4P[6؆'eTwԐ؊8XxB"_!d(@xȘʸ8 
hRg}n͘ڸܨx[Sm"xBH`؎		uPV	؏hx_gȃxh8>	
G2Nh>.Y()
}Б񇑑2	.i	'C#i3)O'ٓ@	:,IG-n!>̀Hp;xÃ.E)>2`AI"B
 R	%rHi@F$Qfr
G*	S)C!ZDG875dWi899	px]I?95
Z :0T?]#zOA@Cs0Kft cU 10%10ɲ\2c'2Y02( J")#c	iBGRs+^pq111X"/28%./90+G8ı140L0@)U-%ef7:P4z,CEf\i__
qSQ{P>-iIˀ!;l5ɖ%X4KpIÆfT;F4}g:Ks"VmhsFI&pʜ7dʁB%z$4cBiOGٶmQll䖤ٵhJO%t5Jy7FL6k83_\zx<8ɀ9 ca'kCɕʃ@ɨQ1˪bKe4	
I\(á˔H]	&+{`ɢãL3)SX%E˂\̈́<nI}Y0Bi@'S /@b,9PRz_,	mor[6flq"HIK	IJx,)),0o1:.
А+`+,9yα#xd4lj:3cp?Fsdq#5/#4CS}G3΃:X1*63ɢp|M?xhա?8S7!{SBf7^C::SS5$5]LK;mDK| 2ۃ}jFN}ݺZ*7AFz;wx^Od>iil	4@x>SIԦ&MеcT4BPBddF ͺ%:~;HQVc KX O*I7o̓
	鲒xU:(	M+hCUVETTƺ1]bK."A@>ԌAo+H$0`Ayjt6▀-ٺH]
jv3ZS;Yܺ6i3)#۸%ÃA ^0 ^:ֽb^k8
!jꀱ9^~ꨞ&蘄22	<ዾrdVo,ukGcZ]
~]5d23}MB%X|޸rT4+]gvd}df⁶DklM?zfglk%(=%[Oe6E`s,tlug
0gGrN>.`H[od:s+o?oz!G:%(Mwt|t0F,^!
,ڰ9z`9#d_f^1=(DN{wD98XXnt
L\oI[bN̽-=2Z./4e;FHGye0릏~ߋP."ѱ
wDMx_L
0*ȟʿ̿U o]ʹ9!j2q/#P??ï);n䝞PhρC>GGGGGFFFê	̭FFFhp~,p)bDP,1 !-@+:;Y[Һ.p6rߙE
0"	zWP"JHLdqh`2ԩz^^>l(=R抢)Vf9 u>L4x3
zHu	H_X7@eyNdG3l&``J-i:Qfw{ p=|o73+BpXP6XʂЪDd\a0Rb%4,ɬ<_pO,<)=nEʑDkl+66mcUmUYFچi:TL%œ!kU|lrk`ȁ27v;ejho_8,JAP3Y"YVXW>*i-L~G~`0vX DB4#"V?NCܜ}.;#,Qh
yУZ)~HSh.)Q:T:${$Z2ҵT&Q_$qc7/.O]k8`Ԙ42XEaBdI|A2E6MAM!DpE/]
QQBD an8$ heSc"NKuy3x,ɘ0 4I.X`*J@x|=L#%WE.ZUHb)fCdAD:BT'0^N,€pKED\<@BdG!c""g3*c9%3^
h}+ݳ-r{@O!8ǰ)PHÌ<R;vՈ.):%[FL!A<$MEM[iuѕgLA܄2[W&p@l#3v	zI4)ٕjk_ۑA8qFq.#@G3Oj>8x[̓Bk_M7:ׅt@?m jF}lHkY-RS)Uk	(,@8ZsK&IЈDOAj&%E#5RKB)+{
gS
c.5^u1l\Ӕx9Ό"Iui#+zN"#\8D[y37r֠sZZ~4f+} 02	Tl(psmz e9)#w.lx*lfRIA@sXUܞf.:]?g>FaMk@Lk[Ͽ(š4Cb$կBy
UD9pTB::EdPw3Ƅl5|,z7#
y9,13S:ȁD:ٳcd:Llw
A6Cl'EJ30MMtA$J@:3@NuD:C>;BQX쥅~4A>=/`@P=hh`WW}w}}Bgbw]_XdI1:Cde|As8TFeTds3R#=A *cӳ+d8D:SB&Ӊ9=#AsBE#TBywt2tI1H6@'zdEѣE1Ut0/l@9DCY@Lu@1/THFI\x2>XwdAч/Z2ڃKh94DEC9*I2ڳJUEI	@Z7#c>*xEY4	EWJm5axBM3M
YbYT+ACGOPT@ćK
KĎbQ76fVfSgikQIvi =WlXD	;_	Y3H5"PaVɘ1)Q8}QV3)W9iUR)A9"SXTH@QÆ1CAeWldSMW߳(ա8+?_
	$RxW,%7De(
]
:@fED29POPQ(B\Ұ1(:Q4]weEO:98#c_3(ytXt0d4^KU1dUTdç(4FWd*B_J_%"Tc>dZ^XLVO1Xb06ң>щک
c^29Dv9(hE_
A(8&_J_Mf${:)QdNp§"Nz_JIw+6YtLH9v$`0)5Be@گ"4b%}Gyiyy
y@D阮Pai}h
0=	)G;	e`
qܶѱp_ys#%688{2D;9J#P;(e&[eKJk:xO˵yd;ˋ'!*Ӗpr;t[v{xz|۷rJ5u7{LQK巊۸}jˆE۹ ldٜkMۺ
90hRa@һ;[{ț
;eY˛ڻ۽K
V+)tG۾
ϋq1՛]YƾF0[j{;FPxKlk@*,.02<4\6|8,LP7`-uY:|HJL<8
80ut7C|LΔũ`JM{	T蛻6Զ%|^mlb<`ViתвQ*IF L}CxkǕ\<@@DS"Aқg<{}€yC:XgU#|Z?\AS*_
ԎU9p%PX6Mly/qlaDI
?Pѝd3$9=W.`=M
PլIGB^8v~m-ē4PMҝ{e.m<^=%0NWĆ*Sٲ1PbQYDK1@"/CēGAEɕ4#HL:q?@w
e
_e[<$/$zՊ+UZ0IXD۞U,[$m"މ@T}D@Ϡhz$$<0
Kٞ@|e,#hiGhڿ*:zޚXG{r3&cE2DEy&"-}	RHR?t8ї;6N!1fD`N2Q[(#Y&|8ճ$/HNHUDc3$֘HL~ٖCUΈc$&,1Մk{1|3MA'Bd0Ioˡ#
9~29ߒ@Κ̕
eG
WWWp=
yKVefEb
	0dU:+^m<Ǚt1GA3Y2-"oHEV.9(I[.f,_;D4A
EOl,}&=[9Ev!ۄ*p{h|W;	P/O2i{t̖r>
^	410Q/%%qy8-_)2L0oHCQ`?=U^T8:3^AOa4_+Ӳ{Rs9Ђz
ECI?d~Ȇ3U+s-{"cM2dC
q,1$b0ɶo8?)~O8{_/9䄔>/H<a^ԜXu@_=Ͽa)WsFҌJ׏d\
	GFFGF

FFɄĪΟφ։ǘڬ؆FƑ̫Xjլ
7}6$UnEs.*`О?ito%XZo%|/Zn瑘	TJ	*=Abde^Þ(S$`d!UDgQɕii|(=o TT#W]졖
@@l `APh*@A
@AN@`koxEBKr|#F;Ix^۰\@@G6g
<h
x}W)`re™gB]"t(yYzlv[DZQGGXE`@P[G<x,t#!OBY[vNb$!H~'"z})(xfHffYIr5` +&`@ֆc"`IGL?L&Mј%<hމ(QdMЛG4hWZq5B>aHK$#o!i'Z g&W-23Kdª7=ˈwᑚz%⪈Ch!$M&{&9䪠ȫfH
H]my-zKmĥ۪sy%
q^/]vݱZ11	
@X6lбM[8L'#v7i$!Bsx6ߜYΐ%o͹
P	*c,nd@TcmUwl.Bp%&pfdg6@sH=HF0G{ԖW-<7n_cs%2,QhJn噩!Pϯ07NpOXp68nMOT$*>jNCD6	-T@Q#1d`I4*K@xd#&sPh8@x0up1Q&Kx	4q"g?2/ya@nRU<Phr2	cUTxx"&3ÉD)4Q$rWƕ0"$&I~eΨJvp"pD&Jd+DwЄvIkoaa%2QYf.6QMf)aKF`1yeP,1!0Қ	&:rWYqs6sC
{Y@:pZ}F@#JQT.l6юz 
HGJҒ() ZQ_Ltq(LgJӚ(J@
PJԢHMRԦ:дFϖ*cVծz`AQӪh$:	u,TDJWgk]|-VB;-jƢ¯pcCXJTv'cSC V;^`4C 9OHd3˦¶cO(>2U?R'fˈ$Dl/h#G%vUD/o	໲,m53j3_aKBD`on(\~6̢#wK'*F5|E0""2l0k.~Û񦤼2fPe}'F+ܚZHVV3]CY}1&7A41B8N>LiP~U}!h g'faxi2 f??dPR~n!w(4~!#Gѧe_ci>9Ĥ#HhE
4:S$W>N,9nN;^xlt8·P۟.A(GFS"9F)J+EEQɂ#RxoKWO5x/ϻ/dSk3$kLDAf4ϛu`~NwW@,%lii87I
{[8oy4R-e*ms|DCj'3;)gGi>ןI+XSwJ54Ӕ.%wnKO)]LFyN,
"e"=*
#
'LR	 .Y?HXe+]	>M=/qe|!̿^G)n4P]{]|ue$cMkLwG{;n
%C~U|H3==!pz*s@}3"(3n?\ZAt%0DE'DGKH<76#"rpZ;Z{#)G4(6y07du
V!vڤ[GUDHQH(0#@%I	*	NP1Di K?^`yXyZyaٖn{Rgp!phu{r8uٗiz{bp80#`=@9	Y IX9	PpYRq50Zi
@#Q].Fl[4qQ	`I
R!{P{$΀PToF]t9ICo;LIQПP
@DXNI)@4ƉVbZbB!P@py:\؁#.q":"&j:ʣ>:@ZWS	Xs!($p+;4+6ڥM&`dzQ]ISڦqq:^JcY@}+ژХZC;@g
"BaH
t=!t&Ulz$.gB07%
w8Yf7&#T0+ҟ͊Y"pjر|C0U	:
*""ꬴU犫zZpDG;Pp3ꯟ"@Ү1GN
*
?:
Gaʨj${2L_Q24;60yb;kR1@\۵08]#%rjIQ@U{c<RtʵvRd˩V˶jlKf;%{k$
۱X;d˸;(!Xy:ˉ
{^{%Q׻[;^ě̻Kۼ;7;{kֻu%bѽV[k䛾u簾+P;{TۿM	\4pl?
|	Rd_"⎠_.|5q6ΎhM=uBHq`M];F,W#p\5z۽nH)oM䎬hn|Y❹L0T	
ݿ*ĒՍ@EoUȉNR&P$݋7<~ݼXU^	nÍ.܏nRY솥}(Ҏ~["I5CMR5N"N$Ѧ|JR	8DQ=S\fn*jѼ!@yVO-ٚ[Pz+^	$|J0_;6*/rE?I6'Q/@)nZ\TM<
oFym_WQ=`2ͯ~1NTm̈KzoXtPҝi%XO>?od{5ta#o /z,O?	DȯѻaޏN?=wKX~-FGF%F
F#FF»%!ڕF!Fpɚ[ȰÇ,`*0BnIfЩ,
QR.$ Rd'sS@JUU\ɴ)
$HJU*	4u駑D贬ٳ'=X@C^d!V9!r,PX+L	dKeea$o!ΞՋi	zuuC.][RM*yVJ܂D^0	F"D@.%3mTވ#A	;PKaTPK+AOEBPS/img/strep009.gifq5GIF89a4d???@@@߫rrr___///999oooOOOUST000   ```ppp*()PPPqpqGEFcbc878纺uuu>>>UUU|||!,4dKK!)$$)JJ+(!㫐(#"VXGم+XxX( |l5{2ȱGo,@A@le-mW8e1e&QRX 'Xh6|JJۿ&0BZ("e"
0%J[E!xT5ІoK	HJQ&2l
Le-J\8	{x

4Jq_2ͺ5+#~"R^קx@ه)n6k$3`:E%ADUN}8$d:*SbSe;x0<8$1BT9o|@By&BO[YPc	2ч`3*eNI	
#zzQD)L⍧p
[u#9 Z@+`p#2PU`E" XO<@YsUkI.ea#eU^٦["}‘oHҚzRu	h%Yx2*US"S[0@H*1BBJ,iTU<`#NjU<?q*[	 b(D,2t`	P0MNkTj<",U#dn?ܒ,+⛯f
*SH`Ad?ưt˰ &|d\m˾N4F4
Ȭsk,Ц0ҬQ 2MJ0`))d[畀4
-}pڅt#y­YѢFHP݃9IнJ$xk
EK*ɘFep9a	\ $(ا4797>w~˶>3Y+r"7& @̟k!2*hak"R0xJT~Q]
8}i@f!ء8I\djp	
0B`@Ȓ,܁PB].FP
qK2Jp	^2T d{n~Y@"S$D0-+JL~I6p$0B\'U,CEDdK<Pi;dМDDҔ|T塒(ڱ(WHbtJ*`r	&HA4W@%lG$0哱 ;K"YOZ$#~w9ikTB=]s	×|̔|+&2B4@uڡ J`&|[X,Q]aBr(Q("CBؼ:)Ǘ0l
4h!:KBL*1X'dHu 8QFh)J)HC(F"$VW2͝R4<dI)riy(B=-2~
D0:iuuX(_9@DSY*哠K=@ cdpEEQ׶u͘c™"4t]CT-oq5Ep$x"2[X|ZdK Ty\q<	S%NOnkLTfLR(hޓ](T"gZ4%$6/&i3i1^$Syx~IG,>h.pahw<6ZV(.%r :%y	ۀ:<2ƚ*_9AӣKzPEUZ~PcRflowe˂L"Fz3W [}hPs])	[C
)[DR|܅|$@BgT;P"S=XַD63GM>L!NE4-?g%z C2:Oeٝ0Zf:}9
`
v*r3rmDF=dڡ_SuC1da@Y~^hu.~fCUS&U[jav|dFG
3
0.`:C_r\"*qpK`]"b}Gi0~Ey$npQ"Tr(C壁(KaV^n_"8JC5tc`1;*҅	 #"T`Qg
*#34Z380Mv,ϐ+ꥆI
c7hB+6E	֔'24635jgW]ju{
vᖉotEpx8X7Gu<\ya=8(btRuK_&H7R9GS^K4I+؋3IҊ8faFѤw>VH0}xG.UG&H hRxp[6YDK!\X	또0}{0}(7x
hЅ	#4h5_Spd&0S#iA^ЈM6yH d]IjƒrK㔎` ip2LҔmS#\cYI9ɖ<2|h0>ki
r`iMp	db(i
z9-|Ӡ*:)0Qٕh
cbɑr+y,I
2)BѲ
$4b
),Y
\Ž˜Y^9>pH(x(+f+y
b'6b
i
B@ʉe	)\
*Ӊ
	y:y+ɝB^HC)q'
hT
"d +ݹ
)JC3&p:)
)80"#MР',$90*J,40R&+&
0L3 Di B#$*,ǣA1aEU`
U]zBZ
 ~asRsLZ(NpE1y 0*bJoeAKQyKz[*|}QGmP@zC8AI^:1zR&
A 817`!:Ka!Uw:'j$BiںG_UVPhO)+Ѱ0*X8qѰ"
	*1;4ΐѮmyFDẲ;"³a8O+ɴR%Tв`=j: he˛gap+]%_;x{
u%wm+o;y+}# ; Kl[չzˠۺ|3ʺۺ#[;
{#H.2{˼AF?{))Mj+K+Bk	˾+Ka뿋!Kk[uW<\W|J(*,af2<4\$I¨P)vi:=9B,`AB'Ɋj",~\ŀ\h#AcDE̙%͘|%LYYE$COX>,GO5H%͜͚=LO5"Uz|$Lv,?ͣēlLR~t<0Hδ%R]f	=ռh48[уrO@vcSW>"qx%]!)mŒϊԭeBB
HC$]L,ŌI!jRN˷!jy,:'^v8[
v
ʎמԁȄحA\ƃlض`|ԤKY¢=ڢ|d&-+-M
'[ò-؁=Ϗś\u}wͮy{q	ڦF=ܬ=NCܢ`-SKkZݚݔۮܩ۫K؋ؿ]D载-=ܪ]]جa]_
]	޻̴߄߉+.לm.-sp8:<>N6.b;L9LNNDp.NRNخ;$>FNf*޿,d]`ۈp=\NWYo^s^>x^p]m≮ߋN>痮[_m>H.ON:]]MQ=^~ꐞ/.Ȏʎrn~읮Nݮ..NO/^U^q?
6 _砽!8nS(//?<_^nHAC'v?I
_֎LNOPkb8KJKJA>J
JōJƑؗ6Kٝ̏	Hm|6K-D5h^J4Xa%($`6RXؒ88bƍKдIG^Wk~j&ի*Sv Β4	lP&4.)c] $H ZHw=	D5mgD?}Uk7}XCdJBy
v@܂.Y`N= 0eH,3P-tԢCOi^CbڝDBIR2jTHqT17Y(@|YGY8wyOI%^vhyc fHDT$`Pp[(1Up &]ԵD8
m`-~dӢB9u#aXfI"(	iYH(<cp9@RuArVA;IvfםyY(q!Q~?W.z &b` 4/UAu&OPmy#@5pnĈ$(ZM+da&ZM:b]EP^cv-&K.Vz퉯StmR25(&l[,|^I-
STB"<޿wlpE
l(,ɺ(IBW3b3@
zl
:L7tfupD+%.?s1}'!	lG-uؖzq0Jhz)k>9flȽ|
v{rLԀ,ȋœp\@-Fl 0L 9R)텽fk`k^7qo@J #[apJuJBMt9.>Cf܉P+>}n*1PnWb"!܍弄`	@7b9q^AAA$.΍0DkKÇj|:	!8y$ps!-i!adWm}[	3d(a+:+S&*)0IFF%\ b(!"Nh(x̣b 6*qV!89Šl,v̐K1>B򓑄aBB
IP?$)GS.bװG)򗞈e6bŤJDi2)%	L?*}̦6nz&3K'j>w@4"66t♝.vaHBІ&!zOLSWɭ(CJWҖᑨ!(zOVH8(G	"$'yd8HMjCZ36ͩT1-˧!DPK/槕gy\J-yf
uh;i@v0kVIsk&#ITUKJ@˃^zE+O5[fW;t,FFdGמVHIjir6bhoԲOV%Vs9<Ե,>hnFSZl;#*cz,%Lp>Lsu{Zh
{>KŅw%>xQ\_$8*\p5bڭ5n6U|iIwr)d,9eѓd6ŏ'KM$iZF`׍3.lbS`W2CF?
/m1RXDl3b"G:9ɧ(Oek5;]W9q775vaBMs Ck/!ވ[?1#x{i? L7Rzc*Y7q=W>,o{{J~i:AnfPP'	y#,LV4;7F"\>I@V~{7~~yy_5Swu}}pp.{}J2.({{>7y!{	KW)P{V^>St=rc(gad_~
@		>X@H7"xrk
-0聐D^0"K,! ! K ӅRF!Đ?p$"^bZMz>,lmnNF}շ"$KP@$+0Ęba(i!ED-`_').@@a&H4̶~&a'2{"!<8P$  KҠQ*+R~t);r
zQ21)hБR6Ǝ#,EV2<F	dua6C $T/@W{f8x$5Gǀq5),).)Yh#iCo'AD3!Ajps"GV)X@vcvP!#+ց+Xuj|pD|k݇GAI뱑HxRţLo'`$@"PPp");9	L2
Ao9
M&B@FA1F i0W	L	I3	}!ȖY.@XJ]OZ
p
[HXXK2 w8k 5}w&* 	AQqi	zZ'	j"0$P^H{C(ri&
/!+;̥(tjqRqTڢp+H!(vq7a(b!kca3ev
Sc#w(vzł|)ɅJ	وp1`#e7sgo0(9GZ
rDȵСvۺ=ʃfKuj[. Ω
< &Dő6A<CIHW0=&NXd{0P"0/˶K`@I{+1$Fy:ie$~?w~ɻTWka9@3{ĹxڱU|J!  k{-)k*)yp"1l.1)IٸW:a b&`qJ>k™Ơ0…y{!j}8$`dwZ:eq&\n~Ds#4pb\1:9Cj	0?.1jd`z罕>#ʄА0`>@!쑥LqƄ,u,<	M$Ã̄%ʜB"9@
y2.0	
(FPNPM+=V
VCpz"p<jZ~L.EG
Vq]vm.G;`L.A,~2dYI؈؊،=,qא--؄Ռ
)j?iArوw'E`;=,W%(
]}Q(rF
5KiNM``8Ća*aM	%AkݯϱA8~}pr~gzzF_dT{œ!]KkmUX~p,#nW!V3)G
0yJ
R^ng'n0WM7Lh>~T;^~)^	
G0^.cbn=վpܙ YSn	u
7p?$ގNn"8 #(8.ٞs(_4(e~y	8XD_FHJFo8	" Z\^`ҿLhjL/
C[E+7
Dxz|V_2NtK޿WaPI.D?V?@?OqOPs?/Oϝ!k/8`?_8@?WNVO^=OBB/>L,߽Uľ!I?4KJKJJ	#ɏJJӸ
J ԓ$JKJ44>,!`ʦS0DH$k)pPǏ\!(\rɃ
XpM	eϟ@aěH1c0hㅤPYh+X21
QæP,~bNcB-l*
Cȥց"bmaYPѸ#J@6U(R
aqӊ(lƄ-TPb"%PFl"[+Kx-[		>0=\woˋHCխfaB%/JxC]"sA&Za1Bh(@.,	НpUx
~(?e|#5݊#BMP!=*rc	prf
, t%0HA ipe#!.`!t 90J,rʵm|&PE3:r/‡%&8oR(.qdA
y}tN~K0PxCD'PNtlZ#n	%rv.@'K0V0tdIHl/\!dتCA4z#A	Ƞ|zd7q6ݵkGkRP]=,D,07d@2B%ѹFI2Smg`rLG@zzFűp1֌w\fDG=2iܰ!9%(k(>(PR&,38Db1`٢kF2l+XP@iۊQͫ^ӂP+OjY]:P%M0ŗ`9\0I\`VjZ@A< "4IX:D,՜Ax)b8^(pbLR-&]@9
#TXZMd.` 2\\B-`@ԹU6)LTd #fZjF_
ptE@V ק>`e7+`U|E[[Қ7ࣅ0JaU*A'JGW*#)2:֮0m(g`(`Xsk*`_ED+Q4
cڴBekS]:ub
z+ 
1to{ի^zWyVK=']uh>Q)=CA	e@l8]۪W֭NoLȀsn8αo32dtCoN/Pm>"cͩ<4ġD^@)v֫ rݱnj21.^+ckpJpbI_y9b,0ND%YYј>F.w4$fN\- ~&8n<̴gHuD}tt9Hi3KOMSVif{Wdr.e9S5+Y{r*rm@O	:I~ӉJ	,v~;rH1RE`ci<
o=O:;PKzZv5q5PK+AOEBPS/img/strep022.gif}SO_}SE/_~SNj27u|75$?}7uԩ%/_~S7_>}~o|N:d>75|oG~˧oԩSP>	/>$XA	.d_>kذaÆ
6DO_AO@
DPB
>QD-^ĘQ|˧oƍ	;/߾7nOA۸qƍ7nܸqƍ
;/_>7n
oƍs/7^|6nܸqƍ7nܸq|ӗƍ{/_>7nOC~mܸqƍ7nܸqƂAԗoƍO_~7nO~۸qƍ7nܸqƍ/3'Q_>~7nO_D۸qƍ7nܸqƍ/>7^o|6n(۸qƍ7nܸ@,h „
2,H_|8`A&TP!|	H`~O@
DPB

ܗo,h „
2l!Ĉ'Rh1>$XA	.d8,hP|,h „
20<0…&O,h „
2l!Ĉ'Rh>~/^p_}/^xP_>~/^x|]xŋ/^xѡ>~/^Ȑ_>}/^xp_}/^x?}]xŋ/^x>~/^ذ_|.^x |.^xbA}]xŋ/^x>~/^_|.^x`|]xExŋ/^xB}.^x|.^xѠ|]xEwŋ/^xń]xb}]xA}]xEwE]tE]tE,h „
2l |>|Ä{Ç>ԗÇ>|Ç>|Â=|Ç
˗Ç>|_>}>|Ç{Ç>|Ç>|HP>|A{Ç˗Ç>|!|>|Ç>|ÇÇ>|P_>~>|!B{Ç:/>|Ç>|Ç{Ç*ܗOÇ>|P_>~>|CC=C=C=C=>~	H˗O_?"D!B}|"D!Bۇ}!B"/B"ԗ,h „
2l!Ĉ'Rh>~'p`?$XP`|
4hРA
/?_>3h`|
4hРA	˧ϟ	?	4xa„	̗OB
˷?	4xaB6tbD)VŃ/_Y8Q_>~o|$gCK/>hQa|H_>}-ZhѢE-ZTŃȏ߿}O`|O_|'0_>'_|Y/߾
|	ܗ/_>}˗/߾|/߾|	/_},Z/_?ȏ~O`|'_|/|/_}/_}/_||/_}O@
/?$XA	.dC%NXq>~gp_}'`>7P?~뗏,h ƒ3/_>}
̗O|˗|'?	o@$XA	˷`|'P_>~/_>o߿|70_>~/_	?	/O`8`A?	4xaB6tbD)VŃ_?~	̗?~˗O`|/?/Ŋg|/@/|˗O`|/?}/Ew0_/߿|'0_>~'0_	̗O`|o_|/߿|
̗_|xP_>~-ZhѢE-Z<Ń_|'0_˗O`|/@<|
/|˗/|/|'0_
̗/a„	a|/|'0_>˗߿|70_>	̗_|/|G0_	̗/a„<0…:|1ĉ+N}	/_|˗O`|/|'0_Y(P_>~70_>	̗?70_>	̗O`|/Ŋp_}/_>/_>/_	̗o`|/߿|˗O`|/?/|,/?-ZhѢE-&A	O'߿}	|?	4x@K0@	o?~o?~8`A/'p O_~'|o	O	O_>~	O?~/_$/>$XA	.dC%NXѢ>~ӗ/~˗}ӗ/?/_>~	̗ |_|ۗ/_}_|_|/|'_|8q_>}
˗O_˧|'_|/_>~
̗O`|/|
ԗ/߿|ӗ/~/EhѢE-Zh"C},Z/A,Zt/>!o |
/Ehb|8|'p "Lp!ÆB(q"Ŋwb|/RԗE//Ŋ]H_|.^xŋ/^8PxQ|]d/_|˗/߾E]8p_>}/^xŋ/^,ŋ/N//^4//^XP_>~/^xŋ/^4ŋ/JܗOŋ/ԗŋ/^$/_~/^xŋ/^<ŋ/Fԗŋ//_/^H_|.^xŋ/^tB<0…:/_~>|!~{Ç:OÇ>|Ç>|C=|Ç˗Ç>|_>}>|Ç{Ç>|Ç>|P>||>|Ä{Ç:/_>|Ç>|Ç
{ÇÇ>D/_~>|CÇ>|Ç>|p|	H*\P?$XР|'p "LpB$X~O@
DPB
O@
O,h „
2l!Ĉ'Rha?$XA	.d(0?$X`|'p "Lpa}8`AO@
DPB

ԗ,h „
2l!Ĉ'Rh"ƌ/>3GQ_}5jODӨQF5jԨQF
/?5'_|4jX>QF5jԨQF_|4j_QFEOF5jԨQF5j~ӨQ@ ˧OF部/>5jԨQF5j1?ӨQ#A˷OFs/_~5jԨQF5jԨQb>
ۧQƂ5/_?5j?	/?$XA	.dC%NXE5o|mܸq|oƍc/7nܸqƍ7n܈0?qF-Oƍ5ӷP_}7nܸqƍ7nܸ1a>	ӷqF)ԗoƍ7ӗ_|6nܸqƍ7nܸq|˷oƍCO_~7n>qƍ7nܸqƍg_|6n܈_qƍ;/7nܸqƍ7n0qƄO,h „
2l ?}Ç>|Ç>|Ç>|X0?{ÇWp_}>|C/_>|Ç>|Ç>|C
ԗoÇ>|8_Ç>LO~{Ç>|Ç>|Ç>|Ç
/>|Ç>|Ç>|Ä˗Ç>|X_{Ç2}'p "Lp!ÆB(q"Ŋ/b̨qb}mܸ|۸qFoƍ7nܸqƍ7R̗oƍ#˗ƍ7./7nܸqƍ7nX1_7Jƍ72oƍ7nܸqƍ7^qƍ7nx,h „
2l!Ĉ'Rh"ƌ7r#Ȑ"G,i$ʔ*Wl%̘2gҬi&Μ:w'РB-j(ҤJ2m)ԨRRj*֬Zr+ذbR;;PK[WPK+AOEBPS/img/strep067.gifrGIF89a???@@@///___ooo999믯OOO```𫫫000rrr   pppPPPUST*()󪪪;;;qpqݜcbc777vvvGEF878<<<,,,


:::xxx555uuusss***tttXXXJJJwwwgggWWWmmm888444nnn>>>RRRGGGVVV666¸UUUEEEccc&&&HHH+++̉yyyCCC}}}aaa)))FFFdddqqq'''\\\ZZZlllNNNō˴{{{iii===]]]^^^BBB(((TTT|||AAAMMMhhhSSS!,	H*\ȰÇ#JHŋ'hqB CIɓ(S<9Ȏ01ʜI͛8sɳϟ@"бȕ)]ʴӧP&@իX$ʵ+
+GAٳhӪ]˶۶8ĀצS:/_	LmBׯ[.CHe
k̹Ϡe^h$]v2Jа&f엂U^)$rN	#>еj뾄KljXp]OZ.AËߙN'}
&Omu
>'hyzM`g@`	X9Qfh9UZ&1U4m>Gc}P@G%,Tv@Lx@`|S`P6喛IN-^MV-VtyRbߒv=&S66f\T襘>mM%Z>b*jVs/V
|*bq~L@*i_J!`6+y%1(&3:k'@V	܊!Jk;.b]K&+p0R+fPoWov֧$Z\
PS&A(	2{Jn8ضar:LBjPP@'4<+	J+Qg
4S0ZvJ-vH lZ MYRqOvKUɃ'D7؊A&px䘇xdtq2}AR<7G7n`yMPu
n{
T	YސJ9l^|A@̀i//=Þ	<LJ&$%|+}ՀBZ(z(L~D#"8#/[#X5Dc6@tDd͈|6tuEwT$Ā	I@) n*`0RB
.YmDc5|yKq@$,rK)R׾T,j$i(`
Dfkp"L/$u7&h{
'gK3݋R-@ 8;!Y
7d5Fp2Ra$[(CxR"Y̛U nVt1`IL|"O4T|@pRT@ԉOO*)Պ`nF@:B
: LmjI¬j
JB"uf5,:ւ(%1a$Y&gbu=52s0`lPδn:8&
VWk5Nk&j5G̱fի2@:Qj
c!	jjH@(4Ё@PJL>Q*Oᗀ^V@	mImZ7@'ϻֆteGނ:ׁTneq?HTP w@4EJ;6X VgzF501XW򭩇M`*8n5j6Ol0 ˵	Hd>!r㽩$s-[ivږ^NshiKymeV(G5۹F3fY XL7s
`А&С7x:7/ U#iLzh&LΝNg,`sܥ֪εflA^9nJWi]-2GdpMmPAmFqvmk6=El䎷Ds[DpfwEHM?*oٲ1Bp;d'PoMMx'6<'5oƏ/hyPo"B	`?{_
ILx.Xg"'CL!GgL
k-ZA-%1
X'ձ&gU2}'!&}#{A{r!4Hy)*Avr}ebآEX/U '5A|!GbB}![؄u7!zK8g#:8adQ1|sWx~XrXxj"Xш^W!=80>8EYу؊(TsՖ((o/HHx/ǘ.Ԩ.Xk(H.2H-蘎θҎh-8Wrr(,,%ِ
9iivk5Q$AqĒ͢A	$8W9sͧX(yo*9y,3.78WA0Dx/99BI h#91jQ?qǓ~6@If`X	w0E(fe9*rdS`|Iҗ4Qy:Ol&Ҕb[&OqYyB( bհDY,{}-J0)I7v4Lг֍Q3Bd}YSQiP_-Ii
S-N
V;D[Ac
EypVT0i?)ӹ5UU2qLO)&bJ3WC3M"8JFU6Lz[dJ{a
TwyB1߷r\AWSIMB5J6LW"׹a	B=Gf= NʢUQ\d[s54AFDqRA"Fr*R	0!0\?hTDDlQ*ut]`V4Smd@ѦmH}(a5e.:0:aAu\Ĝ!"K@JX(SrZQR dBmtI!D$[ٖPy%sM©`SJd
rcsZ:#ctA
fWeDAZԬ|@aM%QeuH6!B2h!:ʛZJDza7>tKq5MV䫘jRB{ۗ@-~q"XWn+ĭ7ź˺$
&Kʙ6J3N*LzKF5\+1sZʪAL[=	KLNJzI«$%ꙙ9p	C	`{TTDljCC5%{t:#D50ŧ%kw+\y;NQs@4+9
DK
Jx!<7$΁Lr{5BTs:jA!9P|}kY
<*LKD!*Sq:JOHB"=ҬQO;P+D.LɥMJݩM
ifơr<-*
UD@F*J+ l'MmXfk(M:9=8*[4^FE)GLzu|sKn!{A<1IYٿ:-i-a;pu})wIʬW
hE5Hb{=$Ak6@
tIgͩLTWsLD,(?.9J;X34Lz[DۋՋM-e*\ߗ<]-DսTVQSMʭH|G{Kp}YXJ`黮
dlj&AYa3K-g@fTH̳(mݍg4ʩF%,Ihũ U&}➱hYt8Lli#Qۆㆡ
1XϴŋO4&#kt8F^Z1)SWYo!PҒ$.,"|.ǍN9Eia.4ӻ"끲ri
ʹNa8a@!&T*,^
^~vچyŘ0@ÞiY黨pP8
u.(Vz-h*andsdM1U&Ii!E9I,!VO_Le(I>T;,-_h~q]R*\HoVZ/OPf2w
	ZTzprb"Oob.@((UhooJ^*dhA̪DğiEg}8o6[\|ڎi^'PP=f<>n
a!T
.:6{WT-سtό؏b]'??KOdmkO\&x`A
`8Ck
TE5n@5Er`I)Ud@@P0h-%jcТIO~P#FA
&!*X5@RufQaC	;/я!b,9a#_&fܘQdž:|jKRYd̎{&]bөUt__2Ͳg]ynQIiV2v浃޼rȿo7<|pfX AsʜjMuGd9#Sh(N" (h2 JP#
AΔ3ׁg?	j	p,
 B9|`8XFU|Ca
bu$
XZm=W<$pIr88(
	6K 5O/chu/UB3˪_|	X+^	| =DY25Nbxքi[dO
Hb>DճdFWТEP0B݀i--Z씾F,l{$;#a&<fX7J:d-]f3HK}qkGրo7|hRn^^ӾvFؠ( 	Nk
ݹ|oIyEI (p
|Z+au (~fb@T\e MgRy#zc ,1*
`=I_5Wo)I5:'i	@*ēxvKZ%*DA;!ډR W3i(8˜,&'ECr<]90/{JZ$"kÎx0C{((p=
n52#4#5GHs$AC04'Cϕ	,yFJETM&m	#Xꗎt0cUr6e+֩uMlfSf7\R>$/SKcr;lySg=yO|Sg?dP4
:οxyPFT}yQn!|͗QT#%H'3Lip(D3iMmzS攦g@ǹKQT<J[*`G-KT}OrUfU[*WP(q*H:U@
UVU_M疊Vs#OkK9՟ǭr%laJו
MիFXTe`
{"+dS֞z>j[EVNEhIڍvgSֶ(+_vMJnw]+eY=w0ɕr~˝Vז-qbmu]jDnz7BŦFI[>sCio~Wދm.~
|O3rUD$pi`W&%A<k~t5uai%F?YCT(׹%(rWP7T='FqTwʼnDd\Xi
2BD9oC@\ZEFUd/#$d<doINsCd2)A3&Lhh<K~N|@o()M!GYS	+<`+atZwӛFluk,9U$ؖ	xaϖs͹M[׶-"@*O/hI	iD@)OuSD'kAcF"]ҧ1Y/JȂOբx;3y
_-чB<[E1`o1 $!9v3@!p&?aJSxb2{KJ$W·=Y[P$3< $ye=*M5/Bh d6|+3UsKoI:{B}motqO4MAI&DݻDȚq7{hЁ\CV'$	?T2LT
aq9[Z`a(t/9\ƚ zd/=
+4;FCĺ|^ĶqEj	CعF*=s	 FJG瘜>p@ȌHB-I*Gȥ@9C	C
QsEœhG2B$ʙRB`DQ6y4>
 ;IZ)!9A7)DyHPGCcGYt/_>10I_SA*ىQ3J3!
ʴDy?KKO#{	Т[X8+JXKJ;́=	D"̰͌l"LHX.1IՂH
ILC̾$95<3NZ⬉c"ɑMZD	hk)"ԓq:yc"Q>92Ɋ:JDq11+0Iˮ<6!M‰1Vs.NNR	i?Hl92-ӊ
xA)3)ˊi<x`3qQ~I cɌAD
6dYQgCI"9:Y։
ECþq4)773;H	l18:y0:%z&lE#P8@#4#".!1"$?)7ЎPQ 5DDHx!/
za4{1=IUD%%&QHRCST%C@!9UI7M P?:Jr
8FCŸaF/}d/A,R;QAkʚX6:Nf
o=]RY@3ZGfaq|#:VԪW(וXHȴ
IvcHh
sp7s#9y8AY9DA{CHYOLͷEM!yM)\F48-<#
w.MeݫŮ"Ʋ(zI=P"BFe"wrC}.lF4RU6:ъԡ>L!H[
[ځZ\ܤPP`h5p0Ԉ͡8\Jqqݎ݈[PN	%9ȳ(5VE2M}l_}ߙb[")ݭٙ}PC>׶uСz`y_בKee^O
ai(1N=e=U	a(
n判(_JwC6>&ړ
[pǰȹL3	hjEL]hVXmQb0,K!Hb[bNkbzb7FV86\9;Q QCUcj`7XrA<	y&eQ#'/y	Ӟdf=)mI1ê(HpZˏYq+;6#`9+fjfk4782nCHF_I0Wv[K+I)Xgvngw~gxgygz~Am	"{{挘w5upi+P)_*#1fkhh+nL4f[Vrfs-*i+@]Z^3rY;BdA:h#OEjx4hj61fbcmo5e:i:Y`;ihYzKxG_E8U# jkj&,U&:?kȲjL#
qQ=тU65y)80lR+HhNg
nm~m؎mٞmڮ>H"\)H NQNk
)1:
_0p%j! VA>~'{gTuCZ1%/s.hrFoccXrӰ"QjĐdj2W	(;HsW?O`9W
}CpjIPsC7qQxnTGŴ[uefWuv:؂jЃTj(H#x` ;[h>-VvjF7(e[(0icP6DM0nAy2 '؁(hu9@u1Rbȁy
k]jMv
*uԘqׁoFaf.+xx:8jP?E/k_Sp]eYy7`y8P/(g zjxieRbzz$+4H7p5PUX3"%w{x_{{}`|7@|g|,h$"(x&'X#8G}i`}{2(_/rz_J7卮_O'(OpȔ\BD 5^@qȨ膵"G,i$JVle/gҬi&Μ:[se5'U-j(ҤJ2m)ԨR&
άZrj1cG`8G?2I"A4P!C%RQ#G($1͘'Slydϟ+T2ТAx4C:8`rlٳi׶}Cx-xMFXbƍ-V=ұskS5MIzҫY/ߕh(aE˔ss,p5`\b`tMgbgvm!$^gXiKpaI^mU3qTcGDAFp.<wr I6aMvHQ!XwFJ%Ld7|UC}` QMT8>G5H5b	RC)v$MN]IgꡤXPPs
eN@0d)(d{w[QuLPsQ
!TFRDHRM({p,*,:&!i*3!:YBI4bK8l)r*)6hZQb*6VM""U
7ݴJiMnfaI0"	`(qX!	 H"Zs+K֘,@ZH7S 9ϼ7,=1ZQҋ+ńtQF(մA)p˭ĄV}5׾-$V5kM5	P]	<Մe#,
$ 8">,@@$3xuԟJ
oxxb5rT}yaUw1oJR5;!P9	aoM$UrP @p@kDp$E]S, KX '^.M@q'%!YגQ$G8f쓎P*@k䎊%8"(<@53Q-;PN#3pqwՐ!(.,n$d!
!N$:N#MD0qfܸe0Zbx@@)CEƔ;)q5@-Yg.8rwe21c|H@E}9H!S(21
1Klj'G
(08|\q"	S3R()Rai
ZP(⢥Ye/xp20VL"IM3H'q`)Iq$-OC蓂FZ8I
:eSINuS]jt2h(*L(o	M
8VG`ZiIZ
@ݢ]2G^#z%fE B tkHfu^IWl$HgP¦1]	ѱg
dTA+9E5%lkAڑ6D$ɥI*0RgxnW^[zۼh-1	STc
fFpV	.+AUcej{u[J18@Ƽ;[Ɔ׶heF5@5!Ր._0Hfx}lbO.'yYt	!Sʼn>YQQb.
Nof_Ajd	c'g?5a|б^o>%0S`p\i<)P*Y^H8H@RL	k_J$I$P5P9_ A PhArTǍ(a͌
]\'1бhx@Z⟷PN
఑PZÌBA!?!!FaYi,L

WʍѠĎ0(533!3"|A5 U!eYOqXOwYx G8р1" _QM]..PUթl"-0O
=a,RPlXQUTK6fX0(Am_R[#+Tx@
@AL"%%V&n^)Iɱ0
5>URMv2Fc4)"1x<V%#cܣq>F(
Wd
_4C$v}A/\8b!' EN"8A@AlguGrHM㖸.JdNĀ$C4lQen8FZѦҢuLZ@ڡqBKhRx^,v-M8,UД+'HQA.UJO"ɼ,n˝=F<g'UQmM8kJ&PDg?Vin>nAkMT*PLjYj(x+9Y(Nn9]H
i/~rhJ澄M)t@$I,pTNNXh
UݚKPNVHl	oO
pc%zh&l,@]Xo%lI&1rc,1]^ >Q^!<8z
O-KϪбK/Mq.gdH,HD'jO,RT/ߧı^!Nh,0|&'/Q,c((I8
"OP@ K+#@21^2x޲jhTe21c1{22o-3gHrɘhl2Ws>i65ߠ2/'^L?bȷ.lZTOhLtQ->+-=7HIkD+)lC7l19V';g:{d;#'^IR@y@i/>,)и)OjKCm\9V=+R3-P?4;,M}yZHo!8ґE!BLٽI	/UIN-ڎF#º5~9[_:_pV&V;H
G!YNRŌAhL,5 X6YY~4-k.WW`cKuH)%xm&U(EnF05ll["brQn즤!Ur
K
%HG"roʡ]NɒzP옰j;1ckkwavc{7mO~Q.P@]vɒSydTPaJI䈱[5%>긚/J2wӈLҦԪ{7Avfo;w{Sr]5TQSz`AhQHP'?U;%Ӿpw@B5xڹ''/T9J:z^u<ȇȋLS_/@sCTף7%N̚uѬw76}s'9P`SMPܼ%zV sþQjSKܗw	k#~y#ߡ/CJSXjc,3Ksӹs`wtj>
FLm̯-5`Z &C (80 1D88#RD`IW*0aN;yh@5A*ꁓPIzk֜NhNaɖ5K5kٶuӟ.	%P*H@Qj
,9ѡ8@'Pˀၨ+< <PF.YT6fw~H$s2o&	8Ч2`z2`RӉDoh=йʒ1klɊ 뺹zX'*)*J*RHR
"
Y"$SG̳Т6-y)0ih-(I20Ɂ|=+>
$=H-ՀHmRI`rNC&! iW),,| <s3?/KLbV@+hE6W䔰7Sqy1* [譊A{ wJ(`k[vr+Q#Ƀ3 J1-N[Q^]{5Y*௚@lFK/[HʣT"@nPͮ+X	+7wbHm'ﮜ
Ok'PVnjnH褊D"jNdSM]dGIdGKTH_›0(?|G <2MRQ%
GprS,jBGT&ZB4$2JP/i3tHf<2E*t4!]g*am"*
rlI'|J+`R3F,tc`+uUJ$[̜icRe_būIAK8dnkrp(
CA=XdOԺ$u'QvE4J$`*r^}d]f5#YbcEԮTLX
~D9	z{֠SIXP%)+"pY\\}`2\[j\RDD;З "\]6aYLta\G%r"c'Y5n[%Z5ZGZbkKN)I6$W
1_b^'XκxX)V^.6/~d? Lu@)	2 qZ2I6%P	
Q!Z,ZnLޞ)RM1SW)1L!Gڼ[|A
QN' g8Z5#q}2Ojpo"ySe q5J0X8@	v]45-Z
9-DPWFk=sݾ@̎4K_2'n7tLkڝ:Չvhx;K%a:e*s.w-4~!Vw+ȭ|	?
&JRb>E
pڢ Sϭ|kEײ_Z*
%Wk.o|38HR8=U__ 8e%nWNN.&;ڔ10ïZ@oLZ<K(t
'IQ.So14Is*WK'2'T36=>]s6k+oR7ge?dAcCШs?S!2IXKg":'BTC.K;0$\F'J;G:;)U1(F4(Գ<˅uD
H)Js<:ba.¤Ȍ;cvo2&91UE.0F3
BUsK;GK-O9LCuBM0*ɳMM]oSu*T0EWd*|Z)GV:hV_bGc*Bx"d@5?>0Yo2iV"_GTO5SՇ,NTUieZU[TGs\U:@^BզHUᤝokO]-RNuVL'HBW;U	=MbY~/竵6Rηva5texb,\B@LMH 6SOЕ^bcbcɂq@@#I%j%MX5$t/i-d2iBL`Ebu,.kjl>P)$"k	ЂXxeUeb?lqȞ*KOng%ncg)*Jh*rfB*[r&)B4
P`mK"0"mCuZ4in$` c&{gIoV'Dig,wGdSZ$q{C^"G.P1w\wTzoa6|dY]$wr6,rtce6,`}mշ:"#.bx=
k1*J"j6㒖/Yքn74*&%E"46<$jAD
w@mVSRl/$/JKCĨʾiC2&l#†7KdɌ#l#7r5ch¡ &B)¯dE"f4./Ay"ORFłNOMv}dCIXq[5oezX$M^&K44n%A@$V
-H'$ePÓ!Xc05H:c5i*0WM8Q,8+bEG6w%FK=xj1M:ytX6C,DQ:!}"0px+WaU!L58'	2YMxK]BGXjg9n9bjGBwSHǀCb"
J@N?9󵬨(3h;fc/xM-<6(e8[NGq/yx'9K,#-YRxV8VׯkmGhN)QutV-
|#_TcyMK4BQ0EX6Ô
\`:۸hŦ', IƕJB~+>jNji%SVSL*ZBź$*$B59h#Rz₭X1E^j%,Z^.Y.!N$:#ΰ9%$F#xA]k ;gš(|$z&.
0z":'G
)|(q;%xL
K"la$
PH.aÉ
RR^[ӻ2f#`*)h`O`(HȾ;(,\82҅|seU-9d'pDX'Y>-Jwiv\>fysߥ`b@>xsJGy^b-3gCg7CD
Bw?&9P'E7cx6,n~ml605∃X[3F]I0}]}*Zb&Ml<5SA>/.Q@~F`s$O\[$}[RtK'At1TG%ՙw">f"S.Klty=5#'%	?#
QBF&c٨Y],沍%v/y:>RWšT;H0…:|1ĉV@ѡE	(	(6#APp`J2nj<{BO7\gE&XS8ib(U@
0H,	
M@MkU4[%@	lMLS!``1s5М-D+>Zʫ;ځ+Թ
TP;[ w
2oH禗60*)Zر\
`iA~[wz$F<0@a5l@va59fQ"A=A
PL
4@PQ|I@ݷ5GAw%FiiMtL$EAHjdfejjD\vCQeIx
H71 Xp*n-@uP&AӑH*$
=YMMRhXV	(fHJSL"(U{h@D*D)`^G*NJ&>(jinOݒ4K--jnYPV2TJY%Kqe%7ј>mO?ChUvۜ"YpY~VͰ]xk14r[%3%VRlrfDۯ2Y2E=L*)C\etF*Q]RM,R)ҵG7{uBE-VCvHf\nߍ.x3׶Fj)qo0Au۝f.x?yONy_yoy	w5r.#4x{N{ߎ{{|O||^F:\Wxql()nEyFsAv/QC9*VPzx"‰Y8Y]
15ipPGBxpјӈ\i2IIrPyLR܈vI`(2	awpoABuype "ɜ9֦_	-ii#AE
#‰h:&`LYi
(ٝQpRdžgh&CxuJW!POb-Ң#bљ8u1nvHCj,f3iHwMH&LrWxxTO")A-a E1t&pj<Otv}r&Z7Ȥ	u!*PigS`.́{[#`i%rT5b`O;ڜG{$P>ڃo]UR
׆.$"hmDȚi>r^9#1WϺa$q*AϑzDw:gft'wїyzR6*g0msK7`op:bnx
a{ǥ]:#lA>Cai$qjY!:n׷t`DZZjֱ{ocu{siJ@zDJ+Vm/=ⶭOѨҠ֛O0$E31jih=y9/v{D6П86tX\;eku&ח:`-J$eENҵQ;}+5fsbPPcp@5t6kLw
8
wdڹT+REP5e[=Kt;$Kc(wH)>šJ*YSTQit{>,fFцoϨe)f/|Rfir'wG"viP3O+ƔxJUCŻ8֫h7E*jp`(w`wD:H(i*m6Rbƞt!"iHnLZ`D.!JTT36\1!k$8+bDwʋc,o'h{HhtQ6gw77U&qJY6Ȏ|jboKрvǕ+Ap{K`U-d$[Tľe%ldDW
9&
gAz{ƞi.
؄wȧLvwDfdFT>na=oB!RKoH?^J/J\nOQ:J|][lq9b
_aƦfmjvOAqyly;߽'0sQd_88|]nl9u/oNhb#tLcޙahzι7o9'w^?ώ	fbpٟ?.#~ ?e#8aM`5
$8AB
>QD-^ĘQFv0H%^PPI-]SDM,,РB8TPg#~4ҡ3>UjE*^*V]~m!$Υ՚JPAkW\U	{Uݼ}}jL)H6@Y5x'po5˗=`fk9
ODx5	A͵%psg۽}_=J@H;0Ar͕HH'!nݽ$ao SkM,G7tH~M܀&BO/* ҢM'лʭ DGt+D1:J1Xf:$DES܀D6؛FPGLJRC.I;+I2 ?-iLjz<L7j)/ē.3P5ДrM*$t8CjPG
=hEUk44QM[,ܴԙ"/9VLTWM#0|@LвVa_
O'@6Yd`hI@Մa:#l4f=/h
]>!5z3Tw(,K_+ʠ܁FZ tU!ibc,j_8(݋G&dbVt8`_9PΑAvhbwh&\eh	hH	zkF{|OgFLד'σ&t?.LЀ,`@6Ё`%8Ϡ`@ GX`!A
4B@V0d(p
BaW`ADkdĆ6aB*GJ()$
%U ,`UtQ^	qʱp5RPB!zvc	*RwW
h2@	\`1zCJ4F_X!vB;H)Dr_
DICRu" %찌J
ƨFQ*,"2Q-Јv(Jb
T@H[vrh1L
8h^8|lBe
̉NF!f@QZJ`
V1@5
jƆR ht#28.XԨ
XFvֈ(CHo{Kӌ=9)Iц;
pB!T FAPRBN]:շ
YBvh
D!R#*!J*Y)Iĵr,PUֹԴ
Ī*STlK5jElb8N*=;PK&JrrPK+AOEBPS/img/strep049.gifT>GIF89a@@@???쿿Ы   000```pppPPP///oooOOO___rrr999⏏ggg;;;vvvXXX


JJJ,,,nnn888:::777<<<yyyssswwwΪ666qqqxxx***ͮtttVVVľµSSSFFF~~~[[[CCCRRRUUUfffuuu>>>YYY'''lll&&&TTTbbbeeeWWW===\\\^^^cccǃ]]]aaa444IIIiii(((mmmHHH333ZZZ...{{{---KKK+++|||NNNkkkhhhEEE!,A

,xYB>B
^bƉ?^T1Ȓ'THReʃ+`L3mdv@N;{eQGq&tE<:ԋTZz¬_jՠׁ`ъ
Kvٲ
l!Hv7+Qo^wK
DXNƏ=wpȿ(h&6F(V؟Zv ($L,0(i3h8^@)DvcH&LxdPF)T>xUXV\vXdi&b,@X8xn:PM癄jhi2曋R@ nVA*,3*jiR:2q6
PgF~bA@@YzаvJf+Vk-iA,3).9A+3T*k[~:nng&)3f^+LTڦK/\w
jv*Awߑ?]6sm">_g4vi k+߭n)uZA+Lˌ3Cd;'_b/Cs~PTmgtP߷6jʦ}ko0%{߽ !
ts׹n9Jnؖpw@zuNEp- {ɘ&0$]*	l]:AV,\njdm	$
2	MwEK(j0UHf6E,hLXđ8\FreT`]uRZeI`V3(-Ud(ykwX&D
`caNL14 ?ցR fǕReC%KfғLcr^Jl0a[*fd
FoD4i1
n¦5nzkHɦLggF=0˸&	*pWg(>>mSwȮd4A|\dKZ
pEIR%d(3
)+N
ЭgiS{(K/iLkA tT*G3\|U>Me3픤Tn*XtREiB DTn܉gfµ9]RCg2A(-JzZJYf
aMUEM	2ES&HD;f{Ś{\a۱t᫬put,edg%
D23+
KM R=\)bymn=fD6;b)XzF n
ͮK4T[JԷkuiO7,aۦ^NֽQ>/n]ꌛ=H0`ȘBӅWmYĶl;&Ɖؕ}Kg3Jůa6õ)JFN!T

ܱN=w%yrSĸLG0٫0m%bUĊ0BXaeCnJHD7MjJIӜ5)RN5QVWծ5Ia-ZOm	O
wNL3W9Ó %&1-LNp,@P'HAV=Ia6nBη
-L!
םvmn
;BTQl{? wY<&"0+<S0^
.ArEex;
 ӑ\
	V{õV`õ7.kp-k SSno;cn/]Fp`Q:arټIsԭx1>0?O[8w.^a\ B5!t`Dntz4( OqJAd+
XO'oOg}roq	ĸ߷únK?@n/wZ0q0 P}ˀ2{Ģ.93l//Y5`22ilr4/V_1e5>f12B
mn)vX)|1V׀%P10(P2:#)0+ާ~|"Wtc B6*9Iy.05AZu<@7h0 HQS0nn&HTpd00@-PWH{0&".T.j)?53KHXv40&6}h%Y>sr~I(8:>{nPnQl$`WppXb.hH{zx,bh$+mQqXD9S7fxK`2+{X12ASy
ِ?'CvwA8)07`ȈM@ Es eP`+
9K;ۨ-0'('P'6_B@\RDG2B|Dl8\BB1b9dYfyhFzWxxؑ#YDG0,0)4iܘx=IJ1,<:y1u`i
A.aBfMElf.cKC2P-^v4rtɑ	"I{ٗ/3Y	4  N i҂}bhh:h 3F")Y uB>@dnzɗ~	+	Yy؉p
0 URL{?r2l9 CtlO, ʉI{f wT.\"(q8
r0sQ #
^	q #pl00i`Ag`dZ"`p{D2r;:䣺	BDR ` \&"T@lШ]p|P
gBO1xdzaX$p*@	£/lRPJ@gp˰+`"
	AP
;&El::ZzؚںڭʩA&&%@" `@`nbꚦ"4z m*s GIyː9qZ^*#
pɚ APD6{8:
lw$i™ip`P;p4J˴I+ (@IJKW{rL۵`+}0,Ūi7ŽْIf:ILRu<BJ&Pa{{lz{(%p{;L<qL { yŘu<Ƣl$.2nl""l ٶKii͓*6`r.4`Ly#ϴIo"+#} ?͛	p*p0hp:,A0Z3m%0x  B~	4ݦDM& ̠ӻ̰m ?ms;0*04pG᩠ZӳIdx|&?x"CMK` KJ+X,lZl@-r>؟M`D\Rb
FP-@$<$ʝJ%biJlz5 M4mnj<}GF)	w9u`
zɊ	pvO(S- N.$PD

!gR0Q;
_0:/[em0		)`kfo&ho~L&@>tojpV>,o2iPUf(0Зfk_ "`PprϽZޔ+0')|T}8`s_& d
nOޟ7p/>ࡶ/ܒ_¯뒽iإ?''$XA	.dp =0XEG!E$YI$K1eΤ	3M9uOAN4cMI.rYKQNTUYnIѪaŎ5*Yi*[^IMPw]IׯE&\aĉ/f̘u7[2ƽ5oܙdϡf]iAftkرe]=6׷u}vos'^\ƋWܹɟg>u`﮾w>ѧ.{n?߾{vw#D/t8\A	+-Bɢ0Caðê6qҐSDDDqʢ;E
YqQ*oq,wT*GG!iH$ikk"&|Ң(M*I(.RL+ԒJ.dL5|"(NtM̳="?dPALTNBSF!}I댔R@%h.S.;QCIQ75TTO51UHUUV(`#fCu]y׍_
b=d-"VXi,#k/2jWmWP\p+"Zf6p5]l]Wv}xW{WAkP-X-
x]`	Fx2)bxaN"fr]f}Vh+YjMU):r9]xfu7_ft.ߥfZi7-c4X⩹ꫭkP[mXI{~{mpp5N!qPq-rn._;s7׼s)|rC'}tKgt]Snvs7ww{}m3w'~xO$k:2zgPF>|S|g{w"ߗ,@`j 
/$#8P@&P\dg2pA	H`%$aBD"P!
p~l9X
<"#@QQ6TbRĉa	8 O!$ HdPp?	X"gdF4|)@>fsX	@-Ic!	1 E:~4=l(@SR̘$1-2C`g@rHjqh)U
`Ww|["cڒd3qo~RM		ԒTlpZd)f:5L vIuB#sBp<_ْ@<N1gGcU0.ҡd#%EV%OV
Dr	YBe0ehIsݨ+=ԓdfKeKڀR*=f",@R)Q̊3(*Ah
_T7ˣ&SfR(<)OUx,\)VfP`	%5p6P&ѯ-@pam]zxDML	"[}a"H}lPL%,M
3PۋRx돭8@@aTۦ3,(NЙ{̀#-.̌^zӝ+}e'?T@sZĪPEQw4hC	xЛ
a#S*6/>CxJ T5nh0\]q݊شn[ﲝ͝f?[(.紭d_[Mh[ܗͭp[ݝmv[c)]t[S
^8"xp;epK8qm\'MA.3#r\+WyYr'&9W`p|A:Nc)_Z.t}F:ҫ3=NߺӼ3hb6MlY#[Flrnwk/[Ϟw}SRxÏ*Uᙡ񈟼+8|)y˃qדFvϫcg~>}}>wܻ>=cO{߿>fۼ;O#?=4C?oc|?}{MYxxO)~7yO<$ks,?9;@Ժĺ	t
̔qz +zA"1 A !",BqJB%T7'|¾p`M	!00c|`XҊB0#ñ7ԈB3ċpe%xCep3@ď=<
>õ	X:e`+
P m


HlբWbCRXW04z&b#ETLQ:
N
C)p)x,( eTNe<(㽤L.>$9j5RLjW0b#+
Nܫ"d1[VZG LU#`D+SVemf=΁-
`L
ˬYb*'#c1%a25KVh;Ҧݕf'.])cn>h&x),l9;uf$	(yh r&
C提hY^>#hM?Nhx{+B %Ž)ueeD2N:".H!6i(N?j)Vˀz$J4>"Zbg(S*+7+~dk^ƻa*jf(XbЌ<xHܕ,Yr'L]u(RA
\%-"Wn2J^"!R)ȁnmUW(C#
`/z%^TB!^S[$m,5^!fp׮S΂eh(^oo.o>oNo2mh(n&Ƃh
/6I4oopp/p?tE^҂vhh,#aTmb"
ItXph3.\ 22".ߊgŨ(Xc!exnee5q&#Fזb"U(1MdD#ڮR r0rhX(`q(f(peJ8)h(}g#h>[jz戲-1Cl,(ޘpe(B	X@yhs 1 e(=c-q*8?!*eR~Uzr/c~}2g)Rx&`u0eXd&	^u	]C,xrneXpe_,)W*Htz!苆5qt,#r@we`guu0u/gzgXs@o@e0"R瀥Pw蘤_uyS6] Qp(:?h)T//9ksP&3y	3
A$h"cƬzx8Se0_V}}zX&pzfw{޿s@~ze X@tW`{$	xe 0Hmc'_C60\1fppŲ@31l!Ĉ'NP!
5d a$2ࠡ,28@%	#_2"
DbdV-/nJ!qSt@@3$
u̖`a
>84[.eˌl/,@n	v@*Th|`)Ȓ'Sl2Q#7Fhy2l/*fOhH	#A.`H B=123(Al.B XpЩ\Y`
"Ɍ&z
TJ)*HxBDPP\MQ92<pVVX1Wc!~-22\y]_UbC|h&|(b9p	 #A
	uYhvZjdQH1DI
tKpWA9p^
8g2B5ԀĐʌ
Ɍ50$
: 'TDk1\Y\be"gUmYPz1a{]˰0AfH&ZTyhZNB)%Vb%^)o
W@h"t{oNI5BjD ,#(0U%+‰a]L>aV/UwP0
~	hN/9_*mOF9eWfe_9fƋ2y3: 2TDC	1˘ BY1fU`[t3A`$}p+z Ѕi-!̠@2lf5晣dIzdB[Hte{\C
gDz/9{mYR
X;yK+n2P:2E'})w{e5Sv7?#<СKG4쥉6{$4|
t2 !()2.>U~(Bg{7=z|ZNxND@#` m0ki׌]'U+Fxq
6|2LH`c!"4"EF(ֲ8ՇcaF6)2
Ɠ=w[gu!}7ceRz"yz)wcTg+3!rYs+/zs6=KsW.G';{z
ÒJa|U>s%'UFG~pe	)(cx/%ا 1D5n].5TDtӿ??蝑]ዀ,$tA92HA&_6USn 	 exTHB,[=|,
t@6  ! \e4@@r^PlA)؁
8va!!:<@ơޯ֑aD.C"x^}DB/ ,
B0a!%VV"&f^]I"u|W8<$	Ap,@\'N&"^"/bRS.5bA@
5R95|c7cfdSq8#::96奣;E#F0h@G4E@%AFin2ISQOQZJ@3 ]JO6Edv%HH`k%&5n5&9YGv@39Pa>=cExDCf0!OZ	&oQvw%ZپD@Gt:E6w^-C$c&cs&tBDTDTpDfwiա&ĂDT>TLIGP4@2
DF	u%`^XjduhJ%CD@VO%eXY~fYZr䎪cYwDz0
9d$Y^)ia]QLzć@HmzIuX&x|Hvxćef_6g2S"L%%JzG~%u \ՌUI9R΢*EXRD>fFqͱV+vd8eedkմBD5->Zg+cf<=kbeD&B+bFI֫~CZC쫕J[q`(hGX|&TN4BfR>#2OV=ĞVQhH%UDJXNXigRuXe:[jM_z*eh%@6Yu:Y@~PG[f3QH^flfiDPXĞ)^egSX,	ڭ.Q%D^Rդ}ְVruJ3\'֒5ɠ\y6
-ָ}~&cnu'2>V~HB*2uj&Pah~,RVв&NnF2NnvTI|~ˢ@*0@rb\~.qDT>+H=~qd@+kwqo.En{Kl.eb
Vl6ERDIlk9@[QPZnl6e["8rͶ#*))2***[p7&bfMN[&YA[fGSL@߆䇅a[&F&a:]VQ`Mt$&Ja2O6*u738s'q.JuQRfDIJa"1R&.Gd
yk${
E:7fI`Ndt;:gOj(\DtE:rZDl.@3([w8ĤbM~CE4s/,_a3'M"Efi4[44i	gtH8@UQ^2u4>4tf܄HJGAȜxPEYxý9o~{ݜqP?oȜﶮ[L5l?|K?s5EdRd[;DT>7};?}Āe4xaB.p0x8pDI4yeJ+YtfL.δY7j#OC5ziR$k.ugǕ"G>zkV[e65*Е~5{mZ<"pn\sֵ{o޻ 6JUIZ	,pYbŋ7vrdɓ)O+oYÛ9w$IEug3I+UfLf&갧~5:<9-``t@eem*s#֒TU,`Qfeߎe`N)R=# Zt "y~"Sf0Or84`<fnw gWK71ʙѠnO*\ߵWVRP%>5sֳ͒x	r6儷?YI-`&h`l.)J8[+Nf'!Wp4	h+Us#8u5c(*$XY"Y@SdZq)3a(#(Az/їzx!'ڡcH6$&ES$ƼaAט*köŀ18cSF-}Ũ/;r ?ӭ7#!I
-;]#)n7&7L.dFWJST*YJWF,".yK_&09@:J`LhY{4YMkV[	:p`8YN\*0tLQ7]V	4B'i[V$E>Kpa@u0d%az1Aɐ$X>5DiJi#d@څ(9-t3eF	D)
Oph2O`>A@fɀH@d ?Pq, 8VfŪEj2ZbBT}sC3D5"0@MʁLd_XaSft`A,Xpt"0,3&R @mlP x2PU2MHW4YA,?@L6p$,Mlf%[j(R65IMLS $`IZ&䡈l	2F)fI٨" bUjM
U.VMjZ;Qf<eFkkkطvn0n/ыhU%HQXp/r5,H:X逌8hr_€edN}@$.V#ȝT(9Z͒UeXI_{:E';/2[(eU,^ԡN*5S5QsyX)B/fEU>/ep 6VG؞nRtb"دw\412e@f5 +&@7:tۀ.ǭ8(!@@R4\ߧBu9
t	,c:-g5t9p[Bx^2:@>qR܁|58pSvXtOঋ5cbg7~3PUik.%noV+A._rI
*LsF=H3o^4e!M,feBv3DsM4hu~ AmhYv(@=i<MHG߲z¬~qTˎ؈Ha'DXM1W%+KbIv\t)	`[kUwy$0rj[۴q>pzJJԂ)/g[+Ai}UӺU\ Ow`s8-
(F:vl⊟t
_B["I N&_8
_$JbN" `G\F
0PE^$(`B!Xk0r$!莦LZ+".`.h*'N^,+AJ fMy%$o,q0"_dNGD[`rGnhHr$dg>nNf(BGpjl0TPjfKoи-"+Dkp!ѱP!^hGT"ne! ``bP&"b b%lB/Ъr^K	PXJpq12EomÓ>"Ɠl"x]b1MfsF&(
dRB!!!"#R"'!eAfdB
IQ`#e$O%SR/nL/%1H6C>SC	'sR'wF."D*{,.v".t Ot% v,.2 tp
BQ`'e*C,ǒ,,-%Z!11xO^DNb1܂1lfXrHRR111eb""@(R?K-$vlj'"j-1IJr5,Z+24c܂Ҋ+)̭MN1Lc>" 4!h бf)@`=kj"@3,BJE@?C1#B(DjD+@>:M@nh*GoN j#-ZD@"$TYL&D(L!3&BU)>t!EYFRs,<~"
F+:ϠʪBe	-(Kd˦Eo6J&NTq pΪH \qM J3KWSod18@`>- h*bN)+>\\*dt1RH0Ul2nmd'6HA@jJx`$`Hq.rNǀ jQTE3rêRÔ)6k5WP4F
N1+bAnў/^2#eD&1$eX#h)4"GBVj1K-zp!qD5Di Sq)-:#ssAtr-$ubuu?u&v+dv
L{ZURxxU2w-Wyy߂/Kzw1qW{2äwFg4,6|}W5`k&4F4W~~6$8Ua>8Hp؀äX9Xl؁'#\7!8l$C>,"87N8YLWRT_H6|aUvksw{O䇃1dC؉iXÅ؊9X#؋BX0vX-+)(䘎X(+V@=v8
bգYX )-
ّ!$%y=X FY=JّC Ly7Pّ]E9aem9Wyqu}9	UYw{ R9ّ yXٚY= Y҈ :ٝ ,ۙžC $+5 v wz!$z):-#Z=?E	"
bMP:UzY]a:dzY}Zy:ZڨgzCZzǫúQƚ:ٺmq:u0xizz庯,Zwi->Ĩ˘3kޜ6DF䎤UAb:z㑑;nغ;`CG7£
[쩵푷Ë_xQHRuw`a/N[ۀFYz_6bHtvw`ԑQ1eZ^%j"A
Z55JU&Iaѽ|&TB6Æ!@m-/+#

Zb9gE+sYa=G *0${SО&BI	`Q2I>Ʀl3MAXŃQaWOeuVd^TBjaiҞVG&`)
X,TAgR[t%,(4?g4QhM5}K2(,SjR)$14v.	#oÝ3)@R70<b3) Q3^pK)fɴ7j xP-F_ZqgPLiEIqAR0X@jf͠> $iQ95stgqE$dW_p)ÁܒP>qVJ(@n9ejJVc3&e0,P~[mj{oNoK9lPgΑL"XȲ
9*;1tQF@e,AEqd̠Z=V { 
Hcee5ϽЍ$.xF5) 䫔*nh2V7DRԁ8ӷ2m{dܨ8e[ޒ1E/fjH~^
yJ̢5UQN)iWd?Z.e'p~`sJH6.?hґ)Ir/T1G®j
\`%,قcbIjMdCLb6^{L,f+@vz=1AjSPBZ6bSU33/0
sr^
W+âPtZ-6aœL-ԋ4g̪	EIA~'6#|^_:E_zMkF·+n[Qx̩%^-Q2x1l⏍n&qݘ|мfiL\2U gIj!seaky޵)2K9l;p4,[AIlzXjRj{8VXv@-ޣ3qNl63N~R~^>`lt^sRI~5YNgԶL{Ue0Vȁ*;-[E,zrc%'|ⳞsLEȤU{was* @OzGV(@Y
trP
G~=L~>9@'	kz>U{m~з?S&:opGB$@RRgDR>!,D@#	a (:uK;42 4qz#;l6e1 )Sre^O=2!XLł|jÃFZ*@ȀnDlGBYfKhaR%sR؅OOxW!&c&U^2:d?4R1Vjx;Z]0QH9xX.2EA~( r@9X1E{E(A~E8@
ш1E66)E6'EŠ195B3ˆHaT؉d6263Ҩ#cAEtHŘЈ8Q<э75(H҈4(?UŸL(%Q^e㱏=0)	j8qhѨ)
a-!C$y^mqᑑg.)
 )8M2-*%igࡒkaL/E293S7u<>i?G$"-F93+є5uy:yhb!^ҕa!#BSji%âSi)b!Hae	P)ٗ!g"(]Ҙh"b	x0	#zpT/z K!%Mq"F+I$YR''$!!0bYiy%'q&R4(2gGѩT2Bɒ#p
	wIw{qS_!#/ɹ"	#N2C\i2
zxsΩ$
:#VOq3!iC12HLڤN:UHX14R V?Of$[2cVAل0@?n۾¥4q{c,rC6F7taȋy6-WFVH;o{A$NһLͰ{2bUW4qfO9W,+Mչ+5CH>J&{T1YiRՂR9J7$#4FILPT`$J{hqŌ#WSg,\.0?%Vi͙5F&,TAbaLAoT8ՒOv/yT,G$(\{DClMdzf|:Dˆ`3W+r>bL}@*1OcŜ|0eRTݭ=!FC_)Ki
kmm6$z՗q?`lc^"{'K76c˥2a!a]BNyGô؈N8˘Nu)"UФ@މ3FnɻCΈY"hi<%R,z4'	3M
CГ4]qn+&h+䩌jĽ$zxna}N~7[UE0~BU^=+;~v!{QPG]c]%Ut:ASJ=+{A=S$\M؞c}>:2OQLO2IO4
GX<(:Yij@ʃ迊]C(ae
Q=,
_"_Mb~	*~M["H;x!*ߣܞnMGfWW^}Nу?| ͝Z]@G
}OGhj#>/lt_MzEg{	tU8Hp֧<+XUkdv_m?s
t|OڏU;i1SkLŕ|@:O>_/*1|N{Q?_o{jiLt39/:slǒ/_VoEx	*Nd\[\]G$XA	.d`3NE5:l&qG!E
l`I.``
@YӦEL
4!ԙHSR`J\,0@Ea>8X;eNmL`̸y5h`M@@
XL @0/Tyu%][zLaλ%aU!f]]ͩ'x@@v&3KL`nޚI[NkzLVzgYD34Og;kGJ;HZ֊~ƺ>7n*µ[żߎop[|·<|#9.rʫ\-n^wLc]iJXR)"DٱV畹t.KRu&.Ic6VT澂a>sьVM1Ԧ$iں&~YNG~]-ø5x泀%=5hO$BN}SqN&TH:yeaj7PA" ֡CNZp?34tlPVI塚ju)
eiGh 4RCa y҈5.fQ}yTt
ĘLQ+[݊3WzU 
xZq걟P*B,#J"	)eS43Z욄U E;djzEyH
i1Ҥ
bؽ5h]tҔ)s*V7VF:%)^rZ):(0zoc-qkǺ3fgjV Z5o8TUj:1g(Xd	I˰.h1d_٤&Ӿ2uђ]$	pu~#05_6/LL80Y[%ah*t~O&&[jj$N%T$>I~/Dਚ#'xsHuw;+Ufm%%Zыvސ:?3Xn٪t=iP{#IM
Wϧna+)b}Y&jR87n`dWPula؎5d3B:Y+tp$	"p
tp+!rsڻAi;!@&q@Ӛ\6\ Rs#vU	R6-k>N4."ڷڰ
ň-6/m^|'3G]͝xsx3XZʯ$L-xשQ?^ugdT/*Cd8;Kw;64NpF~5(Au@4'%7sTdӢ&}MQR	ǖ.ѳ}0CU^*չ}ԣrI;?<]+s/ ?J:y]B݂  G5.(p&hۯ7{{	 7T4!rs
Hss2{A73	<G+s#p+7	<7Xpi>y>S~R7Hx9ꭂp
H0/(rH
B8p t102|Z+[@Ԛ`+Czc13/a/8/3\h3xsCAA?-ܘ91i
艞xC(jD Ծ@4.,6s)
*A/

*j=p5X$r;ºE>$	?D@TԳ+ΛA|A!!p2-	I*K$JK;
ЍƬ'{R)GceA@cl;U:ņ
;3=C-z0[/%i?c3x嘀[>WCbS2cR$:ɂ2}Ps*Szp?LY9L1195$+̈?ӎh
t1/rīX.J|˖شMM~#!N/8ď#Z;L>N'úK	DO$D<"D=]PU|̗{L
gx9[TQ,:^LyKB|N0FXIx1a3v\2hX"`$L<333c3[Ԓ㾸ׅ
&8cC+h6@iǙ=>-!UOHׇ(C4nhd]vC  h8.32Rq
P<1i8]lki[+6	1h+X. +Ȅy/h26Xc!hXD9hEiȁKp]0n&e8XJ ؁xfhn
vTmmR7>VlXZ+=8F=T@81* ! l.jFPk_-&oWjFlmm0 $x&Hp()PφkM(>K^lPp	p
p5pg49	5AVf΀p.HAr!r"/r#Q=>Noooo'kJH7uK\,(&h+w,o4.pnkO؁23OsYs
ifc9Ol)o6x7n ,o@>./0m@pCoDWtatEو~rڦt:o7p&h#@@?@o>`/iFeXucvH?h(uܶtL0fȂ:h;@dEhAAh0AB V?LAyݚ8d}
u,Tr\_:#h[hP\h	؃fH"uQhC`haoX؅ӫPWWQQX\$L
׈0%a̋75g 7]f D,	0v>fLh/o3g?rh\t1UhZ {6A{8q+ʌ`tf4Ȭݭ&u(xTş @8@8{@,x ,  @	0`	)8K~Lq	(&93@3I	 T
A:yLcF"l@O>hvqJ4x-B$n/c\>^DуƏܬ@Y#qe9rą/i>˙Hؑ546ܺw}{/a/n`|Y69H BΈ>@"FywF	
)0_4'X#?$B@A|(!]#]OE#attе$%`etn#Ǖ
w]~%]vrM:d_!cAv%TFWA(Y4RHh
'ɘ0hqkFm<"}'
*PŜ*r0@36=]zuo] BD=:n#%pi	@*FN$+(0ݮo
EH@
jkqiDQۀ1۬z-B>i;ң`
H
upL.:/xpXb5Xd%H$~Sݤ2$WTU;ץE-;ud{`@T7A3	tFD@D {-zx{: q-(MGP_~^cLy;K2;0!<)py|ۻT
c1uY&`+=,b0v`
^	/XCH#B
Ќ{g +Yrf-RU(p.~%-dVWԯu[h!'9VSlC"ld1%hxKv|Y.K\3řW
h:SƏI488hfa0q^Bvjj58&*X*ָXpaH}VkJP24%X0A$C3d`EdtUmW+g)IRD,4rHC)1[mB.ef{Ju&Z	YWBBCKTm~EьI'EkQxX6DmܚeP=/zӫ}/|+we`N:LpqӬ C-%n p3QD^WZ8 ^0C,&>1Sb$	o^L,@oj`l@[D a~vv_;S4@m[zO,1f>3Ӭ5n~3,96w(\\̆tZ6A, A&	ADžЛH!fRF& &O<Ԧ>5SUծ~5c-YUu3K̙dyqLu֌DUf9
50#.7#.SFuƂЇ2!5l8 mb>9Ѓ.F?:ғ3No3@ؗ6N7U>tpE^a0	7͵ۜgv5Nj{d(FΊ7t~I8GhAo&$7oNY߽
w}pEH1!bρ4¸&qJ	OXA=ryy&= 93v`
H 
ppvXA|2|
$S(B8`@> Iɟ-_5>I*
LPG\IWQpY U>ݭN<H:ɠ`&m`>	U
2MO1A%L!@a
jU@lOQTD`DXNQFǔHKLxL3"Z !L(xE8W!Ϝ1D ([TPtKHjQ4ѧ@D|uDq>yT_vTvHDADD\U
0`@$ODQȊQ@XP9cD4D[&Z
Cָc4CT8D:^O̜DO?"@EzE KLf"HV\zD(~/j	=c11Uu頋(~hdxH4ЄEҤL!2yLPDdlJLQ`ʩ|DlQ2
\̌PJ@z\Dw4
%XH٨DPu \(^0na2HdH$XFԔKbp\FeRX<%ƌZפ8#Hǝhg!f>ϟqHM@&):~W Q4$sd˶JI
odލ I
>fW5\DAHH̔
Mfw>i6|ڠ{
Oi6eyzIT%{ʘ贇K0]xZXG#ikbad;5stjU9@<#/VFzJF0uPD,6Ku}p\@eTMxjbDJhP>ZTGǣ!l^NV^@ԜiBȭ(_fhr~(4N5xcF9@=\\$,MvO.bQ@;~ȥ~I .֤Ԣj\셍Xyl{^8GyjqΪLjC`*2X<*FtgQN`rZ!ݩV$_$`(A-!AAHN䩵>
|hibiq
,5,4þлVnal~n\l"Ȟv~,,ʎɆ˾,ʚ,1A,¬,B:,̒62-֬mmVҪ ~>--F+~+ڮ-mFL-nUޭʭu򭢴=ѭr-yᶓ6.&Jq<:E.u,㞮_h.4q6`몛΋4֮2`	onz,L&/&xoRKRzoo>R;k/-͆qTxĬ'%Qb/":o_}RhDԔa&$&R}ooBeΐ-MO!.pa	o
ϭn^^$NIOl(Q\~
	Po?IR(qq$qopk1q+)jfCD..!pTȧ<@ѪSPL ;w0Lk1&gInr JS'2
-BJan-N,s.r
ƾ1P2+s
3#*k
(@fr1N5C.6c/rFkKT UU<XQw(TD͍G5NclT50/JTMxiވό3Hv.Ț5Ƞgbf['
EƚǠvjjw>3vvmsml[v4oPpO,ą'9qϋo'i/d&
u3iKV;!7vUI5qA9QCwR7gˬzYk7w\LƩY-z+uux6^4M"m'ʂ3;x-n|s^d8_K$UW~r݊w!LrQѤ@~_m07;7wb/9;B9,fΏ1n[cƖEXc`CyI8sNy7Dž+}0wlr=τCO#}$2P^e0
AԏEfJvx$tҌ=(l-y{IC҃;_m4Nc/[m>ԮS7~~L9\3_p4>~`eN&vP)QB
%/yD
7ԡ#3T $פNޱmz4H[dL
Ax@S,I)$̄$-p>G
H&!!	yAE!gYD)ҥxˉ"	O$#OJkO r'ѷ%,TDRB9P~GH c
N3ُT'рKDXdz74C.2MYi=YGLT
gm:+Rè!B(;e*@`Jc
$"5bZ(wY"Lr:H0VՒs}@ДRհJ)@TpL5g[#,g#4`GJ*h#{@L*UuXMU@Pӟxar)T[Xq2+NNZuW^Uz^up.OҌ|VhA3hU	\`	N2\
:Д9a!I\b)VYb1= p"hBPf,:0\d#IVd'+PL_r5@͈ȅY2'a\f38(Q
lYnfNh;yg?Ё	]hCщVhG?ґ3
`byPʙ]OWL@Eրj|Vu
@ft!Z,eB5iչvޏ.lIk*|k.+PD`7M
Rlk쟽5bᦗ*lg[P&-Kqe&L0R<{!؀[p1.	PTvj-(}ۂZxؔo@؅ın|'
GQ^7-Eh,6A/ud>c(p(3`t߼-oPKu
	`~rǪ	vh`@[ӢG۹"EX hT0s+_ZF{de4@GqPFDVhb~cuku=/T,@!
([*nox< b
TEP@]FFꐥO똯KOU gb&	f1[@ :@XG0`7*B)Q),#+Vr(,-*9ܲ%.r'G/$/20YB1oe0mr"E021WV"3%4`22[3Ғ%2q$Z<%@0G2"R&TsqX53CS6?7cB77{S,U608343qS97c9Q;M2U:'<5O9E;QpjRW27<7_8۳n>%=Mb=)S?m"s>>s/3?4ܢSps"4BM<A0Ib@ESBKq8!AbC
C=BsD-zV'Rph>s;E
fODuF	GsT;E{T22'tpHtGSIUmʂt&TpJ?t"B4K=-%+)]tL[Gϴ2K{ t5E&@KLTpZ |KOS=#TP(F6B/JT>q6fD!5R-ek"zrL4
SPKTt"sT-'+PXD;Ebu"BNMfVb=VG/Ot xޜ5-6Q)1&YbYu~UNup3.uL[XBj\G*eu(lVL"PW^kU_zo,X"6bu qa'Y!vxr%)V`OXwsccU@AVddAQ^Ut 01n>v*cxfXfSs iu`|v(BhfhLSb6j6+Zfw6c ef6m3l@QBo&$GknuYvlXSnNmCgjzR8qZdzv~qcE _!Gr#rp[VGi3h4Y$kUt?rI5qiuqQ7fp.:'vG7m0va Qf(pcׂ7xE#ZO8l}%veX@
<YYYԚt-z/t Oz"$XG`
zz NKY
*ɘ³Z
ۢy۴S$bY;@ikY
L	ڝk;-B'Z۱?$}۵	њm{:
{tZepۻ.lڪnڝ';Z'b	+Z;繞#=<9
l)O?
bHFA#a"0v#I0J	BHh,.懸<~!Th2b*>B;ç,D ؈M,
+H>z9B٤6H"	dH, @ChhF!$$@d"2Dd+D(!tH?A~"zꆄǜ!!΂.hG4'ĵ&\j3>$^*8B㊨}bb*D_*2RA3g&8;@
($t̙8(p;6 dǑ$K<2ʕ,[|	3̙4kڼ3g.v0AP 8Ďp (E$`8@L)z4	T4#j!|Ȱ(ѫ3|H=޽T|Z҈'X@ֈK>بgɏmu>:լ[~-Ò).+@C5`
)u@@fv
_^,cpnC!g,W#y-x$Exp(&l
.`>!%R
@E@xDV{qpmTH>4Aא(umev/z7gᕸQ3	pA!)E3 C(@haY
	AO`fn	j8L	M@݁ %g.lR]0Vj]c\1	_udKv+eBu.JN;۽pWyLp\ҜǴ֍DJQ5lRoq*54	RpILs6ߜ0ŗ5%WɘjǦ)=RW'	L8_uc7
_kFiLݦL-^Jt@_vkw~5e@ҙ-wgMh+EC@A]	k2SKaKoZlxmc$Wc].|ΩFM甙cEs7PB%\L'@+ ӃC05&uMAe6mCRI.=42l$VS/ANQ:OyB$(
ORU/a	낢KJPi!
yHD4S/~";$:Q}H2i##8 L	(%?	}&@F,(=Biw@v3h4Ԥ3y3NG?*aNilғC\%Hi/C҈'Pȅ<+DqDuʦ9#?T@s4_䩹qӉdO$LT[@:XW3QDe
Q$)U'V倄.KXdUt
mQ,s
H3	 ^N-&eLE	W*Vclmkz0:
ԕTK.u|
\
VGρiX̾*vϤ²v$]c镱ll5>RMTe%-F٬g_[HRJB0;H	'p[UiGB	VJˢHBܴ|U"i)m%B'abg[nwPdv4*'Gn4"ԌQ`H@*tq=T8f܀UI;⽋W0Yʔ˭)""FUB,UmqlC/0u6P@ˉ.2c2u!T@0hQr1,"%'Xr'e.ps_+MTI0IϰVZS4Z/WY($
Ӡ-LTp|L!g$Gg,kόiJ*+tC0:(QQX4{^"+1nX@-zAKj'A)K.&6n+'#%i!T] '1"㝉$Q^It(Ȕ!#)vm^&l1d#nDEQ

d0gӼ5
*OPZQGJ49n(+dRNk-r@T4+]Ez^пDwOn9!a`ōǪ…LaIu?+Mz/\dqjA?H-xߎ߬ըeP]3vorY5>k}3+f/m
(+o!kg>#g/Ϗoq4/ߌC$HX~"$
р(hȁ!,;PK+TLaGaPK+AOEBPS/img/strep048.giftbGIF89a9岲@@@???999000   ```pppPPPrrr///___oooOOO񏏏gggvvv;;;ᱱ:::nnn


+++,,,JJJsss<<<888***777xxxXXXwww666UUUttt|||cccyyy¤˙FFFDDDƭVVVqqqfffaaabbb)))mmmuuuTTT---NNNZZZGGG&&&CCC555WWW'''}}}lllEEE~~~eeeIIIRRR444>>>SSSÃ̈MMM===...QQQ[[[]]]BBBKKK\\\jjjAAAHHHzzzYYY^^^!,9	 A
,x0@B>B
^bƉ?n!Hk2*J-L5DeO?i9KG&hS2FU:iUWڔjW/&@,Y6TVشnmH%%՛bߎI;oa`urUq9!XSʍ-g̟;-4V߮zj^d;5lem=ɑຆ#ots暿:Ig7
{w߹[<ܮ妇ujw~}Ͽ(h&6F(~-!`fv (∱Y(,-4h8(:@)<iH&$E.PF)
T9Xf)X`)f-TS4xtj= Q昀*e@k"jT#@)|P
vHTӦBq^gĀX@@b*P	@r
Eƪz,V@T5y)VL jmb@J5rJAj~k&Jz@lZ+=Vx^ĀJL jv;	ZhjZ 4!K0rl5@R.&`bmϮ߽F'q5K Vk24[c`J܏:@r6j]|i.d嘧__xe0l'_j9@ҫqbAikDe{'jFk/t[:)ܧAZߵ:jʤilO_p%wϽ$١azêZi[ 5Vcj@߮4s
l^7nc&k@'B..Sutմ]u]H4JtJ٬@lW1@;yKh4]DD^H2J;@>֫
tylUWeDIo[2\TIQ4_qqZV.
ˌ|aҨ`U״:+j[Y~T)P̤,͈Y򖘫%.wKj鲗~+k2(fb'O6 j(\̦-L}#8WMmS1$00eJV%S!7L	O[tN`UZ"`~̈́5IpfTh(4Y ҉&0찢rۿ$
[f$5
_R*nf.@4%̤XT9UF=YT*>ꨚ:h!Ү&	?8E'd
M܊)W*F N1~{WUر[=tab@·,vT 4ѫ5~`ٵXlC,@Y/X(>T> $+([Q 0#޳o+VHhOo/kr: jOachߨݺublˆoۣM@J٦dvOym[kBPQ9ۘ>1O|nuBUh^ջ}wQ,^*98ltli'@4DVTSDWF3,HmzTJC	kFk
#:#i4)%HKXf0i9oӠCMȎԨSjgհy;mZ:ΦΏ6I;z6i&$ Ў-m+@HHfc2|.!
B0v;
V txHFz(<؇7P8@pcml~b Ww	/PPg-ł8Rkv:`/A9@.RRvQlxHTQ-|sXAs
ِf#B8~h*O`	Ei gpp)BNA؍p.@D,48'/ȅp5PЅ!s 3@eHH&C9,+Jb9dYfyh)W#Bɇyؑ#YFL0,0)4ix9|ГU(,Kb$TCRoVsX31@R'(}aTȏ8:a悜&DrRS#^'pYrɑ	"Iy}/3YXިՠ4kLt+h}b`g+-vy#jgNoI	t0Yx|]rf`8
1QOHeor#"'KlDp,p7izmP)Š
082Ty^@INS/
*pk$ʜFۆ<j
$p^zQ@#p& ]z! !~ZuL8հУT8CjrY#: l+*1[wb
aBx#n o|8M*P
Fp]P
zP
wP
԰zs蚮꺮ڮ&zְհְn*j*(pگbJ+

A*0qjwwz'аoJz#g{
ip֨SP
bP
Y
k%Z
0iYV{XdY0j
б&P
(#б  Kx  Jxc۱ P#P
& yڲ`g{·kay 
Az#7Ȟ::	vP
'	P
4zP
{P
Mbl\oڶ {0W Ƌ@P [
{
ѪWa;z˻֠=Җ-T`0i0
ϊlayP
pP
R:[ZyI*Ën0j  ½JlʽAyvj’r;-3[
}Z9@PI

J
|jr zb
Rʩ
BP/Zڵ,Kyڪ믭'`˽m+^Kzk蛸p֛DļY Kpy"Z
-@h<#ƙSJx&;kn꼓
_+dZ
$
!֛*˶+|qZ$+P\lLBɼdtْ)IP*j-[ڥ_sq&˲p'##&@x2mqʥ} |")˰}lz&E9Rsٛv	䬟΄:Y)gR[G= ^v*ɛ:@jt9klS`n )!YP2J:e4XZ\^_b>d>>nNCҗ,0g0:	mӻ@@Jp.З9?	"fG}hSmϗΤ)!)} `j
pOGvER.}݊>ΨՔ
@n$`@`Ɯ>1=KC@jiڕ1]uGjt]%;	-P-w`
k )?2pv#l3@~HPDP`gPqpjl
Mqlxw
YR&chn;uqUsr'&
D_7p%w'k5iO>b^3j3M5XuZ`yc^h+3G
eWpbF4PQk"Qfg%3c]P7fv7xc(P޲'UGoqu_^d ɄO"=?*)7|G>'n#;x
V (t@0502`G!E$Yɑ@K1eΤ	s`5'$AV FTQx,T'8@!c֚aŎ%R \p00X…5jPB߲`ĉ/>y3g	QةaI9Z0)0X0G`/dWƱe>k8ЈЃRj-l$^2s?:6!W
r9[x(jd(ӚC3Րk''*>@+(s9	+,.,j 4z@
?k,ƅ "r?/oAzL
`몫!gJ,)×lK0O
 ⌬2 -474h-LĮN	tK\M =	Ib$@EIC&m$1[ E$|Ra"DTq)E0dp6c:3,m-('#J|M9
#jKTz1݌S#5Nú/.RUE,) 0B	KA/Nb%hףBG2U0ԡ)Lūib5^Ą͈D/'aJYT#)s29pޓ"@H5r˞zL~9d@wPpLDPVI7ᨬ2Z:Q%d!HUZ4^x%'NA	G}A,zzHl}7ewK.@3N,ըq~S.S(W5S++x[+Ȼ48k1`@;8:>17uk/+
_:=࿚U.䲰 2〞#s2.9637xL6?3v59#ACB;ж35/k]k8S;@+:ҶB0s<:0.Ե-;;AD3440?3@7)+;PQ@企G:;rI1Hd,IeIмGqI:oITIPCc?u<}[3JJJJJJJK,Kp.))KKKK0KKM1
8ѩmҢQ҈∿y %Ә %i*%򜗚&lgy
`!*
	H**eҏrM*	7	("h	P4ŭ@2}S!Yӂ	%XዃP+K+EB
Jq PԈmzղ=,W}ՖP_yBV
+OjTBV$r&M
ֵ3rXobSX׌9(L(|Q.9"h1ѐ-(QeKm$
H:VR]IR
bz}FACyWY	$T%$
-}ٌ8ُҸh1
[91S}Α%'1P18[
	oZ
Z9QG!=hIԹ}#iT
1ԺEM򐇸j%\2!
AY]*plV.Q!q$M}NQ[*E]x`u Ղ$Ј0HڥV.i]=JE[]]icBV
0MՇ	]%iݍbŒEJq]֋x_qO$t^ea hPy0ўZڹU֗QW! qMʵ*!k%jב}VQ:}+R%FL	˸
^$(a=)Vb++)/P)>&cdXx	9@QH!6I1c"WQ	"
j 	B
QXDfaoӎ2^G&u!GAJ(2
E?]倅dvfR(e@IZ$cTi氰(]cc`셗!I)K`fV8ʉWJ}<^R2e5]v癸rb
`Po6Nhz"5lX%cihbPh_k!%hVfM`kIdijj.j>jNjj\jj	j,iyʳjjT/?.k>h22cz%-&^F{>esx@|O
c;yi>B=»4au.&[+64z<ۖўl7C#ǐiVJhL?Á3nn4n%I;;|2#?j53X,imnP6-/S
o!\D95`o^	alSzcB4n@?Gm(TGnNf8]So pJ?HW5>=
[qIjp_Kw;aq#3S[634&839lE3L57׵H?	hc`+I[0Uoxu>stP[423cvW(QwR'TKf_zv/jbu0
u!qo>Zwvov4Awwzvmrr-ww-/x?x|hk(xxx
	xxr,mx?yOyd,NM$wyLӬz4,yLՔvJz']xwwe*oO?{ +}Զw^ʠU{]
׹7`s{Ё
WQƷaŧ'0W)toɧ-֧j>v(Z}vR'cwg7sT)||/PGX}FRĚ}v'U~f~{G~~'{~)}J~z~w'7W7
taADhM!!tp!C3:(1!ƏJ)bK0]Δ0š9oieO?$ӨϝB
t5RPVKtէL:
UXtI֡ٲ`
A۸/`.ºr-m`߻|
KÃ"XaƋFv3a\:gөQoVݚqO^]خuö&-m+Tm&ܸgŕg;KwH}:a%W;{ẁ!%?{y-vwr_nr6'6s
7p(%xa28!UuAו(Љ)&A-52h/袎H;$D)Hc8RE#LɣEW%\b鐖)z%]fAa8gmi'QGg|)gxi坄i,ƣ1hI:)Zz)j)zZ)U}:*z***:++^ʪ
;,j*,[UJ;-&[-zׂ;.ζZ.۩뺫-;{/^ˀ|80*[	/)kD0P
p@"
Ƥ1Xs*|s<<4|850	 AW#3B[E(M7:ì5њ|5I/}=UguOPmwO(6u %[0W``
g^2O@ܺ:zz=ޢZ:,GnAUI>r䖾Mkι߹5 q+|4V4睹7CN.`jh8HDW.xb;JZC%-hLlf:D(?LK2P
䟤fL(-֘A,=I@;s%kM1!7K\|Lye	wOO~k"wY+Mi\eNـu)kTq?Uf֨^DX[2x:ĂLl\AhFY!zW9_oQG>Y4#-n.G82xZ!tS8_2k_	٫.+|R^+bޥLSA|[VЈG7.K򷊼Esv＆z~ڼ%_K__,˞h{~ҽ'*o>}N?>}iE}ogcD%⚿uF
[`
 "&`N 6 V^ eUrz`@`
j
vDN&D>Hܠ`@ȆH"GvDGaaE2:BERj5(aJZb@ax!FYaY!Z!Bġ]!ƅAa[
 !!""."6b&!~!%V"&aJb'>#F"((~("$j"+b!" @—_	c1c020:c	z njeZ6v4V7^c44~#R9#::#9߳;F
z_=v=j_>">##HIJ
_A-!dEX8d5$E
eX]\aG.-F~dA~$d$$GI
DXEdKb
J$$N3J
 -aާ Nd
BU4RG^\aؤSVO5<%TKUfJFXSVZJWTMJWeeZZZX[JP5q	̺
U]%HfTe&M@5l&XS1_TYLiefe`)UjP,
iг\UF`fl]^GTqUFUW.DUjGq0b*[RynTBYQ1UIf[
BtuU5|i:QTl !}ZZirψYdnj\ajD"gUYνY'	Oq'b>Vdwh N .&Șդ}Z5N	'vhN h|&pYbW6$J'JD@ƎPi(8I(w6^X嗆䮤gZBDIC\)BfxNUZwrGO#!,ga_e~&*di>PY:i2Elg
P	XgY~SeNꨦrOnHjE(9ij&JJ^^%jpΛUBffuJJWzmgWi^JwjޖPghy
B%HNXu]hVqf>'ܵу!DmfPFP1Yc2lm>ll~5XfZ|ANl2,N&,lM	-,LԸѶ6o6_`ViJΞK,Ov-]Z.7ӚdFN]dҠXqMP&W\Bvٚ!5tUWQJ!*[Rnv~dB:rZڥɏg>
DIʥ"y^Mܮ:N@|nel.Gvn|njҊSV*XRj ߎjpԪQQۚDszӄNMv~-F%U!1V EPimM@P$
"vvNp7ԕEX:IIMOϵ﴾
^VJ,qgЗgz%"Q)hwJG^'[ʨ%TE3q#ZIKpF'fŰ\%f]81h$ؚ5T,p˱u&O6
摑:E,M
](¬9ű?BE 'oTR%b 1&?`IՌlОcLdqx+{D@d.sꬌri'(2Ʋ,SJ
CPȥmRmҦiNQ:٭!2XxhqM'ki^[^%k<@*?3,8rҮ;Sd9dtlCvƐ-tU,D:$I/K;L[LdMM,KNKOO{qP
dQQOt@6P.5J\Aa5h5qyu5|LZ̪t}QB]St)JD뵺uuSqEa^s֩`6--O߯zb/%CRWg3viQfkig$UO9yjsRkYފlvceCpJt^W6o6nnwvo[_d%ndom6a_Q"%www7xx7yw#\]7;W 5
 $PYÏ>-4.0&	=4
D2,E *lƔN&J#}h<!\r |2'N#J:BJ%MrNC̟F,-
 
|s!)eNE5
@(|P,x:IB H3jsӐD=*$H:'
@Ic-TkRre`K)`͂`13PԂr XM}Xk$UVH\mn\3l܆4]֚$XkYYW]!`z/mam/ՀX
x5Z{)TQY66k0(
eYoKd7I61@/
WK札vX#E_&ꂵ(ŋ^*~iYf/hJKC8tb~vLκ+sɍBG,?o>?Xre++ NRI\	4avU*47B6 `R	 xVc}`\rveuWEFt{vѫ!"zE=!"H5N1;^(&KۯX-~9?NiU]ZTJU
/]Xb 5V=I|fMRZGkkULƶxog!d]υ3ҴNCHt0	PI	:9,U	*VSfuAP1&PF1ur)Vl201!AI%ѐC~x/PKZˆI	j XٟΨ;xQp`@xn)*j4,
@**kD``%y)#T~Z)3
{@&	4MjnXM6ݤMGLkI@cj?O_~N8i`òiPޜFM
g
iyfAu!drPA;jMg΄&3cKGэ̴LzS;MAJ9.q*QkKbc(INp{7n܎=C8rr7^Djy2D7Q xx"	q_>|Gc7-{@?	Ó~\M0ϕE |w!pT<`O>5TAmYN!@> D.lo"p.߆E⬁ML"
nN!.!tL(ޯ~n"DbfHMN.: p(@N@AW/WG4/Fp8nT4nR/		E	m"1O6P</X݌<`NBX!O6i*c,p[Nm"VNML\@cFN./L` 4.	ϯL- ?~L
:F@nmQ>lKXFO^L*n@N00$^.X2|qL**2VܑRא 2̭%+"2N&0!/=Dؐ1!궒▐F \O<,M\2b1iL/=xq$0i)Ox9/n0xQM/p!@@l/B=
@8M-"xp
|8"M"8C9i1.|R<-kf!W.9#>qH0,02"N8p!tP==/
G3ljMU^E dc̕FȐ5VpTes	$uJ,^6PkUx"wQ7QF&VUBdv/Tɼf}(N'g-UWUeQ!VSWHj	K5y,Ǿك;oKQ&"OٺB󧌸O3kR	Z%tž9!!"WfJuȕdW-dct]e4kZ⌢jT #n0W4Dm+Rr$_3bPzQ*&Zh@z*EklI!j(MK &iXyI|X5D)~|MV?#8ǐ64rֿ[8ZvqMrEψ[]Fg{Ox5";*e/7kh_ HyéE8۳(c:V*ř);Sgڕ3l_~2 ]{OyKm nnr%Z,unU67e?;
^gCy[!.gdgь{ha.uZFS8ebþIgXTn/TV٩uzꀡ49di&!`6ETi9I<0b"#K!| nZgzhf3kg߇YL}wG"y+ 	fj̟QF&dbCU™Otl		l#`eqb4@
@]]@
4N1/4
`/3=
͏P\%H^FKOS]WI?'V k/]ΟD
B=T؇عr'	@nٛ9SLOqVf`ٝܙvDӥfۥ ٥@Tܿ$dE ,!n]m
!ޤp=K}3Nn,`&	k}0a	hG&/!@%Q"/;S3d-~6{~ЉF& 
^옾.7MlO:N߄YTڮ0NcH	!>`1=I(";q0+xK.W#:?7<[Wݞ
	>h-$P"-W1#eh2zԬ2'c ~
&bQ3Sr*2(E 5B_}M_ޥ@S	X^~.ފis2
~bA
kV! YQ	KB2ʕ,[|	3̙4kV@d514СD-*dF5Na2ԩTZ5k
h
6رcTXÁ=Q|Vf#v[#R(`%MT#\D5h!p|PvMv,hm&A
ѤK>:լ[~MBt^#)G{>*Jj(䀬̛;Y)/Xؚf=d4ڇl`'†&alEt`(C(C,`YC EN!@]XDmQ!CQ1*+s/`@*plJ18[kpS>h2)y[^0sm]2Xp< 
HW8,T^@QOy3D5̠BE/5`7ψ4c[1&c@H?hSb$W?]516j+^dʨLjrhd%ħ)QU2|҄$P
IHB
BP>%f(E5,[taO
s,&B%d	D5(`PBj"4MՈE/WH0UQȉtS'o`Y
RaըVTP
S|ӑ{P:Ʃ*tcD؁9ęD AMkbS?7K<COR9(R=-qK^90CMҠ
|;=X;+(1Ya(4$"H.*E8hݲ7԰Ua'ŏy{^VCZ
KXWPi3kF8ŵ/k!8c0uuuymc/T5%_ŝ:T]"lrRl%[m1Fw
>Z7Xf*wѠQӷJ1
L,w5!bP
گ&Idy٩#SC|a8Aqj_Byb(96T
_֑Wsu>jȜ"	+*)m5crX;0$+o[%4ɍZ8Uo5!½ZSQ$%>.9G.B-!cjM&e#P׺+%Pa.vRqFP
f.t1Е,Z#|w/B
(KhC	$WGҕ-D+܈=HXzBa(t51нLm,YT@*%fTFaI\%RUu`RdJ`jml˻@<`/<A(QC4n81`{{cXfP#pj
H>:||@40lakplbaXI,,/uT``I
`Xs}\Yb/٣C}_jGr箺"}lg8v~a<t#~bdW<+7)/W$|t>1o{>?9zқ
T_ɒ^}yoO|_/O|#̧[]~/?>ͯ}+&=K/[&Ioy3
w	wEFy:X&@5؁ x%Q(*.؂0206X8x:;胪Y%QEXGJHM
8	XPxR؅TV(Xa?(g؃j(Ahksmw(uHzhxhywHh
JPDh
%`N8~؈	hN8QaȉhHx艣(%A(8QAQhhuȋ%FxX8ȸh
̸(Ԙ(ٸXH2hh;PK\ybtbPK+AOEBPS/img/strep509.gifaGIF89ad岲@@@???LLL𿿿999榦yyy000```   ppp󐐐߬PPP֏WWWbbbxxxnnnᱱ՚rrr///뼼___OOOoooȻ;;;vvvmmmggg,,,***XXX888sss:::www+++˽<<>>uuueeeFFF\\\]]]MMMkkkfff^^^444UUUjjj((('''TTT)))aaahhhEEEZZZ|||NNN}}}~~~===---HHHSSSBBBIIIzzzAAA555KKK222&&&{{{CCCYYY...!,dHp@	DPa>d(!D/6T"GAZ1H%1TrB/Yt9cH5I&+PP(C:QK6jԤSVzu҃Hfl_ÅE;mYgӮl]w綥
2o`9qNTls%2GqKĔ1[XNɕ?g͠=~˗]]=[^{sWwoޱ;o^^w&]ɨGwN~џ笾=>̑o|}g`^v	`ravQx`Rv ($h(,0(4h8<@)DiH&L6PF)TViXf\Q`)di&lL0	x|j8vv)蠄jhr行6裐(Q_Fj(dJt`騤9&g B#무j+[N"`@-r,zB-*jlAbqķG bqFjZ,*)lغAN"!-`0ކ@WlqGF+Y0د	s@
JrpD=.a$7t 2` Qc|(r8#B`pPڲ Q Bbw/5
EЂd#DN88fqјg>l!>-@>7Eq7QpP `+ˬNn3 k3־;~co"0#DMBk.G-.!S$,d⾃c!\ˋ{Fe#(@
ҳ,-(@FppLuXp4u_p<`I8 0$<8lH<?
ͯzR;`:~;_n67| v|`E1a;Ad&ie,t!B!neˡ&':oC#`m˗ض$
V
BEa h(,Nvt$$%D
eD"/5}7Գdq{b87Fj3ْ5ʆL-!ue7k$BC%3^Y(fL!
L'C.W򝪒efBDAp#Xz߅m~K20+`!?)lA+f"8@Ǻi>gծz7LjpaDf tDZ:Sim.
8n@D8V ([=3eσU	VT.M0-n5AbZJVװLS
 U'b:2LS(c@ q׆XQ.f{d
dZX	n+hFplMmZ}-BV|ͭ`
nGHMb%掋uŭrKcZbՒ$X}#"aR/3 Ez$B)Vd8%xE{Y!B=~4y@>$P@8_}
sQY>@ub70_bz
OSB|WK"as1+PcX\N7(l.Ouh۵NV3aFL2niA4*jUpf*՞ZP6RW TFeR	Z沗7$Zdc%AR2>+N4n`FYd`uHSgƇKV?:3')`
sC_HQ$4"iN;I&aMa3BVfғ
,efH~ǻl S:u]cqw>Q[
3'@nh!+Cq r${Dtj
88~7;[5^+Ѽ^33Had
0&GWɭp/=jdAVƶyϪֳ%tj7[\Gl\];H`*ᠺ9yJRNKGʺN2ΟJ:np'!)FN:.H;+N>ĸ..2.
ſ;Œ!}𣣾? ۫\|&ʴI,$n),V&%?P	O!K}(A)lnF]ܻMZUo(W(O4^ϻL{$Pl2	@)Qu@`i:a~_M~Z`d0#n["IiCif>	8	4$p\ؑ^Ź\ƴ?XP5<13dHp138T=zTxB	KJHxP%dΤYM9uO>	kQI.)QNU: @TnիI1#	
&LL";:t@dܸ\8
40ʀ#D-b#H$MT\%J&]ТUfjرeϦ];hرeϦ]mܹu{L=Cƒ!V4Ċ3n1Ȓ'SlYhD}Oϧ_߾md͢U-\/`A l0`d8Ȳ˾LZbE
3N/>TtEc)??LpA|)8h5 p,.8#V^AF,J1KX|K80Tx#8d! ˆԮ0o<;T=KG׻jH+-

$@N;"p
C)=,tK[4L@Iyv*Lm\S9TWŎI@;Utw\r5\tUw]vuҬ*XxX57O{H!tTTUs?9|rP,…*6@&2xc;cCydK؀w%JU6=1NIZYm2P,"BPf0'pmivizjFZ+]iodY-XZv5hlBRnnZnXZ,2Y~o{Tg	[چ=a[o;\̓b9sKs毓gKm
X[ HWW{w~] xW^wFg^⮏fel{FXaFymW9eE
!څ,p1A
x@2(6ezY|W	3
,@ҁ $a	plW8
qTXFR60!
Kb"$p,F,L]'?P{]4HU$q66qЋ/a
$t$ƽ~Ԫ!@EAl20@0.>V(%0A]~3^mx@yb
LHxm\`(ݓ5CB8/gq`%1hM(oc
Pa\mPyb(&GpQ6(!HC*zdJ"N$pH@;Bp;	2JNL2 geT%+H*y&#@2`5EEf
/ X\ds)bB #A
| c:An/ЊM+ZyVV-:,FW
NuJЂi\$	(Jx(D-j8D1
_"ܢ;ܠu'#"lS6HáX󾼝F
iDvЁx*PLp\1Y]pa1OzKJ@:ȀWSkE Lm2yeyج(#͋[yY0+#ȱ d=N;f	E dS
Y*ZwËM:ٺQcI@+pw0^yd	A2 j×w9y0M@/*M0ΖE#'!rۇ#%g@s
ϽzP'j=M}OmIL}0@ g2|@)0|;QD&)c83p=ܳ	?
"#?={껽ڣ		@#?KA3K,4Ҁ>H@pȧp"pp)?
#@#+>( B
(Ӏ@,>2BA'XC6lC7|C8C9C7^Cw$!Ͳ(~\4`p(EtHAp`HphlB|Dd@I@	>3
(IrBɕ;
GI3T/T+,i,vD!1@WL!A>DNĬ
CȞɑh w>4D1z}IG#=
=iRG0K@	i@==RbN=|˪>lR(>?4L
ɵdǔ!ٜM٨MDxYEcHɶGOؠO{ɬ\	(0
҉/p(	UO,P|<(P(HQ	"PQ́nPl-)
$&Osє:QX9X(P"_2 &!u(xp	P&/1E( ("$P0G4%0R7PPPI GxBX˜1RBRp1'Ձ1XprQ2P//e0"HP"@V%&PIV1K(hդSTC"Ep!,Lɤ	?B$VѤDI+9i L?\GPQe0/nqQ
I
XeLUzUXx0SU
)-X!M-,
S0@S Vc=0Bp,$B3#pK{sHvBоV$J4k9(BOzS	-0uЅ-By%Ú1MS1#H}P/UU"ЁU_T=

!r=$E+LPp=lHpXY+}|qtĻBPQUX(PЪxUͲ5_BpX0X0_K.E[-VH
p)FODuk	}SḶ4G$/,&BZR(p0XX
UW]20X`Z&H_mpT0`"`1ߕ
|DLT܄䝉W4x$?}^E8e˚Pݶ`YTMuQp`ڥ+[ӝUQTSPUzT@xUU=5"D
%BCH@?BP(s\v=ZpRX.=
-	ץ	dQmp?FQ	)<̮Re;RFc` ͉aHV=kdG
*Xܕ
͉\.婀Jta&e&C)g
lfl
@fgq
Ngtung\cscgz,ghh.h>hFN{g}nhhs&F ]=!hURii2iAycriiifгiBMgTd@m^>= pFEjTj]fd(vjiv
>jfffU{X()PH k>Rt.kkTppȂpXhƎ
Ȇ`)X(쮮	Hl(@p+x,-kp`l(,@^	(p-@(؂l-@)@,8n+#@췖	.hk(m~Ή'~\QkH-H+p@$oh(l>n0nHn`
pmPlȞF-`nƖ n(NޚfoKQ	hmp'p˞!Opp.(p pX&n>6FwHq	.@#6l'
qɾk68	H@ $k1klrOmr(88q(q:o!q=OnO(_m>'q.@hhnԎt͞t3Ri3lVlƆ&ooop7G.pnu?qخopHn,n.n''v27:sݡ횐~p^0pܶkHmx&w7ovf0	/~Gu6=A|zyN_zwyzλy`u1zOzzz{{/{6kЀ'!/	#]{{{{{@mOizoM¶?'ww||AjIǫ|}·ʷ jo}}؏}ٟ}گ}ۿ}/9}I}GKyjwPe;TOG'Qżf~X`|r_“/(wpἕ-mXWC$5,-*q^t\R0T-:*0H5cؼȅ"j9P.$#ޥ
oЋ=vm>jѮqUu1XAvq3 yxpB"]0Xq'
H`88Q~)|+eY.ʨVEZI@9NqC1$A>fPA$VDUx3tfK-oiUI!PuJC`ueCdTg]A:@eٜsAh8J a^t&
0'_ɔ*PqMQU]ՖU a*٢A+vy`GHʊi{ZzI][20
+KHѓB:ptEQpNUooV`5_
wQZiC^Yp.[rJDҚҞN
Y|g%Zu6CTfA^;(2,y5.lB%Lp*kBDS}vM(&S\A,-cH p7y7}7>H܉+ȋA[~9k9瘯蝋>:PV{e>;~h奔><P+캃<.[}K}=cf4<>O>?N?i&5pq]*06Mk :*\˸:MB(B΂$vBy0"aW:ʐ+)Z&xFp n Ah@xA8
Ȕj]:|B @8#?h@
mbMbBvV#E;2{lA<$-AhQFu"$2,	PɃ|@CpHN<%0e`*|,
r`
>@i#IPDLd2p|&iG1-HA'}|"1r8h$APP
(h9Q@?ReQgH"dCTb&ңtK[2"!)MߓŜzdGj8hfK
`x*aևhuhah@RQ#`ҼӇ@k
PDn>VLaʒVV(FcXY6~(M>/!\J6EZ~p$skOnRя@Keܐs\Qd1J\s@o	X*$@ M#-UPD6fp
@
2ݵg3ÑMjr3eE/l` vLkO^}]s$7
cX0WԻu{Ћ֑$5(B+jPjRm/$)&	t"?Lcr@,EH}<%.wR@Gbl@{QY>3K@r-3!ئ*qN@pgݳJL
h)E3ю~4#-IK:22MsӞ4AM+\>5S
j1mdc-YӺֶ5o+ 5-a>6lb;!mjЀiS־6msp:|>7of?0nz`wSx;N]={qr'#HL0\qf GWwq
fxx\Աaa
dC	m'׉DZggBm@)pw!R 
LAzN ƫ3Sz2 ±U [@vrwh (0/ w0/qs5W,88DY+pᰁ1*

@8|	
 Bȧ<ǁ>>{dgo*ebև
L}{ ǻө\Q@#G_p(upC^pŕ^1D-_u@TMl!Ʉ)um_
_8 BDmA%6IV-遃
8dҽ^N"
^8L]Ո|*\_Lv	jVM\@\E^%Z"&ӵ!=_S?M==&N>ϳ]:NDDME^&bFFbOG@V!"VCMI^IGNӌ꼤֥$MMBN"#O$$d%td%	1e875&d@.#IQ%Y`%4$?!e(%˨>Х%8%e%\Aaab.`LccKd*dTeeNff%}|fɄ&&ij‹jkk{̦&ܦ@%e
q'r&NW
etFtN'uVu^'vfvn'ubAQ9vT
H䔎y''{4'	̧
'~~''(~6X#,<[8
M^(Fς%
'M5hhP	Y(>vVVh패B֨:֥K))&(>)>RE^)f:)Ub&}2(WgP՘
[)~()ڄ*)y)D٠:*Kt[b	&LmJꤊDlXnGKm衎*vȧ6jHl`*#jDĀj8t՗DO)n.+FNunUvշkaƸU+z@tBTtA&B'Dd+l
AdEt&B'NJg,I0l:BlJRll&IFnnvm~m*ZmnP.Ʈ:m.moZ//oov,2/>lRlbl떭.oή//.
/zk@jk7w3p0%0.0*G(MpkZp?ap10l@PIH|C@wN1rmzYDw0KGU$$D01H0?TqwE@
OV
H{YxQV$8h798X80@Qp8hAqUaup8"DW]8xv08ݰ;#Y!7!X1]UX%<2Yɱ*1(m@:î) ױI!OC:!#U{wH4i>ir53<$Y=C"&H}<dvѰ%WdQ5Y1&1o795H:эis>s#DYsqW5m#s8 9-q;Wf4S'j:M4Ntp-@7с m4?QIp%S2}>vG58qoF)4[uhE|kIuY`}u8D1WSAHqqB0@4}@
P&5$osuL2SY,,=tD|T}l8UsA|1q21!TMۋ6#%w~!FkW%fy6,6'/tgRW"w$q(uf$Q:W/Ql'`XT]u !%XpsOX1߷AwUW,|:6,3Q|!@_3v5Ap4ED|D6z/Q3tEe`A'Sjm	#`dїYRjRY_wH08I%o]ay>d0>e433c5V#u414ѕ@x7SJ^(RnMS
<g4yeJ+YtfL3iִygN3L%ZlPh8(A/|p
	h1Ba"H5{mZ(ȠvOnj7P_	pG$pp7vrdɌ{9Yg\`InCaiիYv.!xvn-=\PewK@l~yrc/GAs_3 @zvۑ7|xɗw|zٷw{׷O02@\p@|ނP,Є.P
$?pCKDP$=L1],EakqsGwGu}4Ȓ8𐅓0JJ'rK+ԒJ.rL0L24,M4T&|Kds7Á3P9UO?TPBXTRJMtHؔNOA
SF%UTPK-Uj5PMp`UX7VViU\e5Wawֻ^_`vbK:`
NTkM–SmZpl5w\t\vuwMU[y۵]U|x7zw`~`&^vXa8Q'6bP/.)cN'VVf=Y^EڐE䑝eeSenfW9S权N9bVaVh	>ޤ^zꦥꃳZ_Ҝ6벷l7Xצb5t[V
o>o;#_q'p3r7|pkq;/]9/q8u_7)vggus}wewރvx]ڗ7yAWy諿>{{o~|{.$f$o}
gϩ_	X@;D(!5@
)U>9vP>IxT8`	#B@zdΰ<.ġ$C0تɣC"⧇GdDщIbDF=)@Rtܸ)cRP<:,	E*E'XG;y#$ЄSdQ@+ڄYDzb20dez2@#dƳ$(IYJST*YyJ,u_M>
%%!y`$+
P8yN'F'a@= )Z($- .Iv$pdI(!pT\PwJ*'X)F pA*{:)RTDgxv$=i)bt+g6,&hQᓁE¡`ZaWx,Ml`լ8A6	Jފ$CQVejQa{̥9eS&ؒȵlZxچ	ih!3ZT􄛎m)\
4m52 
[ ͢&Hu+fQĽ
t(]p'LjWRffQu.IZ_s3"UR`4B)X‘j!Ic'18XG&gJ\@( O[@&rX%yD)"@͋Mid2$n#؀.BeUr2jM+]$'1V
r/@ 

 BK$Ng
Se1zep,.MJ?-jk2U*L-ɑ`5NTenBZ&nP(дB%޴7mnt:٭2\j8%h6Wr̚%am0MovӢm0($PXp@ev+>nk	5xHK'wqDv! tw3A͡,x[4ʕrDLP
(|!8Pu&\S:>0ѻ`u'8nRc
4;;݉`tuOj@$Ƿ~nc8>(χ?IXPH>tn0exBOv8ݐII[oCR2kJlD\Iu8w.(}춷	ub9%{bb!r9
t"ة ̢
z6Ilɣ*B4`4 OhT@0@,*:.%Ќ.Ljt(f,Dn$jeljP2Ϡ
*L-K/4Lm%$+,8$k8j݌,!
[͸Q!jƎ(P:;F *܋&Rp@VPHmZb/ܬ%M@+jZ8`Ű/FQ_,% +*jn1rѿv1K6DLM܌M;P
jgQ0ް(bd:|Kzh,*K{j))),q1bH	o*1126["cgfJ7ʢ#@@u)L
謦"r&{˸j	  `O
W2&ZamlOR`c
Qd՘(jy.$r:U+n)%'Ʈ&I%
.&%,SO	z3>J,M1Ll,1U(X0IhBfO7! 18Q"67,9Y7$9g9S'+AAа:S%sRШ/=>S>>>?3;;<;$!(Q@@ATAA>sA
`
C3TC7C;C?DCTDGD9t
 >$TAb
PtT>X@\`TFil>pt@"yt@&@ISFsAu;uQNUSUUWՔ4=(N=RI$R+u+d`
zb
:uWaW}X;:Hh(DZUZ5CLKN=_MO"1vP[muX̵VCYgh,L^^^_U__u,B5%[1Fu+B`
@\y5C]TQq(^Uc7c;c_jG$`]bh]u+	@fe+fgb^?g{gy6dGGRe	@@\;
b'OWia6gtL@IklVl6llmVmgdHM$p5f[neW`ojo6k/6J
LOR" oá &r-sbs;W;ޕ<3@ qn)ts4t`u'u!uu8h3VhqvLdw%5~wA8?x/+#OiWF-T
-rV2`Kzu:W{hkA6/@{{W
|~A#b .
wB|T|}M%2 |1r$r !$@׆d7|9QOB70077UOBT8. .XetxO8KB= !w8xwchUNy}Mۊ}$JX4r s` |C!J8t`!.$-<@@$
8%D {%'x@. r@Xry;T@X7%rw_{
{CVXŽA)eNL"vI9L9XjyBg748y@<6Ay%X'7f؂%Xނg999XW$٘C @FACzԚX/q9Y*ߢ"XYdx_Y׸08:r$.!@1#U$zuyxK-kXT-Xu٦'+9Y
`wwuɳ#%D-Y!٘'/u-::8ӹ{$Y8{خ:;:?b]cىO"$27*Q"%aس#; ?${_s#X=׊x:sgX4ۀX|\>>~+Lnvf?C\GKOS\đ9HC&ȱh(v(s\w{|+c
ȋ}5fܓ?2`-<1Ük6P(
W9Ϝ³=?\5gٜ=?v@D
2Fw`OQb`Ә'` C7<%^6>	.%2k"ƀT]5B?FH%L
hlخ b\`ݤ<=$,$`]!<<~`˜`@|,=%p}?U%4/
lb2m݉չ=4/}	2
n(MX=~O`<-Q&XnK=`.(*2
,b։@a^v.ʠ.
j.* @Qeh'b?9qߥlx~`~A/$xMh,%axٷ۾{O%gm dq1iP@^Áۍ^!r$$$>}t@NsF9hM
+.B)B3/b
U]]!M	4Bc=E}_bA>
4n1:uĕ>]B|)bAb3hg-5>|#Uh;CԟPܻ{/:j2fݿϿnd{ Ettv`vlEqfAExPJ-EM`$Gwxұx6K.D<0A8#hD	!N0%D(vӁɝ4FfjZDY@##F`^$8 H'vN8"@8~hibF`&Jm
DԤf橪IꨰdQqp%+AF*jlʦ+B)hNG䲧k-Efm6k-UHjmnn8Y@PFPN0@>q6NՎBI!܂n>\_|M- )D@I#AP#	s"+*,OE:sT3牷eyDLAXKld@+U	egqklZxNK1CP^9}?enFyЏmc44'Bm(P 4v%|.^
jMm@3S>wzBDS:ǫ8kGd@T}8"`g9b@O#/?l)뷻yӆAUݾT]Y	&@ p>]ەܯ40@
w[	Ce͝K#V	W5EƋ!Zhp\Me](^l*"KIqT,^u<ȭi'uOt4qll8qtd#C/&j^SR
x)GkdD#%/Ljr'?y,$:c"Y@;^T`-o\r/IKRu*SH!qhJsԬ5ljs,xLl3Mnsl;ͮUpWg2%4 $
-|APƳHDdpL!$xIE+h|Ґt$-IOҔt,-iJF8T`,Y>Ʌ+dh8b.@hRep@
	A-d !@T[j8T+4X@XKQtkd
4XJQ`T6%QppL
qASpDBE$ a
B8 QtQ;U$s+js;\@XW[N4z2AgPѫ^7ul8jffy_p쓿tjTk*v%gqWbUVɀ	\U$ D%6ȉ
"t@\bJ1A8{^w]-+ޅ~7kXm@w}JYra=kOZ3:@9+)x/pPqw@֯ShbQ$p
pw\dAt-iҴ ~d0Pp\ 	J#$@)AA^ăt%DE49Dq8ҍ#gѼ	}
"ֺ]F1
)05Z,* P]!$)soؿN5=/E\T׊6El1A.pf$k">ɢ`ZD:mǼ4C;4y8:0sZg9͋`rЛ>dU`VNu"SHdP. $8Ywʚd!?I.nD 6MpvwtEP1s\tX[!s8:tHvҏfU
bͻ/ab~ٯpx"H-#\ (f}-?mb 1rGnNvS~O{E)| 9}g6t'nGb:UpxcWy1^WczctLGt9l$&gĆ(b0y9t1OH|kJ8Wg6qcVWtUyV(}n%hsx&y1ȆvÖ}w:P0Fl7n>l^!UqhgZAvl &]@tb]XWEyϦDWgwg2
`gvXw-whWy] s=~u9ZPgwE|x.t(AcU`r7sGpsPm8m5~fr"vb@b8&uvv(!p ghpGV(mx،Œ	Itwfk~)7+* <^.
鐪wf'r+sX"^y. afx4&6cdTo.-06gaf&IGL’"C9mEyGyyx&x0m&gFf)7&oɲvVrXPc-7si׉5wc=u*(V:@sSWu7Fv4liz-f8,qIfs-uiic7nHgzv؁ᙕl'VU`f*Ac	"|Ç֢17*H\nU|IhEgyp}$i,țv1	ay\u$y$'G؁,I,ay0VH~YZghǹ^0`s	*,	V1Hi	v(sZhGf6bHiY"B8*hh6rH֍DʏErW7bK1&3j,5j7S[R:,TVjXZZ+\*_"F'ESEp"Dk=vJ hp2+bpJʫ a  '0B?QdrЩ֪!@

SO	ʺ̺^0JlZsLpFu˰
k[0J>EZ$#K%kЄ'fЯJ	Ph8˳4ft/Kz0$5{B7۳盧+ѴMEJEOŴQNOb˳SKY˶zJ_^akDuPh{L}rm뷽jH$JdQ 븽*`
~C" 빢zUFdKf
p+/`:K;Ҩl`+jw3r)Ļ&9CkCq( 5Q%$!43Ѳߛ0`C{Л@O%!9C$)/5d@ۿd
o \3?%q?/aQE!/ޅk;r #,%k'|{_K\$1d7Uf:G	Oç@B\oD/85D2aCl15dM&3
Ul֊$AlDrBqx$
3SšBTu<Pu}Ǡ:<ȧCbL!@#Ia$09B ]<34@`qj,+
`,?LlDȭ4;,4@&0pgg!gPL̓|͇B!=01C|0B^
fbpja0%<ͪl~'$606oLJ<@,;`
pb@x-nl# 	J(.
{&45C]G( 
D
[m0PO=/0e+=Rd&nghjmNW2~49Ao#9Kq);y~9u/$/ ΃NL~D䈾
NVY]N!.$(j	xP37CF`9S2/m^~S吾 #'nٜͮyw*Blb.FB4Rf\7c'$3|.zm@QWZȎdك	ય,72s920F?)Ʋ(BAz'_*oe*â5C<=A7\x^
>.~~b/ޜn3`L4\{S^y&On+a1@C3BLn^ɞ@k/W/.~`?-?%OO{˾@	}b/#B[oƏ_!,`%HF,lڵGM۸sͻo pō1x`	)Q"E5rR$I(UG$D\3Rdto8p6h: #g4!pA:̴۬;Xe[䲧K1U[oc5w0͢^7~O8+N̴=
GȂpNb,i䘸
;sgj
h-dػ,>2F`-&
0FWesVq$AG*J18^2!P	>)NGΐJ;dH~;5{nin(r=)\p.|@b) 7@ |!?0&'` g`@hfǀ@rvc
Y51dC@9LbØDG2PT5Ϩ=ynO&xh
NpD4U֨^s2%5#4@vЀ66pt` O&4(p`vZSHQ>@730:Z
or9IH/"E)l֥҃P	d26AM̘@SIF	G]	;s$SF8vNs4~~@vHA
f't4#`%G&{Tx:FPeja
jBh`TAp\*燼$bdx!mzJ|SvV,<zp\BjN\
PTYK;^c=+XNd/D]]D2Yr+@
]_άfԏWSQѰ/
@Kїu0H=p0pjxlU@[n[yXfu
'Sy?CՊD);?u ]<ͪ?=LgMr)B7э~i{װD6cxGXDp8#wc,,nGJa8S#e`1Hp,Ġ#=	#o+րCf}u{~?9dvevN؉'S$jP}H[v,@yH{G3|3&X	i
3	#4DTdt㫶8:rH0S`y:#& %􋼍"LgB0B!6
7j9"6қ(-
.2%d&t'⸧
4:pHbx AX4	ժkɦqr՛&($B4C|z2Z%#B06hd02t574dCp&Cj?;$jE>tʢ#]^_E#SXMD
dp"CWRF1qޙzEBۂ$Y@ҺEٹl	Br[Dc4CeJU/~_Dž4i&$;H"$K¶cȷ28FD*H4)|F>1l5PȐsg0h?3h=I	*dIzIih	ʲ0-ǭԶ	G]zJh:/TJʸK KGIdIr0dKPx˖{˺ 8TWz	؋،؍؎؏uؘHPiH>(mpDXmENHa(A0H]I$Wؑ	٤UڥeڦX5ژpDЂ3(X(@58Mh}meYS#]-0Y`tQtϨ	uڿmZ[@	@(BX5M@[18[+]½	uׅUݙ0p	](%XP%聋\]$ V%ͻ`*]]!5EUeu_V]_`*&6V`NAvN	`I
N&6KE6afUOn
a &"F$f&v'(b25Q	+-,	-b0	1b2	30b45bb/c/f9:cڵc=c>cc+cB?>>dCN@AVBEFFGVdKfdLvp;dNdOeROd㽍U	W	X	Yne/fpe\WXYZ[bf]f^Nf_^f`nfab*i>iFЙflfmfoffjgn>gsoWfgwfxfyfz{nug}g~ggY~g6&}^~n~耎n傞hh`ghfhfif>i			ni~iiitfrjoFgVg>jN(确hjjjjejj&뭖jjjjIk^knk~kvkiiii6Fli^lV~flNilRll윚	Ͼl m6Ϧ	q	׶lm~홠mmܖݖp@N.n>n~nnnmnnnVnno>vc			>No^ono~o͞ooooooopp;PKNKkaPK+AOEBPS/img/strep_wizard.gif}MGIF87aNBڴlrL<>dfDLV,tfμd䌒t|||\Ҽxv(^ӢL/¸h#x]',4ߌH2	#8ێ)dOBUi%ba$5)	ݔI*.܉:Z#mBcq8UmwSgW}RM7m[w͘D裋bE`tΘ栟I`rx$v6	9hz⨤!͔R(,
ny,jX*늃dv+r
VMv{;/:)YG,q'닮g`OПq{`lBEH]9Npv+9o<+·$A7A*ո,|'K`Q
F`ħf  J*y+Y@@-nIq
lc+ 0adi0HhL+y#$UR<p)LY+3ŀfN_jH
NM:v{DR19I:UQmjI4-OڌbWTDL%QJGcr2:Ǫv8Q;I$u`;Xqb9`+vЗ>GMYCMJ96WRt-@g&:mrsɆ%3='&-9nA&lK20.0	]Isv%AK粴]o_ve1≭c+huR/3VVv8VyWT`gyEweF%kdYX%uY&"cl8owsuGxqX7wHxxAc؈Gˆ8X!uaቢXxLaXxȋ苶¸؋ĸȌ،x֘ȍ(؍8X(8X؏Yy
	ِY9y{ Yn$Y&*D(.09452Y8r:ٓ>I$&eyB!kXaa:YeXNJ	J1[Uw -!JJ	Hq0a֟ٛ :ckXKYJykYƦFhK臟7g	Q-z0i)ibh7(WZkKlDILZJ)J$Jab$aJYRz!ZW0LMfJDբ4[%
Y)ڧ|dc`xH
yp$EKd4񩙅Uq-rQ# 4SɪDTjYzsǨRɫ*PX
Zj:TYK*b$N\ʥY_:ť0:P
E
J[I;Pj
Fڱ5*UJyO-P)5[C٘i8ّ(QjzAk&;1	경);Pk[@dHۭbѮFEZ
-a3ˬEpi[zO2kr[Zrzwo>[w˲{KIKN:~ڳKە2/![-U긛`c5֮ZYK	OV|dԮ`tKpQJ곾Jz4a[N[4P+і́Pj
kEJ/1KqI:Z˕Ԫg:賀
N'	\M,zU*ȥij]
4;AI|Um?ڹBp CYXgp}˩fKjq{YRiKQ`Zz&,MQpe\L|8*l
Z9lܡn@<?A*]3--M?mP&>}2I
F}S-AQDaFbxC=_}\LaGt
`]}"`	Hp-\mWP}@؋
X=ӊҎo]HӘ
YM1[Cl-Պ7ڔ
?ٙ	'\۳AۗڥmJAAMz-E5Ap<+|lҬpԮ
ܠۉ1օّۖ]`
E۟ޚ-ژMڡ54mLAD=B`M05t~eºɘUq}6	&ҭ M,:~ҍ0ҔNBPDN>GJ.5>9 YWnHnK~MMorE??zӈ@җ]@^PpNmg/]Ӯ
Vm[I~^wxMՏ@}~m	{>$]Պ.Ԏn>
3 ە^ԗ饾]N>	in͞X:1[A1Aw-Ǎ/*Va۹NNV-(}p*?S~$m-/;ҟpҊ@փ525.O0,B?S	}n2NҢP@c	^VT/{NZn|FACߪ%=RO> XOvO/qL}Ddoaؾm[F^@xXނR>䇟oҥKقo{qhJ?0
?.7@4$!.
Nqy& ~NO	RC4r!@%K<$hN a	5N8p"D%3P!I=8(QG'VN,e
ms@
PJ*$J֛$NRpΑ-|SLL3m2bײ0}>'/
Do";' 
2-F:`82/$H"RDRl0RqF0.2-N|M'aIEcz|@RI*:T2r7,dž|-#!Z3['Ě)3)14 [,7KS!s+-s2&-PH3R{̵tNSQ5%NC'=S'LJJP'K{p;!;ŮCfTo?@LӢcj$YjW.vVԼ+Hl?i4aw#^ġeE/|ɟm޶s?Di2^䥫IYxHJKB{3}.5!tDK鎀B҉
_c"XDBO9tJw"L0<WÐ\pv^g=eD[tCA~;t8`~D'ge:1C1sC&ʥZBH9!
:p,`!IEH8Kh{2$\%S"d$4ha>%
)=!l$94m%I)#IynVXDe%*)LRINJD-0U	VćYGRH˔&![ʴ%^[/5iEmF?Z~?>U?CS
ӌ_ɑ8O!u<(AӓL[#HA*a!ܕ*@_LB)$A&L&1BC	B	[diiB!D
=C
D)89&>k5?$DBQD%!RLZԛ=?dI|@8aDyDfWHr!׻<)"q>z֣
=9l)REpD7iT'k$kR3X 
 s@;
B&nG
CFNr,l	GB4	F#ȠA
:<)6cǍwܿ+ܐ>t~3gʽ idR'˧*Cw3„cI]`M	ÀTRJCu(S۵y+ʑscħJ~Z_ʨ"STRbKĹ(K2ɨʊ6D'H̷g.L@4D,4E֔٤MZ., 2Ϋ$4DdtNZ,
$4TdOܰ$+OO%eN5UMMe9YY(HR*"J9*r!ѲQ	uO
}Y08AФjQmM)RjчQe&5O}-
UXiA=0-u25()XҸ
!Ѐ"R
p 	S,1ӺR#B}),=JԛLYYЀ*H;T)%QS]py1+Q=liQWՀpUFK`uL-5hS3@RU^VUTT>mga8#5ԑQUVVVP_vuY`S*d]1TSuW3H#@5D>`>N
]V5#(63	b4bJb$0b%^,Nc4V*1&nb[8ĕzsK]KV8`q
l8{80[(oeqz9kJA>%}wC䚻|KUEXM,6.CVW`8>?u_M`	{_u53DȲfMaOjelv+monq'wrGm?tgd_vw~x&z|w~%7GWgwG_^'7gxqyGyω%`o	 xO$O%'7GW{O#8oPO?"@;*gwLJtX!(*Y!_,
)dɎ  ڷwX.}-ڢ҉GW_~ޏQԷf"{Oߧ~ұWg}~r}׎i` „	8hHt@bCj "G,i$ʔ*Wl%̘2gҬi&Μ:ws B-j(ҤJ2U*`+8cŋ(
bǒ-k,ڴjײm&Шrҭk.ѧNX0-l0Ċ3nxd\'SlWoԾ%DɀТG.m4j-n5f"0hAw72W.n8L5K$9ҧK/p@8ڷsﮖ8P
o=
xo>￲yJx 
`RH8!Zx!:!z!!8"%)""18#5x#!:#MAT$EG*cK:$QJydUZ@{-dSz%`)bcy&ix%mef\9ge	w'cg?5phudH*zaq'*nxǡj`x*:zꅢZ"n:+kkuTz)ŊG!x뱔air"fjZK&F&2ka2b
,	[Tp!rPb8b;[	{<X+K޾D;+kJJ10Zh fn.K(s*H< IlG.Bˮ6+=!͸Q?MZ-3ܭbO;ȡAl(!RQ2wWmȁWP
7r]f+G>ys;܊њ[13I(Éy腊8+My.ζ‘h8~ag-v[z|ĦK[FPrKxz?ukrNϵ4.0ؒo䇲%i{cHUtJ擝W)}n@VZ[dN{APܐ.O)X+5)2LByBOu6Auj_

wRS1Y}h+| Ƥ
$"!/'K]78AXjuV\,YTD	2v֥Qaާ	lk.I3ެXűbU=~,-X(RHx4)LjJR4$5Uh2Jh}P|/;Pr¬f-;9̡蠷Y*ye*)OK1B&äLlUTho0{8O,CT9faۣCDh}eE5CFv~"k{l$&R]-CZji['*T	ٳGB6T^ir*TjԩYRSZ'N^U%UÚ_SVֳ^b}뛠B#RSj׽f
b%A*tkX+(AicSRYbꄳg?{Yђ,	7Ҧ&u-kcӢz5lek܊-ph[[ݶ,Z[Y"pGV\0׹Ƶnz]@7Xݞ7A/z]b9ozo_75.{[^?o+W4E3ю~tQ
ISҖx$MsӞB4
QԦOUpMc-YP5s]&ϼ5-Z.cðe(Θ-iS҂>v:1d6
hA_(óp0 `XlF [.Hvo!_p<wy;!<_\)	zrʨ`>>,qu/}|Giz~|Cʶ
`Pt@R7	4`ww\wQOþji#c]@ y'"A|>=`>Sv˕)@濠ss='Mԯ~YπCq'>^؝i@[աƩ^i\[AiAJ 51`BPd
 E 	` 	@`|`v u 
f_ù^HA	%:!]µݿuLHa
!AAa !jY
!ډ
r}>`Dfa	Ba
`
`2!#6`!. f`'Z!"u!!ǹ@i`D"R)["v"!&P _a-bA@5\_%"ay\֑cÁ7͛*; 9_d;_<#c7"0d+"#<;>Ma9^B!!>m#An #;*;r"8nd+&E&@/ 
E<\E#C)<=fb$Gf8ΡH.GNN@bQVAOHcUzcWcP>DfeGFveABeXdH[*ı:ReIrKRAБd-%RO_=$H.CP30?3@T̑N9O]-Ρ$At0jvŎLɑQ]$GCGk3eDtX-xK'vLrt	dG/oatM4JunHMWIt-kuF3q೛uDsS[sMJNnO3G4Rk2KV5WO5[tJuTwP5J\;)5&vb 2~ m.;"a`c&@bj,nP*M2avtff2|b1vqgW`cOalko!j+#k"(F>!kir&_n.*nc6u[(r/weY-c&u[z&wlpr'x'	Vbv*
1wo~566wc~SuLeE.UN/Cjf֠]"Ҟꉳl%14`x{Y9-rRd%Uv:dO"yS8x0jN:y8a* B]bJޡ8\Pe*cg&oYe>2yWp_9ֹ(/Fer.X㯕y3ebza.?*噳loySxU
{/99^#V]&RIzh؞R(jJShfI'ڧ6 {flYS,^5(&2onl6;Sh(zO+o
M{w-{b*P/:;-{~&趟g;f˺*豓h*lRz5+r'v3k#kp*)1m'z+8cWvv*&*꺢WS++;} ?m3機+)m:f̪r뚺\?}
.ŵN#{:jɛ%k=:ٳ,׷W=~gw7K_o
hʾ}g/Ė=ڇl&DZ
-a~G
.߳-ނpq")~r>
z;?{
J<˪lv?Ѻ#?zڞ~Px#og('-@ H @	` H1!*VPqA#Zx1> TȰaS^prG*!zܸeOgQG91Ň+v|3iUUxUt-Vhlڸ-zVmv2`Y	qݾ.0r/ށQI=sԦO2b#:{cAk[_i"jSg3Ǒ

TvxF|X4sI,6m*Ll]zUܖyޭ,},ۡt#_&(GN*0өذʳ=朻N9m0@ݒJ(B,I@EaŃ@x15`j$@dR:\P1vL	D$Q?HGj
+,1I sr1G0iK̼IN-9tO4Rs=RQ'7%$9"Ut.4Ζ	P+L3L,*R#<=,/®1\U]AP\lGVR5e8;EuF4R?DlE1LszĠ:QybW}_yW	6`>XEބ~%%b6Yﭘ#8_s*d}ey)VaSN饑T,a^5`Zka.N[niݎ[{n\	?o~Xciwk\hI%ח(&jL_be'e.in(E>WV[[ҲYnIT,~0Uck󜦊b]E+q6nhFAz7{MWsH$nSbDRTy#!,ψr
@Fbh$D%GJuo3fI̖DɌ\i˖4w9^~0!|$seIuopTAJ5BgɐsFt
C
$:fz*I'7AQny6'@*Mbn:u
p(
-e)u͵j9ҁ*9Pv{Δϟ*b*URuׁyBMeEդLKQ!rITd2QxG03XDW-kVjl5sf(/dq	}܉3[CfaGRԬO@dWq4b;vؼ.h~Jag,Kq1'JoT,DWYf1#rќf5(`fg#Yu}hAЅ6hE/эv!iIOҕ1iMoӝAGϥ67IjTխ&]kYnqk]׽|laߺ%}%0vmiOhjoƶ0lqtHAѝnh'A	xӶv[cf#ěn
t6Fje(6] EJ$נV341n6ğ
r;@16Q-@yE)IJxPEĐ@;Ύ9왛*wӁH;/:щsUv(EblC\mѳuP弄P߱r7 Qp
Cl80!mUX`$
lHWz{^ڰ{鑟|̻[׼>DU)={I^ЖgQm_;
~𬗿kpuJǩ b

Dҏ// 0&P0.d(hϩA4v6e08%0e%LoP< 'Z8nO>>MMM===yyymmmRRRYYY...AAA___{{{HHH///~~~555jjjaaaNNNSSSBBBLLLDDD(((111EEEKKK!!!!,	H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\(`J-WʜP3sV
ڳI4̙#p3%sFಠN1
(4:M:9%sJy`^c!9*̙˿~>!o
=Wwo.IL ہ7.Qj[s6g~EԷ_7yqip1{hXW>!@sKڇq*-n{}$sV
QCpm7I܀I>`ZK i9'S7x9!PA`X&QF<9)
AV@\'$6a.NF`.R
KyJynUaշ6ݪܠۆMa*9ntQZs
,h.KaԞvTOP
ī˽wZ9;_D8;0Ɂ*tX>0QOؗ5(.FyYc<>Pphw7EgE*QyC^
i_!B
UTvt ] PCa)LBQPlsځ|nvո;C+%H² 
~+u-p!0aB.p}[ݽ8M,聧 @"nA@3D=LZ	kNpw}n|<'8APVd#e$eyc^}9
ц& ko;r	G
h
'9P#=v 4
3b
2]3W@8>v@^qd>>	
(C`|^4߻[8D@?[z	(@
+qSsO|==.t['.v,P
Ġl7Z	Dp]eP0	W|ǷwGz\|qtg՗1J7H	OXzTlgX~gi7g-+0)03/hX~|}oC(aRD}#(}MRHUXЅ TA:xx~l(gnsHXLOSXW[؅_c(ehww7WjX n<&##suxԷ)}ȅfȃ~?XqXu_؇HVX\`(w(EHDsHxNjxTHX_娊胢Ѹ@u'؍8ɘ؃؁9vEEX|xȏ(b`y
IxH瘑Xj5^P#R9TYVyXZ!pHwX=˜*xШyphؐcɍR荡BIk訆fbr}٘"	;i'Y))hُjY8of[Hdhy&ى{A9G][r8IFkHxd9gIi	=8Wj1gʩ~IDҙyEpK9QGb(il)dqtiy	)(:o8 i 9a۸i9n7Y؝٥g`SL;Ky\j`p![3*}
Mg.cMiYݖfgξڒ2G1ۖͤk2ۃ
2$@Y`㉪]jqsȆ
I(b0z-
-]VZ0`jإ|_YhrH`X}@]1{ iu"2^;`@rIP	Xu
 uN1SZK#>
I.i&
Z^=ra^;N)~ե&e^e6$^n̮*ܿއ8@
:(o>ݥ D݇<`>Q)^~*[iP"f}*x;P~D.n'
B@
㘮_ iЮ$o4SWF/XG`^jNݯc@!@	O]0jMZX>uNd[ʪmn#`}_N5y[o	pn!!hw~9_)]}ʮ*TNQS?(!1P
}`O%OO
~M_]/^0C(,a0`p"AF
s	:p8WI)UdK1;A>@`"B
0`@B,P!Fr-TXA4hHa 4P!C%fき?P!]yR96qi牠D"U)RWTuk3
${0†#Nx1c\ ;LkwgּsgϟA=tiӧQVWbt6:hߢ@lٵ6ជfqTɔ-sͼy`AgC%mFM@aeI0x	(1 *
Ƃ9D[򛋿qDغ#<Ào1.2ԓcȾ<i#qHg;uS<
B&.q>8Ԉ_H0l>(LXd<'j=5뽲|NMO.^A12
-AZlP'BnNGs^A;
O44ޜ9%uN6hS\aBqCT&2R+'5:t
8u0G#$uIELUkl5Wu,>0gn]@-W%]569T>f;K$ؕ^aalGEnQQXG]$
Ixd!HC^'+VJ~,s7́G9/-SۇW>oᴘh;i
8go0G^DTͣu9ʮ7Ҏ0ǍIzn\CP^&ћ܊Žxc8Bɤjz;Wh;Ԕa~lRf+4W]$6!fo7gOp11G8`V5kcvĜF88}\0ǎDMh{O:\9ҍ3BG=EޜQtk	+_/+0	{y?0$x;an}k_	HWPDS2andtG!0!L"z>!η`yoJv#6L8LB6bIT`^H,rΉ81B"pH%X"
n@儵up *FxG0nxrC	#@(	hrdGA!@4`*Ax6JyaSa"Xh"l^L
a'$Qbd6";&NW`9hp.3;g8?/`A-޾@3(02Z Ua`N#pZʈ4`^bG6؀?xI?.r/a5 
~:8i'Pjv`۰C71O"b
$z/LZMHr`
~ C:9́
{5! $
!SOJ1L>}dPÚ00	-Ԃ,B )Y^Wl%9qS( ,^
,ˮ7$[
 ^0!=Ȃg;b@@H#ےKf7{RWֽ1i	x޹
%&^H$ #"p 9@~p<̃`!(I=y!ķٓ:@p{$B0
c86p=/")505ZtP~/;d㈌`IPK\l^c޼@]#1YfAT6qs)$dWĤ[gKg/'
ʮ$pN/`իv	:'yKmSZլJ\O0AolE6	g
&δY25v6d(PNIHlimHC$F0KxVP.e
S׸΁wQm~=sf0qdv<*WIW9fF$Y;䓄IOO/Qr$?Ņ=&XWgt$H7ϡY^>uqfG;ɵGn?ܫ\Խd{j}dt&
^xa׉߇t{)_u1<;ϛ^O=͂0|eg׾r
\Oz](>s㻺I*۾__P%8{:?I>ݾϟ~9'[Ӿ>Cask,~C	,w9@5,{k-
8?
T?=3[Î}j(L>#8q @=A); dA4? B$;As@LB1@'AJ7i,-dG+[(  9Է9$(%1B;<;B8B(C("$ځDO+#x+W'PDX?ĿDCDXEʢÕ6rӁз"8%
dLFe\Fd z"&åA! }s&`FrlF Xi'<$<],|;r$!+rG}\h*K6"0{G$xF)WC 1{džȎG,<Hs#hH,GX#XPȻ́%hɗI:Gܼ3!!IdFz Fd#8ƥJ}lԬ54Ca2|J\Fıt™0ɲ|e
,JKd)'*JpJ,Lhz*4LWL?Ǽr"L4L,t%M43I؁D\GʠMt"(xFs0OJT*sK|O#з'Px:NUʿO%8PLOsX:
ʾЫ_+цaP&`ўMs*PPss(¤}\huQUepM!H$'s؁m|V@@	PsM-%G.E)I0)3- Hap!8sȁS;u%5mS(;!16SӛX00ITd)Q%`T@X!)+H&/MӚ(UYU]]EUPU,XMU$ɾ4b4`XUN
_ʼnVDmRKQVfuV۠Wa+~QdUЙ%pE9T`p`0J#X:E͘\WsR`WHfuS8R|{\Ѭ 聈&oH 5X_	rE0[WMY|HI&+XT-(yM?z!`x'觷b PYpFhª6h>퀛]XQVP!M4ڗZtTa*ڳ}uxeZٮ9Q7`@/2,(IЃ8KuNWۡ 5`>p'EX~2,*h1#ܵو.FuaY
 N-終.^C0<(%]W22]H5s
4)$h_"x_%E*28P{0]R1V
23^U؜Zeex6a`Q#_ݘ6RV\!e(}&6]Laa
޸ݸ
_`N}	a߄(aݵM-0`*uUv*ᨺeL	x`(9z(%_0a'NM)vb?b1a=!Nc6F7f`M:*~V+~c|y*?/`T1ȃB^YQFn($vc&w-d<OGcR֏->dVVW&XfHIFJ^VXHLMMZ(adod^fukU FcX`Y>gsIaXȃSg r~g\cvm2]z6beH}>~fsE`f&j^޹ cMyh5vja}c\T%@,eO>42 VT@6x6~v%f.\^VbhƻdN
fs&V刖鉦ih[,4f..FQjFVjiNbie46i"f]h/`lǞȶhhk~j,MrZ
:x4h^3.N习;PmFH.	,c@҅lFl1 )(C/9+ޤrZ
] ls0^g4XڄR߫}5$00ovbs؃&be6L0Wo0$-1@"H"&Z$58;c c60pFpI8uVP
%< 3>(.0xM=(8h%pAoo$qM.spKx_h$s@8P,`?J0?&Ts"7msH$'cs
0|UhCȅa@1, 7XE7~*iY>o
ۮ4XBgCZHt>0m`KPD)G
o3PsPsRgS(6X
pus0,I0%\8q^(us"O *؀BvWvK&0xs`1 jTN'iNti=؁Ahv0FEwo<"2((u((fŔ5H?]ZHxTxs9`agw8qZIvs_)S(So60f`kEz/to'w>uaЁFD*2Mxz#5p馅{k0\8h{
xG0"()_X76@]|9|EH78|mO|Jt!Ax+0&@WʂN0.ЀF0(aP#8S}~OlsH>H}9Vx.c]Vs(d1g܀륧&uihkHs@dsB-j(ҤJ2m)Qp8pP D`Ήa%^8S9(^ # !
DSF
s?S@3ZbH+˜dN-s."xPqbE+9ǐ:ƻKn&\0ˤfe<}	;JjV^%+AT\ᄐZ8iqp,zsg'	jn;h
"z+]0,ZV!ûټW}p—hӪ-Sja708ig"qxYY1z^)Sh2Vt+r%;JaFmY2xy+Usіp
!
D
0%,lR`7q
-vK4D4(z:ܕӍ9w罟^F9R!A#n䭚t?MT$~~g\z^{*pBCķlTo.P}EXo(3Z
@&v`#P"`v_}c%&1tʱE2a3xBLsIR]S.xiҗ:*Psa*)Ѕ.llePXFp,aMlӎ؝(G*pb$	M4VDjeȀ
	nT\*.zp/.Р,'gKbM?5~
=\T"(tu"""hwI,ȨNќy1d
F*
^{>y  Y=OSNH9i`k GHivHlЂzj\8c $U̓t@H	xHPP6Uq,*00PSS6P`^@00ȴ
j]ذ$,Cj$+;`meY~e_c\`V.m۹|ʖP.5Cl.'k~IH{]ҴLm0@߼{-Lh~[f`j7?ʪ`
yt^/_y҆,@&Yw{1T'n((CfDǁGu\㆙cN>A
OEp㞫dRw(H@,/҄*x`G6XAoA	[l9hּOF0:L/ΙI@iL1Š2D	^
~6LlT_zҴ@iZiI&5LN*ݘ	SGs q3CQcY:0b_[Yv/=
/S9&0k3':pncHZN<Xw=]N(=d7[V͆mn8g	-@MpEcc 8;%>q~̀`ISdUA;H(0Ήc@ P@NvӼ<	BՑu6-SX.33WE@\.!
I-9Zv8ؓM x7(a}Q&ElnG!2Ld#pǘ 6
J|Jkkѐ
@W
Tyw7.U
B
8E3}{WZwb!'ܙgQ?=Ȝ\}1U(pW)XY^N1( 4`X@-!( 	;7ߊ9j-9`
'7`9j_tU94@Q܀9`
waBjȂ9Pax@mZ\} B1C*


aGX.b#!Nbx/ !f!m)d('@M;A$
&b &)@PC\bܙbx$^+6+f_,^4@":PHj#[u6#9
D9lU",&"p a&2cQ9&Wibw_;"1'\^.dC:x%Ehb#_*07tA"`!I"d^HB$B;;\(OL@(n`3h6>*B,\-BNV.C+d6ERv"5And(`@
P%\I(#]+K:B0A7n%]b*`U6RnT+;A/M~+d
f()@-0as@#Lh8/CAs@%jJ90r2S<@$&tu@eP3Bu$A%BT%
X@)ڧ4
L3$4bznԁ,PHX@&vlx@(銪$B|@X@Hd,Ee
n@9(2^ix<	'ȁr3B4B!؝ڢ@ѭ$qjԇHN*	Jt	c a,*pK	Dc9@@XjX++&.+6>+F+ċF
\*+ċ;eg+^29re9@##Z[@@9ZƼ֫P@99
@vP62
 \^@Z,
9ſZ++@짘PXlQV,H

9 ЀĢ
뽚
99nr";m9"-9`-n9-Vۮޖ븒PnTG+^9*.Vk~mQ!^0.Jv-^m­>ٞ
0ܺ
T+̬VG,
@Tkeb/Ilޡ.
Ph
ڞ#coroҚ-H9T,F0JEpŒG;a[N+	S+Pp-R,SC9To^9n
!.q;#Ҟc+ښPL{;0fm
̺	
pֺ020$+1#9@/-luX1ހnq$0Nq+q٪1
Op
9h.
`n
2²@V0
í;؞klo2n׎?s$c#ʬov//̎ku
)1*'v0/
9~9oAӲ2qⅷ
o"Brmn,.⦱7=:=gn?nE9
1wr=o벮r5z4^Ԯ$'YF2-S\To+&O5SOS-В&mպI+
fXkOl>T@˖cĢpφu++65ګ`P@[;b/7+&Mf

qgc;PKA5?0?PK+AOEBPS/img/strep040.gifGIF87aX?**?***UU?UUU????**?*******?*******U*U?*U*U*U**?*****?*****?*****?***UU?UUUU*U*?U*U*U*UUUU?UUUUUUUU?UUUUU?UUUUU?UUUUU?UUU?**?***UU?UUU?????**?***UU?UUU?????**?***UU?UUU?ժժ?ժժժ???**?***UU?UUU?????***UUU,X	H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜI͛8sɳϟ@
JѣH*]ʴӧPJJի( ?'p@$X	8 ?'P ,h „
2l!Ĉ'Rh"ƌ7rCǏ>}'p 8P @~,h}	(`>	̧O}ϟ?$XA	.dC%NXE5nѣDO>$O>}ǯ?'p "LP?Ǐ}O@Ǐ_?8`A&TaC!F8bE1fԸcGO>O>~,h „
2lП?O|ԧ~'p "Lp!ÆB(q"Ŋ/b̨q#ǎO>̧O?~O@
DPB
>,?~O|,h „
2l!Ĉ'Rh"ƌ7r}8P>~O@
DPB
>_?~O@}O@
DPB
>QD-^ĘQF
`>,h „
2l!ĈO|,h „
2l!Ĉ'Rh"ƌ7no|ӷ?9rȑAӗ/_|Ǒ#G9rȑ#G9O_|G9r8_?~˗O~9rȑ#G9rb}˧?9rȑ~˗O~9rȑ#G9r"?}׏#G9r}׏#G9rȑ#G9*/_>}qȑ#G'/_}8rȑ#G9rȑc}Ǒ#G9r/_|8rȑ#GqGq?o,h „
ܗ/_>~*̗/_>~	%ǐ!C2Lo_|8`A&TaC!F8bE1fԨ_|6n/_h0_C/a7>ܗOƍ7nܸqƍ7nL/'7_70|'_|˗|'_|˗?~_>}O |	ܗ/-˧oƍ7nܸqƍ7ܗoƊ?~۷O`|/?
̗O`|O`'0߾_>˷o_>۸Ѣ|'p "Lp!ÆB(q"Ŋ/b̨`}7ZO_|O`/@/|'}؏߾|	̗_?~	̧	̗oƋmܸqƍ7nܸqFmXџ70|70_>˗O|'0>~o|	̗_}	/_}˗Oƍ۸qƍ7nܸqƍӷq#E~O߾|'07P_>O~/_?߿|_o߿|o߿~	H*\_|8`A&TaC!F8bE1fh0|m8_|	ܗ/>˷O߿|˗o?G0_|
ԗo>/>}˗?}O_|ӗ/+˗/7nܸqƍ7nh0?qƍ7nذ_|qƍ7nܸqƍ
'_|mܸqƍ7"/_>}qƍ7nܸqƍ
G߾|qƍ7n|GP7nܸqƍ7nh0˗/߾~	H*\ȰÇ#JH}>~)RH"E)RH"E#߾|E)RH"Eӗ/_>})Ǐ"E)RH"E)RHb|ۗ/_|G"E)RHq?~˗O~H"E)RH"E)R1?O@}O@
DPB
>Q"BO}'p O@
DPB
>QD-^ĘQ|.O|ϟ?$XA	.dCo>
Ǐ?$XР@}8`A&TaC!F8bE1fh0O|Ǐ?	H*\ȰÇǏ>}	O?~8`A<0…:|1ĉ+Z1FmD?~'p>}?	4xaB6tp?ӧ`>ϟ?$X'p "Lp!ÆB(q"Ŋ/b̨`>!Ǐ>}80>}ϟ?$XA	.dС@O>}	O}<>~	H*\ȰÇ#JHŋ3j4ƌo>}	HP>}ϟ?8`A&T0?Ǐ>}'p A}ϟ?$XA	<0…:|1ĉ+Z1FmܘП?O>}	Hp @}'p~	H8P>O@ӷ?~O@
DPaB}8`A&TaC!F8bE1fh01_?
O@$XA	
'p @~ϟ?$XA	.d,h „
2l!Ĉ'Rh"ƌ
qF	H8`A&TaC9tСC:tСC:tСC:<ϟC:tСC:tС9tСC:tСC:tСC:<ϟC:tСC:tС9tСC:tСC:tСC:<ϟC:tСC:tС9tСC:tСC:tСC:<ϟC:tСC:tС9tСC:tСC:tСC:<ϟC:tСC:tСO@
DPB
>QD-^ĘQ|6nܸqƍ/qƍ7nܸqƍ
qƍ7nxQ7nܸqƍ7nh07nܸqƋmܸqƍ7nܸqFmܸqƍ7^oƍ7nܸqƍ7oƍ7nܸ>~7nܸqƍ7nܸ`>7nܸqƍ۸qƍ7nܸqƍ۸qƍ7nƍ7nܸqƍ7n4ƍ7nܸqE}6nܸqƍ7nܸq|6nܸqƍ/?	4xaB6tbD)VxcF۸qƍ7nƍ7nܸqƍ7n4|+O`&ȏ߿|A0|7noƍ7nܸqƍ7o"|+`>*Әo|
mܸQ7nܸqƍ7nh0/|O ߾|	Է/?'0A~/_>|/?}	'P?~|/_>ǯ '_|0߿ۗ_?}?	4xaB<0…:|1ĉ+Z1FI>~/߿}'0|>ϟ>o?o|O`_>ϟ>o߾	_/?~'0߿|۷|_>۸>~7nܸqƍ7nܸ`>O߿|70|	̗o`>#/|
o`>O`O`>
'0|O`_'0߿|'_	O>	H*\XP?$XA	.dC%NXE5O"|߿|/߿/߿Ǐ_/߿_߿|߿/߿맏|O߿|	_>80߿|70?
߾|8`A&Tp>~	H*\ȰÇ#JHŋ3j4_~o?_>O߾	'0߿|'0@}ӷ|	'0|/߿|O`>O`>}'0|'0?}_ӷ|6n|ƍ7nܸqƍ7n4_}O_>}ӗO>/?}O`ӧ߿|˗?}O`>O_}˧O|˧O?ϟ|߿|	_>ӗ/_?˧O?ϟ|/_~'p "Lp?}8`A&TaC!F8bE1fh07&Oྍ7nܘP7nܸqƍ7nh07&/_>7nܸ1>~7nܸqƍ7nܸ`>(`
,X`+`,X`'p "LpB}8`A&TaC!F8bE1fh0"kc$(1ƍ۸qƍ7nܸqƍۘ |	/GП|/_?'P?~O|ܗ/?'?~/_>#O_}_|ӗo@~'p_>~6nƍ7nܸqƍ7n4ϟ|O`_~}?}	|۷|o|۷_>~߾@_>~_~O`>O ?	4xaB<0…:|1ĉ+Z1FmO@_߿|o/߿_߿|߿߿|O ?'P`@~
7_>'߿|'p "LpB}8`A&TaC!F8bE1fh0
Ǐ_
`}'0߿~'0@
߿/߿߿
/(0|	O@>~߿_>$XA	.\,h „
2l!Ĉ'Rh"ƌ
1_|O> _>O>~ӷ|/|/>~ӷO`
߾'|ۗ?@~/ƍ۸qƍ7nܸqƍ0@	ԧ?}_7߿|O>}ϟ>ӗOO`	_>O~߿|/߿	/|OO ӧ?	4xaB<0…:|1ĉ+Z1Fmܸb>۸qcE}6nܸqƍ7nܸq|6n8_>}9̷qƊmܸqƍ7nܸqFmܸqƍ7^oƍ7nܸqƍ7o#?~
m$Oa7n(Q7nܸqƍ7nh060|7nܸ>~7nܸqƍ7nܸ`>o_|o ?ϟ|˧|	Է/|O?~O}mܸF>~	H*\ȰÇ#JHŋ3j4|o|߿|o߿|O`>~	'0?}	'0߾}߿|7nܸ>~7nܸqƍ7nܸ`>70|	'0?}
G_>O`	'0_oƍ7oƍ7nܸqƍ7oc`>o_>~맏|	'0|O`>
'0|7nܸ>~7nܸqƍ7nܸ`>8`Aӷ|'0|
/߿|'0|	̗?O߾	'0,h „
2l!DE1bĈ#F1bĈ#F1b|"*ϟ|	W0|/_~/>}O`>~˗O>~ϟ|	'0_Ĉ#F1A}"F1bĈ#F1bĈ#F1b>#F1bĈ#F1?}"F1bĈ#F1bĈ#F1b>#F1bĈ#F1?}"F1bĈ#F1bĈ#F1b>#F1bĈ#F1?}"F1bĈ#F1bĈ#F1"@'p !B"̇!?~ˇ|!!B"D!B'p "Lp!ÆB(q"Ŋ/b̨`>˷o|='0|-̷qmܸqƍ7nܸqFm_>'P?~'P|˗}/_~߿}o_>~o_|o|㗯?~+/_~O|	/?˷qmܸqƍ7nܸqFİ_>~۷}?}۷_|O`>o|@>
O`~'	o߾۷|߾}O@
DPBkذaÆ
6lذaÆ
6lذaÆ
6lذ|6߿~
_o`70A/|	W0߿|	g0|'A_'߿|5lذaÆkذaÆ
6lذaÆ
6lذaÆ
6lذ|60@	o`O`/߿|맏|	̗o`>(0߿|	7p`>'pǏ__7P|<0…	װaÆ
6lذaÆ
6lذaÆ
6lذaC5l/@}߾_>/_|/|_>+}`>O ?/?}O߾O ?aÆ
6$_Æ
6lذaÆ
6lذaÆ
6lذaÆ

װ>~#O_}/_~˷|O_}˗O>~ϟ|	'0_|/_'p`>~	O_|/>}˧O?ϟ|/>}	H*\Ȑ>~
6lذaÆ
6lذaÆ
6lذaÆ
64_Æ5O?5lذaÆ
6lذaC5lذaÆ
6lذaÆ
6lذaÆ
6l`>
._>aÆ
6lذaÆ

ǯaÆ
6lذaÆ
6lذaÆ
6lذaÆkؐ`5|
	kذaÆ
6lР>~
6lذaÆ
6lذaÆ
6lذaÆ
64_Æ5p`	!̇0_Æ
6lذaÆkذaÆ
5PC
5PC
5PC
5PC
5PC
5d@'p 
/@~O_|?}/_~}o_>~O |ӗO?~o_}?}/_>	H*\ȰÅ=|Ç>|Ç>|Çp}/@~o߿|_	'0|o߿|#o?~'0|O`>~O`㷏_>>|Ç{Ç>|Ç>|Ç2|O O`#/|70߿|70A#/|
}'Ç>|p>~>|Ç>|Ç=C=C,o`	_}_>~߿|/߿|߿|>~_?}/߿Ǐ_o@	H*\ȰC=|Ç>|Ç>|Çp}@~
/|	/	'0?}/|/߿|'0߿|'0_O ?>|C=|Ç>|Ç>|Çp?}O_|˗/_/|˧Oϟ|'0A_||O_|˗O>~ϟ>O@
DPB
.Ç>|Ç>|Ç>|0>|Ç>|C}>|Ç>|Ç>|Ç{Ç>|Ç:Ç>|Ç>|Ç>|0>|Ç>|C}>|Ç>|Ç>|Ç{Ç>|Ç:Ç>|Ç>|Ç>|0>|Ç>|C}>|Ç>|Ç>|衇z!O@
DPB
>QDgѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-Z",", O@
DPB
>QDgѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-Z",", O@
DPB
>QDgѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-ZX0?-ZhѢE'gѢE-ZhѢE-O@	/A$H 'p "Lp!ÆB(q"Ŋ񓘯|-gѢE-ZhѢE(H0?-ZhѢE'_}̷0E-ZhѢE-3o?/_>?}/?}hѢE-Zhq>~7p_>~/@~/|-ZhѢE-Z>}	/_>YhѢE-Z8Q?߾}o?~'߿}gѢE-ZhѢE	?O>߿|_O@O@
DPB
>QDq70߿|O hѢE-ZhѢ|_}	'0߿|70|,ZhѢE-ZD
߿_߿|	H*\ȰÇ#JHŅO`>~	'0߿|_|xŋ/^x1>~}o?'?}wŋ/^xŅ	?~~/߿|O_}8|8`A&TaC!F8bE=o`?}ӧ?}O_|ӗO>-ZhѢE-ZП?gѢE-ZhD},ZhѢE-ZhѢE
˗|,ZhѢE-ZE-ZhѢE-Z/_|gѢE-ZhD}拘ϢE-ZhѢECa>hѢE-Zhq>~!̇0E-ZhѢE-.ܗ_>O_>}O`}	/_|O'p "Lp!ÆB(q"ŊK/||˗|/_~˗?~hѢE-Zh"}ϟ>O|o?}}	0?-ZhѢE'p߾O`>'0|O|o|YhѢE-Zha'0Ao|'0?gѢE-ZhD}|O`O>ϢE-ZdEYdC_߿|/߿>~o_>~	?<0…:|1ĉ+"aǏ_>Ǐ_>맏|`>'p "Lp!ÆB(q"Ŋ/߿|'0߿|'0_O ?hѢE-Zhq>~/߿|'0߿|'0_O ?-ZhѢE-Z\O_>}˗O>~/>}˗o?~_|ӗ/YhѢE-Z8Q?ӧ|/?~|/>}˗?}hѢE-ZhѢEhѢE-ZdE,h „
2l!Ĉ'Rh"ƌ
qƍ7nxQ7nܸqƍ7nh07nܸqƋmܸqƍ7nܸa>;ȏ|6nܸqƍ/1߿|!oƍ7nܸqƂ;/c>7nܸqƍ/a>6nܸqƍ7n4O '0?˧߾|	Ǐ|6nܸqƍ/1?~O`ԗO߿}7nܸqƍ	/`'p 'p "Lp!ÆB(q"Ŋ_'0?}۷}hѢE-ZhѢŁO`>+_惘ϟE-ZhѢE_O?_>-ZhѢE-Z$O`O`>YhѢE-Z8Q?O`>3_hѢE-ZhѢEO`>G0?}'0|,ZhѢE-Z|'0|+}/,h „
2l!Ĉ'Rha>O`>O_|惘ŋ/^xŋ	_O`ӗ/_.^xŋ/^x|.^xŋ/^Lŋ/^xŋ/^xa>/^xŋ/&ŋ/^xŋ/^0/^xŋwŋ/^xŋ-S|.^xŋ/^LE
[ŋ/^xŋH0/^xŋw`xE]tE]tB˗?~?/ۗ߿<0…:|1ĉ+"O"|	ܗ_>'_|/E-ZhѢE+'@}	/'0߿|o߿~gѢE-ZhD}"'0߿}o߾O ϢE-ZhѢEO|oO`kϟE-ZhѢE/߿|70߿|o`>-ZhѢE-VO@___?	?	4xaB6tbD)VD_~/|
`>_>$XA	.dC%NXѢB}O_|70߿|'0?}0/^xŋ1ӷ|/?}o?.^xŋ/^П|_?}/_~_>ӗo_]xŋ/^Pӧ?}O_>}ӗ/ӧŋ/^xŋ#'p_|.^xŋ/^Lŋ/^xŋ/^_|5/^xń?	4xaB6tbD)VxcƈQF5jԨ>~'ӨQF5jԨQ|ӨQF5jXP?iԨQF5jO_}/_>˷O |	ܗ>O_>}ۗ/?70?5jԨQFO_}o_|ӗo?~/?}|/_>OF5jԨQ#|/}'0_'0߿}ϟ>o߾	߿|?	4xaB6tbD)VD|/O`~'0߿}ϟ>߾}߿|-ZhѢE-Z70߿|
'0|o`>	'0_o`>-ZhѢE-No`o`>/߿|O`>O`>,ZhѢE-Zo`O`/߿|맏|	̗o`>ϟE-ZhѢEo`O`0߿|>~߿|/߿<0…:|1ĉ+.}ӷ|o_>߿~_>ӷ|	70?-ZhѢE'70'P߾	|O|	O߾	'0E-ZhѢE˷O`O`>}/>}˷/?~_>~ӗ/_?ϟE-ZhѢEO_}	/_~˷_|/߾|˧O?}/߿8`A&TaC!F8bŅSϟ}	gѢE-ZhD}{/?YhѢE-ZhѢ|)/_>	gѢE-ZhD}{/a|hѢE-ZhѢEgѢE-ZhD},ZhѢE-ZhѢEgѢE-ZhD},ZhѢE-ZhѢEgѢE-ZhD},ZhѢE-ZhѢE	ϢE-ZhѢʼnhѢE-ZhѢE-Z/_>	H*\ȰÇ#JH"B}hѢE-ZhѢE-Zԗ/_>-ZhѢE-Nԗ/_>}-ZhѢE-ZhѢE˗ϟE-ZhѢE˗/>-ZhѢE-ZhѢD}ϟE-ZhѢE/_>}-ZhѢE-ZhѢE_>-ZhѢE-N|hѢE-ZhѢE-:ԗ/_~hѢE-Zhq>~˗OE-ZhѢE-Zh|ϟEYdEYdE߿˗O,h „
2l!Ĉ'Rh"ƌ˗|4jԨQF5Ǐ|ӨQF5jԨQFׯ`>5jԨQFW_|iԨQF5jԨQ#F}g0?5jԨQF3/_|4jԨQF5jԨѢ|;ϟF5jԨQƂ/_>}5jԨQF5jHQ_|!OF5jԨQcA}˗/>5jԨQF5j/_|QF5jԨ>~	˗OF5jԨQFiD˗/_?$,h „
2l!Ĉ'RP?˧ϢE-ZhѢE-Z/_|gѢE-ZhD}˗/>-ZhѢE-Zh|cϟE-ZhѢEc/_|,ZhѢE-ZhѢEׯa>-ZhѢE-Nǯ|hѢE-ZhѢE˗/_?YhѢE-Z8Q?˧ϢE-ZhѢE-ZT/_|gѢE-ZhD}˗/>-ZhѢE-Zh!@?	,h „
2l!Ĉ'RP?˧ϢE-ZhѢE-Z4/_|"gѢE-ZhD}"˗/>-ZhѢE-Zh|ϟE-ZhѢE/_|,ZhѢE-ZhѢEob}-ZhѢE-No|hѢE-ZhѢE˗}YhѢE-ZQ_˧ϢE-ZhѢE-Rԗ/_~gѢE-ZhѢC/_|,ZhѢE-Zh"CO@}7p/_~	H*\ȰÇ#JH}8_|WbŊ+VXbŊ%7P_|U,O_|*VXbŊ+VO_|*/_>}XbŊ+VXbŊO_|UDo_|UXbŊ+V߾|_|ۗ/_+VXbŊ+V|O@
DPB
>QD-^l`>'p "o_|<0…:|1ĉۗ/_>}Q`>'p "Lp!ÆB(q"Ŋ/6O@}	H/_|<0…:|1ĉ/_|HQ><0…:|1ĉ+Z|<~˗/>~'p "Lp!ÆB(?~˗/>~&N<`>O@
DPB
>QD-^\`>O@
Dp?~'P>~'p "Lp!ÆB_?~˗/}Ip|
<0…:|1ĉ+Z`><0aBO@}?	4xaB6tbO|ǯ?$XA	08`A&TaC!F8bEO}8`A&T_?~'p>}?	4xaB6t?ӧ`>,h „
0@8`A&TaC!F8bE˗o_?1}8P>},h „
2l0?O>̧O?~'p "Lp!~ǐ!C2dȐ!C2dȐ!C2LC2d?ӧ`>ӧo?~?	4xaB"ϟ?~ӧO|ԧo?~'p "Lp!C'p "Lp!ÆB(q"Ŋ/b̨qcAO>}	HP>}O@< @	0ӧO?~<0…:|1ĉ+Z1ƍ8?$X@$<0BǏ?~ӧ`>	4h>	
O@
O@
ϟ?$XA	.П'p O@	H*\ȰÇ#JHŅ@	0<0	?~,h „
'p~	H}
П8`A&TП?Ǐ>
O@
DP@O@O@
DPB
>QDǏ}O@(p@~O	HA	H ?'P |O>~,h „
2l!ĈǏ?}'p 	8 ,h @(`>	
ԧO>~?	4xaB6tbD׏?}'p@}Ǐ_?'p "Lp!Á׏?~0Ǐ?	H*\ȰÇ
o>}	8P>}ϟ?8`A&T@Ǐ>}'p@}ϟ?$XA	.dC%6}'p`>}ϟ?$XA	.dСAO>}	O}O@
DPB
*׏?}80>}ϟ?$XA	.dСAO>o?~'p "Lp!ÆB?~'p>}?	4xaB6t?ۧ`>ǯ?$XA	.d~O|ϟ?$XA	.dÆO>ԧ?	H*\ȰÇ#׏>}	O?~'p "Lp!ÆB?~'P}O@
DPBۧ`>,h „
2l!DO|Ǐ?$XA	.dC`>,h „
2l!Ĉ`>?	4xaBO|ϟ?$XA	.dCo>
ǯ?$XA	.dÅ˗/_>}"D!BbAO}'p "LP?~(P~8`A&TaC!F}˗O~'N8q"B˗/>~M8qĉ'N(}˧o_'/_|7qĉ'N8q@˗/_>}M8qĉ˗O߾~&N8qĉ'Nd߾|oą˗/>~&N8qĉ'Nd?}oĉ'6/_|M8qĉ'N8Q?~˷ĉ˗/>~&N8qĉ'N(߾|7qĉۗ/>~&N8qĉ'h/_|8`A/_}8`A&TaC!F8bB~ׯbŊ˗/+VXbŊۗ/߾˷_Ŋ+VXbŊ˗_Ŋ+*ԗ/_(Gp$HP`|#H@$Hp?$HP`|#H?'p "L |-\_|.\Р|3oao@-o`˗B	-\p‚o….\P|-\a|[0_[80ƒ*̗|Co…&ܗo…۷p…`>+/?-o|_>~%̷p…˗….\p|-\0a|/_˗o|'0|	O|O}/_}˗ϟ˗߿O_|/_}/_~/߿/_~_|/˗߿߾|'p "O|/_>~/_|o_|˗o?}O`>~/_~>'0|̗O`>}|/_?'_|˗o}K0aƒ%L0a„	&~?	/?_}߿|߿|o߾/߿	O_߿|ϟ|/?$XAK0a>}	&L|/ۗ?}/}ӗ`|ۗϟ|/߾?~/|㗏߿}_	̗	7P?/߾'0?_>~	&Lx0	&L0a„K0aB/?߿|	70|̗O`|/߿|O`>؏߾|	/_`|؏߾|	o|/_ۗ߿|O߿'p "}	70|o_>/|
W0_>o_>/|׏߾|_>}K0aƒ%L0a„	&4/߾	&70|̗O`>}O`>'0|/~˷/>'p "˷_>˷/|O@
Dh_}	&L0a„	
˗o_„	̗>}	>O`o_>㗯?}o|O`/|ۗ߿}`|'0߿~_|o|o|_„	/_	˗/	&LX_~ۗ߿}߾|	o_>+/?~'P_?~/|
/߿~߾|/|/_߿|_o߿|o߿~	H˗_„	&L0aB˗_„	O@}뗯߿|ϟ|/߿O|70?}/|_ۧ?}o@}߿|70˷O߿ӗo?}O@}?	4xa}˗0!B˷/a„	o|˷O@}O_|˗o?}O_|ӗ߿|
O_}_>_
˗/?'P_>ۧO>}/>}˗O?0a„O	&L0a„O_|&L0a„	/_„	&L0a„	&L0aA_	'_|'p "Lp!ÆB(q"ň>~+V8˷_Ŋ˗O+VX"|/_ł/_>~*VXbŊ+V\o_|
ǯbŊg_|WbŊ+VX"~˷_A*`}ׯbŊ+VXbE˗/?XbŁ!O_|WbŊ+VX1?~˷B*/a}_Ŋ+VXbň/>~WbŊco_|ǯ,h „
2l!Ĉ'o|o|
?}ӷ?)RH"Eӗ/_|1Ǐ"E?}˧_?)RH"E
O_||
}˧o?)RH"E
O_|>~)Rx>ӗ/_|"E)RHѡ?~'P>~8`4hР@48}	?8`A&TaC!F(_?~˗/}Mĉ'.oAO@}<0…:|1Aӧ`>?	4H_`>,h „
2l!ĈO|ǯ,h>~~O@
DPB
>hП?~O@}<8_>
!BO|Ǐ?	H*\ȰÇ
׏>}	O?~8`A	!B"DA~"D~0ǯ?	H*\ȰÇǏ?}80>}}	O}?	4xaB6t?ۧ`>ǯ?$XAK0a„	&Lh	&L(П?~0Ǐ?~O@
DPB
	?~0ǯ?	HOB)TPAO|ԧo?~?	4xaB6$ϟ?~ӧO|
ԧo?~'p "L(P?
*TPƒ)TPƒǏ>}	H0>}Ǐ~	<0B	@0ӧ?~O@
DP?.$/….ϟ?~ӧ`>	ӧO>
O@$XA	
O~O>}8`>}ϟ?$XA	
o….\.\p?Ǐ>}'p 8}	H`A$`>	P@ϟ?$XA	./CcȐ!C
Ǐ?~ӧ`>	P'p 'p A}	H@}Ǐ~O@
DP1dȐ!Cǐ!C2П8@},0@	H }	ȯ@'p "Lp!C5l/_Æ
6l?8>$H`>8`	(?8`A&T!B}6lذaÄ5lذaÆ
6lذaÆ
6lX_
kذaÆ
6lذaÆ
6lР>~
6lذaB~6lذaÆ
6lذaÆ
6,/_Æ5lذaÆ
6lذaÆ
6lhP
6l0!?}
6lذaÆ
6lذaÆ
aC6lذaÆ
6lذaÆ
64_Æ
6l
6lذaÆ
6lذaÆ
װ|
6lذaÆ
6lذaÆ
ǯaÆ
6LO_Æ
6lذaÆ
jj?	4X_>$XA	.dC%NX1>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢE&_>$X`A8`A&TaC!F8bńYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE- 8`AO@
DPB
>QDgѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊIo`>W0|QW,ga>,ZT/EY|	G0|"|1̷0EgѢŊI̗o`3`>,W1E,Z\ϢEY$/3`>,泘"|[ϢEhbE~$Ǐ߿˗o|	ܗ_>}o_>~O`߾|	Է/߾|	'0@}/_߾|	Է/_|˷O|	'P?~'p_>~8`A&L/BSp`>/}O_>}	ܗ/'_|+/_>O}ӗO?~O`>|ӗO?~O}O߾|˗߿|	'p_>~˗?/B
*THP?
*TPƒ)D_>߾߾}o?~O`O`>~O`>_}'0o߾	'0|߿|/߾}/(0	o߿~O`>'߿}<0aB*4/B߿}o߾	/|o߿|O||O`>~	'0߾}O`>O`>۷}`߾'0|/?~?~*TPB)TPB
O!|/|O߿|70|	/|	G_>/|	'0|O`>
'0|O`?~߿|/߿?	4xa„)Th_>
o`>_|7_O`>
'0|O`>
'0|'0߿|'0|
/?OB
*DB
*TPA~"'P_|+0@/߿|_/߿߿|/߿߿/߿_/߿_/߿߿|/0_߿|
߿8`A&L/BSP |߿|/߿/߿|/߿Ǐ__߿|/߿߿|/߿맏|O߿|	_>(0|70?
߾|8`A&TP.\pB~'_|`|ӷ|/|	O߾	'0߿|'0@}ӷ|	'0|O`	'0	'0}O`'}_|	O?_.T/…[__O`o?_>}_>O`>}'0߿~?O߾/߿(0߿|ӷO`/?}O??	4xaB[p…*o|/_~O?}O_>}߿|˗|/>}O_|˗|	'0?}/>}	/>}/?}O`ӗ/?'p_>}?}O_>}.\P|o}O_>}ӗO>/?/|˧Oӗ/_?'0|	O_}˧O|P>~ϟ|߿|	_>ӗ/_˧O?ϟ|/_~'p "L0>~.\pB-\p….4ϟ}.\h0….\|o….\?-\p….\pB}.\p…
[p….\h_|-\p|.\p-\H_.\p‚o….\p…p….TO….\p….\p….D/…[p….\p….\p…	[p…*o….\p….\p…"|	H_A~97P_?"F1bĈ
1bĈ1bĈ#F1bĈ#/bB":/|O?~د_|
Է/	/@˗?}/_'0|O`>˗_Ĉ#F(P#F(#F1bĈ#F|`>}_o?߾7_	'0?o߾	'0?~O`>~O@
DPB
СCϡC:tСC:t?2ϡC`?~/?׏>~O`>/||
'0|O`>ϡC:thP?:tp ?}:tСC:tСC琡|
O@
o|
o|'P>?Ǐ_맏|߿_߿'p "Lp!ÆsСCСC:tСC:t|~G
7
o>~	'_>~
_>_>#o߿~/?}/߿~ϟC:t谠>~:t@~:tСC:tСC!C:~
˗/>˗/>7ϟ|'_||7П|	ܗOO|/_>~	H*\ȰaC}:tСÁ9tСC:tСC:/C9tСC9tH0C:tС9tСCsСC:tСC:t_>sСC!|:tСCСCϡC:tСC:t?2ϡC:oa>˗}|С|:tp>~:t@~:tСC:tСC!C:a>sX0_?/_O@+ϠA
gРA
4hРAO@
DPB	kذaÆ
6lذaÆ
6lذ|
װ!|?}/'P߾|˧@~/˗ϟ@}+o`~O`>~O_|˗?}
ԗO߿}'_|˗߿|kذaÆkذaÆ
װaÆ
6lذaÆ
6lذaA6a|	_O`	'0?}	'0߾}߿|߿'p|o`>/@~߾}@~O|/߿|O@
DPB1dȐ!Cǐ!C2dȐ!C2dȐ!Å1d(_>
O`#|	'0߿|O`|	'0~/|o}'|70|ȏ|
/|2dP>~2dȐ!Á1dȐ!C2dȐ!C2dp|
!CO`}	>~	'0|맏|	̗o`>#@#O`>#o_>~(߿|	_`>Ǐ_(0|	H*\HP?2dȐ@~2dȐ!C2dȐ!C2d_>ǐ|	||	'0߿|/|_>#O~'>˗o '
o?#@~/?}O`>2dP?2dȐ@~2dȐ!C2dȐ!C2d_>ǐ|	_|	Ǐ_|O`>/_>}_>'0@(_|
/߾7_|/_>~/?'0|O_|?	4xaB	ǐ!C2OC2dȐ!C2dȐ!Cǐ@2dȐ!C2dȐ!C2dP?2dȐ@~2dȐ!C2dȐ!C2d_>ǐ!C2dȐ!C2dȐ!C1dȐ!Cǐ!C2dȐ!C2dȐ!Å1d(_>2dȐ!C2dȐ!C2o|3_>c0CcȐ!C2dȐ!C2dȐB2/C1\oa2dȐ!b!b?	/_`,`?	4xaB6tbD)VD/EYt|MgѢE->oa>}
ܗ/|/?}>'0|	/_?,ϢE-ZhѢʼnY$/ŃO`>~	/_?/?Wp_|ۗo@~O |ӗOE-ZP?ۗO|o_>~O`߾}/@}"A~,ZhѢE-Z/EY~
/_
/_o`
/|ۗO`	1bĈ#F1bĈ1|`>'0߿|o`>o`_1bĈ#F\B
O߿|߿	_߿|/,h ?}	H*\ȰÇ#JH"B,"~O`O`	/߿_/߿8_><0…:|q>~	'_/߿}ۗ_>/70|/bB~"F1bĈ#F1bEL/_DO`O`	O߾Է|o߿|	O>1b#F\_B~|/_}/˗O/>}ELO_Ĉ#F1bĈ#F_	_|	'0?~_?}O?'P_|/_>~˗|8`A&TaC!*/bĈ#
/bĈ#F1bĈ#F/_ĄE1|#F1bĈ1bĈ1bĈ#F1bĈ#/bB"F|"F1bĈ#"/bĈ#
/bĈ#F1bĈ#F/_ĄE1bĈ#F1bĈS/_|ϡ"B/bĈ#F1bĈ#F/_ĄE|_Ć"Fȏ_|#F1_ĈS/?9_1bĈ#F1bĈ# 8`A;x;xA~;x ?}	H*\ȰÇ#JH"B,b|Է/?'P|ӗo|>}	Ǐ߾|	/?ϟ|ӗ//_>7P_>}O |
/_>O`>Ǐ_|˗}/_~_|ۗo@~O_|˗C}'0_߿|/|/?}o`o߿|G>-ZhѢEM|	H~
O`>_~_}#?}o?_	/>>'0_'|o߾	'0|/?~o?~'0|O`>~O`㷏_>	̗_>}O?
'0|ۗO`70߿|$XA	.dC%NX|	g>~O`>	70߿|'0߿}_o	O>g0߿|	g0|O o`>_'|O`>	70@O`>~=Oa|O_|/_}
'0|O`70߿|QϢE-ZhѢʼnY$/E	߿|_?}/߿߿|_>
70߿|
/@	_}//߿?	'0?
߿"~߿_@	߿|>~_?}/߿Ǐ_o@	H>~_~}o`>_|
o_>~o`?	4xaB6tbD)VD/EY?~߾ǯ`>}o|
G0?}'0|	O?	70?}'0߿~o|ϟ@}/	/	}ϟC}˗/??}O_>	70?}/˗OOE-ZhѢEH 8`A7>/_>}˧/>'0|
ӗo|˗?ϟ|/_~׏`O`>'0?7_|/_~ӧO`?}O_>}˗O>~/>}˗o?~_|ӗ/?C!B"D ?}	H*\ȰÇ#JH"B,ϢE
C/|-ZhѢEYh"?}-ZhѢE-N"A,ZD`3ϢE-ZP?-VϢE-ZhѢʼnY$/E	?#H A	ǏA	#H A	<0…:,|_|>|Ç>|С|a!`>C>|ÇS/?!̗0ÇÇ>|Ç>t/Å=|`>|/_>|˗@}ۗ/?/'_|
˗@}O_}'0_A}'_|˗?ϟ|=|!A}߿|/__|/?~o_|/>$X A~8`A&TaC!F8bEY$/|
O`>O ?|	/o߾	Ǐ`>_>'0|/_o߿~
O|߾_>߾ϢE)̗O`|O`'0߾_>˷o_>ϟ|,
ϢE-ZhѢʼnY$/E	߿|O }߿O>	_(0|O '0|
/߿|(0|_}?	4xaBS/|/|ۗO`>o_>/>˧ӷp….\p….\p…˷p!A.Do ?}	'`>_}(߿|ۗ߿߿@|_?}/߿߿|//|7|o_>~ۗ,h „
0_>	̷_>/|o|˗o_>}߾|-\(.\p….\p….\_	˷p!|_|'@~o`>_>
O`	o`>?~߾`>'P߾ӷO`>}o`[p…	S/?~	_>/|/߿~'0_>}O@
?	4xaB6tbD)VD/EYD`>'0?}#/_|ӗ/?˗/_?ӗ/_?
/|˗A~_>}	̧/>g0|O_|ӗ/_?_|/_~-ROa|/>}O_}ӗ/|/_>~˗O?hѢE-Zhq|	gѢE+|YhB},ZX>-Zh",h"O@
?	4xaB6t0_|w0Ç>|P>|Ȑ>|Ç>|C.Ç>|Ç>|P>|Ȑ>|Ç>|C.Ç>|Ç>|P>|Ȑ>|Ç>|C.Ç>|Ç>|P>|Ȑ>|Ç>|C.Ç>|Ç>|P>|Ȑ>|Ç>|C.0,h „
2l!Ĉ'RP?-VϢE-ZhѢʼnY$/E-ZhѢEhbE~,ZhѢE-Z/EYhѢE-ZHQ?-VϢE-ZhѢʼnY$/E-ZhѢEhbE~,ZhѢE-Z/EYhѢE-ZHQ?-VϢE-ZhѢʼnY$/E-ZhѢEhbE~,ZhѢE-Z/EYhѢE-ZHQ?-VϢE-ZhѢE/,h|	H*\ȰÇ#JHbB},ZX>-ZhѢE'g|-ZhѢE-REhѢE-Zhq|	gѢE-Zh"E},ZX>-ZhѢE'g|-ZhѢE-Ro|囨/EYhѢE-Z8_>hѢE-Zh>~囸/},*ϢE-ZhѢʼnY$/E-ZhѢEhbE~,ZhѢE-Z/EYhѢE-ZHQ?$XA	.d
6lذaÆ
6lذaÆ
װ|
6lذaÆ
6lذaÆ
ǯaÆ
6LO_Æ
6lذaÆ
6lذaÆk_
6lذaÆ
6lذaÆ

װaÆ
&䧯aÆ
6lذaÆ
6lذaÂ5l/_Æ
6lذaÆ
6lذaÆkذaÆ
װaÆ
6lذaÆ
6lذaA6aÆ
6lذaÆ
6lذaC5lذaÆ	kذaÆ
6lذaÆ
6lذ @8`AO@
DPB
>QDgѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhEH_>-ZhѢE)gѢŊYhѢE-Zh"O@
?	4xaB6tbD)VLE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhѢ?	4X_>$XA	.dC%NX1>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢE&_>$X`A8`A&TaC!F8bńYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,E-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE- 8`AO@
DPB
>QDgѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Zh"O@
?	4xaB6tbD)VLE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhD,ϢE-ZhѢEYh"?}-ZhѢE-N"A,ZhѢE-ZE+gѢE-ZhѢ?	4X_>$XA	.dC%NX1>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢEH_>-ZhѢE)gѢŊYhѢE-Z8_>hѢE-Zh>~-ZOE-ZhѢE&_>$X`A'p "Lp!ÆB(q"ŊhbE~,ZhѢE-ZOłYhѢE-Z(_>-Z/?-ZhѢE!bA~YhѢE-Z_>}-Z_|,ZhѢE-ZlO_~˷E-ZhѢEhѢEgѢE-ZhbBg1a|YhѢE-Z_|,ZhѠ?}gѢE-Zh"A~g!|hѢE-Zh`}hѢE˗?-ZdEYdD/_}8`A/_}8`A&TaC!F8"~ǯbŊ'ۗ/_>}UXbŊ+Vo_|Xq |ׯb+VXbE˗o+V8?}_Ŋ+VXbE˗/_}*VLo_|bŊ+VX"~˗O?+VXQa?~˗o?+VXbŊO_|W"D˗/>~UXbŊ+V}˧_+V(}	?	H*\ȰÇ#JD?}	?$XA	.׏|ӷ?2dȐ!C2dȐB˗/_>}cȐ!C2dȐ~'P}O@
DPB
>?O@}O@
DP…0@<0…:|1bC0@<0…:|?~O@}?	4xaB6tbCۧ`>,h „
2L}8P>~'p "Lp!ÆBt?~'P}O@
DPB
>q?~O@},h „
2lBۧO|Ǐ_?	H*\ȰBӧ`>ǯ?	H*\ȰÇ
Ǐ>}	O>~'p "Lp!ÆBџ?~0Ǐ~'p "Lp!?~O|ϟ?$XA	.d!Cӧ`>ӷ?~O@
DPB

?~O@,h „
2l!Ĉ!׏}'p A}Ǐ_?O@
DP„׏?~0Ǐ_?8`A&TaCǏ?}'p@}Ǐ?
O@
DP„Ǐ?~0Ǐ?8`A&TaC!F8Q?O>}	Hp @}O@	H'p@O@ӧ?~<0…:|1"AǏ>}8 AO@8`A'p}	0ӧo?~<0…:|1ĉ+
ϟ~	P	HO@
ϟ?	H*\ȰÇ#Jϟ?	>8`A&,P(?8`A&TaC!F8bE8`A	'p "Lp!ÆB(q"Ŋ8`A	'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?)r$ɒ&OLr%˖._Œ)s&͚6o̩s'Ϟ>
*t(ѢF"Mt)NJ;;PK0,"PK+AOEBPS/img/strep043.gifpGIF89a:???///ooo___OOO@@@ࠠ   ```000pppPPP!,:'dihlA0Ett=x|p.H'ШtJZجv=(5#	z
`|N|r51]]/48Chknp&qxj	gC840P/48AoYo}@84M0?jo܌ojf>0*`?moox{<AEݠƣҽ]JmؿP-ȱcwn&@/( JAHHIٻn( [͟r@f]hvh @DX9~`d9JmVۻ"DM[_ݑ!ªK'ty Đ:H@.C9B 5̠' !OlOB4M1:"QwA-~66AQX5@b$(=?I8ia1'Ên Yux&|t`$EzA!gBz9K
xp}$
F8@1x8~`O}0
 gYAt
@Ycۈ"32k	(`0(8Ƞ)=@q	ݐyYN 
89" ?~0g4`i6x`T!f:
,ʷ)Z\s}
6æ
%[cs&ʠUy:eC^+isFw C'".
 hgTe[iq@Y,Pt*hwDoTG(dcfۘy"Y	A0$kM[^c˕[)'c6'vnXIqYaq+7_#	r'_i}IG|%,,ϐ.-cK]I!.6SKbzD֗y9RN8۟k峙P.]Mv)>W1xVζ֢{[s*ͯkB~A;0Idp҄5_Ɖ5*3ZR:dTycP8VfNf0yJ\<"f`2@SbEta`Q{odG/`e✋<ݏ~3,8bBEKAr92	[3IrSᐽ̉:GԋĩH{P/]M"BЩF֐"`dD@NNu,AHTt5bPhU3fD5)@*$u
(%GFh`cyWN9 Ds
 !3j8zff4Os~ngP,(Y಩Z% DqC KFGZ&AH\R4khPڔ.MApP%~?-hָR%5-QR64aܰh	{*ԫ\Iĝ*E+MVajYJ^b%=zTkUCհ%̫!ŎDT[W!ko+["B<)"4!fP&Z%A↸2ⴵU_5l'>[	[!5r{P̾npQ0nx"(FY65	ذ3gu%HQ0԰!AFap+kV
QC/GkwqH8
)zpͺFυ.(Sx伱V
ϸ5s,4ȵ}$YLn2g(KٰT,,v\Q0'u̜-mfȪy$maʙt<뙞w\@u?`hYgSsR T2>Ga9Q (h:4*>Q{IN-8mrGAͬ<:3N*yԠ
;2k?3AɑYcдZ.`JfDX2x-7D:wF
PVr.$$p|b;i%	B*9 %7]1Y-j`ylp'Rk䚋Y{]͖T |ؿ)ZZLMd>&e@XӤQ"5m i*SDkS'h;dWzx#d.㈇,VgU~SkH*:>ήԳ{S}93*GJA-׈9ttU%t2IDdjF߰W "i jx?,.rxU?,S9ow_g?<iP*3+B(np17RjF#Ǵ+u5wI}56B7kW&
P)ׁGFb2.T('%ׂQK{+X
L@b?#2能PjYB53j4рUf.J($a\()"w5"4 {w])BJeB
srM	rkS?"T%x \8qH)a$̔˔'yIRL
j6hX1Ty7P(Qؒl,ЉP6-PEO`ƆZBHpk`bb%Eu D#&p#qC*+mר(D
HHo振@%mZPj$4x(ȇ
4x,k&~!q!A##E.n)(E$5"=U(noG&wHP`mH6pǐKIЖ
tl&.i@O+%`/; >&n(A	4#AA')0s3rB#Ryqe30>=AA&5T>Aq×wzw2YISjð7+-("tijqy(lxW
.o˱vgzd$ȨGj"e)Ŗ-we$,g?/SP{{;C|)|,X]B p]2{1SIlz#,'F4Wp }Eb	&< zA6stH)C{R3\v1$H(hg$tw5y8s*x5i}x5ZDŽNGtƞ`ryuX`΃DIHKe7p!*b%BQ)wB(Z	0Jb<`pu:f?5X/*,H	ts>	*YeڟO|)s(}#pY9P;Rn(
J_63bz%aHn)T:z7'?44#F
z&Iې*W.
pRjMj!agx%9"c)B8d:>cP	1
z]P^	"x*h01n6x["iZkSk"*V\\PAj6kZv*nŧ$MIp{/Y=9"bp	i*whbpqO^njn('	S6wW#
3moxj>CYxmCEM钚֪$_ƴ)n*uR2MxOl
*q >#LJ<4Z)Ӕ?#7jC8K%QIol= ߡW c~NwtDqsAP!l<"skS¡;+'Vt)ăt	mfxV*lZy%>&KL)(aQ?oR|RmGW>w3BWjyA'ZzqvKfZG(It׳gɳ)3T$$Gk27@i>,)-ڞM4>gc}G|
zv'af)]W}/\1xA{37O*3{LuZ;wwiC4tM|zu/x jlh駠QڠGffnӷ3'2%85ʑ"U₭FKnw$OY^͒qIK	v:#kB9xtEٗhʮ)*2g(;e|I`)@/b/…{"wȮ4H"ЪBM*vZ$w+ԶM*BT9$?IIZ+Er!LXxmvѢf-PA]8sv,m106}2OC	2GHl?@Le*E	8I]/Οc\
DUGxQ}L;nUPY;vY&jv+z%30etNj2ܽT۷mˑ2Bh-hL;
̍<\&kyAwn8Ah}$U`2~ernw~+x}v2IwMy񭃋(0}hL'cIm\>ID1
l{|}AU){{gf]JЦ=
H™ʂd~v~)Wӣw\w/#Sj9;[HH4\Gc)l˱ u
}i&Xiw9zcoYe,_̀hjJn]#aJRll=?-qgqՌuB/r9J*QvD9ip{z,뱔-uMw{Y-l00Ok+Ͳin¸ꐑ¹gf†C@~u=E<%[y莉mB"K0TIiVzG4N)$fq?jنz0{?f(x9A7†'s&,MB"h^M^J1^PmQDYt3(8S(wܩ%'kvHӅp̗Ƒ |1ZmurKM>@QQz<*P%-j(*T:LTmcͯO7%RP{5AKCqFR}5SP쟉g{.q$$(!"P|X70Y~gJ=81U4BkP*4iEjb?X1CQ(	c|U4(8|89%($}X&,8, (mv:	XY"DN>~,

(3,4|8&PG3&F",Zmr ~ Gi25 ԋ!TnD,=(pO!@JAy3U/j[cy`F+-Gs@|7`Y{a&T!` g$^M(~@bYS^_`;=@
1D#Јc2 4`+NF
,a*
uNw4ᇄ0
2@$H5n^:3Ty
حMW
pr@ވxr'BMhB+"L
$ߌ~RŃX
"+I*|š1Z,8G󼼉-	#Jng@-hab(*(E2F*M8p Y-)bS[ZWV]_8kƕlQc;SjS+Ժ5^v׾6i``4
KifU"t+)$+va#lau2`Ms]ZR`v̑XV򵳬efz`#$^$HYb׊as^oWS6[t	znXlXPZ^ mF0QQh_X LlA-p;d	Q[QwC*܈Qc0_%.Q] '45}/~Grd 0tFpPU&%`DN*adqhGQz0H2BхtaGTTfy|0c,HY$R&-9QhiтG8P3*cCG[ts,GKMYs.K|"i<$xgvfNʶ9O "y3ʄb{ă{AB|~Z'[
jB	q	W>Msm"tom\C!G|Y8"u\)-I+	b-!?.}~SHt>#SΠ]zuSH''NU7hj*(N{ias
?w?cKgP~AfYy;&4^"ŀZtff-\uawmc:yøBMwu
HWs=8;_AjA2ޝQ-H,8JO_cMZq].P40CSFI9Dsb~hOO˳IKXZ^T^[
[޺@	^@iI8]90菂VgW>܈HJOBeN$JMT^gbjUK%e]0^(Uhiz&RfZfbjFRfbbdb1_<dhFj
X֮(Ip&4@@hc,jqr%BuW'npy
qan"༨4. E@LPk,BLoA궶kF止A©d 1 x@8IX	؇mȞ:l*$a1.!uN5xG 7B# ,:OLOށ`xlP:DG>XP `uIM("5T
ܖ!ՆĜBJ)0׆,aJ"1F"{b-+:
c⺡9M&zb-Rhҩ
H)ʪ!F"~Q&
֛P_NbaЦ*
K#sj{>LRHL{._Kf1=q|p#
dbkfbMN~}`
8MM_ww=&
BJ7H5}`r
ZI(aAanX#$urqvL}
cˈ!$o$5tDvL"/W'cbޢ6nFM'(m'NFG"гx3v2cuz`oLNz׶iB3>3vqGmN $oE$Kɭ016E3M/T<݂piDP'ʐTLDpO]R28C"1\5p>K;\eMPF//)
qE^tZuu_^``v!vbb^c;6|AIdwVeec`ivqvgg^h6ӴivV
jiǞjöB6vm?_kkva6(om^n!wrWapp;w^-5tӪM_7vkLuvsxwxSxXyktBT{z×z7Zw~?w{w&@td<\MS8[TuAC8TXNVh<$D@8`9Ytt@xB@xp6\d@PxrC0L(.BP\y0Ixgl@|~;Xpޗ~z=yx9S~\@w=ݳ=Xl H~SdZW@kO{@GF]K
".z?y|,&2
3~I,
H|=SqF1Qxabs16YwG$ F1摡Fqa+Z,:kܜR̆M]m}=-4
^Ы21AS9bn_4o6@P̈́}\Ha`>H ap3uqLŋ9336pbCtIv2אٴq1!z  ;)b$8YRCo&J*$ԫ]U,2B=`РBL*XqL
qiي]ٺk__?`,	q&`
jA9	MbҰڃ*hxb
^QDhd#	8Q$<A0fi3QPA#P`[3)dD5YafMP*PYo`=e#|xf…yc`^&sOQ(
ֳ yƎQyY(X0@D:iTJ¥d{ӁƚJWD(AttlO$h$P,	qPE{l~
xn	l5K<*YoP-TC&6,L@\\ 	4BlcE-&loDT0c#{o˾ѵDQ7V
g0O@	EQH.u$3PTH==Z,5'|]@V1qE#-191_ oC*DtY-hتh|{c56B=|aИPs/V*$
xnl
á1l/ij6eL~V-x_L`z"r^ wy$H)DG2fPC@10Fֆ8dh3frI="d<!`T*XPd+J\sDKox %hD`"'	5.SMi
@T#ZB3o^@ ?{z&@A&(eC184$dGk06O	H42I'm	@Ga: `4onMq/P0
Tj$jDiTAN$_pɳqLUm 
 iXxӑ6X

J-"Se,B8eWC(xp(eb`iŬ
*li+)@.t;93`kx@P\U,t׋]mP0 KW6P[zӫ"ySPL׼ԭmH*$AXI@
^.acPҠc%n{/9:4M{%%XH(blTӕn\t `a`/;
mJrc3@/mij1xmn*ij
ʄ@1<. >vjcYQ 4O*T@h_:|͒pmok92
c4@kU{l@xA涞Q;
=Ѐ(u;UN/`5sZl0eΝm[/?ny$u+dme4*0mdEXN[C.=h񆋻n=˶o5M8Xvma)&՗[Kx8=Qú)ՈP[ok)^n`Hd9:Ԇ՞t@`v*
VqwldC,	oI~}͘@ݳzzpzUx9ڀ 2Ua+Wg
kK
V27__1aGV@~$O1g|G"Vc
 lAnpGSd`c[Lniq)[Pe[sF^/|>jOe$@T+@\/V(R5k ^J\:G~igS6I_
2hH;|XFhcu[zF&QtUwEOx@O5bs{%\kY( o5lG[67PMP^\% RtQE0?x&z|UkP}XkEbD
eX8^W)ot$ [dUc21a	cjo
Vx++|ES	W7HHT0R>Տ T	Rk%{)@]7H
PN[2BPtԑ	N9z=%c9Px@ S
PTS6P+a+YJ.bA縓EQ!5NiLtTLJQهKyM	RNAM?MP5V[NIP?	~LU/uLjDiq9v`	NNH$Yޔtv1cJTPUY&)$c)yoI@DITpv
Y/s5UFqFIIilj9lG©HI/)Ri:AYAbC.驞&Y.I`	-"
-赓r
856mlg;@78` *P`,G:EM*
YaJ0:#+%:\YS՛P8Eݶ^au4I8^(OO*aRJr_UGM~F$7V[iZއbeJ)Фۤu%O7XUʣzb陇Vt5gdL
fHvg	@Tv}(Oj\*@Xa$qzgeWwTpp~;m'܅_}u_hH{'/+\ީw۵eyVZ5勇KP\pݶѿ&vUʾ!\UG`ߑvg͏۾ W~
q,s|lx`'ЙT @TC!S4R3MJaWh1.uϮ?`^@aI@HAaAߢ]$cݦI@J聝@j\hlI_fZno]!^1r!!3H\3CGC@C7]Y5zz3bؼr@I{S)lpPe&R!`q,BtS|(!DDIBٹ:ӊSeZ[I(tԌI@^b5
dy?>M8%O<8P	  ӌWB%4M@G4C@F|
.l"46hX0VC
	}G*	~} 7G'<"%HMќ3DNTBLDEg	 	AfV= sYgO=d!M``+Rz
$g: "iB@i,y@?jOQW%*Up(7$-E8Z}X8ue
`XulPQPH+sjp@xk,Jr%k6:Wrk@28^K-5a0nrC,NR̀Gq<1s!$EuoPW,2}CP<&=I	X^-vqDҋv",X-U܀#q쒶'M!$J'rM&2v3Ǐ !sLknyHI|c^}LsHq`DNAj4ЃӾT0_;PAOGۃuSv
d, 'H܅O=p>G}(c.-UЇx*%q$`;&db,+Z"-P"j"A>VZg~ȇsL6r&*a,OsLCR,J`-~_44 rUh
IFk7u@2
3k*Y@1̉g"iI=<3T*P)/"MiϚ8ǗL
 LHx	uo|+\0n8	4IAp\_{ƒ@񎷁8$pe*aSVm-lRmA[h ZǃwV@=^ 4>@D|~~c`DT@CJ=)(5AbjB>< uny 0l	E>EUS`LK#iV (5#ĵ6QD6xi,BPM,R{Z+pXw* }H@|k%`~̘ ź1rUGm]INtyE䖿hR@Pꡪ_H[QO")QxRPfCqTl㕠@(wj
/{H)*Bw^/hlDq˜=*/i=g|؅T^5OsT%gSRZ9:p2}o
BOz'iAUZP
]fC`AGsxl"̩5VbXKPZ+jtd2=
Pa~
$sOC+j+bXmA-

`'ĊY\	F@K=tBL|PH*Bl`S<]
PӫС`RBmR@dJO^W
FQaYX@x0!֑ 5	<
E90@@rK	xK9BLC=@$|
I\sx*aυF]Kx	|L̉%KUM%Q"}CYIHVڝaIzEPdVK1a҉[2Oh”B%`\+x|ͪd-(0nSR(
ڙ8:A70{8M8&:
A EgGόY,1C'A O
U?5EUJ|Y@4LaUDV[2/rӥ 1xd22
B,ԁ_	PBȍ.|
,RbU8ePzFRX-\%pB/Q.Cp@}AfuV	tdQVfU{O	јU|%AhfMUtuUp@ei(fhEVafwGC.4nBf8C!%fhAiRFxkkfIY 0&sbo(lŽET
ap#loxBz/X}3왘B%F+ '$C`x$`[bo~Y&3amlC TŇ(lFUyڮ>-@@mu\ZxҮXypG`z3(gl%N8&e'ϐP2}[	!i@iQˉ$`:	&@-	$ȁMǽ	ȾZSP5[yhD]UC6A,H:݄٪
IY`ʨTI.2SOkO.!ѲΠBQQaa t2,YQg0J=z˩YBk&@!˿7@0d6c	Xl#(#N}6ZO~@ڝb8+"bu*AArcʄMAk>:=>
VLBLA;RI̼ҜJc~uR$%a[i@$ҩ$d)nxآ0%.Vf则S^,0M"-͎&x.fcRV<@&)fu`WpjC!-%	خrFB'1of:Ɗ. :fF4x@ίb q#*IfopZذD
XXټ5oXa]&\X)EXd雝.pj)ϵą	ț\ج?<Om1K>Ȇ/1>H
J00T!-l!Iɪiui̪r5Z@T{t!]t|+S=P.ӴᯞN3#O7FIc;UN0HH"̼5T6Z:ɀ_^kx=c̒Zs#5@^A,/M0DUN'dH^
mo.|XX8p`PnRCYLqC@.Osl=PhIrrf tGuu3 eS6wz&iE
bEG(Ё2_p{G~`$B`oo.(B^0W^eDqwx+O#>@Hmă*O08f#{px
}ЬΆ+׼17t6AиH9^E,	Dp	xR
,,ݏ7ԄXR
dOVJ$Am8yN	KD`(o,W&UE%h\og`$8T%xyI(#@R-.cL?#{@O!QRp8אH (g~!cG0|`9ȤR	(.ШtJZFO	0-ld(yK`*"Z&
koqG,[NHEtt'df?|G^@
?'w&5(E?6
F@y}jf?\WMZ\I
j$Eu&}
''DIN;
S	z&m;`(HP#~C$vSWӨ8IMj[4@ ۗ-D2$AnY=5Gݑy@?' oƄ
44*O.	һeciԵp5ͫ+^̸\h(=Hn`m5'U#^Sq"DG~lBOkO];Dk,Ҭ.Z6PسtLs	/Q;0Vϔ5I`&W}'BB6`kV	o(VXhk(șp`
{Z/y@v%4>]LlJ0
.1eBka""$SN'*
%Eߏ4iXcid9t	ٙMi'Ww;H)2u5&7.裐F*
VXf馋R\`j@Ze	qS@k@cצRy
TZo
Ey a.CiyyBn6*e@Y[ȕX+bNت3ɻ'D%>\jkCz6{&yr1B`єǎrEp3#0!9|l",h2ɳ֬I-0@pC̵,

D+D@
᠃#Fe*=5+;Ag6d p$'It2K2-r@ׄQt,~P&y3+1VX:)$6$V.J礴Տ=w(&Xl#@0?{G&;Эjoc'pr	7)+ሇ.o#X"
ji:.ё]X/II+x×\Jt`#x#a .	-:!w^0	q0B NO08.3[󖀹PW` Qbr!*A|1pm6&<+
q#Y!='gI#
1|;B0b\`q:
)S1pqB	@mܳGҐK~b![h.d7x"C?亴@`@r/mK?׃r!I&&p8@93.橌5>4O–z8NpOE6$>AQЃBAP	;ɂlM1HIP*=]3K<	ȱ*$3$JkaRNn:Ri6)(NCb`!	WS$	jWƄ
\	MWl (?iHArxD$#eU-`M@$+)P>:Sh&iM
+b-%ؚ\c)H5
0
-`4+Iy6JVleu* l#]u[e-u(_%+kjVk;͓0)2)"Dd"aؽ
V&.XWT9?V+
$A|N[SkCռ9eľ~W
U?W;w71$ŀob.1020fs*0	X[XV7xaje;4c,
_63176*`&_:&(F*7pl76PXBXRfeea90ɐeiFtbNIk$hA#fk*&t,![)iчuAjPjd?zm\8[K8BQ&"j^D1Vyp3oDb舫x)ˤ9ls[SхXLVIOt0tA؊5o:(}=:5*1w-y?,vrcWeWzwPfkJ}]1Vp{O{8( %G'UBg{FVz"|،!8Y0Yّ iّX&
ၳ!5YͰ"
UU0YvG"M
*-$Q2QEI{Gr0H $4@@snaYI7ZhK2h.4:\ƒ5Z6[&_c'72j{<_k8ٖ^fj
YhTy@cgH\X6P96vտl=f	Is	y=1nc˵Fjo=QW}D@X!8Q!W
jW}YcB!}5! #g$C@.+ԍA(!0ʘ_;PK
rppPK+AOEBPS/img/strep030.gifUTGIF87aXP?**?***UU?UUU????**?*******?*******U*U?*U*U*U**?*****?*****?*****?***UU?UUUU*U*?U*U*U*UUUU?UUUUUUUU?UUUUU?UUUUU?UUUUU?UUU?**?***UU?UUU?????**?***UU?UUU?????**?***UU?UUU?ժժ?ժժժ???**?***UU?UUU?????***UUU,XP	H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜI͛8sɳϟ@
JѣH*]ʴӧPJJիXjʵׯ`ÊKٳhӪ]˶۲O>}	H0>},h „
2l!CO>$O>}?	4xaB6tbD)VxcF9׏>ԧ ?	ԧ`>?	4xaB6tP?~'p>}	Hp>}	o?	H*\ȰÇ#JHŋ3jx|ǯۗ/_|ȑ#G˗/_}?}˧?9rȑ#G9r?~ǯǃ˗/߾~9ro_|?~G9rȑ#G9rO_|q|o_|qȑb|a}Ǒ#G9rȑ#G)˗/?˗G!˗O_?˗G9rȑ#G9r/~3ۗ/?92/>8`A&DO_>}8`A&TaC!F8bE1fԨ_|6n/_>~7nl/_>7/7nܸqƍ7n܈_}7oƍ˷oƃ۸qƍ7nܸqƍӷqcB~mܸ1a|6nL/߾7nܸqƍ7nX1oƍ۸q|6nܸqƍ7nܸqDm0>7n4/oƍ7nܸqƍ7NoƆ۸q}6nlo7nܸqƍ7n(Q_ƍ(_>$XA	.O?	H*\ȰÇ#JHŋ3j/ƍ˷q#Cqƍ7nܸqƍ#˷oƅoƍ۷q}qƍ7nܸqƍ#˗oƍ	˧ϟ7ԧ/_˗o?7nܸqƍ7nܸ1"?}۸`|oƍۗƍۧo?7nܸqƍ7nܸ1"?}oFO?7n,?}mXP_>}oƍ7nܸqƍ7FO`?O@
DP!|O?
*TPB/_>~
*T |o?	H*\ȰÇ#JHŋ3jO}"|>}mܸ>~˷oEϟ?qƍ7nܸqƍ#g_|߾|O}'p "Lp!Cܗ/>~
6,菟|'p}8`A&TaC!F8bE1f>˗o_
ӗ/}	(p>	H*\>~˗/?
./_|'p@}'p "Lp!ÆB(q"Ŋ/b̨1"?}˗/_>}mo_|П'?	4xaB"oa}˷
/_|O@<0…:|1ĉ+Z1ƈ9o>
ԧ?~8 ?~O@}O@<0…?~'P>}ПO>
Է_?$HP>	H*\ȰÇ#JHŋ3jODӧ`>	O?~?	O@$XA	.dPO>$XP>}?$XП}8`A&TaC!F8bE1f8p ПۧO ,h „
2D_Æ8p ПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#ӷ#@,o>	H*\>~
6dПӷO ,h „
2l!Ĉ'Rh"ƌ#wp_|m$ @,o>	H*\>~˗_ÆO@'?	4xaB6tbD)VxcF3/_80A$X>}8`A&T!B}|6$ @,O>	H*\ȰÇ#JHŋ3jO|o_|˗@~_|˗_'0|o@ۧO ,h „
2D|o_|˗@~_|˗__>~/>ԷO ,h „
2l!Ĉ'Rh"ƌ#gp_|/?_~o߿|o_>~|/_~'p}'p "Lp!Cܗ/>~_>~|/_ۗ?}/?㗯_|8P>	H*\ȰÇ#JHŋ3jO~/>'߿|o`
}_>~'p}'p "Lp!C!O_|/_|˗o`/|ۗ|o_>o@$XA	.dC%NXE5FϠ?˧/_|#/|
/_/|ӧO>O@$XA	.dP
̗/|˗`|70߿|o|ϟ>}'p?}'p "Lp!ÆB(q"Ŋ/b̨1"?}_>}	O_>ۗ߿}߾|/߿~|'p}'p "Lp!C?'P_?}o_>~o`/߿|/??'?	4xaB6tbD)VxcF;/_|ӗ/˷O|o`>ۧ|	ϟ?'p}'p "Lp!C!/_}˗?'p_|70@}O_}ϟ?'p@}'p "Lp!ÆB(q"Ŋ/b̨1"?}1'P`}ܧO ,h „
2D_Æ
'p`}
ԷO ,h „
2l!Ĉ'Rh"ƌ#ӷ?П<0…װaC	/<0…:|1ĉ+Z1ƈmϟ?8}'p "Lp!C5lؐ!@8p?}'p "Lp!ÆB(q"Ŋ/b̨1"?}
˗_BEO@'?	4xaB"oa|K/a8`A	O@
DPB
>QD-^ĘQcD~_>~!?	O@$XA	.dP|	5ПӷO ,h „
2l!Ĉ'Rh"ƌ#ӧ0_>	/_/_~˧o |	/߾˷?	ۧO ,h „
2D|'_|˗?~_>}O |/_}	HP>	H*\ȰÇ#JHŋ3jO|'P?|o@}ϟ|/>$O@$XA	.dP	̗O	7P?/߾'0?ׯ_}	8P>	H*\ȰÇ#JHŋ3jO|'}؏߾|	̗O`?~	̧/@ܧO ,h 
2D|'}؏߾|	̗_?~	̧?/@ԷO ,h „
2l!Ĉ'Rh"ƌ#ӧ0_>	̷_>/|o|˗o_>}П<0…0_>	̷_>/|o|˗O_>}П<0…:|1ĉ+Z1ƈ)̗|/|O`>~_|/}П<0…0__|
_>˷_O`|@ԷO ,h „
2l!Ĉ'Rh"ƌ#ӧ0_|
ԗo>ӗo>O|/_>}˗o@O@$XA	.dPo|	ԗ?}O_|˷O?ׯ|'p A}'p "Lp!ÆB(q"Ŋ/b̨1"?}1'p <0…װaC	H?}'p "Lp!ÆB(q"Ŋ/b̨1"?}1'p <0…װaC	H?}'p "Lp!ÆB(q"Ŋ/b̨Q"?}1'p O@
DPB
kذ!C$XП}	H*\ȰÇ#JHŋ3jOF	H}8`A&TB}6l?	,h „
2l!Ĉ'Rh"ƌ'ӷ#@,o>$XA	.dP
2O@<0…:|1ĉ+Z1ƉmПۧ?	4xaB*ǯaÆ8`A'p "Lp!ÆB(q"Ŋ/b̨q"?}1'p O@
DPB
kذ!C$XП>~	H*\ȰÇ#JHŋ3jOF	H}8`A&TB}6l?	,h „
2l!Ĉ'Rh"ƌ'ӷ#@,o>$XA	.dP
2O@<0…:|1ĉ+Z1ƉmПۧ?	4xaB*ǯaÆ8`A'p "Lp!ÆB(q"Ŋ/b̨q"|1'p O@
DPB
kذ!C$X_>~	H*\ȰÇ#JHŋ3j/8`A'p "Lp!C5lؐ!@,/?$XA	.dC%NXE5ŖoE$Xp_>$XA	.d0߾
.O@O@
DPB
>QD-^ĘQc~mП	?	4xaB2䗏_Æ
'p AO@
DPB
>QD-^ĘQE~mП˷?	4xaB6/?O@<0…:|1ĉ+Z1Fq"@/_>~	H*\Ȱ@~s!A$_|8`A&TaC!F8bE1fԨџ|mП˗,h „
2lX_|9tP @/>	H*\ȰÇ#JHŋ3j(_|qtП˗,h „
2lp_|9t?˗/?$XA	.dC%NXE5n4O_|q\ϟ?˗G)˗/߾~?}Ǒ#G9rȑ#G1ۗ/_>}q<؏|Ǒ#G˗o?ۧ/_|qȑ#G9rȑ#Gӗ/_|wџ?~˗O?9r_}˗o?.o_|#G9rȑ#G9r,ϟ~O@}8O@}O@
DPB
:_}'P>}8'p}'p "Lp!ÆB(q"Ŋ/b̨qF׏߾}'p ϟ?$XA	.dCׯ}O@Ǐ?	H*\ȰÇ#JHŋ3j1!@$/_|8`A&TaC!O@˷?$XA	.dC%NXE5nر|co_?=^O_>˷ϣG=zѣG=zܸ/_|˗/>~=z؏|'p ˷?	4xaB6tbD)VxcF9vt/_|O@}'p "Lp!Æ	O|8|O@
DPB
>QD-^ĘQF!˗/_?	8P,h „
2lx|˗o,h „
2l!Ĉ'Rh"ƌ7r(q_|%0'p "Lp!Æ'p@/_|8`A&TaC!F8bE1fԸcG??	4xaB6T`>'p}<0…:|1ĉ+Z1ƍ;Zܗ/_~8p,h „
2lp|O˷?	4xaB6tbD)VxcF9vĸ/_|O}	H*\Ȱa}	?˗/>$XA	.dC%NXE5nQ|3/_|˷ϣG˗o_|ܗ/_}=zѣG=zѣdž`|˗/>=ܗ/_}Wp_|yѣG=zѣG˗/_
/_}=z$/_|+/_|QD-^ĘQF="ܗ/_~
˗oǏ˗o}Ǐ?~Ǐ?~T/_|˗/߾-˗/>˷Ǐ?~Ǐ?~p_|)/_}?Rܗ/_}
˗oǏ?~Ǐ?~|S/_|>~/_|˗/߾?~Ǐ?~#}맰_|}q_|)ܗ/_}?~Ǐ?~GOa||˗o,h „
2l!Ĉ'Rh"ƌ7r|S/_|>~d/_|˗/߾?~Ǐ?~}맰_|}p_|)ܗ/_}?~Ǐ?~GOa||S/_|>~Ǐ?~Ǐ˗~}ۧp_|}Ǐ?~Ǐ9˗/_?˷G˷O|Ǐ?~Ǐ?zܗ/_~
˗oǏ˗>$/_|8`A&TaC!F8bE1fԸcG˗/_?˷}ۧp_|	$H A	$H '˗/_?˷$}ۧp_|	$H A	$H +˗/_?˷}ۧp_|	$H A	$H /˗/_?˷$}ۧp_|	$H A	$H 3˗/_?˷}ۧp_|	$H A	$H 7˗/_?˷$}ۧp_|O@
DPB
>QD-^ĘQF=~l/_|W_|/_|
7p_|	$H A	$H ?˗/_3/_|@Bܗ/_}o_|	$H A	$H Aۗ/_>}g_|t/_|˗/|	$H A	$H A`>'p~<|;`>'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?VO|	(_|'p "4/_|'p>$XA	.dC%NXE5nNJ80/_}	Ǐ>}8@}˗/߾O|8`A&TaC!F8bE1fԸcG'O@8p`|?}	O@~$O|o}	8p|
<0…:|1ĉ+Z1ƍ;zџ>?	O|?~(PO8`A&TaC!F8bE1fԸcG)0	8|G A	$8_}Ǐ@	,h „
2l!Ĉ'Rh"ƌ7rc~ׯ}B˷ |$H A	$H A?~˗Ȉ˷O>~@	$H A	$H /˗H$H A	$H A_|@jܗOH A	$H A	Eɱ_>} A	$H A	$H_| A	$H A	$Hd|@	$H A	$H %@}	$H H H D?	4xaB<0…:|1ĉ+Z1ƍ;z_~ A
ϟ? A	$H A	$ȇ	R|	$H A	$H At/_> ˗ϟ? A	$H A	$H˧GH A	$H A	C?}H A	$H A	C˗H/?@	$H A	$H 7P_>}@Z/>H A	$H A	C/~	H/_~ϟ?	H*\ȰÇ#JHŋ3jȱǏ3/_|do_|'P`|8`A&TaC!F8bE1fԸcG=ˇ߾|$A˗o@
o ,h „
2l!Ĉ'Rh"ƌ7rG/_|}˧o_?$/@$XA	.dC%NXE5nG=O|ӷ?~8P`?~0O@<0…:|1ĉ+Z1ƍ;z_>ۧO|,O>~?$X_	H*\ȰÇ#JHŋ3jȱǏП8`A$X_	H*\ȰÇ#JHŋ3jȱǏI?	o ,h „
2l!Ĉ'Rh"ƌ7rG@RO@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$E$X_	H*\ȰÇ#JHŋ3jȱǏI?	o ,h „
2l!Ĉ'Rh"ƌ7rG@RO@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$E$X_	H*\ȰÇ#JHŋ3jȱǏI?	o ,h „
2l!Ĉ'Rh"ƌ7rG@RO@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?za|g0_F$X_	H*\ȰÇ#JHŋ3jȱǏs/|@'p 
O@
DPB
>QD-^ĘQF=~/|/_|	/>~	/_?ۗO`}	H`|8`A&TaC!F8bE1fԸcG=0__?//|_~	H`|8`A&TaC!F8bE1fԸcG=0_|`>O`?~	70?~8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?za|'0|	̷_>ӧ@,/@$XA	.dC%NXE5nG9̗`>O`>'0~'p <0…:|1ĉ+Z1ƍ;z_>G0|	'P_}#/?$X_	H*\ȰÇ#JHŋ3jȱǏ1	H`|8`A&TaC!F8bE1fԸcG=b|8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$D8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?zoa|C/a	H`|8`A&TaC!F8bE1fԸcG=˷0_;/a	H`|8`A&TaC!F8bE1fԸcG=˷0_>/__|O@~/_}˷?	o ,h „
2l!Ĉ'Rh"ƌ7rG'0_'0@}o߿|/|۷/_~'p ~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?zoa|׏߾|
o_>}߿|˗?	7?	4xaB6tbD)VxcF9vѣ|O߿|o`}	'0_'߾|ӗ/_>}	H_	H*\ȰÇ#JHŋ3jȱǏ[/?~_>/|/߿~'0_>}?	7?	4xaB6tbD)VxcF9vѣ|˗@}/'P|ӗo˧ϟ?}O@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?~$E$X_>	H*\ȰÇ#JHŋ3jȱǏ I?	?	4xaB6tbD)VxcF9v?BNO@O@
DPB
>QD-^ĘQF=~_8`~8`A&TaC!F8bE1fԸcGA/D$X_>$XA	.dC%NXE5nG9?	?	4xaB6tbD)VxcF9v?BNO@O@
DPB
>QD-^ĘQF=~_8`~8`A&TaC!F8bE1fԸcGA/D$X_>$XA	.dC%NXE5nGR"@,/,h „
2l!Ĉ'Rh"ƌ7r#HП<0…:|1ĉ+Z1ƍ;zR|BFO@<0…:|1ĉ+Z1ƍ;zr`|!#'p O@
DPB
>QD-^ĘQF=~I_>}B>O@<0…:|1ĉ+Z1ƍ;zҠ|tП˧?	4xaB6tbD)VxcF9vdB~?˗,h „
2l!Ĉ'Rh"ƌ7r#ȅ/B/_}	H*\ȰÇ#JHŋ3jȱǏ ۗ/>~B_}2dȐ!C2dȐ!CIq|/?˗O_!C2dȐ!C2dȋӗ/_|Ϣ?˗/_}B2dȐ!C2dȐ!;׏>}	O@~O>,h „
2l!Ĉ'Rh"ƌ7r#Ȑ}07?	H*\ȰÇ#JHŋ3jȱǏ C6O@_|8`A&TaC!F8bE1fԸcGA_|F9rȑ#G9rȑ#'/_>#G9rȑ#G9rȑ_|F9rȑ#G9rȑ#%˗!|9rȑ#G9rȑ#GFܗ/_>~oȑ#G9rȑ#G92"|'p A<0…:|1ĉ+Z1ƍ;z2}	?	/?$XA	.dC%NXE5nG!O|	Hp |'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?P|˗,h „
2l!Ĉ'Rh"ƌ7r#Ȑ
'p@$(_|8`A&TaC!F8bE1fԸcGAl`>O@?	4xaB6tbD)VxcF9vdȈ{/_>"E)RH"E)RH"_|D)RH"E)RH"E˧!|)RH"E)RH"E̗OC~)RH"E)RH"E/'RH"E)RH"E)2_>}OH"E)RH"E)Rd|˗ϟH"E)RH"E)R|=/?"E)RH"E)RH{/_>"E)RH"E)R$D	|'p <0…:|1ĉ+Z1ƍ;z2d|=/?"E)RH"E)RH{/_>"E)RH"E)RH"_|D)RH"E)RH"E˧!|)RH"E)RH"E̗OC~)RH"E)RH"E/8 ,h „
2l!Ĉ'Rh"ƌ7r#Ȑ`>O@
DPB
>QD-^ĘQF=~a|O@	H*\ȰÇ#JHŋ3jȱǏ C>̗O_C}	?	4xaB6tbD)VxcF9vdȇk`>8`A&TaC!F8bE1fԸcGA/>˗H"E)RH"E)Rd|=̗/_>"E)RH"E)RH{/_>~"E)RH"E)RH"1_>"E)RH"E)RH_?"E)RH"E)RH@~ϟ?$XA	.dC%NXE5nG!O>$X`>}<0…:|1ĉ+Z1ƍ;z2@'P}	Ǐ>}˧o?$XA	.dC%NXE5nG˗/}yo_|2dȐ!C2dȐ!Ciq_|y߾|2dȐ!C2dȐ!CO_|lo_|2dȐ!C2dȐ!C6ԗ/˷/dȐ!C2dȐ!CR!|/_~!C2dȐ!C2dȐR?}2dȐ!C2dȐ!Cܗ_Ȏ2dȐ!C2dȐ!C/߾2dȐ!C2dȐB
)H>$XA	.̧,h „
2l!Ĉ'Rh"ƌ7r#/!C2dȐ!C2dH/?!C2dȐ!C2dHr_>B2dȐ!C2dȐ 2d|2dȐ!C2dȐ!C~/_ϟ!C2dȐ!C2G#|/dȐ!C2dȐ!C_q_}/dȐ!C2dȐ!C_>b|ϟ?!C2dȐ!C2dH/߿˧,h „˧ϟ??	4xaB6tbD)VxcF9vѣ|˗Hϟ?H A	$H A	Cӗ/>~@"/_|'p`|8`A&TaC!F8bE1fԸcG=˧|d?~˧@o ,h „
2l!Ĉ'Rh"ƌ7rGۧ/_|_D/_|П7?	4xaB6tbD)VxcF9vѣ|ۧ`>'p@_?8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z~>Ǐ?	(?	o ,h „
2l!Ĉ'Rh"ƌ7rG@RO@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$E$X_	H*\ȰÇ#JHŋ3jȱǏI?	o ,h „
2l!Ĉ'Rh"ƌ7rG@RO@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$E$X_	H*\ȰÇ#JHŋ3jȱǏI?	o ,h „
2l!Ĉ'Rh"ƌ7rG@RO@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$E$X_	H*\ȰÇ#JHŋ3jȱǏI?	o ,h „
2l!Ĉ'Rh"ƌ7rG˗/'p 
O@
DPB
>QD-^ĘQF=~/A}|8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z`|/_>~O |	/_~/?~_>o@7?	4xaB6tbD)VxcF9vѣ|˷|/|O_'0>~/_?o ,h „
2l!Ĉ'Rh"ƌ7rG/_>~	̗/_>70߿|˗o`'0?/@o ,h „
2l!Ĉ'Rh"ƌ7rG70_|˧/_>
/|_}	ϟ?П<0…:|1ĉ+Z1ƍ;z_>/>}/>}
o_>_||'p~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z |O_|ӗ/>_˗o'0@7p~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$E
̷o@
O@
DPB
>QD-^ĘQF=~/H/@o ,h „
2l!Ĉ'Rh"ƌ7rG˗/?ϟ?8`|8`A&TaC!F8bE1fԸcG=˷0_;/a	H`|8`A&TaC!F8bE1fԸcG=˷0_>/__|O@~/_}˷?	o ,h „
2l!Ĉ'Rh"ƌ7rG'0_'0@}o߿|/|۷/_~'p ~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?zoa|׏߾|
o_>}߿|˗?	7?	4xaB6tbD)VxcF9vѣ|O߿|o`}	'0_'߾|ӗ/_>}	H_	H*\ȰÇ#JHŋ3jȱǏ[/?~_>/|/߿~'0_>}?	7?	4xaB6tbD)VxcF9vѣ|˗@}/'P|ӗo˧ϟ?}O@<0…:|1ĉ+Z1ƍ;z_>8`~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?z$E$X_>	H*\ȰÇ#JHŋ3jȱǏI?	,h „
2l!Ĉ'Rh"ƌ7r#H@RO@O@
DPB
>QD-^ĘQF=~_8`~8`A&TaC!F8bE1fԸcGA/D$X_>$XA	.dC%NXE5nG9?	?	4xaB6tbD)VxcF9v?BNO@O@
DPB
>QD-^ĘQF=~_8`~8`A&TaC!F8bE1fԸcGA/D$X_>$XA	.dC%NXE5nG9?	?	4xaB6tbD)VxcF9v|BJO@O@
DPB
>QD-^ĘQF=~)08`|8`A&TaC!F8bE1fԸcGA
엏_Ȉ	H|	H*\ȰÇ#JHŋ3jȱǏ 	/$D$8P_~	H*\ȰÇ#JHŋ3jȱǏ ˷/C$_|8`A&TaC!F8bE1fԸcGA/_
8|'p "Lp!ÆB(q"Ŋ/b̨q#ǎ?T/_>~!'p}O@
DPB
>QD-^ĘQF=~П|?˗o,h „
2l!Ĉ'Rh"ƌ7r#H˷_Ȃӗ/_>~!C2dȐ!C2dȐ˗/_}yO_|2dȐ!C2dȐ!Cџ~˗/_>}篡?ӧ/_|2dȐ!C2dȐ!Cҟ?ӧ`>	4O>~'p "Lp!ÆB(q"Ŋ/b̨q#ǎ??>	?	4xaB6tbD)VxcF9vdH	Hp ,h „
2l!Ĉ'Rh"ƌ7r#Ȑ"G,i$ʔ*Wl%̘2gҬi&Μ:9w'РB-j(ҤJ2m)ԨRRj*֬Zr+ذbǒ-k,ڴj7;;PKItZTUTPK+AOEBPS/img/strep052.gifguGIF89a	忿???@@@///___999rrroooOOO   000```pppPPP;;;ggg<<<888vvv:::,,,XXXssswwwqqq***


777UUU+++xxx666nnndddJJJVVV}}})))|||yyyTTTƝ̺WWWccchhh>>>EEEDDDaaa[[[˂444FFFttt(((lllMMMmmmbbbGGGHHHeeeĻuuuRRR...~~~NNNiii{{{fff555^^^jjjkkk333'''ZZZzzzCCC]]]---SSS!,		H*\ȰÇ#JHŋ3jȐDH(Xd4Yr$AbNH͛6%$A	#t0kTd!x`xd6ly6PeMpd}j`M0؀ 	A	!ho)Xb#&X`gm* vA)I>k!@~UZ'6&k
*mp	B	wnX^snu `[)La!(At B_v4!얐dJ\M`2m_~~}0
%M\_!0ګ_qO!8]Wa5ƴSu	S"cn6|v}j
:j@`76
pў%o%f
<.:@'Ch'۫O	.	jjWȷ_CT6D0Ё7=4@,~ڃ{I{D~c>?Onf`H3	+u@lNWA"
:h`ǀo(4Hn)R!ڰ!Ԃ
FAV"@4D"!hӰ1s{R;!RUg.A,6Mʈ}lҀyExNqe>Dh&[B	`n4|duBP`&	@>@ɷ(@löhB8xJrCB5iBfXG&j%M$,~TJF%e
1e4`Ëhi@z`礼r*3L${Uy"6qf#8DRh4g'C#*D|2
f` 9q裷5fC3*6#TQ )Iu(`m2ghyTQc5F#bZ'@+JfT,QUAg$*fuX@9A/WQYH*]e k/ƜXfS)@/K;E<,lHKfhZeaF
RhUl3،,«]٫4M!8 JY2Xl SO-7]
nhA	O$IATU$Ut\ﵳdYsLEm⪊H^˟xjYMmfL-W< ߆
ppu[KXʓ1
&d9_dFBZ)KuWձ@h@7Ukn-Ήs'XΆqٺ*m,"Wѳ0	GRiA@-s4ݨĿ~󯅬qEu4xHe/x\
\SF3GL>RuԨkQ_^'s	
ϛnt%SZѬL,b}~U$@tnMO'jEiu1Ð+HR`*x6[rJx?%nҺ]akkVKQ'gAR&5t0
5yַ^*?D/U~X.-`_%CUHt')a/Tlvm[gȮq;9OiYDb1@=;UC!O O`N	B1F0tO@p2X
[rdT DSG,8w}\r4yq0OTK&Hy54uaFU!7N]=eq>;s
isBs;3=x1,8!7Gc|5YZ8"OVncdd?D#Yx%sNpXPɄ
xɑCt,=AEih<]rN^j¡8fV֤&bUd;=S7o(+Hy춊^ee'ni	RyHgWV?Lhb1xb茻sDNeeԅ"x;Ӈ
BV<_׎6ax#RQ=CԌb
LebHS;C0
I?rbI%3iy	2akq`&(H
8HmH:?ybQCA:q``	P3qSL 2XVXq`搑TXl%s\bl#hpxNVv)5(Ș`D	_y9c[,KZ8љ1 <	!A3|`q6-p~1e	Hʉ7 2'BhSZLui.YB\-5'SFF#R6WZY)1Ct0pr՜+A290?E)6R
y
W~2QSimhtO	9JWq%b[BycY8Q r[cp"Ii]F$-R5%A22%]$n!RLr,g]WQI=pخ]Nmx oۆW.I,U*T!0`E]
`d B<:J m=`
ݐEL,(]FNmopm=pC+#42;=!
}"Ri
NQ*<+C
()8`Q
Rq!&[-)S|..BUP.)(;!;~m$#Nlȫ\ͭCmn
)pb7m<)(I[g( !+m;kJ.B?=}`:&b"s⦮'A ̸G2!龎>8毮=P>W~
~0hA۽s2Ž
8}W°쁂9n
Ƞv
3D" 6s 7
Q	;7nN	'!M0(i܏I
qп8rMJ˷<.˲="34a> K}4PpWۦ~
'*?8ɱ$Y!)T/um
E+KeN"9oW-i؀y/)q8łb=$s;BOlLѓQ=~$x*W߻@*pHm֬xh6(b	߀*ZDLDSH	6SE-ͬB5@	vX`̆#p1,κ|뤬(o-q +/	=蒯>1lM4뒿8|MKp{1!4RCS&GD#$'I4sG @BH#=2Q,N<тDnYOpʪN)M(訦]JdwŪgJڮ#@O`É\xR
IPȈ$9MNl d;(k`~.f	pH;2Pf8%f) B) $>@&zJ\ R\$i@Iy<5KX bUG!<"QXGO&EePe`.҂!ec
"aI~!c[,Ɍ7^@B"H
)_몓^
#0[.Am6dY_7a`AijV"z "m'5xr_
V;:--AO;7!
].oQ]lHm
y{.(·ذ0VW.&@5sm:Kn@lPD0K}c YC&2aq~P
*P
0'5	a
J~8@
T-9b(v"Ys3:VW	K%
ӵaó].S0ָz?`㩇
S$|s||jTzwNq;I
.mP($1`cCl߮ NfP1GSȸfY5-lg[vmp[}nt NEyY3dơаFڼpXLo;cEh9}9n幻0Aek8za\
FGۀ
 rY02[ygVISRSdPpP`u$ǩv)m4]*Z~
#EH\`Yq^Bxqg|;u
"MzA؍8z)	GlAˉ0aXA ԣֱ'rh(Be[ާMxveB)	z!)2{>Chzk^]PBf8G"X [wnL@a0]ٗS
 NqE&Aby8>*>֡%!1U:p(H	`lxN(rA-s/1CeX%,&h>0Z@Ll`9cAk 8XBxpL؃1B <,$AJ
؁<#X]`0c
W),']HRa.	L\B1,T4|8jh47@DDXB:08#@
J<%P)H,1a䝃=؅44ÖAɳL P*_
*<((Ђh8EL[?(5H, Pt;làBpJX0#%58h4TGzDh<D2$	,IHɘPL<ɒGKȀ=T	I`IښJpƋHaJx 
@
pQlØllʃʘD_KZIK(`ȸ`)؀ZR3k刀
ȀrIt)KKΌ,	*ͭl@!@,KT	(lܖjK
͠ҎDl*	l@PѼQu2lFѥqQRa4ȄG-QOpD22D@RҥӍ(ʃDl0fMVSNnq
x	 			lJLPELFm7GȀDT@IXep8L̀t/
S6MȀh9FEdmeeNh-MVMPC[P=UUs=gUUvuWNĖ4nPR{
PK?m TcMӂ)oA
(A\Pll?llTqZX=lByt5l`Ulc5sml,ԍ0>A:ϗ-ʜ̝O
uỲx^ЍMA$YU~
VŶUZץY\XR7ҚQP=IrP4Hd\$܋mP}GX쐏nYܪlW0		IH/ݑ=WX'mp]pX]M	V	h^/	lϽ8>0p^%}R5ITOpiP̭\WmGu>%	_	(,Xl)m	vZI2LVZLDdKll̀\`plsM4#7ְ\xU[IـU$dO/(Evdߠ9]ͯ
UQ p	
h_Z}Kl]ˍ]K)']V_(82^lhdcf-
dU}\Q^(=Llɬ̚xmP4
c<]a`fMsJdP^5X[Ȁj(O@ڧ@l-Tĉ%׌ļDNtR-T|zALd-U[PhX8ipa^da]MM<X
	˻==hNxdZEm̻]WC災3΍LU@	\	l0l.KJQo̓=_L}ʮvk%vtTlΰD{]ib~p5ΣԙU(Dۗ%Y ƎܫTo܀HdXvdn@eqPhUkXW.'а`=؄GK=q܍mTnu^n_$i
B, nb@Ӈ5P|n??HZ̳[ke5	_]@0]Յv$	"-ʠTKLh	 j
oW%kxdxiOE^eb`iiQ?$>d`''_hpg
s&	8?lv+CWt`rfg݊!Ơ ?5A9lC5ldL[raBa( l-[?l0j\!s>KJmP옎<_ueVn(bow/Ylu(l~'h0w]^f4 眬vg%>}waF>2 `YM(`GK:G[f`YoxAgy
a
&h[kvm1}~ N3&f_32v1ǪgSv0x6耤.&0Y&\xdyeUk?vwGǀ70~ca	0Cз{ʧZ'd̗_pȂWmT0v߇ņiF$>=@l!}
Kz\V	(xF`	N/{~~lpzla800ۄ0MB'
6"ƌ7rcG
A,i$H,leIl2i@l9fP 
Hć9DApg
J	L{B9D4BWU)lI$0Ѐ8QlmYqx夨cEߔ(דY_H.	EA$uDvu*xd~=tM48d:Pj E0 f#/!P"6\ ;o
[}RI1{1!Mr'!lF3'Ы
 d@)[A40@$g#h>=)82$pZpM|l6m-'!o2#w6>姭F@A\ihЀm9`Үg駧ۭ&gAp
b
.xE8uM.r-,}KLz7Ib%?>X6t>>r{w,cQ@-A9)n8@l .kI@TJ @qaSg;bɫzB;
@6q~<vL$8zC`6|xxMD`F 	a	AB0guEBf-@ޕ] [@xU0r+FY7)m2RIUTHirf逝4S
de\>i$8#-Ԑ)aٕTm'Y$/scV$1KuQּ&6mr&8)qb3[/)%W5U
_'yҳ'>9ikg	М3@Hފ0}(D#*щR .`(H=~p:7'0f|)Lc*әҴ6)N_ZP >)P*K՘@'#.*T*U=*V:~cW5VP5"O*ZӪ^Un}+Lj԰f\*:p~+`+=,b9"},d#+Yt+:VT_XYaŏ^=Vd,1Z?}v%mR*ҩp]˽۾6-oKZe7…%lI{nn&4IH*$(pquN[D&
-!m1+{4WnZDl8X#/o1x
DHL[+uKn;+yXW 2~܍
3	yI;ʁ0Hl)q2vt&9k,n5O[H5`{b]~is7IȔ5Fj}SsMD[VK8ma=dn.½K~+Ɲ؇/RD.؍dĕOnde3~T
k<峣>/<Խjz>uxս/jx|+g>~rk6t>Ck_,׾Dxwfu꼵>ݞߑRB. fSOh@F䉕&fn v8Q2iD		 
u ƠH~y  9і+ `=
haz)9r>n
ߢlb!Ki!I^Sr`bՄQX|Vq4yT!܌4I]a}[RD\M\QQt$z   ܡ!="]%SΑ},Bh @YĢhJԕ8@X[W8c/V''J.I!@AlD8f0xW"MiNV4xMbM4&9X݌)m4I
8ץ@I^Zݤi.\rb#j$ȋ1%Q9
5i=Z}&"䍘,$@Z1ZFPм	َi尙:)B)srR	8ΨZZb{݋ՓalDa}P*Kczc6RfIZ㪦E6|jnxB\j&t+&.eGMK"^+frtkKdL+++ƫ++*v@ +,&žxjV^,T=aCbt*iIƎ,ɖl@@qĚ˾,f,ExDiď,vDTzDmjl6D@"NmZC`C,v~-؆؎-ٖٞ-ڦڮ-۶-Ve*Er
--ߊHlvO8nr)@c!n<:.]|rR.ljM@jdm	fG zjF
.S&.4@l.ʭ~@uS`t"/0@bt*JjBN;ffuΝ,o.fmV/w4o;Fև9rd@m(Lc4}WQƔnV0Z06o}H0N6H(qt0Z06H/D`SXﰯIo0YL0EMH4aC.~ذWG"1@s"q+Gz-6{pܱFqL1 Ϭt|
cHe"Ga!"-r#g#/t@(. #g%#Gqw|2ZLp(-0D챑r[.g-fw@`12}	D2df7@5F(˄6k2-k	3L|3k@r슮@I=#Jl3e7GB+@g	 g/J,4h@&?Dc T}]dAtO	4p4uͦ7cCn3Ũ}LMO&YIsq	mMCmMIsu`{H85]}E@)I@	,
e.y5~D XgU%i:a83ܠKPqP&͵@ȴ 2)"ID	_@DfK9(f>+Bco
Io`AZv^k[7HXn|eF,u4A;<aMQ4bgwr)鈀w+KxyQ5Yd\G@oDd{k'lHϢCm0
Ž0ls@Blt|Iȥ:j
Vɼ8`,L7,
@B6f 'Z†r1<3(944[%93AN=i?drT>s1ɹ9{-`DK*MI/+C\X\Tl,`͆Y2IY[3XrM
QcjLkX0'B jUfpOy#MnQ@Aq6~?^/0@CUjqPKJF!ycMjS!tQóհLD@g3W_{`.D{YKhh-XNs,%ΰ 	Q64'݉;q7OE8.&|M8_SE:yP(NF}y!	=UI E?\)8886hNw:}KM@t043H(XӑgfAy+%P2HH$MNh;
{T$/NJb*_ӹs%bN(HEjID'榈JK|D+p^%E@e({Bhi" H\$NFG;Nw$ֆ0h idž"!E89ud$ObHl@`")y2Gn (`zx)QI%MI((\2- 83?B`Lg
!怠tgZ{a$Ͳ	S#򼹖H	if9̈́s<ڀvY@iYg=cN 9E`eAGσt:zfgE)P!E93T"-)!=*f#JO(%T[j>1wjZQiQS2$zpԈ8bRJFT("ɮ.fSU5ӳ%@V"@1շ^1&Y6@Գ^ B2hW3#Obî)'V%xfTo5d<;HоXʩH֮ kkZ&e kb'
lGO,Lv[!&	p@jEIic\>1nj1^xoPpN(0KkN
|6Gor@r̵W=BЯV,*
(	fr\FoRaX2f0_X,`WsAqG tTqMᵐB1R/Y2teWRr]`NfL.ﳜ/k.<]$iaTH4=^{"uk:GF	l^;Now{N$'Q#m]2]\KY/;Ƈ揗M"qC;V/.p6)]ikߚ^X=6x*0}RyAw茱S!1Z
$v7LH.bXA"p<@R$z.7dü4e$E§16#~@8|A% +0JE.b#
;iBb&bpB &
B  f &$  l,n/" H,`:&@:pA>%
 #BХ "
m
On0J F'$QcbQZذ @}Q#`/;
:
i@>"1^¶f*Q(#  !
RQ" ``*B`
A`*DO%W%[%_&cR&gR%+#(&sR'w'{+!>G6AX$B#ab)QH#$"%}R,ǒ,W&'R-ײ,
R(3QB$q0Iq
`0p:@D`= _Q1'",ْ2+%2--S37s%RQ Bs4K01H$`+WXLsH6<* 889S999#::;R!R%msdI3R>5e<هғH3!|k&r ,P>
"
bϱs0&G%N,Ч@@
B3pBBOBBK@c;h<|9E;"CmCAI6 2<@DmBd檘&FG&ff/0kT4L)
-pC>O:7=HQT>yTE#@s4@60fo
NFZGFKk#QH4>)tf"KVct>pfOMp'nPC#f?,PDI(E *ff UN$kTZk8'U4I	N(8otXύKQU 9qeΔUӴB'PN.H"LrduKoSH]45Q5MTʬ;k4/86=Nd \EN;dUYGs#\[b(f+"Vv-jfOI^a6c¸s~gH"$MLȞ0?iei;'8Zmgita6(^v!Oed"Ij,m'Vt!xW@4>Vok4.S.M4-wqqAD 4@4TN)q6s3hVQ.ƶsoS26t04dQ,Gj}u,0wcGˀöJ :'txQ7y#tu6MS{w%tlrW|{w{}
7w~sy}÷~U~wł||~7fQ&Mi~dx,8}1d4X8X|=\@Dx{I\LP8yUH/$v#XvsX+`H$hS\ẇBAkCqը|d>5Wt"4X*X4d8uxH׋XyRp)踎ᢂkɈFzH3Wd"Y'+ْ/3Y7;W.KٔO[lbKÓcYgkٖkJNwyo{608Ub.TΌlw=Ӑ923B,sM˺l$9-<{s,670
ph
S'o<0 c$%e"'-NI`Pfw#6/_%LGzdG4P0a`FǢ& z,JϦ;L,.%
M&q.+\Zڲ#0ΣzW+ڮmbwb'dz. $({9D# `
lOo)fB!Y)
	m,L4g5migjLJpOIsb^cFgι&,{S+CvZ!iU)#ٺf6@VY#gx2Ym>b6`;#:+ϷVu#fGK@fFTZ2eY7
i}WGN1cþE4ő
oIM~PvDGJI"`f́YqY7N[7oyoH0gwTcVq2sG-Mq}Y]1 J\A`T=۷|۩ cK.t9~]qV< rs}}:.6e!XG%ޥ=m;MK8
ZC['o#fZFdlQ?8GL:HK']vmI' XN]0[;n3^a}~6W(\:%՞JO̲&咽@lL~No0.3o0&N;S~-uFJft%$[l/ǾQYgxDm/`/6I#a$egU["fc1
W84'/1xY)*?(c-X"hwO&ӈe"}Yq[]Rb>hv߂z˥։_}H][xb<0…:|1"D$Z1ƍ;z2Ȇ/bq X|0ɔ*ҁI%s /+  ٴk۾;ݼ{
,,6ovj"ˀ<qrꩍiif
HX(Ik^{r-YAr@H>y}$~+.S2I6znr_?~UW20@}`9
wlDZV7 h1P-hС.$NmP3'@F23%RՂ>.g.	(`f6(B
Re6#h%R<^8Ny@rxO	+ɑp$,	Op,l_%e;CHB 
qD,$*Q TarŎ(B ,jq\0qd,ψ+@p et>>uuuddd!,?I*'
#H&!Ň	ή%!"
֢usk
)\ȰÇ3	"C_\S\ɲKIT,k/AD
0ѣH**V h	>%nCկ`Êm!)VL00"Ax;쉧H@(亮>l5ǐ#'-qT%kbABxLs@th	Os<Ʋsm)	V5!'_\U	Lh"pS=/HO@#@&Ͼ=
*!	~u:(Ͽ@6/T4cpzv!$AaSPlX,bb0Ԗ"3_	(4 Dv	X95JKF[H@D	8b%__@@YcQlP'igUHy9g"1c{ID!B"0ؐfNH[p$`rK!
JL	p#*D#|*jl/:kk$)Hĩ`
z,;j6y6DHі qD409/[4Px8Tz"˦<ધu玈		Q"1bb.˸.J;;|n3A7&q I˫
Gz^'ؐ3*؞ADeh@XNJI,aނզ ⲟE+fJ3
@ʅu!LVƈO_ZX>50u}0QWJ%Lp"1h-)BlsV׊EnuOf]Ƈi_?x4c,Є};lQ\R|\Lx!)*[K!!S/I"`Q	䕄H~˕LXvhU\'IUYa,	c$gi-|I7^	KGɒi_"p$A2Ӓo>RhFCQf6SPK@"MБi'F6'Ovi?0:6fiC{:#"Mvr䐭`ŎW
b($SPbKNjJss"h=KQxF+ZEpKudtKRpҖ4ԄF4n&'CtXwp&黇(JN}3S44RL{<59ƾ*XQ +K=ˑr+ǣ|.Bl$\Ā>I@IbTަFL0İb{BLmD)X	xWp܎+%FwM}DK6Fu]uqPagH(BRy	ALjftL77J%YLؼwH&D}u~|)…|fcaľ= So-M
}l]C`NI	Bh2'>fcULdF@9%M6ñXr$-=	xMH,%H)]~ė!1zJRjx%Z'+1hB?ЍVD- LϞ̣@^3LL -3YԲL=['y>!RqZ
Pkb+|栰fmY_@;6& \g$l[f5QB0b
	t{wk=z1<\n#4|;Νy'I"*\%+hIw1qSng &F9('N/`#'G@2Ɣ]o^	Xї\)j_@h^͙T!mpaZ]vsyKNvݘI5
wwݰ]6oGv'KfO!z~)=DOowN˾-?n^,gIhKWTUlI̎+ɯUTKUE}FY
?Gɜm!OtdCa
4LCTqB9DY}H		 $Cْ p1􏑣44i	
PFܨc%yCPI`ViU 
[Y	]ie<`Vri$kYgma/z,2XMP)7'a>
i		I	òE6`'O,

LՎ`VVLȂ?-(hiO C1.F#29b}or%恟睑	H8Ej۩	֠pƇZj#	:
#:qR5-1jRR`T7h|Jy1FJLڤN`GV01E2%o1,!5ؑ&JzFnp
)r>YWz
2Ȃ8PBZjڀF[ON]t	+/p
@~=C?4-ܩZ)--;px2h'JZ0J5[䂀`P*LqڬwR3c0O$XD+ӑ+]ZFhɊ* r#]4I)~7hZpOJ*HF)sc۪ڢ@d
64Z--p@$	P	v*#Kelk K:2I-Ip,{	 5{	vt
fJq0𲂐0M{д$/, ,n+(ж,0
z<Z]aBۍ+I/J+h,P1.Š*1С
C 6:-Ds"}3VOv(  (b.`)˻ Ȣz`E!2>p"l.Z.$oQX8%[K`;O0"z|+s~7P`#kQ#KeKa;LIcHKBEY6w6p	kW5$@ F5FcDH;fě$)V(+U1;=H2CDTZ0Y)3Kj1- .T,. 2 H.ya)3<74⽞|-e+ׄia	&lgXb8+*B6H6}s<'liKQ˹İĆ		<gMW.lb	/д0Q-zʜxȼpί̬ҫ\]|+{qkr/`I0i(޼j˶s[ܷ}:	ݍ-`||я;;1@00l$]븐Kœ[,0eЫ*4kppӵeJR|JKOb{K+=ž Uń`ч1S>ٙ}1ļЄY<[, K'ͲW-
ݿY켋PΆ5p?:Зݾ΃ݲ/I{%I0m‚]E.֓4p}y]0]}=A}--l1+o]) ]Ͳ[W*<}<-م@jiİ*,.Ŝ\M\bLV,+@r<,+ȃ\ȇ0=+Z/~X,Ѭc,`&>Vl-]_~NCRM?>^~.pω@".Pr*T  K`L{
ꪾ벮P i]p¾ȪeM.ϏήlIaϞnx^]>^~\$~
8*5
.w̮
jD=D\1µ/|	d9Ͱ.eQ'qGLOk(jn 0Y2$.(|=%ި'(
`  p(ak~P1q
ۀqפXwtgx"p
pXZ?{H/JA/0
PxQwa!ZsD
&AMdwo\?^_}1	4v#0tr2p=ݑ1q!G`'s P_o?Aa"qNpq
pD|ȿL`g'taKq_P* !oHHDIHH
HH 
	"!ɅάՅӯ%*#	H& ̐ћHg%NaBLx0 2rOc~ӤyD%Pȓb!F@Fg qRmE&Q	K[JeBEc3}NЭTZH@9mԨ-5$vƲB"	"{(6ghZU,NCpb}K`6Ô&\)tFOC`
kX
G	0OlZ6
Ps]ps8߈Х@,	>bSQ8d'KZ $R8EğZVITsbʵvh)i|.t3yHSQ^Qq1ݵX/]k	LU-}#"Vf/Pa[)uQSHxKG
-vC0hJA΋2I[|0
XmwWE.@*:M8J_D9Q@ք盄
^p
-"[׼	X-KlŐ0䃚F$"+sqF9cw!X!87N=c|4d܇2@Q&&4"hxg.&!HMaXw8o()VGXHǺaڞ҈Y4s[1VMӧvkUGF:TU/y8nZ1'gU#lfX!MI)khi>$2
Z=.'ݛ
t	 ";*n:%{a1%I!oBihzZC!!!D	grqKL8qy3Nâ@y`Y`!Gs7FsJ$zӵ,2y%~^
0S';*\٣#`a.P]8ˈrE}߅plq=<zW>&xGGHrvP<;Es|`;󀱃sPHcX{Ud[{3D%al-`Ŋ=mjBS/?AC1}J@3?'bs@0
JCw&-0y~"~.!Hv!A"~Pg1d`my&A  {mRhAp'+xA[ӣ%{-H}1t1W
 
6qddZ+$F |t1'mV `(CmBa;@`Pj(|00g
W1	‡pd!&&e;@)T/g* 0hLPE9%:ЄEЋ (HP2*	E44SZ䍳ee!p
CPP;֨^Epd0I̸lvhU01Pp&1#dJ#`@(HEh+*&r2PK:#A`Vq68D␏`!@?Ag29yuC9a(٦
p(vPE[ ؉?M!fs-Ϛ\|/ؕ-d"s
 %_P_"?tL)1*Ec]1 57a2,QUқRaR8 ,p**|u<U݈p0?%]گ];uKrއ>P5o"Č-Y'TYj%ԗ(v[죄f$PT7u+jրU{'M4ےV0"6͙4}ʑc*ۉ!$0N	nHGHWߓBKgݹ=R:7EWgS a&g=ƞ>ClԌ阞	k1s
/P,pmDB#RNu?#=B)>f!1N"0PK/>^?-鞗oU˙0˝JPV%bjJ0U[ I	~6<@DE+̊X [<]ñl#6EE+kpBJ` H	#c=^M
n_L"a%m1ʹ\$@ϛ0“Pv3^.u3gtSI]`EQ,F(@(`\fnue"$eA 'GQb~VLF6WL2.SJco`qƂJ0+\R!i\8XЊ0cԧvyxo#@_~?
D@c^tou%@Q.U+óNF/gvpa=9:6iD] ?lr9u W}sEd͟

IIIHHHHH
ĝ˝HɕI	H	HHH *Yc/	8H`:x! H0!		tPJ)sjb(mҵׯ8sEIOΠ!bwȗG)Pyܣ
D4<
39
\Z01p(ALp(	iH 8`f1G-cǐ#KL9%*Kʊ֗ah]iEB]O$QB !Txb`+E1w.FVb@Z6g|d-+q˟O>\9\WhqLְs\W	P<
ING@nꡃM($P9\4`sj=GLA
" AIc4cR1Xf3}柒P~r]Q{dUbwhXP!>ᬆdJte3X%1d@.#u86	BF`Z{\	fWQLbG/1Mi
NS%NWꩣO	Ǒ#j0SI&0ev@%ql楴zI~Xkv-HZ	2H#J<ےhxJh-Cbo.o//W]/jF"){bm~'	S)R*%p5spzr'#;\rH,&ѝَ|H-F-HBK16V"5e;!"ݻN3`j4.=
Ao#|
֖j3y]~"qa~HT3͛eڎHC3pK_Wy;lw|ۚxl5NV;n&&hM=Qm 
l	ekHXZ5 @9i6K w/o觏lY2>wpacY TMa&ܭb@B:1z%˸4?7XяpAXE:C8 "r)90̕~'LIQ:")gM9)9j3HKD1o w<aхA{Ш-3	<@JЂMBІZ`>潮lVB
'Ҕ$W4@&yWA4qlc96wF4NDJRPCF$tHMRTvŨ_PlnSUQsmUSԬZJTRJbh%me>P&\ZU6V*6yXdd֨
z8mf9-Z#:SvU[8ZqaUe,=ٞ6kiyۓu.kڬN	/T2m[Y9tKZѝk$ʰ#+DϧC)a-o|N/'"
q*$]2-vowrh@XRxDwX
RعXxbmn,n톫p%LWܥcŖNy2n=C/^r"[lT~a&fSgYQdb*oYMr
ǼbϬU+YB*l
V$5|q-dx]
<{$:=f7eMsͲ/$hWl↜Q
3ʘ./i~Zי2.-pޞ|
n?+|F
o9վ	<vl9nܶ~'N
v켍} `ww=C@Ao_`uqCm;Jx{
0_FN5}n3I%О}u-hxCi.zŽߺ@9B|?uU`\Tϰ!q&]/P;ĥ]sW$4_XADGzT]xω+oykhGR$ƻy]^vk<~Z=ٜK^:8
&ׅ(|ŞO2*q
69Z{~26GsD}ʆG4bh*׀sygfX3	xbyW}XWHa/e؁2n~&xGt.-,x3YwR=V8({:v֧ӗiȃZZ(_*->b@H4ф4IX~#}Kp#_b!#wIdC0\]^-SxbU30BR0"Cء6!X#`9s͕=c؉G
@@+=W#HcV8P؋(ps%}Ș%2&$R!АYJyCyrHĸqg긎j
p4#8 􊽡,GCѲf+ 2=	4"(y#
0
:(sEIÄLt@#"FZ3KV)З)YHwB)JŐ	wbRy'
NyZɕWY%T_V9_X>iUP)_%a^ce؀[}#	s03xԕNؖP
	dt+XMr_N^rAIzH]gCu!$33,UD`2~!"I'@gsB}^k$\	
XV
V!O!Oy	@_Yt8SzGcX5f~`(a*՜٩#ZI6XfekIi?kH_<J?@k&ddQ3

Zeɖާ>4Z6>dgٜ%$i)I W㘝C^#	ژT#!$`bj:zWQpy8
PF}_`83W*H@P|ԨEȣ0ttP2H6EULCZM#YP	Þ\ꨑZz(:X5	0r>
_vδث@1z{>Ai[3
Z*hCPz芮<`Z&b(*okG`φ`**sBPA/	z4aj
@ T4.#
{x*s"
sU#4#b0|=	r2!gJ*c$r²L˲.|w&C%qИN	p!KJjx-Z  T@T#(FHY+=@R#J5c6Y9Y	t	?%*B(8pQIc$5
˓.ɲG
,u+#Te~a".!pD;k1ˇ[4ip+D 9@fQ:0yf5[0[{i+M<ڥ¼H0+jPkaQ
k/	l
LN*=.;.s.@}L/\Lmr"#	tO ,S,A(b1Aܼ;SvX#~4
GZA	 $^&&5#kRڻB7]_~@D0֣}@
	l\L1lwLy,{lFYâ G!W1C[Q|%ɥ8Ý@$N{5	q[J0|2L˱BŽu\˚UurpAR#X1Ɠ,c[i|[LMŢBq*&#|̦rBKl4>l.A0)$@
=(
LZ|;\ɳZ2]UI·p/+q2 9m
M9\ !M#]%]S@<[FLjd[\?.=8]	_},I00`Ip?3/1((
ӈpt$/p֝7nl-I]Ϝ-maz@	@rDk9WlQ]-_-@)1@n3:M$9
3`/_1.@ۂ>-ԏmtG]~F9ɰ8rzLH!Ϋ=Cp+I33+$0(/`I9s~(  (؜
-=hǘ
j[ٕ4\i	ޗṔsKM&߻!ɍߕ,In-a֍}L~ݸ,=, l-P
@Pk:/J(bN/I~8=Y>ەS&NQ^=@9ݒ63=&I#. N(jZ  -(wI 6:}) bX~mΞ-/d~❰o}qAbnBF|1	j@d:CPў-2.+@0@ +IP-2Ph
He~Fo*nMn(>P馰^2{<ߨ>Hk:.Zǎ"'PR T_t	#\#r	^/^
,p$Hٽu9P?_~u=U!VX9ҷgk_
 nndv>p,BpW <o	QV/ҮF[;MRY \O`"KxʶnFFT?_T#HHIHHH
HIHH	IڌHHɖ	H0)TIף^~mBL!&hˢ%n[L09z0cʜI&aYN'@nDr*Uj(iW	x@R@(+F2JW^IݻL_nLXYф?1eAq
@I %QB!J-\M<Aݾ%)0 .A?uH;t	0mȓ+_μd$HS.Q3H=ʉ$L0@sC:?p	pm1- 8%H݂6H<7#4bᅶE΁v8aG%%="D @9Bb-F_|}E0`bHBjj@ȌFM"_54\>NJ)f%!
p'mtb^9&(a>xFoMg(ug!JQ״@*Ť9
zIA)|pJDzvov阄F&"&^Pad$Wf`wTd@3%>*oh苧n)%r&L`ΒJBB"@`
S	S_lnD*k+`>Bi[؝K#HhK&RXh& =rxL	ߩK	\AB,'YJMQ^+T{C<_8;sPFX%Q1mPpR߀.8R۔cuD*,vB-	LVI4T][8-J25u9͊Lt<{Lߞ !A, Sn
x!"-KGm=RpfJ2=<8
V6kua<4r}B.}
LIԼ "Îfed'ʷeu]eX/{ϼv|?otm&;ձϩjq	F7-i\۳#&:oZv6(Ab߹wmemz!jwپ?p
:/Ur1!طnI,gv˫h{)ǹ.o#h(yOŠSzDwiﻤַ{)cN;wf	ApNxmN?}	O,xA5OE䗺ё{ff_7~?C?Xσ_as z_sjB~GWWH=
?ԠS{rgx<~7J#Q"xm$x"WuHkÂ-0HrB%p@6`'18nrS6V1J5q~N3y(y	GWYX,[O8qQs&v(H=g((+\5kqqQ{4tkSopTHu8*!{rqQ!W ,0IW8UB"PB׆%X\w&腰o}P%g0Qԡt$&.1>x	Xv_acV! ͐ 	h{S~f7x(tAar	8hX֊ W
(Yx\嘐`$cOB8DXufPI	8UnpHtȒ`D3Ɇ5i;}  >9/.iOyH yl%Xα{xq'@OI'АQ|Za7KAhc锋dl)#%|9)tٌlxsY"g&HUYm(Jb֠C"`7L0^Y%pTr("Ln12#pH&S駌A)w!pH f92" 9*	 :9
PSI"H0'jיcכyFYH`b.1=IAP$9yڡ99	ùe@JFԞ &p' 9zX9y$Fß @NK Є9}	LʜZ	%@'IF{)R0,:Ot0ڡr
G
Wy!K&4H0"7#EpcsH@4*xzB}K EzY ELv4!{5iVکAګʫV9aJ0tbJtd"=0cؚںZcy
Jz
Z*~nʮzg
*Z䨟uzQv¬p[	J	JAH#j @?t1HE,@E4X~!8{B>K
?J+	g1YIOMKijTVKz
Ha+)Y<3gRmb19bw.6"PѢ*!{bJ(S8a*:Xy)@,	)[lKQTtѨPʫ[jI uS8#+&YꣴkpPAR$0#l}|C[#YMA!pKuӢCkCI~ۑlYз3)i ;"=II2@,D62=\K8&Y+\kcoJ]J/ACek:D7='\䋟Չ0K֍ԟBC֎ !֗ւr3y=*t'}-	Ȱ!='zPs
֍#~)
5
:[F6-)-%	@ڡ'!Tv*‘OJ'V #Xۘ"/cZ,-}M$
O3.L=dA2ٙ*ެ`1đ-)M ݉@Q3
!
On/qPJ߾=ê.):s
}ڵ‘{ـ4-I۵

`"m70~)v"9>0 p?)Ѥ+~SCT?ΐ	kBA&BBD,ՂICICrSb
71 ,]h+S	g^N9#p)"p?JdjMwZqJiqr}-z.n(->Q@/=dgQߍ6
ڄ<ʢK#1͞
A 
a$^,)꟢,(fOqW=V"fd
)#fZO#?*Ԑ.~));Ag
iGGHM(/(8
I_.!D򗂤!OX
|0?ԍs
00.+FU,>(J|CsT4}s5[5~_#4>7..%N2F}\s?x'hV.~;`<z~S2n̃B1YSJ#d3}ϋ+,dn>-L
N2߬f?6`/H2 _Z+Nܭӏq~qf~K\)@9`HIIHIH
IHIHHIHI
H

HHH
ƞH	IH	
I NÇ#J3U]F5@Ȁ9gEz%LZ|Yw$M,$?J+CH*]*"4H7W	j4uzU*PIAc  *H
KWjGG
L8zP&X˘gΜMƜC%ykdžSVy1ϟ
yB~*ͻ}< -ra&c>ۃ1hzxW4
8N[wU9Eg=I
=T߁ɗ_}y"%ΘEvx1J| "ጘ\yOhh4)K00BX.yJ"98͊! hrep~ex]Ƣ&bb SSjR9̛q*ќ)˝]M0ބ)Rj!J\'9C mL:鬇j!Y@[$ @J벝ڊ [2;"IhjxzI#Xn6ضxk E2:@`N,´L+0rӪ'9@!9prrd2 ? F2nͽݜT[HmHt4|PK
!y
X/v0P!5"ͧy;МY+rFCh@ @VU2yԏ}8϶8E%A(E7]<y[`熆Hި4sĕ`U
H
Ķ;ºƻ`/~×oϋO^M{~=٫}fgUVş?B KKh2F	RC/Hr@?>!O0<)
_0>:o91H:1KA/?ˇGM-DK٦L2U)\D9lōfD‰]\nj` @9K@VIRRF>:揄8rFL'l$u&1ʩpbO0MQ#^f/
P2	@TىE2]q
Om0
m)\FIFIrLg9=P+	
TgBb,#@i13&gIp7h}	N'
IDLҡq#lr7hr"vMBaAEΫJb8hL	q1HD4Yi
:+`'CLQsb`1%f1[KWuhz¤*kC5p-," Qpk]sWz0׷2[H],_˔Ǻ(hc/+I+\:B+pI@Mr\RMvHv┝p
x@I,k	`EI2V{BL/w2W`=dW +,Y>c@r{8~ߤ#.yEOe.6OՒ<-sR!2iS`9X'W
L@1l^H`/}narkd8*LJeZ7:cp'M_pj@]i\IˆyCidĨYEnP,$|1M!zo|epUE)
64tap5k<QQ[m^Llڲʼnnekh5h}"Fqѡ)+fD׿ 0$e"OY/6H=|d1|r6Ј؊xH(q6kc6x>,#	{ы	ȁM2c8exJHkTb"Ĕlȳ7)6WC˨
%RttG-SRxyYcHz~LQ|I&qȓtTXo
&
 9[珙!.p9)03 }E~L1Vҏr.!	$@-@-qK!rF5iD3[)I]9BI,p$)p=I/nٓII(@a
) JP&)dXPq
0 -D8I	).20.,+@?IY0`QJ!1򘐩%WI@3 II( 990 ?)s)9
XyD.Iƙioʹ6y/0=)zٕIgΙɖ9J)‰o9ɟV90 Y,	0ʡ-
-P
0[p!*rTZӘ@x(jW-J$PIP))*I9?y*Pf)
芀@p.Ǘ[*Q,K
)-2@;/+I-02	I	J00꤄z@7ZzȊV@,ڕ!y)@.Pʗ{٧( 㧘I!ɚ꺮ƺ*$pvg|ʮzd*
^:3Ъpʯv[V[HQ
J+qKٯS&K({03T9`"pB;D[F{HJL۴>8;w:;#3kZ+yGb&[[fL.ki`K/bd{r;ygokkm;/owf浤ۈz#;+{˷%hg0jyD=T҅wf.;;{0+0uߒڹ"K;63bػ#H1{;/,6S-ya-+ͻ,{s#M$k޻,;[&K;+/k<.˶q2x[,
X;[\$,)*鿨$!!E*©G6Ⱦ"2L48I=~Da4(\pbZ4`P])}0aFW=JA/0D * {޻*VX} ]kJ򷻆f' &Y0>bE%z!iq
!O[K|kP
ّM^ז3؝=#P[* HpգM#%h֫``]EZ!H
Yrи*H`^<'L"Mݴ"pݦbrt}M޳*ܤ/]MB҂"0pY/-a]}gCcKA;5ڂP?4r>#!1;##&@'~A)&߳-3~Ap
17+4~? 618*CX'1LE%&p2->#T
"a*pY~VN.*)pm8j##hFF*7pN9Q*`x~B
=:a~-I>
`@B
qMMt\M`q<ރE>B~@롮ѿA ~ŭ޴E{~;PKڵxlslPK+AOEBPS/img/strep039.gify`GIF89ac???///___oooOOO@@@ppp   000```PPP!,c'dihlQ,tm|pH,>ͬiB&4Zجvf҉ҙizn#	b|~~	yyvW`Ne1pi1MQ]y
}
j}
y]QM9=JOQ[y})}yZ_b?PZ|AxZQbLXLZ`^
2*HqO]	 Pŏ0ʅ
8>U!8W
H8d)%zT0 ѧ
$bKPXېԃ&(#]BC0˶Xy.VM HC!N%kWCn'ApF.8*$[ݬ}@y0MN톀#4 x,07u$(@3i
~ߑ2խ]: |p^(B~-!@}gdv"$@Six\,0K)"X~ɘ2$PEt
`(w܀HGd8L@Pd$d+՟W1LWm=y\jBu'B^0B:)C0wxp>䍚.0%6uFbJ鬲kǡhHj0 ,;wm/v0((U,p8
қ,x\"l.[s8k	}݁;Z (o2ژ"I/B(]^q+3j:gzA0o/xk/		ܣ8g
(qjaַgr* sLɆ~5؊^
"ZY&AㄸHoԝګp$]"#Y"\q
lb n`qIo+%ր%zlDqOYZNs%lrڄb]p
,r:a˨gG41:HHFX"F~0Jn:DHK&p@$y ǓTcڕ(Q-.`gVy,WpH+
e0UXXRr0ad#9""jBMiZЛՌ[ID:vvZa)Ѝ lI"b!N+aIOX FچEr+T<}OyE}Ek"_Ԥ@NxrSua:DZ>\8j#L⯀+:Fx^)ER:>TP!"")a?qA!;EOk_Kآs
mro=	e
w,n0k$X*r[\WQg
0]T7Yt
j;w'.*[0QCkTjcT디Ŀ,'+- jμۣ'r1@jdD&B;Ap>lI/Gf4w˲(ք!@''51'WI
X]*p$Mٱpx3O1&̍$7rf-AJzGeU	gB275?:#w'rQ@
{܍:>H{hv3^ʉ&ѩI/ڛW(=ASS}ALQ'jf+VE[aԞ@M@prdʫj
=!nQf`훰)s2ū'[14޲}	7rIm|[A6@9/ica3=axpT"5\GIP[9QWUn23wgAҀiԨKY)~##.:Rnט~҉~(ºBE@nT!A䠹7Y{	WD)]]> 8Fa:w
#KU.:}+s0=䃼&GGyIeFӊz3/DW2wۜ;3{D8.ưc
7wvVXJgˡLkfdP_ջ}1KmʾAll
*V'oﯗ}0LbwbV&0#hf)nwd6$aw\t ,NEw|tQ'/ԇ-f
a*_1fs޷c&6pq"p6%$؅%X-@TfUWlǖ=uơ$BG*0ӒuZ##fm"F7F8@g|fQQ\o{v5fi52mQnQ#Y58 I]!R8C
N5VZXIk3XH
Pk?u^E(n[7aeHx.p.?}Dp'Ѹ{Z(U_܈U(>)HKX8)voG
{=Gpeqr$t('- F
VבOR)"uZpL$uDtp&`p sƆf6]Vpto	W)ғ92' Gz"s"rycnp!#R$?r"@&)sZ`#s#xבiarkq"]2*]
MG!ɒpxS,6N"|}`re|뵜8{+-+Ud-֓9GJ76ivV7c'(BU+k|`|rUEYa7,79Bfn؂ 
*96(t<%{*v&Eؗ-ѡ]L,ܣ	>{ןGQ\gqs"gtF+`a2բz)6w3|L@шO_gV0RyM5
rf#;ב+8%2,jU)2J68r^+ׄM^m7Ah>gzBxWeQh+8*((g(h8fBȉ
*'5щ@#!*$B䭊h!VC=gꚧ{X.T"r]3'ѵ=т6LWҟ`d#}%0}*f}~̒عcGL{s}>8IT	SdAdƶqW'rI٘+;<1hlsL6m|Ɉ]n.9GƆ>#w '"{e/+T8B,01`Dg&N
b
֫LOHrPoFLZHu|?~q).X?N
wF
>ogq/&a!jEȯ({N"+ܑدJtڶߞ|jm˪gB
jDx
ƺ-"*sjo͙'ޭl&%㒬}HlC@=0kabl@I,˟jX1J?/\H/TLoIߪo8'!
r±<ӵ}㹮{!QiC2>
`]HI4.Lkv`=$>lFO(RABf3G	rWd	8h~UW3E!L,&GR.VပbK2@'@j8#C@c)
B$YÌ	9#	:pb=@`&QUyYqec(CYo9$gy	mצD9Ku"^47@drPz7~:ԩ`YC1T
C	0TX@#0	5Djlzj>.
dBH^4Q i#o X]B%XE0C!n@mwEBxm1YhHR$1́r$8!8+{	߼90L!&gFiT4mc"a
TZw+!+q(Y.r00t&BiDLˌQ,P&M[{dSfH&"IC"9}TMtXo?CLl%ThʶS5L8ǡgpq+#	pCBˉfZSC1
ix[E1UW5CӘ='<ѱu	!`K*,=d
TD$jz:L&C䤪.)KPdhRW3*OTOv8'}4ґMhB &h949hz-Դ	vp2v';vd;@`	7'<~C:&
 ӚA9gpPGCA,UuդkJ^k"	|Ӫ%Ï2Oj+$+s[$XxKZn9A7[J'2 Fޅ,a`wXTcO+]lp4	msCZ 
%;ȓ5r502gX6\leF5čb4Z`	dcLQT$H]@ii*@HTml,B({
Y1`CGQyUV/؍ֳ\ei#KrMoK)buWF6#g.yp	U{"~,^¶%z',SB"WM*_l> S.px`Q(b
xsF1J.BD8L84GX
2f%uZ!9%zc8$#
Xb999Hĥdţcʬ@doXHq
LڱAo<>Z=@,`>T%)YEËA
ϓ[	۾ \[DJRCM/Ӧ:dĝ[e@x>]قҡDo9dAv<
>He
p	q.'E{%C\qKCaY$E˻0D(Ј-NJlie~Mȡ
4e\_`_NipS^cEE'pgh(0*
nA$Ĩ|ih)π)~nK10vaNM,T
'+lP4F(1Tb]	~ qi<0FQeK=C{"#^
_{ƖDz\YKxXjũnDz&^@=fnVRx3Tq%Xk9.8eK><0!4¬zG/F稢#;@G+DI!-	JV;TLFHuپ >4\)mtVD@YM+p%[mb2"Yg}JXLܤО?4BPx[d A:-A~	ZjpeC.%ù$F:L%,:	`ŕna.	d(nhw%
]Efl'
B	@rBб@g1
tr&bFBLAj͠aGͩ&fe[ůx]U.BARfwo!m9
c*,,YgM"(DdD^lnwZ灶B
g(.2hNlK<6Gx~ȧ
'Km
Sʊl(0bFhN-\iQkiMԏߍ˔ԞDUhƪ
fAYݶX= aCa4E.3_JIkFN"i!)4Y"&QB/xB]DDD@/a8DͭltZd'D93WA4	""!avtB/"s2c#$^dbAoNF
 ,8l4FbJmt+!
`c̀lH#54ZL[KtP_bl"㮢1IWb*zDt+2g8>-)_
JTu8^5YZZW!Z77)Z2YX
5|u5^Ϭ=|7ҭtbawƈtM2Ë)ȕ%Dt۷
4n1Xv5\uS6#Pp^,l\˴iW_D^?#q905 mfd8(CtpC)|	w y[GP`A	}lFy=
z&Osk
;Y U6RF~aG@hK	`$@G:C8$B!
x[iN+xxO1BsB8Nu6%TW#,2ƂM\'~aJX-<@&`R.\	f:%ss0B@fd\@AJa8M|dX%2$NQuz@ZS48%F9;БH.j*
"!Ě~ZC@Yr%4BBoX5E&@^eiDipKR-,d=-)*KCpbxkMp'†$і"mK{sª*!̲a	[~l!I8rH|(ґi0;xA1h:2Z3yw&pߌpd
o C=j,B2`18pCн
-F!\t
G5[$Њj:zB|;!kxs3it\bڗ&@<95׺5HDģ>EjbB2րSս`B7dd[LţQӣumS/5
B BB5:o|@Pm:Cvǰޡ$LLA[B€`3\`BǼW#`'(^宁	dN1V$pFv
QdttR
դ?EWʼnZKu2EST-Eh.-_4Ey|
F_$lGDD
PMB4N+D@6i,);1*jܤXH
(K.J]@nm
X;Ht8B !x:r@~2	mV5"偞iPTH՝d2C](p\b# ftJ)@W1iXiMFWBuya[*
M)kX)*,x/FKH3*M3CCV-e
jpN3 ~İ" 
2gjp1dBMl$A8Ц3,wm&prx4y[r3q?P
˥fd`ÛJSn妠lpX-س
{"	9K]:Fg
C>;=^xP`&oB٢^`:݆ms\7(L}PX'$wk]P/H~']oJ	-SQc,~uBo'IˉD$NjQqVAN~8	2jfDBB9qnL'эu軮
)ާ$H*0y w%d<ɈRH&ÔAH	aK4WZ#s/̽l!/7YJ8bYgixf<H8FL""!3nC*
fa5zRHޫd=ԕFkuj)T HAknz-2~iN⦸D.*ZM-]ԁD.n
񗏕cK|I-}hY@{(Km0_,"&݀ 54wZT,qɘ_Wp5<5hvKaÄanoyPm[AJn>:Phu$[Y
@tnaG
:&; X
TtxGB,_ˌa&r䌵t[IQc|ųBY~KB=XqEћ'_=#$9=U̻F߽9/ۋ#;Џo[؟~1?(ߟT@kw0	zO		RzP	80
x i/\`n``#@i׃h(3xG E=9 w&-UF{10iXc89rX4	|a@wh{h!1
{`Cwxpfwe[	wb SX^T	HMX$td(4
{؊ ˨P荽-
qf`4ۘ.(He(8n"-mÐ~%݈.׌討(َ-R.
ɒ-/)&Ȩؑ_;!xG4hHyI('		c \?=%Y'Ж$F
5w@	 `GPh@\)@qy}P9{	#	82hqYp28^醂gi@ȹ{X9	'ИqYbɛ)&Ќ])=HdSot	ߙcɟc)q#칗	3فٝ&c)Y0&@YM)dv'P	镵9qI&jF
چ@tɤrٚ\ٕәyf)f9(Iَ,ihZEĦu*w
Xy-	nzP;1HYp頄c{7X
⨟i%a~

p;ɘ0EKB8\FIФ6ѕ`	s	کjj
YyQ<~N<1'ڥ\z
ΙJzK^Jъbʤ"HXYj٥2x{H0XXcZnx0X9{5婃ڭrZۉ)]
XZ*
j{	]=?jܪ	Z 
ڙgߙf{㸈P𙱹oٴ`3u@nٕ8,n@AyYZh
4k{چС0ZHإ~gk	݊WO[]ipt?Y$y7ɟh+ˮiͧ )ˡP8ͦǕă5඘2Ĩ(QΣx ]U[ȱ [VJ oמ2)pY }ĈiJгIL(bفK(;ȱXʍLiμz퉝a\]2,1ߞM0npa%m;~=\D.8tyZPȮIήfjh
ڋ:g䉍	<>;x)Mt-)㸫ӯcjo~~qNYIu{蘷KH ٮKW>NgXPrQ,K^0ëZK=K^w!9]J'b[K׾Ҧj]Ʌ'_O[fC&;9.[DUɣI\LN0<u=燤h.)Z	L𽚪LXʜ-xȇy{K~*ڎֽPඕZw	X??95O^ѧw,0P>wxODa{%9th?{'EnzlI`O
5 QY/
^/q/mjEaBIox~
?YzrDyHɋKoH	!BlN
OG2I0YIO3!R/Y{xI}C.؎*ꈎӌO%cp5D^b <$E׺/3]7;?fp (y@@RknE84p",:^ۼJy\C@@D?`J ccN\]ScTWbJg%Þ,C@RI
K/0ZFH@T2@FisvBC6y9@Dy<F”|B#(`x
5!ЦyWČ3*tw YG@&+1si(E<3^$(	]t	Ct xp&ZKdxpأ
h@#
Rn8:c5Є
`ˁ6:C$%g>8i=XV	Bo@p.ĸ5,?	D$P >Ey@XuCF6w
#``{C8-xw,`),pjpV)
V`ه,ky0[f/xQX@a
K?zbVz@t@C!b
Xgސ-8R(dnY"|ag)􉰀nMU!8\jd[WuX23YlyE E*ے_}!:ilivZg8}AzyPv"qg-&i`2ŕ`pݞq:hV*bu;)mWL-.[jf1P$kped#e~~h[j3\hyJk).knmj_$z}!J3 t<#|pœiHI0`'l^8d{cB4!KZd@`;t"2Rl$2qzuO3HlB/gʑup2fQٺExE:JhJ1?INwEK.(@Z @<
pfBG-P׼.Aw@!s~Fjzpn\xڛ6C(~x s%N3F,&%l]ài@V[E渚7qzf]V1iЛggI]gԗOhCB~1بPUkc0},Hw-y|D2$<3ȿ.(Q}ԄsA!Z9sb959,>$}(Oj;]l},",wR^z7Ҵz0
%vQ#D@xuw5M~^7{=ugoA9n&Vn\$>F/2Jux K#i~q@jtO?(gPqԋjb8!40ǘHE©ٖW̛Vi|GBLpx5$nTFVD6=dta`ʈ݌PD&]O2]AEÃi
mDνfH㍤,Z[pf$Wܰb r-V[ZĥH&&dv.>B$m|Ye|)JXxuM5^gK%9%V,k\孊[R~b&wQa9a$VmZ@VUeʀ-@rir@	b5f!|flZ~mn&B[|Q_6
$F-϶`ש	Zgb
Qgv{_)LfxǼPeExEN\бZ툦@|HeH׈m=w݊2͛E|FƁW!)aQۄ'zN rR:zحnP!Щjg Uިᆑmb%Wõ=T5
*qF# hpaUOf'a
aɢhfG	FæjaJVU7nB*gTb#܌ibpb5Ƒр!&V"N{2/CQiC_fв&LA~v"ޘ&FԒVVT,\(k6H\Ft#6ƚ[@dA
9:Z%9PУU9N>#91ڮYe%ڤ}W#>6lڶ׻JURNHfpȭѤ0
2ЖWȖu(hACfdfKmϹ+@|GDB^IIؕR>aDqvqq
UQigŽя
2;Y|,FaIӥf1XeWU8m]tj*K$aΒE Dk"
,V
Q+w+rU
B(?=']vhď)22RH0ܦ%#|N`5jVf٬5+s0QlV$
!\1$Sǀ$ۆu|Pj-,IO8eI
cve~^(|B4N;G(}2
Yf&*EWEF{04ِ)H/vo4MuߢlG'V؉H/k(tKtz1/ɴ%֘qxf1ST(QD[}rYQ--uY^__$,3ՀTA_5I` 6Ï@?]4v\
6XiUZ8?Z˺Hĺ,2jKBM=ʝ667R,lB6lƂghň][f	a:&vʛI?].M-ķ]rd8Y7DP64rCPmc,mO,$n 5׳2IъV6wЮVjy
@HT`BOnԥu8W׹.bqr5;`Ȭn[DTHs fcWv]c$뾈Cb>6q^8mt	e!:ٍ).Yo2/pTkA^z]I\ndx3
BU/g•onr.ȴi,:9]矷Jg4npdĒЈﮣz`voCn8Nyay!W6ef -2
z6I^9(빰$r;
Ro,xdg2
FčUCq[9-?uh,$
+

1}ab!iؑ|9!7WiC=,XzW*ޡV6ƟVӴa50FGn%ˢ\rg*+"[@#7"]vrLP9FuF2|
$3*i=gۀ9]cq=N`>v{Vp0sMsPF}ua(0@=7y	84.!Pɹ8ƓCITkгA3C
#ǟ2Mn_@i3!;~ w%X|$`FzHS021&@!p0xO<%6``O6"hԵ#'6KkD[l36
mí6@	4e 45'kx0@pD241eEĘH&xɕN%z8|!VL/),!@*`-``,2%0
wB/6M>G1*):B)bb%BP!%)b+	iZܢ@^n@萟( $vQɯ|00BJF1ġ>fQ!!	@]D, NM]Ļ$PBaLatH!zDƈrK7{xu%E)'puKR
'Lt4xB?T811aJ41`3p
XʁHen
 
F@\G+&aۢV+2tx+rTNx*$&u<``ޱOvu_/t]4^`9jP=&@0X(SR5!+@[E+o?yּnG#R4RM**]L`[Z̫&Ī~]FV頎@tYT0017fh7VxP㸰UVlxDQD*,jÌB(5xIBÅcpIqqod
H!C=`࠸mKaV3ՃBa@D-+:à\KE䲈t%M+t@`!GYǚɮn#5|=5c!.)ce84)_C`:\2@+쓊xe1jR(}pE\B7ÃPپ٣PZPIQ
vOcܺwslh:(tӚɔmkot&|JA:G~xLc
̉697t hNO%@gjQh稵@7}v}D1T$VfR
	XhE@+mζ
p8H&Em
<1AՂ|mqK&Ƀ][)IP!-m; ;ٝq݂vI3hg
zڮZ(xR+8X. 
-rY| $6	.7P6dij\Sl'#y,j`PZyVg"!|m.&ՂPڄ7 @QݎS`Qw5SZw`)CG+܊hWBTO5𘞳Lcbn;p,v
#5$lx[5m
M;T
=2u0'1?$ZBQxX?;dg7K'W!r@b! [*q!!'*
A[+PTjB*M !-@lK0`c_C8_n׆T >)1	7[Q"c!w3@CdQWǃEWtV&y4-F۠Jo`F} fFs>Gn$P6D#G#FanKj_blv֕Heh!8auGq8d1ev vɖ,dTgRzgJxqJr,\rkmj lbB&R6$:irؤ$$%1N4&c2k&Lhh$jmB#t

D騎oRw+q,p
b,,	Bl3,R?v".)@	В+@?VB
oFmQlB OB4Ixs(H%1"2eV3`vG!0Z
1Á3E't$gÛ4s&s!ug5@w5V@W>C8cob>XJ5'Yp7R0l:w9s4w~G	E5^!7#@(ꧠD
m}"o(8q=7#µ	ƂnXC1).T`/hx	+J >@+G-U29NfFpC/w!Uȓ~!#z,Z
C*&Q>Ih&*S[1?DY9%X.
`|q*&B)uAqyB4*Eq̹핃ADa1AFBzgD^Rxha@Ń.6QaZt'e6XEvPZa`rEPk8pL:y>GSf0x;(Z}r̷K[FΌ{;9&TZNt;%I\bh*.e/CjUQeP5:","n%5ϵH!KxLP
RBSEu5G=SMd{͈Nj5I68Իey?WQ`7-<`x}%mڿ#
Уs[[]5VPlZL}l4̓Ɉî82\P4,pF\%\s:"<gs\GXm+'[PB%j0)ݮGAQH4rLYY?&H+`OLd]-qp(bf7Q3PqjIa-NnKytQ_Oa
5bq.nT)r]yf:8*trҘ95>VS[KGvr1cYp=v9tI8k,B>S#FyyT	û.u2v̦Ud57>RyOرk	u7bc;U|޸e!cJ{'.1S޷_(6Zz2M:V1$]>W]/!L;J?hb&
8P;plA?2UϤd7s&@,xyN}ГDi(oah=a<2	e\V'*ADQQ5za!`Aupya2uD\ˇJwn]mۮ-E|b8ڤjl`zɫdoʘڊGʡQׯOj=+}@n]},БݨtC}Z(b2
(2xz±<ӵ}O@ QR G9D(L!q9&D>NBAu}EM2Uy8}d6
F~ȴ80(|0\}$4,$(, ~x0&<$($TH;$ |3/8lWÿ#Wo3V~ܼ
pA qZpKPa}𠩀d9k6o\%fL@!@L^w|*h.Ȏ"qT>qP@PnAAY]Xd/Zt1TAS8,Jݻyg̩y3;g" vͷSeO؎Vo
=D<@
Rc,`p&&׺}mi[޲SO(t63w/~ 5JUy
>'08/@H7Tvٵ{4`Սۆ,RjMŖA,A^Ip z΍XbYa|G"C}HK HkY46R	8.g86C1$Bwb>
,%'KeȸLj^Bj]XRxRQdÒre	Uq9*5TJ&@4@
-713ms*e%rY~ >K&+;EҬx`-
|ꨰPr>N
)U1b4͌jT)8TPp# 1[!kP6Пli2
JoHBp
@HJ)<,&fEtbbL?	joD%p6,lh=Ӆ=
Dݷ/콸8-ivnw\?49*#c1MEebVBL|cx)N(eMOxC?8X4Ї09;B)-?[ً,`
 lKb/ A-!-yln@FuȢP&%Q@n DI*7-nJeU'$'O{W~RT-Pl
!xW~=فLSPg5)#4	gp)Fk"2:·qQmb5!YB[QQz q?oP*MFNB~'r)$QIs%)K]*QMTXZ3^E@^+\RN,![DYZRs$8d΀a]Ǵt1Qv¸C؍v;@1A(4yљ=?ŮHZZQpQ>[)0T=D5`wI›
HZiŌ|kfN'YϦ&/`Ϗ)lfA$&<\

U
[ /wIZ&ZDd:Zw(D2.P_73)y	U2jS]ʚC{U0U
T9D
fx rVوr_aUm.+)9aC)愭)6p 
4fmް|E
QBEQVۜT9àQT+LJ)
}r0m1I.ݧW*5h/UI~%8ynђ}q$`$Ȋ!c#k"GR〃eͰM4QJAVd\{@ٕS"A4WqL~311:B(LX!6DB`{.~p+P2QV6˔9i;LY%
,/8a	%lU%^
F)d39'*{+ěm@eVp:	l+=UWpY͡1l,`SI[@03en7$gMVZih3zE,{@#P'A!kw1|n/p.F7{<:4]'(G7WrJjk	9csBOk{Jך4tXW}:y	TQ*o`
x@#^/t8<ɽK;*wDQ@~$`oWQ\ZC}@]] X{:l=|gaL E[?$0@v"`ͼȀG"}z7O
t?$04߻
D݃3@S|<gcCUU@H<D_! X@H	*=x_G0`> pM`E_@@Rr0鵝]Q_	J@H`

ZD^_ 4h=h]xU-<A:_=TU!З9lF_t!d!a))@".~Y0b$2"z"baޡ 
^ ^*"f@*&	!bJ;PKC'yyPK+AOEBPS/ptrep_config.htm


Configuring Oracle Streams Replication



Part I


Configuring Oracle Streams Replication


This part describes configuring Oracle Streams replication and contains the following chapters:







PK["

PK+AOEBPS/img_text/strep050.htm4

Description of the illustration strep050.eps

This illustration is described in the surrounding text.


PKPK+AOEBPS/img_text/strep101.htm"

Description of the illustration strep101.eps

This illustration is described in the bullets following the illustration.


PKGPK+AOEBPS/img_text/strep014.htm0

Description of the illustration strep014.eps

This illustration shows changes at a non-Oracle database being applied at an Oracle database. A user application gets changes from the non-Oracle database and enqueues them as user messages containing LCRs at the Oracle database. Next, an apply process dequeues the LCRs and applies the changes to database objects.


PKb:[PK+AOEBPS/img_text/strep061.htmE

Description of the illustration strep061.eps

This illustration shows an Oracle Streams replication environment with a capture database and three destination databases. These databases are:


  • 

    The capture database has a capture process and a queue. The capture process enqueues captured LCRs into the queue. Propagation B at the capture database propagates LCRs to a queue at destination database B. Propagation C at the capture database propagates LCRs to a queue at destination database C.
    

    The capture database also contains a cloned capture process and a cloned queue. The cloned capture process is enabled, and cloned propagation A is sending LCRs to the queue at destination database A.
    

  • 

    Destination database A contains a queue that accepts LCRs from propagation A. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database B contains a queue that accepts LCRs from propagation B. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database C contains a queue that accepts LCRs from propagation C. This database also contains an apply process that dequeues LCRs from the queue.
    



PKSQJEPK+AOEBPS/img_text/strep509.htmo

Description of the illustration strep509.eps

This illustration shows an Oracle Streams two-database replication environment that includes the following Oracle databases:


  • 

    db1.example.com
    

  • 

    db2.example.com
    



Both databases contain the redo log for the local database. This redo log records changes to the hr schema.


The db1.example.com database has the following Oracle Streams components configured:


  • 

    A queue with a system-generated name.
    

  • 

    A capture process with a system-generated name that captures DML changes to the tables in the hr schema from the local redo log. The capture process enqueues these changes into the local queue.
    

  • 

    A propagation with a system-generated name that sends changes from the local source queue to the destination queue at db2.example.com.
    



The db2.example.com database has the following Oracle Streams components configured:


  • 

    A queue with a system-generated name.
    

  • 

    An apply process with a system-generated name that dequeues changes that originated at db1.example.com from the local queue and applies them to the tables in the hr schema.
    



For an optional bi-directional replication environment, the db1.example.com database also has the following Oracle Streams components configured. These components are shown in gray in the graphic and their actions are shown in dashed lines.


  • 

    A queue with a system-generated name.
    

  • 

    An apply process with a system-generated name that dequeues changes that originated at db2.example.com from the local queue and applies them to the tables in the hr schema.
    



For an optional bi-directional replication environment, the db2.example.com database also has the following Oracle Streams components configured. These components are shown in gray in the graphic and their actions are shown in dashed lines.


  • 

    A queue with a system-generated name.
    

  • 

    A capture process with a system-generated name that captures DML changes to the tables in the hr schema from the local redo log. The capture process enqueues these changes into the local queue.
    

  • 

    A propagation with a system-generated name that sends changes from the local source queue to the destination queue at db1.example.com.
    



PK0,PK+AOEBPS/img_text/strep009.htm

Description of the illustration strep009.eps

This illustration shows an apply process applying changes from an Oracle database to a non-Oracle database. The apply process dequeues LCRs that contain the changes in the Oracle database and applies them over a network to database objects at the non-Oracle database. The illustration shows that Heterogeneous Servers and an Oracle Database Gateway are used to apply the changes.


PKpXPK+AOEBPS/img_text/strep038.htmB

Description of the illustration strep038.eps

This illustration shows an example of an Oracle Streams single-source replication environment.


The source database includes:


  • 

    An ANYDATA queue
    

  • 

    Supplemental logging specifications
    

  • 

    A capture process and/or synchronous capture
    

  • 

    One propagation for each destination database
    

  • 

    Rule sets for the capture process and/or synchronous capture and the propagations
    

  • 

    Each shared object prepared for instantiation
    

  • 

    A database link to the destination database for propagation
    



The destination database includes:


  • 

    An ANYDATA queue
    

  • 

    Instantiation SCN set for each shared object
    

  • 

    An apply process for the source database
    

  • 

    Rule sets for the apply process
    



The environment can include additional destination databases.


PKlJGBPK+AOEBPS/img_text/strep066.htm

Description of the illustration strep066.eps

This illustration shows three Oracle databases named mult1.example.com, mult2.example.com, and mult3.example.com. Each database has basically the same configuration:


  • 

    One queue that is used by the capture process, propagations, and apply processes.
    

  • 

    A capture process that captures changes in the redo log and converts relevant changes into LCRs, which it enqueues.
    

  • 

    One apply process that applies changes from each of the other two databases. For example, mult1.example.com has one apply process that applies changes from mult2.example.com and another apply process that applies changes from mult3.example.com. Both of these apply processes dequeue changes from the same queue.
    

  • 

    Each database uses two propagations to propagate locally captured LCRs to the other databases. For example, mult1.example.com has one propagation to propagate locally captured LCRs to mult2.example.com and another propagation to propagate locally captured LCRs to mult3.example.com.
    



PKejPK+AOEBPS/img_text/strep059.htmg

Description of the illustration strep059.eps

This illustration shows an Oracle Streams replication environment with a capture database and three destination databases. These databases are:


  • 

    The capture database has a capture process and a queue. The capture process enqueues captured LCRs into the queue. Propagation A at the capture database propagates LCRs to a queue at destination database A. Propagation B at the capture database propagates LCRs to a queue at destination database B. Propagation C at the capture database propagates LCRs to a queue at destination database C.
    

  • 

    Destination database A contains a queue that accepts LCRs from propagation A. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database B contains a queue that accepts LCRs from propagation B. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database C contains a queue that accepts LCRs from propagation C. This database also contains an apply process that dequeues LCRs from the queue.
    



Destination database A is down and is not accepting LCRs from propagation A. These LCRs are building up in the queue at the capture database.


PKjNlgPK+AOEBPS/img_text/strep040.htm&

Description of the illustration strep040.eps

This illustration shows an example of adding a destination database to an existing Oracle Streams single-source replication environment.


Additional source database configuration includes:


  • 

    Each shared object prepared for instantiation
    

  • 

    A propagation for the added destination database
    

  • 

    Added database link for added propagation
    



Also, the source database has existing database links for existing propagations.


Additional destination database configuration includes:


  • 

    An ANYDATA queue
    

  • 

    Instantiation SCN set for each shared object
    

  • 

    An apply process for the source database
    

  • 

    Rule sets for the apply process
    



The environment can include additional destination databases. No additional configuration is required for existing destination databases.


PK`+&PK+AOEBPS/img_text/strep504.htm

Description of the illustration strep504.eps

This illustration shows an Oracle Streams hub-and-spoke replication environment that includes the following Oracle databases:


  • 

    hub.example.com
    

  • 

    spoke1.example.com
    

  • 

    spoke2.example.com
    



At each database, the local redo log records changes to the hr schema.


The hub.example.com database has the following Oracle Streams components configured:


  • 

    The following queues: source_hns, destination_spoke1, and destination_spoke2.
    

  • 

    A capture process named capture_hns that captures DML changes to the tables in the hr schema from the local redo log. The capture process enqueues these changes into the local source_hns queue.
    

  • 

    A propagation named propagation_spoke1 that sends changes from the local source_hns queue to the destination_spoke1 queue at spoke1.example.com.
    

  • 

    A propagation named propagation_spoke2 that sends changes from the local source_hns queue to the destination_spoke2 queue at spoke2.example.com.
    

  • 

    An apply process named apply_spoke1 that dequeues changes that originated at spoke1.example.com from the destination_spoke1 queue and applies them to the tables in the hr schema.
    

  • 

    An apply process named apply_spoke2 that dequeues changes that originated at spoke2.example.com from the destination_spoke2 queue and applies them to the tables in the hr schema.
    



The spoke1.example.com database has the following Oracle Streams components configured:


  • 

    The following queues: source_hns and destination_spoke1.
    

  • 

    A capture process named capture_hns that captures DML changes to the tables in the hr schema from the local redo log. The capture process enqueues these changes into the local source_hns queue.
    

  • 

    A propagation named propagation_spoke1 that sends changes from the local source_hns queue to the destination_spoke1 queue at hub.example.com.
    

  • 

    An apply process named apply_spoke1 that dequeues changes that originated at hub.example.com and spoke2.example.com from the destination_spoke1 queue and applies them to the tables in the hr schema.
    



The spoke2.example.com database has the following Oracle Streams components configured:


  • 

    The following queues: source_hns and destination_spoke2.
    

  • 

    A capture process named capture_hns that captures DML changes to the tables in the hr schema from the local redo log. The capture process enqueues these changes into the local source_hns queue.
    

  • 

    A propagation named propagation_spoke2 that sends changes from the local source_hns queue to the destination_spoke2 queue at hub.example.com.
    

  • 

    An apply process named apply_spoke2 that dequeues changes that originated at hub.example.com and spoke1.example.com from the destination_spoke2 queue and applies them to the tables in the hr schema.
    



PK>PK+AOEBPS/img_text/strep067.htmd

Description of the illustration strep067.eps

This illustration shows the details of the mult1.example.com Oracle Streams configuration, including the following mechanisms:


  • 

    One queue that is used by the capture process, propagations, and apply processes.
    

  • 

    A capture process that captures changes in the redo log and converts relevant changes into LCRs, which it enqueues. The capture process captures a change only if its tag is NULL.
    

  • 

    One apply process that applies changes from mult2.example.com and another apply process that applies changes from mult3.example.com. Both of these apply processes dequeue changes from the same queue. Any apply change from mult2.example.com and mult3.example.com has a tag of '00' in the redo log.
    

  • 

    One propagation to propagate locally captured LCRs to mult2.example.com and another propagation to propagate locally captured LCRs to mult3.example.com
    



PKciPK+AOEBPS/img_text/strep048.htm4

Description of the illustration strep048.eps

This illustration is described in the surrounding text.


PK5|PK+AOEBPS/img_text/strep043.htm


Description of the illustration strep043.eps

This illustration shows an example adding a source/destination database to an Oracle Streams multiple-source replication environment.


Additional configuration for existing source/destination databases includes:


  • 

    An ANYDATA queue to stage changes from the new source database (optional)
    

  • 

    Each shared object prepared for instantiation
    

  • 

    A propagation for the added database
    

  • 

    Instantiation SCN set for each shared object for the added source database
    

  • 

    An apply process for the added source database
    

  • 

    Rule sets for the added propagation and apply process
    

  • 

    A database link for the added propagation
    



Additional configuration for the added source/destination database includes:


  • 

    One or more ANYDATA queues
    

  • 

    Supplemental logging specifications
    

  • 

    Each shared object prepared for instantiation
    

  • 

    One or more capture process(es) and/or synchronous capture(s)
    

  • 

    One propagation for each of the other destination databases
    

  • 

    Instantiation SCN set for each shared object for each of the other source databases
    

  • 

    One apply process for each of the other source databases
    

  • 

    Rule sets for the capture process(es), synchronous capture(s), propagation(s), and apply process(es)
    

  • 

    Conflict resolution if necessary
    

  • 

    A database link for each propagation
    



The environment can include additional source/destination databases.


PKAiPK+AOEBPS/img_text/strep022.htmS

Description of the illustration strep022.eps

This illustration shows three arrows pointing in the same direction. The first arrow is labeled "Capture", the second arrow is labeled "Staging", and the third arrow is labeled "Consumption".


PK~WXSPK+AOEBPS/img_text/strep052.htm

Description of the illustration strep052.eps

This illustration shows the role of the capture database in the Stream replication environment. This illustration shows the following Oracle databases:


  • 

    The source database contains the following:
    

    • 

      The database objects in the database.
      

    • 

      The redo log recording changes to the database objects.
      

    

  • 

    The capture database can be the source database, the destination database, or a third database. The capture database contains the following:
    

    • 

      A capture process capturing changes from the redo log of the source database. If the capture database and the source database are the same, then a local capture process captures changes in the redo log at the source database. If the capture database is the destination database or a third database, then the source database redo log is shipped to the capture database, and a downstream capture process captures changes in this redo log.
      

    • 

      The capture process converts the changes to logical change records (LCRs) and enqueues the LCRs.
      

    • 

      If the capture database and the destination database are different databases, then a propagation propagates the LCRs to a queue at the destination database. If the capture database and destination database are the same, then the propagation between databases is not needed.
      

    

  • 

    The destination database contains the following:
    

    • 

      The queue that contains LCRs that were captured by the capture process.
      

    • 

      An apply process that applies the LCRs as changes to the database objects.
      

    



PKq8PK+AOEBPS/img_text/strep506.htm

Description of the illustration strep506.eps

This illustration shows an Oracle Streams two-database replication environment that includes the following Oracle databases:


  • 

    src.example.com
    

  • 

    dest.example.com
    



The src.example.com database contains the redo log for the local database. This redo log records changes to the hr schema. This redo log is sent to the dest.example.com database by Redo Transport Services.


The dest.example.com database has the following Oracle Streams components configured:


  • 

    The streams_queue queue.
    

  • 

    A capture process named capture_hns that captures DML changes to the tables in the hr schema from the src.example.com redo log. The capture process enqueues these changes into the local streams_queue queue.
    

  • 

    An apply process named apply that dequeues changes that originated at src.example.com from the streams_queue queue and applies them to the tables in the hr schema.
    



PKCe PK+AOEBPS/img_text/strep024.htm_

Description of the illustration strep024.eps

This illustration shows a primary database and three secondary databases. The primary database communicates with each secondary database, and each secondary database communicates with the primary database. However, the secondary databases do not communicate with each other.


Also, each secondary database communicates with two remote secondary databases, and each of these remote secondary databases communicates with the secondary database. However, the remote secondary databases do not communicate with each other.


PK28PK+AOEBPS/img_text/strep064.htm4

Description of the illustration strep064.eps

This illustration is described in the surrounding text.


PK&PK+AOEBPS/img_text/strep051.htm4

Description of the illustration strep051.eps

This illustration is described in the surrounding text.


PKs+PK+AOEBPS/img_text/strep_setup.htmp

Description of the illustration strep_setup.gif

This screenshot shows the Streams page that enables you to open the Setup Streams Replication Wizard in Enterprise Manager. At the top of the page are the Cancel and Continue buttons. Under the buttons is the text, "Oracle recommends that, prior to performing Streams Replication on databases in your configuration, you create a Streams Administrator user." The "Streams Administrator user" part is a link.


Under the text is the Setup Streams Replication option. This option includes the following sub-options:


  • 

    Replicate Whole Database
    

    Setup replication for whole database
    

  • 

    Replicate Schemas
    

    Setup replication for selected schemas by excluding desired tables
    

  • 

    Replicate Tablespaces
    

    Setup replication for a selected set of table spaces
    

  • 

    Replicate Tables
    

    Setup replication for selected tables and specifying the rules
    



Next is the Setup Downstream Capture option with the text, "Create downstream capture processes that can be used in replication by other databases."


Next is the Create Advanced Queue option with the text, "Create Advanced Queues that can be used by replication processes or any other processes."


Next is the Host Credentials section with the following text, "Operating System login credentials of the machine that runs the selected database." This section includes the Username and Password fields. Under these fields is a Save as Preferred Credential option.


On the right side of the page is an Overview section with the following text:


  • 

    Using the Streams Replication Setup wizard you can setup the streams replication between two databases.
    

  • 

    Replication can be setup for the Whole Database, selected table spaces, schemas or tables.
    

  • 

    It is possible to specify objects to exclude from replication.
    

  • 

    Downstream capture setup wizard helps to setup the capture and propagation processes on a different database from that of source database. These processes can be used in subsequent replication setup operations.
    

  • 

    You can edit the replication setup scripts to fix any issues or use any advanced data import export mechanism.
    

  • 

    You can create advanced queues, wizard helps to create the new queues for the messages that can be used by stream replication or any other processes.
    

  • 

    You can execute the setup processes immediately or schedule for later.
    



PKhZupPK+AOEBPS/img_text/strep039.htm

Description of the illustration strep039.eps

This illustration shows an example of an Oracle Streams multiple-source replication environment. Each source/destination database includes:


  • 

    One or more ANYDATA queues
    

  • 

    Supplemental logging specifications
    

  • 

    Each shared object prepared for instantiation
    

  • 

    One or more capture process(es) and/or synchronous capture(s)
    

  • 

    One propagation for each of the other destination databases
    

  • 

    Instantiation SCN set for each shared object for each of the other source databases
    

  • 

    One apply process for each of the other source databases
    

  • 

    Rule sets for the capture process(es), synchronous capture(s), propagation(s), and apply process(es)
    

  • 

    Conflict resolution if necessary
    

  • 

    A database link for each propagation
    



PKYPK+AOEBPS/img_text/strep042.htmT

Description of the illustration strep042.eps

This illustration shows an example of adding shared objects to an existing Oracle Streams multiple-source replication environment.


Each additional source/destination configuration includes:


  • 

    Supplemental logging specifications for added shared objects
    

  • 

    Each additional object prepared for instantiation
    

  • 

    Appropriate rules for the added objects included in the rule sets for the capture process(es), synchronous capture(s), propagation(s), and apply process(es)
    

  • 

    Instantiation SCN set for each additional object for each of the other source databases
    

  • 

    Conflict resolution for the added objects if necessary
    



Also, each source database has existing database links for existing propagations.


PKLPK+AOEBPS/img_text/strep_wizard.htmB

Description of the illustration strep_wizard.gif

This screenshot shows the first page of the Setup Streams Replication Wizard in Enterprise Manager. At the top is an arrow showing the pages of the wizard, including Source Options, Destination Options, Replication Options, Schedule, and Review. Under the arrow, the page title reads, "Setup Streams Replication: Object Selection". Below the title is the text, "All the tables listed in the table below will be captured. Table Replication will be configured for each table without a Subset condition and Subset Replication will be configured for each table with a subset condition." Next there is a Cancel button, the text "Step 1 of 5," and a Next button.


Below the buttons is the Include Tables section. This section includes the text, "To specify that replication should be configured for a table, add them to the table below." Next is a table with an Add button at the top. The table has the following blank fields: Selected, Schema, Table, and Subset Condition.


Below the table is the following text: "TIP A subset condition is a special type of table rule for DML changes that is relevant only to a subset of the rows in a table. You can specify a condition that will allow the replication of table rows pertaining to that condition only. e.g. to replicate hr.regions table where the region_id is 2 enter 'region_id=2' against the hr.regions table."


Next there is a Cancel button, the text "Step 1 of 5," and a Next button.


PKr@2GBPK+AOEBPS/img_text/strep049.htm4

Description of the illustration strep049.eps

This illustration is described in the surrounding text.


PK0PK+AOEBPS/img_text/strep065.htm4

Description of the illustration strep065.eps

This illustration shows the details of the primary database ps1.example.com Oracle Streams configuration, including the following mechanisms:


  • 

    One queue that is used by the capture process, propagations, and apply processes.
    

  • 

    A capture process that captures changes in the redo log and converts relevant changes into LCRs, which it enqueues. The capture process captures a change regardless of whether its tag is NULL.
    

  • 

    One propagation that propagates captured changes to ps2.example.com. The propagation propagates all changes except changes with a tag of '2'.
    

  • 

    One propagation that propagates captured changes to ps3.example.com. The propagation propagates all changes except changes with a tag of '3'.
    

  • 

    One propagation that propagates captured changes to ps4.example.com. The propagation propagates all changes except changes with a tag of '4'.
    

  • 

    One apply process that applies changes from ps2.example.com. These changes have a tag of '2' in the redo log.
    

  • 

    One apply process that applies changes from ps3.example.com. These changes have a tag of '3' in the redo log.
    

  • 

    One apply process that applies changes from ps4.example.com. These changes have a tag of '4' in the redo log.
    

  • 

    One propagation to propagate locally captured LCRs to mult2.example.com and another propagation to propagate locally captured LCRs to mult3.example.com.
    



PK`s94PK+AOEBPS/img_text/strep063.htm4

Description of the illustration strep063.eps

This illustration is described in the surrounding text.


PKHtPK+AOEBPS/img_text/strep030.htmY

Description of the illustration strep030.eps

This illustration shows a primary database and three secondary databases. The primary database communicates with each secondary database, and each secondary database communicates with the primary database. However, the secondary databases do not communicate with each other.


PK%%PK+AOEBPS/img_text/strep060.htms

Description of the illustration strep060.eps

This illustration shows an Oracle Streams replication environment with a capture database and three destination databases. These databases are:


  • 

    The capture database has a capture process and a queue. The capture process enqueues captured LCRs into the queue. Propagation B at the capture database propagates LCRs to a queue at destination database B. Propagation C at the capture database propagates LCRs to a queue at destination database C.
    

    The capture database also contains a cloned capture process and a cloned queue. Cloned propagation A at the capture database is configured to propagate LCRs to a queue at destination database A when destination database A is up and the cloned capture process is enabled.
    

  • 

    Destination database A contains a queue that accepts LCRs from propagation A. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database B contains a queue that accepts LCRs from propagation B. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database C contains a queue that accepts LCRs from propagation C. This database also contains an apply process that dequeues LCRs from the queue.
    



PK#PK+AOEBPS/img_text/strep028.htmp

Description of the illustration strep028.eps

This illustration shows the details of the secondary database ps2.example.com Oracle Streams configuration, including the following mechanisms:


  • 

    One queue that is used by the capture process, the propagation, and the apply process.
    

  • 

    A capture process that captures changes in the redo log and converts relevant changes into LCRs, which it enqueues. The capture process captures a change only if its tag is NULL.
    

  • 

    One propagation that propagates captured changes to ps1.example.com.
    

  • 

    One apply process that applies changes from ps1.example.com. These changes have a tag of '00' in the redo log.
    



PKupPK+AOEBPS/img_text/strep041.htm3

Description of the illustration strep041.eps

This illustration shows an example of adding shared objects to an existing Oracle Streams single-source replication environment.


Additional configuration at the source database includes:


  • 

    Supplemental logging specifications for the added shared objects
    

  • 

    Each additional shared object prepared for instantiation
    

  • 

    Appropriate rules for the added objects included in the rule sets for the capture process and/or synchronous capture, and for the propagations
    



Also, the source database has existing database links for existing propagations.


Additional destination database configuration includes:


  • 

    Instantiation SCN set for each additional shared object
    

  • 

    Appropriate rules for the added objects included in the rule sets for the apply process
    



The environment can include additional destination databases.


PK3'e83PK+AOEBPS/img_text/strep062.htm-

Description of the illustration strep062.eps

This illustration shows an Oracle Streams replication environment with a capture database and three destination databases. These databases are:


  • 

    The capture database has a capture process and a queue. The capture process enqueues captured LCRs into the queue. Propagation A at the capture database propagates LCRs to a queue at destination database A. Propagation B at the capture database propagates LCRs to a queue at destination database B. Propagation C at the capture database propagates LCRs to a queue at destination database C.
    

  • 

    Destination database A contains a queue that accepts LCRs from propagation A. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database B contains a queue that accepts LCRs from propagation B. This database also contains an apply process that dequeues LCRs from the queue.
    

  • 

    Destination database C contains a queue that accepts LCRs from propagation C. This database also contains an apply process that dequeues LCRs from the queue.
    



PK 6PK+AOEBPS/ptrep_ap.htm{

Appendixes



Part IV



Appendixes


This part includes the following appendix:







PK2*"PK+AOEBPS/man_lcrs.htm

Managing Logical Change Records (LCRs)



14 Managing Logical Change Records (LCRs)


This chapter contains instructions for managing logical change records (LCRs) in an Oracle Streams replication environment.


This chapter contains these topics:







Requirements for Managing LCRs


This section describes requirements for creating or modifying logical change records (LCRs). You can create an LCR using a constructor for an LCR type, and then enqueue the LCR into an persistent queue portion of an ANYDATA queue. Such an LCR is a persistent LCR.


Also, you can modify an LCR using an apply handler or a rule-based transformation. You can modify captured LCRs or persistent LCRs.


Ensure that you meet the following requirements when you manage an LCR:


  • 

    If you create or modify a row LCR, then ensure that the command_type attribute is consistent with the presence or absence of old column values and the presence or absence of new column values.
    

  • 

    If you create or modify a DDL LCR, then ensure that the ddl_text is consistent with the base_table_name, base_table_owner, object_type, object_owner, object_name, and command_type attributes.
    

  • 

    The following data types are allowed for columns in a user-constructed row LCR:
    

    • 

      CHAR
      

    • 

      VARCHAR2
      

    • 

      NCHAR
      

    • 

      NVARCHAR2
      

    • 

      NUMBER
      

    • 

      DATE
      

    • 

      BINARY_FLOAT
      

    • 

      BINARY_DOUBLE
      

    • 

      RAW
      

    • 

      TIMESTAMP
      

    • 

      TIMESTAMP WITH TIME ZONE
      

    • 

      TIMESTAMP WITH LOCAL TIME ZONE
      

    • 

      INTERVAL YEAR TO MONTH
      

    • 

      INTERVAL DAY TO SECOND
      

    

    These data types are the only data types allowed for columns in a user-constructed row LCR. However, you can use certain techniques to construct LCRs that contain LOB information. Also, LCRs captured by a capture process support more data types, while LCRs captured by a synchronous capture support fewer data types.
    










See Also:















Constructing and Enqueuing LCRs


Use the following LCR constructors to create LCRs:


  • 

    To create a row LCR that contains a change to a row that resulted from a data manipulation language (DML) statement, use the SYS.LCR$_ROW_RECORD constructor.
    

  • 

    To create a DDL LCR that contains a data definition language change, use the SYS.LCR$_DDL_RECORD constructor. Ensure that the DDL text specified in the ddl_text attribute of each DDL LCR conforms to Oracle SQL syntax.
    



The following example creates a queue in an Oracle database and an apply process associated with the queue. Next, it creates a PL/SQL procedure that constructs a row LCR based on information passed to it and enqueues the row LCR into the queue. This example assumes that you have configured an Oracle Streams administrator named strmadmin and granted this administrator DBA role.


Complete the following steps:


  1. 

    In SQL*Plus, connect to the database as an administrative user.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Grant the Oracle Streams administrator EXECUTE privilege on the DBMS_STREAMS_MESSAGING package. For example:
    

    GRANT EXECUTE ON DBMS_STREAMS_MESSAGING TO strmadmin;

    

    Explicit EXECUTE privilege on the package is required because a procedure in the package is called within a PL/SQL procedure in Step 9. In this case, granting the privilege through a role is not sufficient.
    

  3. 

    In SQL*Plus, connect to the database as the Oracle Streams administrator.
    

  4. 

    Create an ANYDATA queue in an Oracle database.
    

    BEGIN 
  DBMS_STREAMS_ADM.SET_UP_QUEUE(
    queue_table          =>  'strm04_queue_table',
    storage_clause       =>  NULL,
    queue_name           =>  'strm04_queue');
END;
/

  5. 

    Create an apply process at the Oracle database to receive messages in the queue. Ensure that the apply_captured parameter is set to FALSE when you create the apply process, because the apply process will be applying persistent LCRs, not captured LCRs. Also, ensure that the apply_user parameter is set to hr, because changes will be applied in to the hr.regions table, and the apply user must have privileges to make DML changes to this table.
    

    BEGIN
  DBMS_APPLY_ADM.CREATE_APPLY(
     queue_name      => 'strm04_queue',
     apply_name      => 'strm04_apply',
     apply_captured  => FALSE,
     apply_user      => 'hr');
END;
/

  6. 

    Create a positive rule set for the apply process and add a rule that applies DML changes to the hr.regions table made at the dbs1.example.com source database.
    

    BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name          =>  'hr.regions',
    streams_type        =>  'apply',
    streams_name        =>  'strm04_apply',
    queue_name          =>  'strm04_queue',
    include_dml         =>  TRUE,
    include_ddl         =>  FALSE,
    include_tagged_lcr  =>  FALSE,
    source_database     =>  'dbs1.example.com',
    inclusion_rule      =>  TRUE);
END;
/

  7. 

    Set the disable_on_error parameter for the apply process to n.
    

    BEGIN
  DBMS_APPLY_ADM.SET_PARAMETER(
    apply_name  => 'strm04_apply', 
    parameter   => 'disable_on_error', 
    value       => 'N');
END;
/

  8. 

    Start the apply process.
    

    EXEC DBMS_APPLY_ADM.START_APPLY('strm04_apply');

  9. 

    Create a procedure called construct_row_lcr that constructs a row LCR and enqueues it into the queue created in Step 4.
    

    CREATE OR REPLACE PROCEDURE construct_row_lcr(
                 source_dbname  VARCHAR2,
                 cmd_type       VARCHAR2,
                 obj_owner      VARCHAR2,
                 obj_name       VARCHAR2,
                 old_vals       SYS.LCR$_ROW_LIST,
                 new_vals       SYS.LCR$_ROW_LIST) AS
  row_lcr        SYS.LCR$_ROW_RECORD;
BEGIN
  -- Construct the LCR based on information passed to procedure
  row_lcr := SYS.LCR$_ROW_RECORD.CONSTRUCT(
    source_database_name  =>  source_dbname,
    command_type          =>  cmd_type,
    object_owner          =>  obj_owner,
    object_name           =>  obj_name,
    old_values            =>  old_vals,
    new_values            =>  new_vals);
  -- Enqueue the created row LCR
  DBMS_STREAMS_MESSAGING.ENQUEUE(
    queue_name         =>  'strm04_queue',
    payload            =>  ANYDATA.ConvertObject(row_lcr));
END construct_row_lcr;
/

    

    


    

    

    Note:
    
The application does not need to specify a transaction identifier or SCN when it creates an LCR because the apply process generates these values and stores them in memory. If a transaction identifier or SCN is specified in the LCR, then the apply process ignores it and assigns a new value.
    

    

    

    


    

    

    See Also:
    
Oracle Database PL/SQL Packages and Types Reference for more information about LCR constructors
    

    

    

  10. 

    Create and enqueue LCRs using the construct_row_lcr procedure created in Step 5.
    

    1. 

      In SQL*Plus, connect to the database as the Oracle Streams administrator.
      

    2. 

      Create a row LCR that inserts a row into the hr.regions table.
      

      DECLARE
  newunit1  SYS.LCR$_ROW_UNIT;
  newunit2  SYS.LCR$_ROW_UNIT;
  newvals   SYS.LCR$_ROW_LIST;
BEGIN
  newunit1 := SYS.LCR$_ROW_UNIT(
    'region_id', 
    ANYDATA.ConvertNumber(5),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  newunit2 := SYS.LCR$_ROW_UNIT(
    'region_name', 
    ANYDATA.ConvertVarchar2('Moon'),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  newvals := SYS.LCR$_ROW_LIST(newunit1,newunit2);
construct_row_lcr(
  source_dbname  =>  'dbs1.example.com',
  cmd_type       =>  'INSERT',
  obj_owner      =>  'hr',
  obj_name       =>  'regions',
  old_vals       =>  NULL,
  new_vals       =>  newvals);
END;
/
COMMIT;

    3. 

      In SQL*Plus, connect to the database as the hr user.
      

    4. 

      Query the hr.regions table to view the applied row change. The row with a region_id of 5 should have Moon for the region_name.
      

      SELECT * FROM hr.regions;

    5. 

      In SQL*Plus, connect to the database as the Oracle Streams administrator.
      

    6. 

      Create a row LCR that updates a row in the hr.regions table.
      

      DECLARE
  oldunit1  SYS.LCR$_ROW_UNIT;
  oldunit2  SYS.LCR$_ROW_UNIT;
  oldvals   SYS.LCR$_ROW_LIST;
  newunit1  SYS.LCR$_ROW_UNIT;
  newvals   SYS.LCR$_ROW_LIST;
BEGIN
  oldunit1 := SYS.LCR$_ROW_UNIT(
    'region_id', 
    ANYDATA.ConvertNumber(5),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  oldunit2 := SYS.LCR$_ROW_UNIT(
    'region_name', 
    ANYDATA.ConvertVarchar2('Moon'),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  oldvals := SYS.LCR$_ROW_LIST(oldunit1,oldunit2);
  newunit1 := SYS.LCR$_ROW_UNIT(
    'region_name', 
    ANYDATA.ConvertVarchar2('Mars'),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  newvals := SYS.LCR$_ROW_LIST(newunit1);
construct_row_lcr(
  source_dbname  =>  'dbs1.example.com',
  cmd_type       =>  'UPDATE',
  obj_owner      =>  'hr',
  obj_name       =>  'regions',
  old_vals       =>  oldvals,
  new_vals       =>  newvals);
END;
/
COMMIT;

    7. 

      In SQL*Plus, connect to the database as the hr user.
      

    8. 

      Query the hr.regions table to view the applied row change. The row with a region_id of 5 should have Mars for the region_name.
      

      SELECT * FROM hr.regions;

    9. 

      Create a row LCR that deletes a row from the hr.regions table.
      

      DECLARE
  oldunit1  SYS.LCR$_ROW_UNIT;
  oldunit2  SYS.LCR$_ROW_UNIT;
  oldvals   SYS.LCR$_ROW_LIST;
BEGIN
  oldunit1 := SYS.LCR$_ROW_UNIT(
    'region_id', 
    ANYDATA.ConvertNumber(5),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  oldunit2 := SYS.LCR$_ROW_UNIT(
    'region_name',
    ANYDATA.ConvertVarchar2('Mars'),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  oldvals := SYS.LCR$_ROW_LIST(oldunit1,oldunit2);
construct_row_lcr(
  source_dbname  =>  'dbs1.example.com',
  cmd_type       =>  'DELETE',
  obj_owner      =>  'hr',
  obj_name       =>  'regions',
  old_vals       =>  oldvals,
  new_vals       =>  NULL);
END;
/
COMMIT;

    10. 

      In SQL*Plus, connect to the database as the hr user.
      

    11. 

      Query the hr.regions table to view the applied row change. The row with a region_id of 5 should have been deleted.
      

      SELECT * FROM hr.regions;

    









Executing LCRs


There are separate EXECUTE member procedures for row LCRs and DDL LCRs. These member procedures execute an LCR under the security domain of the current user. When an LCR is executed successfully, the change recorded in the LCR is made to the local database. The following sections describe executing row LCRs and DDL LCRs:






Executing Row LCRs


The EXECUTE member procedure for row LCRs is a subprogram of the LCR$_ROW_RECORD type. When the EXECUTE member procedure is run on a row LCR, the row LCR is executed. If the row LCR is executed by an apply process, then any apply process handlers that would be run for the LCR are not run.


The EXECUTE member procedure can be run on a row LCR under any of the following conditions:


  • 

    The LCR is being processed by an apply handler.
    

  • 

    The LCR is in a queue and was last enqueued by an apply process, an application, or a user.
    

  • 

    The LCR has been constructed using the LCR$_ROW_RECORD constructor function but has not been enqueued.
    

  • 

    The LCR is in the error queue.
    



When you run the EXECUTE member procedure on a row LCR, the conflict_resolution parameter controls whether conflict resolution is performed. Specifically, if the conflict_resolution parameter is set to TRUE, then any conflict resolution defined for the table being changed is used to resolve conflicts resulting from the execution of the LCR. If the conflict_resolution parameter is set to FALSE, then conflict resolution is not used. If the conflict_resolution parameter is not set or is set to NULL, then an error is raised.









Note:

A custom rule-based transformation should not run the EXECUTE member procedure on a row LCR. Doing so could execute the row LCR outside of its transactional context.













See Also:












Example of Constructing and Executing Row LCRs


The example in this section creates PL/SQL procedures to insert, update, and delete rows in the hr.jobs table by constructing and executing row LCRs. The row LCRs are executed without being enqueued or processed by an apply process. This example assumes that you have configured an Oracle Streams administrator named strmadmin and granted this administrator DBA role.


Complete the following steps:


  1. 

    In SQL*Plus, connect to the database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Create a PL/SQL procedure named execute_row_lcr that executes a row LCR:
    

    CREATE OR REPLACE PROCEDURE execute_row_lcr(
                 source_dbname  VARCHAR2,
                 cmd_type       VARCHAR2,
                 obj_owner      VARCHAR2,
                 obj_name       VARCHAR2,
                 old_vals       SYS.LCR$_ROW_LIST,
                 new_vals       SYS.LCR$_ROW_LIST) as
  xrow_lcr  SYS.LCR$_ROW_RECORD;
BEGIN
  -- Construct the row LCR based on information passed to procedure
  xrow_lcr := SYS.LCR$_ROW_RECORD.CONSTRUCT(
    source_database_name => source_dbname,
    command_type         => cmd_type,
    object_owner         => obj_owner,
    object_name          => obj_name,
    old_values           => old_vals,
    new_values           => new_vals);
  -- Execute the row LCR
  xrow_lcr.EXECUTE(FALSE);
END execute_row_lcr;
/

  3. 

    Create a PL/SQL procedure named insert_job_lcr that executes a row LCR that inserts a row into the hr.jobs table:
    

    CREATE OR REPLACE PROCEDURE insert_job_lcr(
                 j_id     VARCHAR2,
                 j_title  VARCHAR2,
                 min_sal  NUMBER,
                 max_sal  NUMBER) AS
  xrow_lcr   SYS.LCR$_ROW_RECORD;
  col1_unit  SYS.LCR$_ROW_UNIT;
  col2_unit  SYS.LCR$_ROW_UNIT;
  col3_unit  SYS.LCR$_ROW_UNIT;
  col4_unit  SYS.LCR$_ROW_UNIT;
  newvals    SYS.LCR$_ROW_LIST;
BEGIN
  col1_unit := SYS.LCR$_ROW_UNIT(
    'job_id', 
    ANYDATA.ConvertVarchar2(j_id),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  col2_unit := SYS.LCR$_ROW_UNIT(
    'job_title', 
    ANYDATA.ConvertVarchar2(j_title),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  col3_unit := SYS.LCR$_ROW_UNIT(
    'min_salary', 
    ANYDATA.ConvertNumber(min_sal),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  col4_unit := SYS.LCR$_ROW_UNIT(
    'max_salary', 
    ANYDATA.ConvertNumber(max_sal),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  newvals := SYS.LCR$_ROW_LIST(col1_unit,col2_unit,col3_unit,col4_unit);
  -- Execute the row LCR
  execute_row_lcr(
    source_dbname => 'DB1.EXAMPLE.COM',
    cmd_type      => 'INSERT',
    obj_owner     => 'HR',
    obj_name      => 'JOBS',
    old_vals      => NULL,
    new_vals      => newvals);  
END insert_job_lcr;
/

  4. 

    Create a PL/SQL procedure named update_max_salary_lcr that executes a row LCR that updates the max_salary value for a row in the hr.jobs table:
    

    CREATE OR REPLACE PROCEDURE update_max_salary_lcr(
                 j_id         VARCHAR2,
                 old_max_sal NUMBER,
                 new_max_sal NUMBER) AS
  xrow_lcr      SYS.LCR$_ROW_RECORD;
  oldcol1_unit  SYS.LCR$_ROW_UNIT;
  oldcol2_unit  SYS.LCR$_ROW_UNIT;
  newcol1_unit  SYS.LCR$_ROW_UNIT;
  oldvals       SYS.LCR$_ROW_LIST;
  newvals       SYS.LCR$_ROW_LIST;
BEGIN
  oldcol1_unit := SYS.LCR$_ROW_UNIT(
    'job_id', 
    ANYDATA.ConvertVarchar2(j_id),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  oldcol2_unit := SYS.LCR$_ROW_UNIT(
    'max_salary', 
    ANYDATA.ConvertNumber(old_max_sal),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  oldvals := SYS.LCR$_ROW_LIST(oldcol1_unit,oldcol2_unit);
  newcol1_unit := SYS.LCR$_ROW_UNIT(
    'max_salary', 
    ANYDATA.ConvertNumber(new_max_sal),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  newvals := SYS.LCR$_ROW_LIST(newcol1_unit);
  -- Execute the row LCR
  execute_row_lcr(
    source_dbname => 'DB1.EXAMPLE.COM',
    cmd_type      => 'UPDATE',
    obj_owner     => 'HR',
    obj_name      => 'JOBS',
    old_vals      => oldvals,
    new_vals      => newvals);  
END update_max_salary_lcr;
/

  5. 

    Create a PL/SQL procedure named delete_job_lcr that executes a row LCR that deletes a row from the hr.jobs table:
    

    CREATE OR REPLACE PROCEDURE delete_job_lcr(j_id VARCHAR2) AS
  xrow_lcr   SYS.LCR$_ROW_RECORD;
  col1_unit  SYS.LCR$_ROW_UNIT;
  oldvals    SYS.LCR$_ROW_LIST;
BEGIN
  col1_unit := SYS.LCR$_ROW_UNIT(
    'job_id',
    ANYDATA.ConvertVarchar2(j_id),
    DBMS_LCR.NOT_A_LOB,
    NULL,
    NULL);
  oldvals := SYS.LCR$_ROW_LIST(col1_unit); 
  -- Execute the row LCR
  execute_row_lcr(
    source_dbname => 'DB1.EXAMPLE.COM',
    cmd_type      => 'DELETE',
    obj_owner     => 'HR',
    obj_name      => 'JOBS',
    old_vals      => oldvals,
    new_vals      => NULL);
END delete_job_lcr;
/

  6. 

    Insert a row into the hr.jobs table using the insert_job_lcr procedure:
    

    EXEC insert_job_lcr('BN_CNTR','BEAN COUNTER',5000,10000);

  7. 

    Select the inserted row in the hr.jobs table:
    

    SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';

JOB_ID     JOB_TITLE                           MIN_SALARY MAX_SALARY
---------- ----------------------------------- ---------- ----------
BN_CNTR    BEAN COUNTER                              5000      10000

  8. 

    Update the max_salary value for the row inserted into the hr.jobs table in Step 6 using the update_max_salary_lcr procedure:
    

    EXEC update_max_salary_lcr('BN_CNTR',10000,12000);

  9. 

    Select the updated row in the hr.jobs table:
    

    SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';

JOB_ID     JOB_TITLE                           MIN_SALARY MAX_SALARY
---------- ----------------------------------- ---------- ----------
BN_CNTR    BEAN COUNTER                              5000      12000

  10. 

    Delete the row inserted into the hr.jobs table in Step 6 using the delete_job_lcr procedure:
    

    EXEC delete_job_lcr('BN_CNTR');

  11. 

    Select the deleted row in the hr.jobs table:
    

    SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';

no rows selected











Executing DDL LCRs


The EXECUTE member procedure for DDL LCRs is a subprogram of the LCR$_DDL_RECORD type. When the EXECUTE member procedure is run on a DDL LCR, the LCR is executed, and any apply process handlers that would be run for the LCR are not run. The EXECUTE member procedure for DDL LCRs can be invoked only in an apply handler for an apply process.


All applied DDL LCRs commit automatically. Therefore, if a DDL handler calls the EXECUTE member procedure of a DDL LCR, then a commit is performed automatically.









See Also:

















Managing LCRs Containing LOB Columns


LOB data types can be present in row LCRs captured by a capture process, but these data types are represented by other data types. LOB data types cannot be present in row LCRs captured by synchronous captures. Certain LOB data types cannot be present in row LCRs constructed by users. Table 14-1 shows the LCR representation for these data types and whether these data types can be present in row LCRs.




Table 14-1 LOB Data Type Representations in Row LCRs


Data TypeRow LCR RepresentationCan Be Present in a Row LCR Captured by a Capture Process?Can Be Present in a Row LCR Captured by a Synchronous Capture?Can Be Present in a Row LCR Constructed by a User?


Fixed-width CLOB



VARCHAR2



Yes



No



Yes




Variable-width CLOB



RAW in AL16UTF16 character set



Yes



No



No




NCLOB



RAW in AL16UTF16 character set



Yes



No



No




BLOB



RAW



Yes



No



Yes




XMLType stored as CLOB



RAW



Yes



No



No







The following are general considerations for row changes involving LOB data types in an Oracle Streams environment:


  • 

    A row change involving a LOB column can be captured, propagated, and applied as several row LCRs.
    

  • 

    Rules used to evaluate these row LCRs must be deterministic, so that either all of the row LCRs corresponding to the row change cause a rule in a rule set to evaluate to TRUE, or none of them do.
    



The following sections contain information about the requirements you must meet when constructing or processing LOB columns, about apply process behavior for LCRs containing LOB columns, and about LOB assembly. There is also an example that constructs and enqueues LCRs containing LOB columns.


This section contains the following topics:










See Also:












Apply Process Behavior for Direct Apply of LCRs Containing LOBs


An apply process behaves in the following ways when it applies an LCR that contains a LOB column directly (without the use of an apply handler):


  • 

    If an LCR whose command type is INSERT or UPDATE has a new LOB that contains data, and the lob_information is not DBMS_LCR.LOB_CHUNK or DBMS_LCR.LAST_LOB_CHUNK, then the data is applied.
    

  • 

    If an LCR whose command type is INSERT or UPDATE has a new LOB that contains no data, and the lob_information is DBMS_LCR.EMPTY_LOB, then it is applied as an empty LOB.
    

  • 

    If an LCR whose command type is INSERT or UPDATE has a new LOB that contains no data, and the lob_information is DBMS_LCR.NULL_LOB or DBMS_LCR.INLINE_LOB, then it is applied as a NULL.
    

  • 

    If an LCR whose command type is INSERT or UPDATE has a new LOB and the lob_information is DBMS_LCR.LOB_CHUNK or DBMS_LCR.LAST_LOB_CHUNK, then any LOB value is ignored. If the command type is INSERT, then an empty LOB is inserted into the column under the assumption that LOB chunks will follow. If the command type is UPDATE, then the column value is ignored under the assumption that LOB chunks will follow.
    

  • 

    If all of the new columns in an LCR whose command type is UPDATE are LOBs whose lob_information is DBMS_LCR.LOB_CHUNK or DBMS_LCR.LAST_LOB_CHUNK, then the update is skipped under the assumption that LOB chunks will follow.
    

  • 

    For any LCR whose command type is UPDATE or DELETE, old LOB values are ignored.
    









LOB Assembly and Custom Apply of LCRs Containing LOB Columns


A change to a row in a table that does not include any LOB columns results in a single row LCR, but a change to a row that includes one or more LOB columns can result in multiple row LCRs. An apply process that does not send row LCRs that contain LOB columns to an apply handler can apply these row LCRs directly. However, before Oracle Database 10g Release 2, custom processing of row LCRs that contain LOB columns was complicated because apply handlers had to be configured to process multiple LCRs correctly for a single row change.


In Oracle Database 10g Release 2 and later, LOB assembly simplifies custom processing of row LCRs with LOB columns that were captured by a capture process. LOB assembly automatically combines multiple captured row LCRs resulting from a change to a row with LOB columns into one row LCR. An apply process passes this single row LCR to a DML handler or error handler when LOB assembly is enabled. Also, after LOB assembly, the LOB column values are represented by LOB locators, not by VARCHAR2 or RAW data type values. To enable LOB assembly for a procedure DML or error handler, set the assemble_lobs parameter to TRUE in the DBMS_APPLY_ADM.SET_DML_HANDLER procedure. LOB assembly is always enabled for statement DML handlers.


If the assemble_lobs parameter is set to FALSE for a DML or error handler, then LOB assembly is disabled and multiple row LCRs are passed to the handler for a change to a single row with LOB columns. Table 14-2 shows Oracle Streams behavior when LOB assembly is disabled. Specifically, the table shows the LCRs passed to a procedure DML handler or error handler resulting from a change to a single row with LOB columns.




Table 14-2 Oracle Streams Behavior with LOB Assembly Disabled


Original Row ChangeFirst Set of LCRsSecond Set of LCRsThird Set of LCRsFinal LCR


INSERT



One INSERT LCR



One or more LOB WRITE LCRs



One or more LOB TRIM LCRs



UPATE




UPDATE



One UPDATE LCR



One or more LOB WRITE LCRs



One or more LOB TRIM LCRs



UPATE




DELETE



One DELETE LCR



N/A



N/A



N/A




DBMS_LOB.WRITE



One or more LOB WRITE LCRs



N/A



N/A



N/A




DBMS_LOB.TRIM



One LOB TRIM LCR



N/A



N/A



N/A




DBMS_LOB.ERASE



One LOB ERASE LCR



N/A



N/A



N/A







Table 14-3 shows Oracle Streams behavior when LOB assembly is enabled. Specifically, the table shows the row LCR passed to a DML handler or error handler resulting from a change to a single row with LOB columns.




Table 14-3 Oracle Streams Behavior with LOB Assembly Enabled


Original Row ChangeSingle LCR


INSERT



INSERT




UPDATE



UPDATE




DELETE



DELETE




DBMS_LOB.WRITE



LOB WRITE




DBMS_LOB.TRIM



LOB TRIM




DBMS_LOB.ERASE



LOB ERASE







When LOB assembly is enabled, a DML or error handler can modify LOB columns in a row LCR. Within the PL/SQL procedure specified as a DML or error handler, the preferred way to perform operations on a LOB is to use a subprogram in the DBMS_LOB package. If a row LCR contains a LOB column that is NULL, then a new LOB locator must replace the NULL. If a row LCR will be applied with the EXECUTE member procedure, then use the ADD_COLUMN, SET_VALUE, and SET_VALUES member procedures for row LCRs to make changes to a LOB.


When LOB assembly is enabled, LOB assembly converts non-NULL LOB columns in persistent LCRs into LOB locators. However, LOB assembly does not combine multiple persistent row LCRs into a single row LCR. For example, for persistent row LCRs, LOB assembly does not combine multiple LOB WRITE row LCRs following an INSERT row LCR into a single INSERT row LCR.









See Also:












LOB Assembly Considerations


The following are issues to consider when you use LOB assembly:


  • 

    To use a DML or error handler to process assembled LOBs at multiple destination databases, LOB assembly must assemble the LOBs separately on each destination database.
    

  • 

    Row LCRs captured on a database running a release of Oracle before Oracle Database 10g Release 2 cannot be assembled by LOB assembly.
    

  • 

    Row LCRs captured on a database running Oracle Database 10g Release 2 or later with a compatibility level lower than 10.2.0 cannot be assembled by LOB assembly.
    

  • 

    The compatibility level of the database running an apply handler must be 10.2.0 or higher to specify LOB assembly for the apply handler.
    

  • 

    Row LCRs from a table containing any LONG or LONG RAW columns cannot be assembled by LOB assembly.
    

  • 

    The SET_ENQUEUE_DESTINATION and the SET_EXECUTE procedures in the DBMS_APPLY_ADM package always operate on original, nonassembled row LCRs. Therefore, for row LCRs that contain LOB columns, the original, nonassembled row LCRs are enqueued or executed, even if these row LCRs are assembled separately for an apply handler at the destination database.
    

  • 

    If rule-based transformations were performed on row LCRs that contain LOB columns during capture, propagation, or apply, then an apply handler operates on the transformed row LCRs. If there are LONG or LONG RAW columns at a source database, and a rule-based transformation uses the CONVERT_LONG_TO_LOB_CHUNK member function for row LCRs to convert them to LOBs, then LOB assembly can be enabled for apply handlers that operate on these row LCRs.
    

  • 

    When a row LCR contains one or more XMLType columns, any XMLType and LOB columns in the row LCR are always assembled, even if the assemble_lobs parameter is set to FALSE for a DML or error handler.
    










See Also:















LOB Assembly Example


This section contains an example that uses LOB assembly with a procedure DML handler. The example scenario involves a company that shares the oe.production_information table at several databases, but only some of these databases are used for the company's online World Wide Web catalog. The company wants to store a photograph of each product in the catalog databases, but, to save space, it does not want to store these photographs at the non catalog databases.


To accomplish this goal, a procedure DML handler at a catalog destination database can add a column named photo of data type BLOB to each INSERT and UPDATE made to the product_information table at a source database. The source database does not include the photo column in the table. The procedure DML handler is configured to use an existing photograph at the destination for updates and inserts.The company also wants to add a product_long_desc to the oe.product_information table at all databases. This table already has a product_description column that contains short descriptions. The product_long_desc column is of CLOB data type and contains detailed descriptions. The detailed descriptions are in English, but one of the company databases is used to display the company catalog in Spanish. Therefore, the procedure DML handler updates the product_long_desc column so that the long description is in the correct language.


The following steps configure a procedure DML handler that uses LOB assembly to accomplish the goals described previously:


Step 1   Add the photo Column to the product_information Table


The following statement adds the photo column to the product_information table at the destination database:


ALTER TABLE oe.product_information ADD(photo BLOB);

Step 2   Add the product_long_desc Column to the product_information Table


The following statement adds the product_long_desc column to the product_information table at all of the databases in the environment:


ALTER TABLE oe.product_information ADD(product_long_desc CLOB);

Step 3   Create the PL/SQL Procedure for the Procedure DML Handler


This example creates the convert_product_information procedure. This procedure will be used for the procedure DML handler. This procedure assumes that the following user-created PL/SQL subprograms exist:


  • 

    The get_photo procedure obtains a photo in BLOB format from a URL or table based on the product_id and updates the BLOB locator that has been passed in as an argument.
    

  • 

    The get_product_long_desc procedure has an IN argument of product_id and an IN OUT argument of product_long_desc and translates the product_long_desc into Spanish or obtains the Spanish replacement description and updates product_long_desc.
    



The following code creates the convert_product_information procedure:


CREATE OR REPLACE PROCEDURE convert_product_information(in_any IN ANYDATA)
IS
  lcr                      SYS.LCR$_ROW_RECORD;
  rc                       PLS_INTEGER;
  product_id_anydata       ANYDATA;
  photo_anydata            ANYDATA;
  long_desc_anydata        ANYDATA;
  tmp_photo                BLOB;
  tmp_product_id           NUMBER;
  tmp_prod_long_desc       CLOB;
  tmp_prod_long_desc_src   CLOB;
  tmp_prod_long_desc_dest  CLOB;
  t                        PLS_INTEGER;
BEGIN
  -- Access LCR
  rc := in_any.GETOBJECT(lcr);
  product_id_anydata := lcr.GET_VALUE('OLD', 'PRODUCT_ID');
  t := product_id_anydata.GETNUMBER(tmp_product_id);
  IF ((lcr.GET_COMMAND_TYPE = 'INSERT') or (lcr.GET_COMMAND_TYPE = 'UPDATE')) THEN
    -- If there is no photo column in the lcr then it must be added
    photo_anydata := lcr.GET_VALUE('NEW', 'PHOTO');
    -- Check if photo has been sent and if so whether it is NULL
    IF (photo_anydata is NULL) THEN
      tmp_photo := NULL;
      ELSE
      t := photo_anydata.GETBLOB(tmp_photo);
    END IF;
    -- If tmp_photo is NULL then a new temporary LOB must be created and
    -- updated with the photo if it exists
    IF (tmp_photo is NULL) THEN
      DBMS_LOB.CREATETEMPORARY(tmp_photo, TRUE);
      get_photo(tmp_product_id, tmp_photo);
    END IF;
    -- If photo column did not exist then it must be added
    IF (photo_anydata is NULL) THEN
      lcr.ADD_COLUMN('NEW', 'PHOTO', ANYDATA.CONVERTBLOB(tmp_photo));
      -- Else the existing photo column must be set to the new photo
      ELSE
        lcr.SET_VALUE('NEW', 'PHOTO', ANYDATA.CONVERTBLOB(tmp_photo));
    END IF;
    long_desc_anydata := lcr.GET_VALUE('NEW', 'PRODUCT_LONG_DESC');
    IF (long_desc_anydata is NULL) THEN
      tmp_prod_long_desc_src := NULL;
      ELSE
      t := long_desc_anydata.GETCLOB(tmp_prod_long_desc_src);
    END IF;
    IF (tmp_prod_long_desc_src IS NOT NULL) THEN
      get_product_long_desc(tmp_product_id, tmp_prod_long_desc);
    END IF;
    -- If tmp_prod_long_desc IS NOT NULL, then use it to update the LCR
    IF (tmp_prod_long_desc IS NOT NULL) THEN
      lcr.SET_VALUE('NEW', 'PRODUCT_LONG_DESC',
                    ANYDATA.CONVERTCLOB(tmp_prod_long_desc_dest));
    END IF;
  END IF;
  -- DBMS_LOB operations also are executed 
  -- Inserts and updates invoke all changes
  lcr.EXECUTE(TRUE);
END;
/

Step 4   Set the Procedure DML Handler for the Apply Process


This step sets the convert_product_information procedure as the procedure DML handler at the destination database for INSERT, UPDATE, and LOB_UPDATE operations. Notice that the assemble_lobs parameter is set to TRUE each time the SET_DML_HANDLER procedure is run.


BEGIN
  DBMS_APPLY_ADM.SET_DML_HANDLER(
    object_name         => 'oe.product_information',
    object_type         => 'TABLE',
    operation_name      => 'INSERT',
    error_handler       => FALSE,
    user_procedure      => 'strmadmin.convert_product_information',
    apply_database_link => NULL,
    assemble_lobs       => TRUE);
  DBMS_APPLY_ADM.SET_DML_HANDLER(
    object_name         => 'oe.product_information',
    object_type         => 'TABLE',
    operation_name      => 'UPDATE',
    error_handler       => FALSE,
    user_procedure      => 'strmadmin.convert_product_information',
    apply_database_link => NULL,
    assemble_lobs       => TRUE);
  DBMS_APPLY_ADM.SET_DML_HANDLER(
    object_name         => 'oe.product_information',
    object_type         => 'TABLE',
    operation_name      => 'LOB_UPDATE',
    error_handler       => FALSE,
    user_procedure      => 'strmadmin.convert_product_information',
    apply_database_link => NULL,
    assemble_lobs       => TRUE);
END;
/

Step 5   Query the DBA_APPLY_DML_HANDLERS View


To ensure that the procedure DML handler is set properly for the oe.product_information table, run the following query:


COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A10
COLUMN USER_PROCEDURE HEADING 'Handler Procedure' FORMAT A25
COLUMN ASSEMBLE_LOBS HEADING 'LOB Assembly?' FORMAT A15

SELECT OBJECT_OWNER, 
       OBJECT_NAME, 
       OPERATION_NAME, 
       USER_PROCEDURE,
       ASSEMBLE_LOBS
  FROM DBA_APPLY_DML_HANDLERS;



Your output looks similar to the following:


Table
Owner Table Name           Operation  Handler Procedure         LOB Assembly?
----- -------------------- ---------- ------------------------- ---------------
OE    PRODUCT_INFORMATION  INSERT     "STRMADMIN"."CONVERT_PROD Y
                                      UCT_INFORMATION"
 
OE    PRODUCT_INFORMATION  UPDATE     "STRMADMIN"."CONVERT_PROD Y
                                      UCT_INFORMATION"
 
OE    PRODUCT_INFORMATION  LOB_UPDATE "STRMADMIN"."CONVERT_PROD Y
                                      UCT_INFORMATION"



Notice that the correct procedure, convert_product_information, is used for each operation on the table. Also, notice that each handler uses LOB assembly.












Requirements for Constructing and Processing LCRs Containing LOB Columns


If your environment produces row LCRs that contain LOB columns, then you must meet the requirements in the following sections when you construct or process these LCRs:










See Also:

Oracle Streams Extended Examples for an example that constructs and enqueues LCRs that contain LOBs









Requirements for Constructing and Processing LCRs Without LOB Assembly


The following requirements must be met when you are constructing LCRs with LOB columns and when you are processing LOB columns with a DML or error handler that has LOB assembly disabled:


  • 

    Do not modify LOB column data in a row LCR with a procedure DML handler or error handler that has LOB assembly disabled. However, you can modify non-LOB columns in row LCRs with a DML or error handler.
    

  • 

    Do not allow LCRs from a table that contains LOB columns to be processed by an apply handler that is invoked only for specific operations. For example, an apply handler that is invoked only for INSERT operations should not process LCRs from a table with one or more LOB columns.
    

  • 

    The data portion of the LCR LOB column must be of type VARCHAR2 or RAW. A VARCHAR2 is interpreted as a CLOB, and a RAW is interpreted as a BLOB.
    

  • 

    A LOB column in a user-constructed row LCR must be either a BLOB or a fixed-width CLOB. You cannot construct a row LCR with the following types of LOB columns: NCLOB or variable-width CLOB.
    

  • 

    LOB WRITE, LOB ERASE, and LOB TRIM are the only valid command types for out-of-line LOBs.
    

  • 

    For LOB WRITE, LOB ERASE, and LOB TRIM LCRs, the old_values collection should be empty or NULL, and new_values should not be empty.
    

  • 

    The lob_offset shoul4Ad be a valid value for LOB WRITE and LOB ERASE LCRs. For all other command types, lob_offset should be NULL, under the assumption that LOB chunks for that column will follow.
    

  • 

    The lob_operation_size should be a valid value for LOB ERASE and LOB TRIM LCRs. For all other command types, lob_operation_size should be NULL.
    

  • 

    LOB TRIM and LOB ERASE are valid command types only for an LCR containing a LOB column with lob_information set to LAST_LOB_CHUNK.
    

  • 

    LOB WRITE is a valid command type only for an LCR containing a LOB column with lob_information set to LAST_LOB_CHUNK or LOB_CHUNK.
    

  • 

    For LOBs with lob_information set to NULL_LOB, the data portion of the column should be a NULL of VARCHAR2 type (for a CLOB) or a NULL of RAW type (for a BLOB). Otherwise, it is interpreted as a non-NULL inline LOB column.
    

  • 

    Only one LOB column reference with one new chunk is allowed for each LOB WRITE, LOB ERASE, and LOB TRIM LCR.
    

  • 

    The new LOB chunk for a LOB ERASE and a LOB TRIM LCR should be a NULL value encapsulated in an ANYDATA.
    



An apply process performs all validation of these requirements. If these requirements are not met, then a row LCR containing LOB columns cannot be applied by an apply process nor processed by an apply handler. In this case, the LCR is moved to the error queue with the rest of the LCRs in the same transaction.









See Also:















Requirements for Apply Handler Processing of LCRs with LOB Assembly


The following requirements must be met when you are processing LOB columns with a DML or error handler that has LOB assembly enabled:


  • 

    Do not use the following row LCR member procedures on LOB columns in row LCRs that contain assembled LOBs:
    

    • 

      SET_LOB_INFORMATION
      

    • 

      SET_LOB_OFFSET
      

    • 

      SET_LOB_OPERATION_SIZE
      

    

    An error is raised if one of these procedures is used on a LOB column in a row LCR.
    

  • 

    Row LCRs constructed by LOB assembly cannot be enqueued by a procedure DML handler or error handler. However, even when LOB assembly is enabled for one or more handlers at a destination database, the original, nonassembled row LCRs with LOB columns can be enqueued using the SET_ENQUEUE_DESTINATION procedure in the DBMS_APPLY_ADM package.
    



An apply process performs all validation of these requirements. If these requirements are not met, then a row LCR containing LOB columns cannot be applied by an apply process nor processed by an apply handler. In this case, the LCR is moved to the error queue with the rest of the LCRs in the same transaction. For row LCRs with LOB columns, the original, nonassembled row LCRs are placed in the error queue.









See Also:















Requirements for Rule-Based Transformation Processing of LCRs with LOBs


The following requirements must be met when you are processing row LCRs that contain LOB columns with a rule-based transformation:


  • 

    Do not modify LOB column data in a row LCR with a custom rule-based transformation. However, a custom rule-based transformation can modify non-LOB columns in row LCRs that contain LOB columns.
    

  • 

    You cannot use the following row LCR member procedures on a LOB column when you are processing a row LCR with a custom rule-based transformation:
    

    • 

      ADD_COLUMN
      

    • 

      SET_LOB_INFORMATION
      

    • 

      SET_LOB_OFFSET
      

    • 

      SET_LOB_OPERATION_SIZE
      

    • 

      SET_VALUE
      

    • 

      SET_VALUES
      

    

  • 

    A declarative rule-based transformation created by the ADD_COLUMN procedure in the DBMS_STREAMS_ADM package cannot add a LOB column to a row LCR.
    

  • 

    Rule-based transformation functions that are run on row LCRs with LOB columns must be deterministic, so that all row LCRs corresponding to the row change are transformed in the same way.
    

  • 

    Do not allow LCRs from a table that contains LOB columns to be processed by an a custom rule-based transformation that is invoked only for specific operations. For example, a custom rule-based transformation that is invoked only for INSERT operations should not process LCRs from a table with one or more LOB columns.
    










Note:

If row LCRs contain LOB columns, then rule-based transformations always operate on the original, nonassembled row LCRs.













See Also:



















Managing LCRs Containing LONG or LONG RAW Columns


LONG and LONG RAW data types all can be present in row LCRs captured by a capture process, but these data types are represented by the following data types in row LCRs.


  • 

    LONG data type is represented as VARCHAR2 data type in row LCRs.
    

  • 

    LONG RAW data type is represented as RAW data type in row LCRs.
    



A row change involving a LONG or LONG RAW column can be captured, propagated, and applied as several LCRs. If your environment uses LCRs that contain LONG or LONG RAW columns, then the data portion of the LCR LONG or LONG RAW column must be of type VARCHAR2 or RAW. A VARCHAR2 is interpreted as a LONG, and a RAW is interpreted as a LONG RAW.


You must meet the following requirements when you are processing row LCRs that contain LONG or LONG RAW column data in Oracle Streams:


  • 

    Do not modify LONG or LONG RAW column data in an LCR using a custom rule-based transformation. However, you can use a rule-based transformation to modify non LONG and non LONG RAW columns in row LCRs that contain LONG or LONG RAW column data.
    

  • 

    Do not use the SET_VALUE or SET_VALUES row LCR member procedures in a custom rule-based transformation that is processing a row LCR that contains LONG or LONG RAW data. Doing so raises the ORA-26679 error.
    

  • 

    Rule-based transformation functions that are run on LCRs that contain LONG or LONG RAW columns must be deterministic, so that all LCRs corresponding to the row change are transformed in the same way.
    

  • 

    A declarative rule-based transformation created by the ADD_COLUMN procedure in the DBMS_STREAMS_ADM package cannot add a LONG or LONG RAW column to a row LCR.
    

  • 

    You cannot use a procedure DML handler or error handler to process row LCRs that contain LONG or LONG RAW column data.
    

  • 

    Rules used to evaluate LCRs that contain LONG or LONG RAW columns must be deterministic, so that either all of the LCRs corresponding to the row change cause a rule in a rule set to evaluate to TRUE, or none of them do.
    

  • 

    You cannot use an apply process to enqueue LCRs that contain LONG or LONG RAW column data into a destination queue. The SET_DESTINATION_QUEUE procedure in the DBMS_APPLY_ADM package sets the destination queue for LCRs that satisfy a specified apply process rule.
    










Note:

LONG and LONG RAW data types cannot be present in row LCRs captured by synchronous captures or constructed by users.













See Also:















PK;۔44PK+AOEBPS/prep_rep.htm

Preparing for Oracle Streams Replication



1 Preparing for Oracle Streams Replication


This chapter contains information about preparing for an Oracle Streams replication environment. This chapter also describes best practices to follow when you are preparing for an Oracle Streams replication environment.


This chapter contains these topics:










See Also:

Oracle Streams Concepts and Administration for general information about Oracle Streams. This document assumes that you understand the concepts described in Oracle Streams Concepts and Administration.









Overview of Oracle Streams Replication


Replication is the process of sharing database objects and data at multiple databases. To maintain replicated database objects and data at multiple databases, a change to one of these database objects at a database is shared with the other databases. Through this process, the database objects and data are kept synchronized at all of the databases in the replication environment. In an Oracle Streams replication environment, the database where a change originates is called the source database, and a database where a change is shared is called a destination database.


When you use Oracle Streams, replication of a data manipulation language (DML) or data definition language (DDL) change typically includes three steps:



  1. 

    A capture process, a synchronous capture, or an application creates one or more logical change records (LCRs) and enqueues them. An LCR is a message with a specific format that describes a database change. A capture process reformats changes captured from the redo log into LCRs, a synchronous capture uses an internal mechanism to reformat changes into LCRs, and an application can construct LCRs. If the change was a DML operation, then each row LCR encapsulates a row change resulting from the DML operation to a replicated table at the source database. If the change was a DDL operation, then a DDL LCR encapsulates the DDL change that was made to a replicated database object at a source database.
    

  2. 

    A propagation propagates the staged LCRs to another queue, which usually resides in a database that is separate from the database where the LCRs were captured. An LCR can be propagated to several different queues before it arrives at a destination database.
    

  3. 

    At a destination database, an apply process consumes the change. An apply process can dequeue the LCR and apply it directly to the replicated database object, or an apply process can dequeue the LCR and send it to an apply handler. In an Oracle Streams replication environment, an apply handler performs customized processing of an LCR. An apply handler can apply the change in the LCR to the replicated database object, or it can consume the LCR in some other way.
    



Step 1 and Step 3 are required, but Step 2 is optional because, in some cases, a capture process or a synchronous capture can enqueue a change into a queue, and an apply process can dequeue the change from the same queue. An application can also enqueue an LCR directly at a destination database. In addition, in a heterogeneous replication environment in which an Oracle database shares information with a non-Oracle database, an apply process can apply changes directly to a non-Oracle database without propagating LCRs.


Figure 1-1 illustrates the information flow in an Oracle Streams replication environment.




Figure 1-1 Oracle Streams Information Flow

Description of Figure 1-1 follows

Description of "Figure 1-1 Oracle Streams Information Flow"





This document describes how to use Oracle Streams for replication and includes the following information:


  • 

    Conceptual information relating to Oracle Streams replication
    

  • 

    Instructions for configuring an Oracle Streams replication environment
    

  • 

    Instructions for administering, monitoring, and troubleshooting an Oracle Streams replication environment
    

  • 

    Examples that create and maintain Oracle Streams replication environments
    



Replication is one form of information sharing. Oracle Streams enables replication, and it also enables other forms of information sharing, such as messaging, event management and notification, data warehouse loading, and data protection.









See Also:

Oracle Streams Concepts and Administration for more information about Oracle Streams









Common Reasons to Use Oracle Streams Replication


The following are some of the most common reasons for using Oracle Streams replication:


  • 

    Availability: Replication provides fast, local access to shared data because it balances activity over multiple sites. Some users can access one server while other users access different servers, thereby reducing the load at all servers. Also, users can access data from the replication site that has the lowest access cost, which is typically the site that is geographically closest to them.
    

  • 

    Performance and Network Load Reduction: Replication provides fast, local access to shared data because it balances activity over multiple sites. Some users can access one server while other users access different servers, thereby reducing the load at all servers. Applications can access various regional servers instead of accessing one central server. This configuration can reduce network load dramatically.
    









Rules in an Oracle Streams Replication Environment


A rule is a database object that enables a client to perform an action when an event occurs and a condition is satisfied. Rules are evaluated by a rules engine, which is a built-in part of Oracle Database. Rules control the information flow in an Oracle Streams replication environment. Each of the following components is a client of the rules engine:


  • 

    Capture process
    

  • 

    Synchronous capture
    

  • 

    Propagation
    

  • 

    Apply process
    



You control the behavior of each of these Oracle Streams clients using rules. A rule set contains a collection of rules. You can associate a positive and a negative rule set with a capture process, a propagation, and an apply process, but a synchronous capture can have only a positive rule set.


In a replication environment, an Oracle Streams client performs an action if a logical change record (LCR) satisfies its rule sets. In general, an LCR satisfies the rule sets for an Oracle Streams client if no rules in the negative rule set evaluate to TRUE for the LCR, and at least one rule in the positive rule set evaluates to TRUE for the LCR. If an Oracle Streams client is associated with both a positive and negative rule set, then the negative rule set is always evaluated first.


Specifically, you control the information flow in an Oracle Streams replication environment in the following ways:


  • 

    Specify the changes that a capture process captures from the redo log or discards. That is, if a change found in the redo log satisfies the rule sets for a capture process, then the capture process captures the change. If a change found in the redo log does not satisfy the rule sets for a capture process, then the capture process discards the change.
    

  • 

    Specify the changes that a synchronous capture captures or discards. That is, if a DML change made to a table satisfies the rule set for a synchronous capture, then the synchronous capture captures the change. If a DML change made to a table does not satisfy the rule set for a synchronous capture, then the synchronous capture discards the change.
    

  • 

    Specify the LCRs that a propagation propagates from one queue to another or discards. That is, if an LCR in a queue satisfies the rule sets for a propagation, then the propagation sends the LCR. If an LCR in a queue does not satisfy the rule sets for a propagation, then the propagation discards the LCR.
    

  • 

    Specify the LCRs that an apply process dequeues or discards. That is, if an LCR in a queue satisfies the rule sets for an apply process, then the apply process dequeues and processes the LCR. If an LCR in a queue does not satisfy the rule sets for an apply process, then the apply process discards the LCR.
    



You can use the Oracle-supplied PL/SQL package DBMS_STREAMS_ADM to create rules for an Oracle Streams replication environment. You can specify these system-created rules at the following levels:


  • 

    Table level - Contains a rule condition that evaluates to TRUE for changes made to a particular table
    

  • 

    Schema level - Contains a rule condition that evaluates to TRUE for changes made to a particular schema and the database objects in the schema
    

  • 

    Global level - Contains a rule condition that evaluates to TRUE for all changes made to a database
    



In addition, a single system-created rule can evaluate to TRUE for DML changes or for DDL changes, but not both. So, for example, to replicate both DML and DDL changes to a particular table, you need both a table-level DML rule and a table-level DDL rule for the table.


Oracle Streams also supports subsetting of table data with subset rules. If a replicated table in a database contains only a subset of the data, then you can configure Oracle Streams so that only the appropriate subset of the data is replicated. For example, a particular database might maintain data for employees in a particular department only. One or more other databases in the replication environment might contain all of the data in the employees table. In this case, you can use subset rules to replicate changes to the data for employees in that department with the subset table, but not changes to employees in other departments.


Subsetting can be done at any point in the Oracle Streams information flow. That is, a capture process or synchronous capture can use a subset rule to capture a subset of changes to a particular table, a propagation can use a subset rule to propagate a subset of changes to a particular table, and an apply process can use a subset rule to apply a subset of changes to a particular table.









Note:

Synchronous captures only use table rules. Synchronous captures ignore schema and global rules.













See Also:

Oracle Streams Concepts and Administration for more information about how rules are used in Oracle Streams














Decisions to Make Before Configuring Oracle Streams Replication


Make the following decisions before configuring Oracle Streams replication:






Decide Which Type of Replication Environment to Configure


Before configuring a replication environment, first decide how many databases will be included in the replication environment, which database objects will be replicated, and how database changes will flow through the replication environment. Here are the most common types of replication environments:


  • 

    One-way replication in a two database environment where one database is read/write and the other database is read-only
    

  • 

    Bi-directional replication in a two database environment where both databases are read/write
    

  • 

    Hub-and-spoke replication with a read/write hub and read-only spokes
    

  • 

    Hub-and-spoke replication with a read/write hub and one or more read/write spokes
    

  • 

    N-way replication with multiple read/write databases
    



One of these environments meet the replication requirements of most organizations. Oracle Database 2 Day + Data Replication and Integration Guide describes these common types of replication environments in detail.


If these common replication environments do not meet your requirements, then you can configure almost any type of custom replication environment with Oracle Streams. For example, a custom replication environment might send database changes through several intermediary databases before the changes are applied at a destination database.








Decide Whether to Configure Local or Downstream Capture for the Source Database


Local capture means that a capture process runs on the source database. Downstream capture means that a capture process runs on a database other than the source database. The primary reason to use downstream capture is to reduce the load on the source database, thereby improving its performance.


The database that captures changes made to the source database is called the capture database. One of the following databases can be the capture database:


  • 

    Source database (local capture)
    

  • 

    Destination database (downstream capture)
    

  • 

    A third database (downstream capture)
    



Figure 1-2 shows the role of the capture database.




Figure 1-2 The Capture Database

Description of Figure 1-2 follows

Description of "Figure 1-2 The Capture Database"





If the source database or a third database is the capture database, then a propagation sends changes from the capture database to the destination database. If the destination database is the capture database, then this propagation between databases is not needed because the capture process and apply process use the same queue.


If you decide to configure a downstream capture process, then you must decide which type of downstream capture process you want to configure. The following types are available:


  • 

    A real-time downstream capture process configuration means that redo transport services use the log writer process (LGWR) at the source database to send redo data to the downstream database, and a remote file server process (RFS) at the downstream database receives the redo data over the network and stores the redo data in the standby redo log.
    

  • 

    An archived-log downstream capture process configuration means that archived redo log files from the source database are copied to the downstream database, and the capture process captures changes in these archived redo log files. These log files can be transferred automatically using redo transport services, or they can be transferred manually using a method such at FTP.
    



The advantage of real-time downstream capture over archived-log downstream capture is that real-time downstream capture reduces the amount of time required to capture changes made at the source database. The time is reduced because the real-time downstream capture process does not need to wait for the redo log file to be archived before it can capture changes from it. You can configure multiple real-time downstream capture processes that captures changes from the same source database, but you cannot configure real-time downstream capture for multiple source databases at one downstream database.


The advantage of archived-log downstream capture over real-time downstream capture is that archived-log downstream capture allows downstream capture processes from multiple source databases at a downstream database. You can copy redo log files from multiple source databases to a single downstream database and configure multiple archived-log downstream capture processes to capture changes in these redo log files.


If you decide to configure a real-time downstream capture process, then you must complete the steps in "Configuring Log File Transfer to a Downstream Capture Database" and "Adding Standby Redo Logs for Real-Time Downstream Capture".


If you decide to configure an archived-log downstream capture process that uses archived redo log files that were transferred to the downstream database automatically by redo transport services, then you must complete the steps in "Configuring Log File Transfer to a Downstream Capture Database".









Note:

When the RMAN DUPLICATE or CONVERT DATABASE command is used for database instantiation with one of these procedures, the destination database cannot be the capture database.













Decide Whether Changes Are Allowed at One Database or at Multiple Databases


A replication environment can limit changes to a particular replicated database object to one database only. In this case, the replicated database object is read/write at one database and read-only at the other databases in the replication environment. Or, a replication environment can allow changes to a replicated database object at two or more databases.


When two or more databases can change a replicated database object, conflicts are possible. A conflict is a mismatch between the old values in an LCR and the expected data in a table. Conflicts can occur in an Oracle Streams replication environment that permits concurrent data manipulation language (DML) operations on the same data at multiple databases. Conflicts typically result when two or more databases make changes to the same row in a replicated table at nearly the same time. If conflicts are not resolved, then they can result in inconsistent data at replica databases.


Typically, conflicts are possible in the following common types of replication environments:


  • 

    Bi-directional replication in a two database environment where the replicated database objects at both databases are read/write
    

  • 

    Hub-and-spoke replication where the replicated database objects are read/write at the hub and at one or more spokes
    

  • 

    N-way replication where the replicated database objects are read/write at multiple databases
    



Oracle Database 2 Day + Data Replication and Integration Guide describes these common types of replication environments in more detail.


Oracle Streams provides prebuilt conflict handlers to resolve conflicts automatically. You can also build your own custom conflict handler to resolve data conflicts specific to your business rules. Such a conflict handler can be part of a procedure DML handler or an error handler.


If conflicts are possible in the replication environment you plan to configure, then plan to create conflict handlers to resolve these conflicts.









Decide Whether the Replication Environment Will Have Nonidentical Replicas


Oracle Streams replication supports sharing database objects that are not identical at multiple databases. Different databases in the Oracle Streams environment can contain replicated database objects with different structures. In Oracle Streams replication, a rule-based transformation is any modification to a logical change record (LCR) that results when a rule in a positive rule set evaluates to TRUE. You can configure rule-based transformations during capture, propagation, or apply to make any necessary changes to LCRs so that they can be applied at a destination database.


For example, a table at a source database can have the same data as a table at a destination database, but some column names can be different. In this case, a rule-based transformation can change the names of the columns in LCRs from the source database so that they can be applied successfully at the destination database.


There are two types of rule-based transformations: declarative and custom. Declarative rule-based transformations cover a set of common transformation scenarios for row LCRs, including renaming a schema, renaming a table, adding a column, renaming a column, keeping a list of columns, and deleting a column. You specify such a transformation using a procedure in the DBMS_STREAMS_ADM package. Oracle Streams performs declarative transformations internally, without invoking PL/SQL.


A custom rule-based transformation requires a user-defined PL/SQL function to perform the transformation. Oracle Streams invokes the PL/SQL function to perform the transformation. A custom rule-based transformation can modify captured LCRs, persistent LCRs, or user messages. For example, a custom rule-based transformation can change the data type of a particular column in an LCR. A custom rule-based transformation must be defined as a PL/SQL function that takes an ANYDATA object as input and returns an ANYDATA object.


Rule-based transformations can be done at any point in the Oracle Streams information flow. That is, a capture process or a synchronous capture can perform a rule-based transformation on a change when a rule in its positive rule set evaluates to TRUE for the change. Similarly, a propagation or an apply process can perform a rule-based transformation on an LCR when a rule in its positive rule set evaluates to TRUE for the LCR.


If you plan to have nonidentical copies of database objects in your replication environment, then plan to create rule-based transformations that will modify LCRs so that they can be applied successfully at destination databases.









Note:

Throughout this document, "rule-based transformation" is used when the text applies to both declarative and custom rule-based transformations. This document distinguishes between the two types of rule-based transformations when necessary.













See Also:

Oracle Streams Concepts and Administration for more information about rule-based transformations












Decide Whether the Replication Environment Will Use Apply Handlers


When you use an apply handler, an apply process passes a message to either a collection of SQL statements or a user-created PL/SQL procedure for processing.


The following types of apply handlers are possible:


  • 

    A statement DML handler uses a collection of SQL statement to process row logical change records (row LCRs).
    

  • 

    A procedure DML handler uses a PL/SQL procedure to process row LCRs.
    

  • 

    A DDL handler uses a PL/SQL procedure to process DDL LCRs.
    

  • 

    A message handler uses a PL/SQL procedure to process user messages.
    

  • 

    A precommit handlers uses a PL/SQL procedure to process the commit information for a transaction.
    

  • 

    An error handler uses a PL/SQL procedure to process row LCRs that have caused apply errors.
    



An apply handler can process a message in a customized way. For example, a handler might audit the changes made to a table or enqueue an LCR into a queue after the change in the LCR has been applied. An application can then process the re-enqueued LCR. A handler might also be used to audit the changes made to a database.


If you must process LCRs in a customized way in your replication environment, then decide which apply handlers you should use to accomplish your goals. Next, create the PL/SQL procedures that will perform the custom processing and specify these procedures as apply handlers when your environment is configured.









Decide Whether to Maintain DDL Changes


Replication environments typically maintain data manipulation language (DML) changes to the replicated database objects. DML changes include INSERT, UPDATE, DELETE, and LOB update operations. You must decide whether you want the replication environment to maintain data definition language (DDL) changes as well. Examples of statements that result in DDL changes are CREATE TABLE, ALTER TABLE, ALTER TABLESPACE, and ALTER DATABASE.


Some Oracle Streams replication environments assume that the database objects are the same at each database. In this case, maintaining DDL changes with Oracle Streams makes it easy to keep the shared database objects synchronized. However, some Oracle Streams replication environments require that shared database objects are different at different databases. For example, a table can have a different name or shape at two different databases. In these environments, rule-based transformations and apply handlers can modify changes so that they can be shared between databases, and you might not want to maintain DDL changes with Oracle Streams. In this case, you should make DDL changes manually at each database that required them.


When replicating data definition language (DDL) changes, do not allow system-generated names for constraints or indexes. Modifications to these database objects will most likely fail at the destination database because the object names at the different databases will not match. Also, storage clauses might cause problems if the destination databases are not identical. If you decide not to replicate DDL in your Oracle Streams environment, then any table structure changes must be performed manually at each database in the environment.









Decide How to Configure the Replication Environment


There are three options for configuring an Oracle Streams replication environment:


  • 

    Run the Setup Streams Replication wizard to configure replication between two databases. You can run the wizard multiple times to configure a replication environment with more than two databases.
    

    The wizard walks you through the process of configuring your replication environment, but there are some limits to the types of replication environments that can be configured with the wizard. For example, the wizard currently cannot configure synchronous capture.
    

    See "Configuring Replication Using the Setup Streams Replication Wizard", Oracle Database 2 Day + Data Replication and Integration Guide, and the Oracle Enterprise Manager online help for more information about the replication configuration wizards.
    

  • 

    Run a configuration procedure in the DBMS_STREAMS_ADM supplied PL/SQL package to configure replication between two databases. You can run the procedure multiple times to configure a replication environment with more than two databases.
    

    The following procedures configure Oracle Streams replication:
    

    • 

      The MAINTAIN_GLOBAL procedure configures an Oracle Streams environment that replicates changes at the database level between two databases.
      

    • 

      The MAINTAIN_SCHEMAS procedure configures an Oracle Streams environment that replicates changes to specified schemas between two databases.
      

    • 

      The MAINTAIN_SIMPLE_TTS procedure clones a simple tablespace from a source database at a destination database and uses Oracle Streams to maintain this tablespace at both databases.
      

    • 

      The MAINTAIN_TABLES procedure configures an Oracle Streams environment that replicates changes to specified tables between two databases.
      

    • 

      The MAINTAIN_TTS procedure clones a set of tablespaces from a source database at a destination database and uses Oracle Streams to maintain these tablespaces at both databases.
      

    

    These procedures configure multiple Oracle Streams components with a single procedure call, and they automatically follow Oracle Streams best practices. They are ideal for configuring one-way, bi-directional, and hub-and-spoke replication environments.
    

    See "Configuring Replication Using the DBMS_STREAMS_ADM Package" and Oracle Database PL/SQL Packages and Types Reference for more information about these procedures.
    

  • 

    Configure each Oracle Streams component separately. These components include queues, capture processes, synchronous captures, propagations, and apply processes. Choose this option if you plan to configure an n-way replication environment, or if you plan to configure another type of replication environment that cannot be configured with the wizards or configuration procedures.
    

    See Chapter 3, "Flexible Oracle Streams Replication Configuration" for information about configuring each component of a replication environment separately.
    



Your configuration options might be limited by the type of replication environment you want to configure. See "Decide Which Type of Replication Environment to Configure".


Table 1-1 lists the configuration options that are available for each type of replication environment.




Table 1-1 Oracle Streams Replication Configuration Options


Type of Replication EnvironmentConfiguration Options and Examples


One-way replication in a two database replication environment



Setup Streams Replication Wizard in Oracle Enterprise Manager. Examples:



A configuration procedure in the DBMS_STREAMS_ADM supplied PL/SQL package. Examples:



Configure each Oracle Streams component individually. Examples:





Bi-directional replication in a two database replication environment



Setup Streams Replication Wizard in Oracle Enterprise Manager. Example:



A configuration procedure in the DBMS_STREAMS_ADM supplied PL/SQL package. Examples:



Configure each Oracle Streams component individually. Example:





Hub-and-spoke replication with a read/write hub and read-only spokes



A configuration procedure in the DBMS_STREAMS_ADM supplied PL/SQL package.


Configure each Oracle Streams component individually.




Hub-and-spoke replication with a read/write hub and one or more read/write spokes



Setup Streams Replication Wizard in Oracle Enterprise Manager. Example:



A configuration procedure in the DBMS_STREAMS_ADM supplied PL/SQL package. Example:



Configure each Oracle Streams component individually.




N-way replication with multiple read/write databases



Configure each Oracle Streams component individually. Example:





Custom replication environment



Configure each Oracle Streams component individually. See Chapter 3, "Flexible Oracle Streams Replication Configuration" for instructions. Examples:








Before configuring the replication environment, complete the tasks in "Tasks to Complete Before Configuring Oracle Streams Replication".










Tasks to Complete Before Configuring Oracle Streams Replication


The following sections describe tasks to complete before configuring Oracle Streams replication:






Configuring an Oracle Streams Administrator on All Databases


To configure and manage an Oracle Streams environment, either create a new user with the appropriate privileges or grant these privileges to an existing user. You should not use the SYS or SYSTEM user as an Oracle Streams administrator, and the Oracle Streams administrator should not use the SYSTEM tablespace as its default tablespace.


Typically, the user name for the Oracle Streams administrator is strmadmin, but any user with the proper privileges can be an Oracle Streams administrator. The examples in this section use strmadmin for the Oracle Streams administrator user name.


Create a separate tablespace for the Oracle Streams administrator at each participating Oracle Streams database. This tablespace stores any objects created in the Oracle Streams administrator schema, including any spillover of messages from the buffered queues owned by the schema.









See Also:

Oracle Database 2 Day + Data Replication and Integration Guide for instructions about creating an Oracle Streams administrator using Oracle Enterprise Manager






Complete the following steps to configure an Oracle Streams administrator at each database in the environment that will use Oracle Streams:


  1. 

    In SQL*Plus, connect as an administrative user who can create users, grant privileges, and create tablespaces. Remain connected as this administrative user for all subsequent steps.
    

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
    

  2. 

    Either create a tablespace for the Oracle Streams administrator or use an existing tablespace. For example, the following statement creates a new tablespace for the Oracle Streams administrator:
    

    CREATE TABLESPACE streams_tbs DATAFILE '/usr/oracle/dbs/streams_tbs.dbf' 
  SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;

  3. 

    Create a new user to act as the Oracle Streams administrator or use an existing user. For example, to create a user named strmadmin and specify that this user uses the streams_tbs tablespace, run the following statement:
    

    CREATE USER strmadmin IDENTIFIED BY password 
   DEFAULT TABLESPACE streams_tbs
   QUOTA UNLIMITED ON streams_tbs;

    

    


    

    

    Note:
    
Enter an appropriate password for the administrative user.
    

    

    

    


    

    

    See Also:
    
Oracle Database Security Guide for guidelines for choosing passwords
    

    

    

  4. 

    Grant the Oracle Streams administrator DBA role:
    

    GRANT DBA TO strmadmin;

    

    


    

    

    Note:
    
The DBA role is required for a user to create or alter capture processes, synchronous captures, and apply processes. When the user does not need to perform these tasks, DBA role can be revoked from the user.
    

    

    

  5. 

    Run the GRANT_ADMIN_PRIVILEGE procedure in the DBMS_STREAMS_AUTH package.
    

    A user must have explicit EXECUTE privilege on a package to execute a subprogram in the package inside of a user-created subprogram, and a user must have explicit SELECT privilege on a data dictionary view to query the view inside of a user-created subprogram. These privileges cannot be through a role. You can run the GRANT_ADMIN_PRIVILEGE procedure to grant such privileges to the Oracle Streams administrator, or you can grant them directly.
    

    Depending on the parameter settings for the GRANT_ADMIN_PRIVILEGE procedure, it either grants the privileges for an Oracle Streams administrator directly, or it generates a script that you can edit and then run to grant these privileges.
    

    


    

    

    See Also:
    
Oracle Database PL/SQL Packages and Types Reference for more information about this procedure
    

    

    

    Use the GRANT_ADMIN_PRIVILEGE procedure to grant privileges directly:
    

    Run the following procedure:
    

    BEGIN
  DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
    grantee          => 'strmadmin',    
    grant_privileges => TRUE);
END;
/

    

    Use the GRANT_ADMIN_PRIVILEGE procedure to generate a script:
    

    Complete the following steps:
    


    1. 

      Use the SQL statement CREATE DIRECTORY to create a directory object for the directory into which you want to generate the script. A directory object is similar to an alias for the directory. For example, to create a directory object called strms_dir for the /usr/admin directory on your computer system, run the following procedure:
      

      CREATE DIRECTORY strms_dir AS '/usr/admin';

    2. 

      Run the GRANT_ADMIN_PRIVILEGE procedure to generate a script named grant_strms_privs.sql and place this script in the /usr/admin directory on your computer system:
      

      BEGIN
  DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
    grantee          => 'strmadmin',    
    grant_privileges => FALSE,
    file_name        => 'grant_strms_privs.sql',
    directory_name   => 'strms_dir');
END;
/

      

      Notice that the grant_privileges parameter is set to FALSE so that the procedure does not grant the privileges directly. Also, notice that the directory object created in Step a is specified for the directory_name parameter.
      

    3. 

      Edit the generated script if necessary and save your changes.
      

    4. 

      Execute the script in SQL*Plus:
      

      SET ECHO ON
SPOOL grant_strms_privs.out
@/usr/admin/grant_strms_privs.sql
SPOOL OFF

    5. 

      Check the spool file to ensure that all of the grants executed successfully. If there are errors, then edit the script to correct the errors and rerun it.
      

    

  6. 

    If necessary, grant the following additional privileges:
    

    • 

      If you plan to use Oracle Enterprise Manager to manage databases with Oracle Streams components, then configure the Oracle Streams administrator to be a Database Control administrator. Doing so grants additional privileges required by Oracle Enterprise Manager, such as the privileges required to run Oracle Enterprise Manager jobs. See Oracle Database 2 Day DBA for instructions.
      

    • 

      Grant the privileges for a remote Oracle Streams administrator to perform actions in the local database. Grant these privileges using the GRANT_REMOTE_ADMIN_ACCESS procedure in the DBMS_STREAMS_AUTH package. Grant this privilege if a remote Oracle Streams administrator will use a database link that connects to the local Oracle Streams administrator to perform administrative actions. Specifically, grant these privileges if either of the following conditions are true:
      

      • 

        You plan to configure a downstream capture process at a remote downstream database that captures changes originating at the local source database, and the downstream capture process will use a database link to perform administrative actions at the source database.
        

      • 

        You plan to configure an apply process at the local database and use a remote Oracle Streams administrator to set the instantiation SCN values for replicated database objects at the local database.
        

      

    • 

      If no apply user is specified for an apply process, then grant the Oracle Streams administrator the necessary privileges to perform DML and DDL changes on the apply objects owned by other users. If an apply user is specified, then the apply user must have these privileges. These privileges can be granted directly or through a role.
      

    • 

      If no apply user is specified for an apply process, then grant the Oracle Streams administrator EXECUTE privilege on any PL/SQL subprogram owned by another user that is executed by an Oracle Streams apply process. These subprograms can be used in apply handlers or error handlers. If an apply user is specified, then the apply user must have these privileges. These privileges must be granted directly. They cannot be granted through a role.
      

    • 

      Grant the Oracle Streams administrator EXECUTE privilege on any PL/SQL function owned by another user that is specified in a custom rule-based transformation for a rule used by an Oracle Streams capture process, synchronous capture, propagation, apply process, or messaging client. For a capture process or synchronous capture, if a capture user is specified, then the capture user must have these privileges. For an apply process, if an apply user is specified, then the apply user must have these privileges. These privileges must be granted directly. They cannot be granted through a role.
      

    • 

      Grant the Oracle Streams administrator privileges to alter database objects where appropriate. For example, if the Oracle Streams administrator must create a supplemental log group for a table in another schema, then the Oracle Streams administrator must have the necessary privileges to alter the table. These privileges can be granted directly or through a role.
      

    • 

      If the Oracle Streams administrator does not own the queue used by an Oracle Streams capture process, synchronous capture, propagation, apply process, or messaging client, and is not specified as the queue user for the queue when the queue is created, then the Oracle Streams administrator must be configured as a secure queue user of the queue if you want the Oracle Streams administrator to be able to enqueue messages into or dequeue messages from the queue. The Oracle Streams administrator might also need ENQUEUE or DEQUEUE privileges on the queue, or both. See Oracle Streams Concepts and Administration for information about managing queues.
      

    • 

      Grant the Oracle Streams administrator EXECUTE privilege on any object types that the Oracle Streams administrator might need to access. These privileges can be granted directly or through a role.
      

    • 

      If the Oracle Streams administrator will use Data Pump to perform export and import operations on database objects in other schemas during an Oracle Streams instantiation, then grant the EXP_FULL_DATABASE and IMP_FULL_DATABASE roles to the Oracle Streams administrator.
      

    • 

      If Oracle Database Vault is installed, then the user who performs the following actions must be granted the BECOME USER system privilege:
      

      • 

        Creates or alters a capture process
        

      • 

        Creates or alters an apply process
        

      

      Granting the BECOME USER system privilege to the user who performs these actions is not required if Oracle Database Vault is not installed. You can revoke the BECOME USER system privilege from the user after the completing one of these actions, if necessary.
      

    

  7. 

    Repeat all of the previous steps at each database in the environment that will use Oracle Streams.
    










Configuring Network Connectivity and Database Links


If you plan to use Oracle Streams to share information between databases, then configure network connectivity and database links between these databases:


  • 

    For Oracle databases, configure your network and Oracle Net so that the databases can communicate with each other.
    

  • 

    For non-Oracle databases, configure an Oracle Database Gateway for communication between the Oracle database and the non-Oracle database.
    

  • 

    If you plan to propagate messages from a source queue at a database to a destination queue at another database, then create a private database link between the database containing the source queue and the database containing the destination queue. Each database link should use a CONNECT TO clause for the user propagating messages between databases.
    



A database link from the source database to the destination database is always required. The name of the database link must match the global name of the destination database.


A database link from the destination database to the source database is required in any of the following cases:


  • 

    The Oracle Streams replication environment will be bi-directional.
    

  • 

    A Data Pump network import will be performed during instantiation.
    

  • 

    The destination database is the capture database for downstream capture of source database changes.
    

  • 

    The RMAN DUPLICATE or CONVERT DATABASE command will be used for database instantiation.
    

    This database link is required because the POST_INSTANTIATION_SETUP procedure with a non-NULL setting for the instantiation_scn parameter runs the SET_GLOBAL_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package at the destination database. The SET_GLOBAL_INSTANTIATION_SCN procedure requires the database link. This database link must be created after the RMAN instantiation and before running the POST_INSTANTIATION_SETUP procedure.
    



In each of these cases, the name of the database link must match the global name of the source database.


If a third database is the capture database for downstream capture of source database changes, then the following database links are also required:


  • 

    A database link is required from the third database to the source database. The name of the database link must match the global name of the source database.
    

  • 

    A database link is required from the third database to the destination database. The name of the database link must match the global name of the destination database.
    



Each database link should be created in the Oracle Streams administrator's schema. For example, if the global name of the source database is dbs1.example.com, the global name of the destination database is dbs2.example.com, and the Oracle Streams administrator is strmadmin at each database, then the following statement creates the database link from the source database to the destination database:


CONNECT strmadmin@dbs1.example.com
Enter password: password

CREATE DATABASE LINK dbs2.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'dbs2.example.com';



If a database link is required from the destination database to the source database, then the following statement creates this database link:


CONNECT strmadmin@dbs2.example.com
Enter password: password

CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'dbs1.example.com';



If a third database is the capture database, then a database link is required from the third database to the source and destination databases. For example, if the third database is dbs3.example.com, then the following statements create the database links from the third database to the source and destination databases:


CONNECT strmadmin@dbs3.example.com
Enter password: password

CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'dbs1.example.com';

CREATE DATABASE LINK dbs2.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'dbs2.example.com';



If an RMAN database instantiation is performed, then the database link at the source database is copied to the destination database during instantiation. This copied database link should be dropped at the destination database. In this case, if the replication is bi-directional, and a database link from the destination database to the source database is required, then this database link should be created after the instantiation.









See Also:















Ensuring That Each Source Database Is In ARCHIVELOG Mode


In an Oracle Streams replication environment, each source database that generates changes that will be captured by a capture process must be in ARCHIVELOG mode. For downstream capture processes, the downstream database also must run in ARCHIVELOG mode if you plan to configure a real-time downstream capture process. The downstream database does not need to run in ARCHIVELOG mode if you plan to run only archived-log downstream capture processes on it.


If you are configuring Oracle Streams in an Oracle Real Application Clusters (Oracle RAC) environment, then the archive log files of all threads from all instances must be available to any instance running a capture process. This requirement pertains to both local and downstream capture processes.









Note:

Synchronous capture does not require ARCHIVELOG mode.













Setting Initialization Parameters Relevant to Oracle Streams


Some initialization parameters are important for the configuration, operation, reliability, and performance of an Oracle Streams environment. Set these parameters appropriately for your Oracle Streams environment.


Table 1-2 describes the initialization parameters that are relevant to Oracle Streams. This table specifies whether each parameter is modifiable. A modifiable initialization parameter can be modified using the ALTER SYSTEM statement while an instance is running. Some modifiable parameters can also be modified for a single session using the ALTER SESSION statement.




Table 1-2 Initialization Parameters Relevant to Oracle Streams


ParameterValuesDescription


COMPATIBLE



Default: 11.2.0



Range: 10.0.0 to default release


Modifiable?: No



This parameter specifies the release with which the Oracle server must maintain compatibility. Oracle servers with different compatibility levels can interoperate.


To use the new Oracle Streams features introduced in Oracle Database 11g Release 2, this parameter must be set to 11.2.0 or higher.




GLOBAL_NAMES



Default: false


Range: true or false


Modifiable?: Yes



Specifies whether a database link is required to have the same name as the database to which it connects.


To use Oracle Streams to share information between databases, set this parameter to true at each database that is participating in your Oracle Streams environment.




LOG_ARCHIVE_CONFIG



Default: 'SEND, RECEIVE, NODG_CONFIG'


Range: Values:


  • 

    SEND
    

  • 

    NOSEND
    

  • 

    RECEIVE
    

  • 

    NORECEIVE
    

  • 

    DG_CONFIG
    

  • 

    NODG_CONFIG
    



Modifiable?: Yes



Enables or disables the sending of redo logs to remote destinations and the receipt of remote redo logs, and specifies the unique database names (DB_UNIQUE_NAME) for each database in the Data Guard configuration


To use downstream capture and copy the redo data to the downstream database using redo transport services, specify the DB_UNIQUE_NAME of the source database and the downstream database using the DG_CONFIG attribute. This parameter must be set at both the source database and the downstream database.




LOG_ARCHIVE_DEST_n



Default: None


Range: None


Modifiable?: Yes



Defines up to 31 log archive destinations, where n is 1, 2, 3, ... 31.


To use downstream capture and copy the redo data to the downstream database using redo transport services, at least one log archive destination must be set at the site running the downstream capture process.




LOG_ARCHIVE_DEST_STATE_n



Default: enable


Range: One of the following:


  • 

    alternate
    

  • 

    defer
    

  • 

    enable
    



Modifiable?: Yes



Specifies the availability state of the corresponding destination. The parameter suffix (1 through 31) specifies one of the corresponding LOG_ARCHIVE_DEST_n destination parameters.


To use downstream capture and copy the redo data to the downstream database using redo transport services, ensure that the destination that corresponds to the LOG_ARCHIVE_DEST_n destination for the downstream database is set to enable.




LOG_BUFFER



Default: 5 MB to 32 MB depending on configuration


Range: Operating system-dependent


Modifiable?: No



Specifies the amount of memory (in bytes) that Oracle uses when buffering redo entries to a redo log file. Redo log entries contain a record of the changes that have been made to the database block buffers.


If an Oracle Streams capture process is running on the database, then set this parameter properly so that the capture process reads redo log records from the redo log buffer rather than from the hard disk.




MEMORY_MAX_TARGET



Default: 0


Range: 0 to the physical memory size available to Oracle Database


Modifiable?: No



Specifies the maximum systemwide usable memory for an Oracle database.


If the MEMORY_TARGET parameter is set to a nonzero value, then set this parameter to a large nonzero value if you must specify the maximum memory usage of the Oracle database.


See Also: "Configuring the Oracle Streams Pool"




MEMORY_TARGET



Default: 0


Range: 152 MB to MEMORY_MAX_TARGET setting


Modifiable?: Yes



Specifies the systemwide usable memory for an Oracle database.


Oracle recommends enabling the autotuning of the memory usage of an Oracle database by setting MEMORY_TARGET to a large nonzero value (if this parameter is supported on your platform).


See Also: "Configuring the Oracle Streams Pool"




OPEN_LINKS



Default: 4


Range: 0 to 255


Modifiable?: No



Specifies the maximum number of concurrent open connections to remote databases in one session. These connections include database links, plus external procedures and cartridges, each of which uses a separate process.


In an Oracle Streams environment, ensure that this parameter is set to the default value of 4 or higher.




PROCESSES



Default: 100


Range: 6 to operating system-dependent


Modifiable?: No



Specifies the maximum number of operating system user processes that can simultaneously connect to Oracle.


Ensure that the value of this parameter allows for all background processes, such as locks and slave processes. In Oracle Streams, capture processes, apply processes, XStream inbound servers, and XStream outbound servers use background processes. Propagations use background processes in combined capture and apply configurations. Propagations use Oracle Scheduler slave processes in configurations that do not use combined capture and apply.




SESSIONS



Default: Derived from:


(1.5 * PROCESSES) + 22


Range: 1 to 231


Modifiable?: No



Specifies the maximum number of sessions that can be created in the system.


To run one or more capture processes, apply processes, XStream outbound servers, or XStream inbound servers in a database, you might need to increase the size of this parameter. Each background process in a database requires a session.




SGA_MAX_SIZE



Default: Initial size of SGA at startup


Range: 0 to operating system-dependent


Modifiable?: No



Specifies the maximum size of System Global Area (SGA) for the lifetime of a database instance.


If the SGA_TARGET parameter is set to a nonzero value, then set this parameter to a large nonzero value if you must specify the SGA size.


See Also: "Configuring the Oracle Streams Pool"




SGA_TARGET



Default: 0 (SGA autotuning is disabled)


Range: 64 MB to operating system-dependent


Modifiable?: Yes



Specifies the total size of all System Global Area (SGA) components.


If MEMORY_MAX_TARGET and MEMORY_TARGET are set to 0 (zero), then Oracle recommends enabling the autotuning of SGA memory by setting SGA_TARGET to a large nonzero value.


If this parameter is set to a nonzero value, then the size of the Oracle Streams pool is managed by Automatic Shared Memory Management.


See Also: "Configuring the Oracle Streams Pool"




SHARED_POOL_SIZE



Default:


When SGA_TARGET is set to a nonzero value: If the parameter is not specified, then the default is 0 (internally determined by Oracle Database). If the parameter is specified, then the user-specified value indicates a minimum value for the shared memory pool.


When SGA_TARGET is not set (32-bit platforms): 64 MB, rounded up to the nearest granule size. When SGA_TARGET is not set (64-bit platforms): 128 MB, rounded up to the nearest granule size.


Range: The granule size to operating system-dependent


Modifiable?: Yes



Specifies (in bytes) the size of the shared pool. The shared pool contains shared cursors, stored procedures, control structures, and other structures.


If the MEMORY_MAX_TARGET, MEMORY_TARGET, SGA_TARGET, and STREAMS_POOL_SIZE initialization parameters are set to zero, then Oracle Streams transfers an amount equal to 10% of the shared pool from the buffer cache to the Oracle Streams pool.


See Also:"Configuring the Oracle Streams Pool"




STREAMS_POOL_SIZE



Default: 0


Range: 0 to operating system-dependent limit


Modifiable?: Yes



Specifies (in bytes) the size of the Oracle Streams pool. The Oracle Streams pool contains buffered queue messages. In addition, the Oracle Streams pool is used for internal communications during parallel capture and apply.


If the MEMORY_TARGET or MEMORY_MAX_TARGET initialization parameter is set to a nonzero value, then the Oracle Streams pool size is set by Automatic Memory Management, and STREAMS_POOL_SIZE specifies the minimum size.


If the SGA_TARGET initialization parameter is set to a nonzero value, then the Oracle Streams pool size is set by Automatic Shared Memory Management, and STREAMS_POOL_SIZE specifies the minimum size.


This parameter is modifiable. If this parameter is reduced to zero when an instance is running, then Oracle Streams processes and jobs might not run.


Ensure that there is enough memory to accommodate the Oracle Streams components. The following are the minimum requirements:


  • 

    15 MB for each capture process parallelism
    

  • 

    250 MB or more for each buffered queue. The buffered queue is where the buffered messages are stored.
    

  • 

    1 MB for each apply process parallelism
    

  • 

    1 MB for each XStream outbound server
    

  • 

    1 MB for each XStream inbound server parallelism
    



For example, if parallelism is set to 3 for a capture process, then at least 45 MB is required for the capture process. If a database has two buffered queues, then at least 20 MB is required for the buffered queues. If parallelism is set to 4 for an apply process, then at least 4 MB is required for the apply process.


You can use the V$STREAMS_POOL_ADVICE dynamic performance view to determine an appropriate setting for this parameter.


See Also: "Configuring the Oracle Streams Pool"




TIMED_STATISTICS



Default:


If STATISTICS_LEVEL is set to TYPICAL or ALL, then true


If STATISTICS_LEVEL is set to BASIC, then false


The default for STATISTICS_LEVEL is TYPICAL.


Range: true or false


Modifiable?: Yes



Specifies whether statistics related to time are collected.


To collect elapsed time statistics in the dynamic performance views related to Oracle Streams, set this parameter to true. The views that include elapsed time statistics include: V$STREAMS_CAPTURE, V$STREAMS_APPLY_COORDINATOR, V$STREAMS_APPLY_READER, V$STREAMS_APPLY_SERVER.




UNDO_RETENTION



Default: 900


Range: 0 to 231 - 1


Modifiable?: Yes



Specifies (in seconds) the amount of committed undo information to retain in the database.


For a database running one or more capture processes, ensure that this parameter is set to specify an adequate undo retention period.


If you run one or more capture processes and you are unsure about the proper setting, then try setting this parameter to at least 3600. If you encounter "snapshot too old" errors, then increase the setting for this parameter until these errors cease. Ensure that the undo tablespace has enough space to accommodate the UNDO_RETENTION setting.














See Also:















Configuring the Oracle Streams Pool


The Oracle Streams pool is a portion of memory in the System Global Area (SGA) that is used by Oracle Streams. The Oracle Streams pool stores buffered queue messages in memory, and it provides memory for capture processes, apply processes, XStream outbound servers, and XStream inbound servers. The Oracle Streams pool always stores LCRs captured by a capture process, and it stores LCRs and messages that are enqueued into a buffered queue by applications.


The Oracle Streams pool is initialized the first time any one of the following actions occurs in a database:


  • 

    Messages are enqueued into a buffered queue.
    

    Oracle Streams components manipulate messages in a buffered queue. These components include capture processes, propagations, apply processes, XStream outbound servers, and XStream inbound servers. Also, Data Pump export and import operations initialize the Oracle Streams pool because these operations use buffered queues.
    

  • 

    Messages are dequeued from a persistent queue in a configuration that does not use Oracle Real Application Clusters (Oracle RAC).
    

    The Oracle Streams pool is used to optimize dequeue operations from persistent queues. The Oracle Streams pool is not used to optimize dequeue operations from persistent queues in an Oracle RAC configuration.
    

  • 

    A capture process is started.
    

  • 

    A propagation is created.
    

  • 

    An apply process is started.
    

  • 

    An XStream outbound server is started.
    

  • 

    An XStream inbound server is started.
    



The size of the Oracle Streams pool is determined in one of the following ways:










Note:

If the Oracle Streams pool cannot be initialized, then an ORA-00832 error is returned. If this happens, then first ensure that there is enough space in the SGA for the Oracle Streams pool. If necessary, reset the SGA_MAX_SIZE initialization parameter to increase the SGA size. Next, set one or more of the following initialization parameters: MEMORY_TARGET, MEMORY_MAX_TARGET, SGA_TARGET, and STREAMS_POOL_SIZE.










Using Automatic Memory Management to Set the Oracle Streams Pool Size


The Automatic Memory Management feature automatically manages the size of the Oracle Streams pool when the MEMORY_TARGET or MEMORY_MAX_TARGET initialization parameter is set to a nonzero value. When you use Automatic Memory Management, you can still set the following initialization parameters:


  • 

    If the SGA_TARGET initialization parameter also is set to a nonzero value, then Automatic Memory Management uses this value as a minimum for the system global area (SGA).
    

  • 

    If the STREAMS_POOL_SIZE initialization parameter also is set to a nonzero value, then Automatic Memory Management uses this value as a minimum for the Oracle Streams pool.
    



The current memory allocated to Oracle Streams pool by Automatic Memory Management can be viewed by querying the V$MEMORY_DYNAMIC_COMPONENTS view.









Note:

Currently, the MEMORY_TARGET and MEMORY_MAX_TARGET initialization parameters are not supported on some platforms.













Using Automatic Shared Memory Management to Set the Oracle Streams Pool Size


The Automatic Shared Memory Management feature automatically manages the size of the Oracle Streams pool when the following conditions are met:


  • 

    The MEMORY_TARGET and MEMORY_MAX_TARGET initialization parameters are both set to 0 (zero).
    

  • 

    SGA_TARGET initialization parameter is set to a nonzero value.
    



If you are using Automatic Shared Memory Management and the STREAMS_POOL_SIZE initialization parameter also is set to a nonzero value, then Automatic Shared Memory Management uses this value as a minimum for the Oracle Streams pool. You can set a minimum size if your environment needs a minimum amount of memory in the Oracle Streams pool to function properly. The current memory allocated to Oracle Streams pool by Automatic Shared Memory Management can be viewed by querying the V$SGA_DYNAMIC_COMPONENTS view.









Setting the Oracle Streams Pool Size Manually


The Oracle Streams pool size is the value specified by the STREAMS_POOL_SIZE parameter, in bytes, if the following conditions are met.


  • 

    The MEMORY_TARGET, MEMORY_MAX_TARGET, and SGA_TARGET initialization parameters are all set to 0 (zero).
    

  • 

    The STREAMS_POOL_SIZE initialization parameter is set to a nonzero value.
    



If you plan to set the Oracle Streams pool size manually, then you can use the V$STREAMS_POOL_ADVICE dynamic performance view to determine an appropriate setting for the STREAMS_POOL_SIZE initialization parameter.









Using the Default Setting for the Oracle Streams Pool Size


The Oracle Streams pool size is set by default if all of the following parameters are set to 0 (zero): MEMORY_TARGET, MEMORY_MAX_TARGET, SGA_TARGET, and STREAMS_POOL_SIZE. When the Oracle Streams pool size is set by default, the first use of Oracle Streams in a database transfers an amount of memory equal to 10% of the shared pool from the buffer cache to the Oracle Streams pool. The buffer cache is set by the DB_CACHE_SIZE initialization parameter, and the shared pool size is set by the SHARED_POOL_SIZE initialization parameter.


For example, consider the following configuration in a database before Oracle Streams is used for the first time:


  • 

    DB_CACHE_SIZE is set to 100 MB.
    

  • 

    SHARED_POOL_SIZE is set to 80 MB.
    

  • 

    MEMORY_TARGET, MEMORY_MAX_TARGET, SGA_TARGET, and STREAMS_POOL_SIZE are all set to zero.
    



Given this configuration, the amount of memory allocated after Oracle Streams is used for the first time is the following:


  • 

    The buffer cache has 92 MB.
    

  • 

    The shared pool has 80 MB.
    

  • 

    The Oracle Streams pool has 8 MB.
    










See Also:

"Setting Initialization Parameters Relevant to Oracle Streams" for more information about the STREAMS_POOL_SIZE initialization parameter














Specifying Supplemental Logging


When you use a capture process to capture changes, supplemental logging must be specified for certain columns at a source database for changes to the columns to be applied successfully at a destination database. Supplemental logging places additional information in the redo log for these columns. A capture process captures this additional information and places it in logical change records (LCRs), and an apply process might need this additional information to apply changes properly.


This section contains these topics:










Note:

Supplemental logging is not required when synchronous capture is used to capture changes to database objects.













See Also:

Oracle Streams Concepts and Administration for queries that show supplemental logging specifications









Required Supplemental Logging in an Oracle Streams Replication Environment


There are two types of supplemental logging: database supplemental logging and table supplemental logging. Database supplemental logging specifies supplemental logging for an entire database, while table supplemental logging enables you to specify log groups for supplemental logging of a particular table. If you use table supplemental logging, then you can choose between two types of log groups: unconditional log groups and conditional log groups.


Unconditional log groups log the before images of specified columns when the table is changed, regardless of whether the change affected any of the specified columns. Unconditional log groups are sometimes referred to as "always log groups." Conditional log groups log the before images of all specified columns only if at least one of the columns in the log group is changed.


Supplementing logging at the database level, unconditional log groups at the table level, and conditional log groups at the table level determine which old values are logged for a change.


If you plan to use one or more apply processes to apply LCRs captured by a capture process, then you must enable supplemental logging at the source database for the following types of columns in tables at the destination database:


  • 

    Any columns at the source database that are used in a primary key in tables for which changes are applied at a destination database must be unconditionally logged in a log group or by database supplemental logging of primary key columns.
    

  • 

    If the parallelism of any apply process that will apply the changes is greater than 1, then any unique constraint column at a destination database that comes from multiple columns at the source database must be conditionally logged. Supplemental logging does not need to be specified if a unique constraint column comes from a single column at the source database.
    

  • 

    If the parallelism of any apply process that will apply the changes is greater than 1, then any foreign key column at a destination database that comes from multiple columns at the source database must be conditionally logged. Supplemental logging does not need to be specified if the foreign key column comes from a single column at the source database.
    

  • 

    If the parallelism of any apply process that will apply the changes is greater than 1, then any bitmap index column at a destination database that comes from multiple columns at the source database must be conditionally logged. Supplemental logging does not need to be specified if the bitmap index column comes from a single column at the source database.
    

  • 

    Any columns at the source database that are used as substitute key columns for an apply process at a destination database must be unconditionally logged. You specify substitute key columns for a table using the SET_KEY_COLUMNS procedure in the DBMS_APPLY_ADM package.
    

  • 

    The columns specified in a column list for conflict resolution during apply must be conditionally logged if multiple columns at the source database are used in the column list at the destination database.
    

  • 

    Any columns at the source database that are used by a statement DML handler, change handler, procedure DML handler, or error handler at a destination database must be unconditionally logged.
    

  • 

    Any columns at the source database that are used by a rule or a rule-based transformation must be unconditionally logged.
    

  • 

    Any columns at the source database that are specified in a value dependency virtual dependency definition at a destination database must be unconditionally logged.
    

  • 

    If you specify row subsetting for a table at a destination database, then any columns at the source database that are in the destination table or columns at the source database that are in the subset condition must be unconditionally logged. You specify a row subsetting condition for an apply process using the dml_condition parameter in the ADD_SUBSET_RULES procedure in the DBMS_STREAMS_ADM package.
    



If you do not use supplemental logging for these types of columns at a source database, then changes involving these columns might not apply properly at a destination database.









Note:

Columns of the following data types cannot be part of a supplemental log group: LOB, LONG, LONG RAW, user-defined types (including object types, REFs, varrays, nested tables), and Oracle-supplied types (including Any types, XML types, spatial types, and media types).













Specifying Table Supplemental Logging Using Unconditional Log Groups


The following sections describe creating an unconditional supplemental log group:






Specifying an Unconditional Supplemental Log Group for Primary Key Column(s)


To specify an unconditional supplemental log group that only includes the primary key column(s) for a table, use an ALTER TABLE statement with the PRIMARY KEY option in the ADD SUPPLEMENTAL LOG DATA clause.


For example, the following statement adds the primary key column of the hr.regions table to an unconditional log group:


ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;



The log group has a system-generated name.








Specifying an Unconditional Supplemental Log Group for All Table Columns


To specify an unconditional supplemental log group that includes all of the columns in a table, use an ALTER TABLE statement with the ALL option in the ADD SUPPLEMENTAL LOG DATA clause.


For example, the following statement adds all of the columns in the hr.regions table to an unconditional log group:


ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;



The log group has a system-generated name.








Specifying an Unconditional Supplemental Log Group that Includes Selected Columns


To specify an unconditional supplemental log group that contains columns that you select, use an ALTER TABLE statement with the ALWAYS specification for the ADD SUPPLEMENTAL LOG GROUP clause.These log groups can include key columns, if necessary.


For example, the following statement adds the department_id column and the manager_id column of the hr.departments table to an unconditional log group named log_group_dep_pk:


ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG GROUP log_group_dep_pk
  (department_id, manager_id) ALWAYS;



The ALWAYS specification makes this log group an unconditional log group.










Specifying Table Supplemental Logging Using Conditional Log Groups


The following sections describe creating a conditional log group:






Specifying a Conditional Log Group Using the ADD SUPPLEMENTAL LOG DATA Clause


You can use the following options in the ADD SUPPLEMENTAL LOG DATA clause of an ALTER TABLE statement:


  • 

    The FOREIGN KEY option creates a conditional log group that includes the foreign key column(s) in the table.
    

  • 

    The UNIQUE option creates a conditional log group that includes the unique key column(s) and bitmap index column(s) in the table.
    



If you specify multiple options in a single ALTER TABLE statement, then a separate conditional log group is created for each option.


For example, the following statement creates two conditional log groups:


ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA 
  (UNIQUE, FOREIGN KEY) COLUMNS;



One conditional log group includes the unique key columns and bitmap index columns for the table, and the other conditional log group includes the foreign key columns for the table. Both log groups have a system-generated name.









Note:

Specifying the UNIQUE option does not enable supplemental logging of bitmap join index columns.












Specifying a Conditional Log Group Using the ADD SUPPLEMENTAL LOG GROUP Clause


To specify a conditional supplemental log group that includes any columns you choose to add, you can use the ADD SUPPLEMENTAL LOG GROUP clause in the ALTER TABLE statement. To make the log group conditional, do not include the ALWAYS specification.


For example, suppose the min_salary and max_salary columns in the hr.jobs table are included in a column list for conflict resolution at a destination database. The following statement adds the min_salary and max_salary columns to a conditional log group named log_group_jobs_cr:


ALTER TABLE hr.jobs ADD SUPPLEMENTAL LOG GROUP log_group_jobs_cr 
  (min_salary, max_salary);









Dropping a Supplemental Log Group


To drop a conditional or unconditional supplemental log group, use the DROP SUPPLEMENTAL LOG GROUP clause in the ALTER TABLE statement. For example, to drop a supplemental log group named log_group_jobs_cr, run the following statement:


ALTER TABLE hr.jobs DROP SUPPLEMENTAL LOG GROUP log_group_jobs_cr;







Specifying Database Supplemental Logging of Key Columns


You also have the option of specifying supplemental logging for all primary key, unique key, bitmap index, and foreign key columns in a source database. You might choose this option if you configure a capture process to capture changes to an entire database. To specify supplemental logging for all primary key, unique key, bitmap index, and foreign key columns in a source database, issue the following SQL statement:


ALTER DATABASE ADD SUPPLEMENTAL LOG DATA 
   (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;



If your primary key, unique key, bitmap index, and foreign key columns are the same at all source and destination databases, then running this command at the source database provides the supplemental logging needed for primary key, unique key, bitmap index, and foreign key columns at all destination databases. When you specify the PRIMARY KEY option, all columns of a row's primary key are placed in the redo log file any time the table is modified (unconditional logging). When you specify the UNIQUE option, any columns in a row's unique key and bitmap index are placed in the redo log file if any column belonging to the unique key or bitmap index is modified (conditional logging). When you specify the FOREIGN KEY option, all columns of a row's foreign key are placed in the redo log file if any column belonging to the foreign key is modified (conditional logging).


You can omit one or more of these options. For example, if you do not want to supplementally log all of the foreign key columns in the database, then you can omit the FOREIGN KEY option, as in the following example:


ALTER DATABASE ADD SUPPLEMENTAL LOG DATA 
   (PRIMARY KEY, UNIQUE) COLUMNS;



In additional to PRIMARY KEY, UNIQUE, and FOREIGN KEY, you can also use the ALL option. The ALL option specifies that, when a row is changed, all the columns of that row (except for LOB, LONG, LONG RAW, user-defined type, and Oracle-supplied type columns) are placed in the redo log file (unconditional logging).


Supplemental logging statements are cumulative. If you issue two consecutive ALTER DATABASE ADD SUPPLEMENTAL LOG DATA commands, each with a different identification key, then both keys are supplementally logged.









Note:

Specifying the UNIQUE option does not enable supplemental logging of bitmap join index columns.













See Also:

Oracle Database SQL Language Reference for information about data types












Dropping Database Supplemental Logging of Key Columns


To drop supplemental logging for all primary key, unique key, bitmap index, and foreign key columns in a source database, issue the ALTER DATABASE DROP SUPPLEMENTAL LOG DATA statement. To drop database supplemental logging for all primary key, unique key, bitmap index, and foreign key columns, issue the following SQL statement:


ALTER DATABASE DROP SUPPLEMENTAL LOG DATA 
  (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;










Note:

Dropping database supplemental logging of key columns does not affect any existing table-level supplemental log groups.












Procedures That Automatically Specify Supplemental Logging


The following procedures in the DBMS_CAPTURE_ADM package automatically specify supplemental logging:



The BUILD procedure automatically specifies database supplemental logging by running the ALTER DATABASE ADD SUPPLEMENTAL LOG DATA statement. In most cases, the BUILD procedure is run automatically when a capture process is created.


The PREPARE_GLOBAL_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, and PREPARE_TABLE_INSTANTIATION procedures automatically specify supplemental logging of the primary key, unique key, bitmap index, and foreign key columns in the tables prepared for instantiation.


Certain procedures in the DBMS_STREAMS_ADM package automatically run a procedure listed previously. See "DBMS_STREAMS_ADM Package Procedures Automatically Prepare Objects" for information.









See Also:

Oracle Database PLd$/SQL Packages and Types Reference for more information about these procedures














Configuring Log File Transfer to a Downstream Capture Database


If you decided to use a local capture process at the source database, then log file transfer is not required. However, if you decided to use downstream capture that uses redo transport services to transfer archived redo log files to the downstream database automatically, then configure log file transfer from the source database to the capture database before configuring the replication environment. See "Decide Whether to Configure Local or Downstream Capture for the Source Database" for information about the decision.


You must complete the steps in this section if you plan to configure downstream capture using either of the following methods:


  • 

    Running a configuration procedure in the DBMS_STREAMS_ADM supplied PL/SQL package to configure replication between two databases
    

  • 

    Configuring each Oracle Streams component separately
    



See "Decide How to Configure the Replication Environment" for information about these methods.









Tip:

You can use Oracle Enterprise Manager to configure log file transfer and a downstream capture process. See Oracle Database 2 Day + Data Replication and Integration Guide for instructions.






Complete the following steps to prepare the source database to transfer its redo log files to the capture database, and to prepare the capture database to accept these redo log files:


  1. 

    Configure Oracle Net so that the source database can communicate with the downstream database.
    


  2. 

    Configure authentication at both databases to support the transfer of redo data.
    

    Redo transport sessions are authenticated using either the Secure Sockets Layer (SSL) protocol or a remote login password file. If the source database has a remote login password file, then copy it to the appropriate directory on the downstream capture database system. The password file must be the same at the source database and the downstream capture database.
    

    


    

    

    See Also:
    
Oracle Data Guard Concepts and Administration for detailed information about authentication requirements for redo transport
    

    

    

  3. 

    At the source database, set the following initialization parameters to configure redo transport services to transmit redo data from the source database to the downstream database:
    

    • 

      LOG_ARCHIVE_DEST_n - Configure at least one LOG_ARCHIVE_DEST_n initialization parameter to transmit redo data to the downstream database. Set the following attributes of this parameter in the following way:
      

      • 

        SERVICE - Specify the network service name of the downstream database.
        

      • 

        ASYNC or SYNC - Specify a redo transport mode.
        

        The advantage of specifying ASYNC is that it results in little or no effect on the performance of the source database. If the source database is running Oracle Database 10g Release 1 or later, then ASYNC is recommended to avoid affecting source database performance if the downstream database or network is performing poorly.
        

        The advantage of specifying SYNC is that redo data is sent to the downstream database faster then when ASYNC is specified. Also, specifying SYNC AFFIRM results in behavior that is similar to MAXIMUM AVAILABILITY standby protection mode. Note that specifying an ALTER DATABASE STANDBY DATABASE TO MAXIMIZE AVAILABILITY SQL statement has no effect on an Oracle Streams capture process.
        

      • 

        NOREGISTER - Specify this attribute so that the location of the archived redo log files is not recorded in the downstream database control file.
        

      • 

        VALID_FOR - Specify either (ONLINE_LOGFILE,PRIMARY_ROLE) or (ONLINE_LOGFILE,ALL_ROLES).
        

      • 

        TEMPLATE - If you are configuring an archived-log downstream capture process, then specify a directory and format template for archived redo logs at the downstream database. The TEMPLATE attribute overrides the LOG_ARCHIVE_FORMAT initialization parameter settings at the downstream database. The TEMPLATE attribute is valid only with remote destinations. Ensure that the format uses all of the following variables at each source database: %t, %s, and %r.
        

        Do not specify the TEMPLATE attribute if you are configuring a real-time downstream capture process.
        

      • 

        DB_UNIQUE_NAME - The unique name of the downstream database. Use the name specified for the DB_UNIQUE_NAME initialization parameter at the downstream database.
        

      

      The following example is a LOG_ARCHIVE_DEST_n setting that specifies the downstream database dbs2 for a real-time downstream capture process:
      

      LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=dbs2'

      

      The following example is a LOG_ARCHIVE_DEST_n setting that specifies the downstream database dbs2 for an archived-log downstream capture process:
      

      LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   TEMPLATE=/usr/oracle/log_for_dbs1/dbs1_arch_%t_%s_%r.log
   DB_UNIQUE_NAME=dbs2'

      

      See "Decide Whether to Configure Local or Downstream Capture for the Source Database" for information about the differences between real-time and archived-log downstream capture.
      

      


      

      

      Tip:
      
If you are configuring an archived-log downstream capture process, then specify a value for the TEMPLATE attribute that keeps log files from a remote source database separate from local database log files. In addition, if the downstream database contains log files from multiple source databases, then the log files from each source database should be kept separate from each other.
      

      

      

    • 

      LOG_ARCHIVE_DEST_STATE_n - Set this initialization parameter that corresponds with the LOG_ARCHIVE_DEST_n parameter for the downstream database to ENABLE.
      

      For example, if the LOG_ARCHIVE_DEST_2 initialization parameter is set for the downstream database, then set the LOG_ARCHIVE_DEST_STATE_2 parameter in the following way:
      

      LOG_ARCHIVE_DEST_STATE_2=ENABLE 

    • 

      LOG_ARCHIVE_CONFIG - Set the DG_CONFIG attribute in this initialization parameter to include the DB_UNIQUE_NAME of the source database and the downstream database.
      

      For example, if the DB_UNIQUE_NAME of the source database is dbs1, and the DB_UNIQUE_NAME of the downstream database is dbs2, then specify the following parameter:
      

      LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'

      

      By default, the LOG_ARCHIVE_CONFIG parameter enables a database to both send and receive redo.
      

    

    


    

    

    See Also:
    
Oracle Database Reference and Oracle Data Guard Concepts and Administration for more information about these initialization parameters
    

    

    

  4. 

    At the downstream database, set the DG_CONFIG attribute in the LOG_ARCHIVE_CONFIG initialization parameter to include the DB_UNIQUE_NAME of the source database and the downstream database.
    

    For example, if the DB_UNIQUE_NAME of the source database is dbs1, and the DB_UNIQUE_NAME of the downstream database is dbs2, then specify the following parameter:
    

    LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'

    

    By default, the LOG_ARCHIVE_CONFIG parameter enables a database to both send and receive redo.
    

  5. 

    If you reset any initialization parameters while the instance was running at a database in Step 3 or Step 4, then you might want to reset them in the initialization parameter file as well, so that the new values are retained when the database is restarted.
    

    If you did not reset the initialization parameters while the instance was running, but instead reset them in the initialization parameter file in Step 3 or Step 4, then restart the database. The source database must be open when it sends redo log files to the downstream database, because the global name of the source database is sent to the downstream database only if the source database is open.
    



When these steps are complete, you are ready to perform one of the following tasks:









Adding Standby Redo Logs for Real-Time Downstream Capture


The example in this section adds standby redo logs at a downstream database. Standby redo logs are required to configure a real-time downstream capture process. In the example, the source database is dbs1.example.com and the downstream database is dbs2.example.com


See "Decide Whether to Configure Local or Downstream Capture for the Source Database" for information about the differences between real-time and archived-log downstream capture. The steps in this section are required only if you are configuring real-time downstream capture. If you are configuring archived-log downstream capture, then do not complete the steps in this section.









Tip:

You can use Oracle Enterprise Manager to configure real-time downstream capture. See Oracle Database 2 Day + Data Replication and Integration Guide for instructions.






Complete the following steps to add a standby redo log at the downstream database:


  1. 

    Complete the steps in "Configuring Log File Transfer to a Downstream Capture Database".
    

  2. 

    At the downstream database, set the following initialization parameters to configure archiving of the redo data generated locally:
    

    • 

      Set at least one archive log destination in the LOG_ARCHIVE_DEST_n initialization parameter either to a directory or to the fast recovery area on the computer system running the downstream database. Set the following attributes of this parameter in the following way:
      

      • 

        LOCATION - Specify either a valid path name for a disk directory or, to use a fast recovery area, specify USE_DB_RECOVERY_FILE_DEST. This location is the local destination for archived redo log files written from the standby redo logs. Log files from a remote source database should be kept separate from local database log files. See Oracle Database Backup and Recovery User's Guide for information about configuring a fast recovery area.
        

      • 

        VALID_FOR - Specify either (ONLINE_LOGFILE,PRIMARY_ROLE) or (ONLINE_LOGFILE,ALL_ROLES).
        

      

      The following example is a LOG_ARCHIVE_DEST_n setting for the locally generated redo data at the real-time downstream capture database:
      

      LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local_rl_dbs2
   VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'

      

      A real-time downstream capture configuration should keep archived standby redo log files separate from archived online redo log files generated by the downstream database. Specify ONLINE_LOGFILE instead of ALL_LOGFILES for the redo log type in the VALID_FOR attribute to accomplish this.
      

      You can specify other attributes in the LOG_ARCHIVE_DEST_n initialization parameter if necessary.
      

    • 

      Set the LOG_ARCHIVE_DEST_STATE_n initialization parameter that corresponds with the LOG_ARCHIVE_DEST_n parameter previously set in this step to ENABLE.
      

      For example, if the LOG_ARCHIVE_DEST_1 initialization parameter is set, then set the LOG_ARCHIVE_DEST_STATE_1 parameter in the following way:
      

      LOG_ARCHIVE_DEST_STATE_1=ENABLE 

    

  3. 

    At the downstream database, set the following initialization parameters to configure the downstream database to receive redo data from the source database and write the redo data to the standby redo log at the downstream database:
    

    • 

      Set at least one archive log destination in the LOG_ARCHIVE_DEST_n initialization parameter either to a directory or to the fast recovery area on the computer system running the downstream database. Set the following attributes of this parameter in the following way:
      

      • 

        LOCATION - Specify either a valid path name for a disk directory or, to use a fast recovery area, specify USE_DB_RECOVERY_FILE_DEST. This location is the local destination for archived redo log files written from the standby redo logs. Log files from a remote source database should be kept separate from local database log files. See Oracle Database Backup and Recovery User's Guide for information about configuring a fast recovery area.
        

      • 

        VALID_FOR - Specify either (STANDBY_LOGFILE,PRIMARY_ROLE) or (STANDBY_LOGFILE,ALL_ROLES).
        

      

      The following example is a LOG_ARCHIVE_DEST_n setting for the redo data received from the source database at the real-time downstream capture database:
      

      LOG_ARCHIVE_DEST_2='LOCATION=/home/arc_dest/srl_dbs1
   VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)'

      

      You can specify other attributes in the LOG_ARCHIVE_DEST_n initialization parameter if necessary.
      

    • 

      Set the LOG_ARCHIVE_DEST_STATE_n initialization parameter that corresponds with the LOG_ARCHIVE_DEST_n parameter previously set in this step to ENABLE.
      

      For example, if the LOG_ARCHIVE_DEST_2 initialization parameter is set for the downstream database, then set the LOG_ARCHIVE_DEST_STATE_2 parameter in the following way:
      

      LOG_ARCHIVE_DEST_STATE_2=ENABLE 

    

    


    

    

    See Also:
    
Oracle Database Reference and Oracle Data Guard Concepts and Administration for more information about these initialization parameters
    

    

    

  4. 

    If you reset any initialization parameters while an instance was running at a database in Step 2 or 3, then you might want to reset them in the relevant initialization parameter file as well, so that the new values are retained when the database is restarted.
    

    If you did not reset the initialization parameters while an instance was running, but instead reset them in the initialization parameter file in Step 2 or 3, then restart the database. The source database must be open when it sends redo data to the downstream database, because the global name of the source database is sent to the downstream database only if the source database is open.
    

  5. 

    Create the standby redo log files.
    

    


    

    

    Note:
    
The following steps outline the general procedure for adding standby redo log files to the downstream database. The specific steps and SQL statements used to add standby redo log files depend on your environment. For example, in an Oracle Real Application Clusters (Oracle RAC) environment, the steps are different. See Oracle Data Guard Concepts and Administration for detailed instructions about adding standby redo log files to a database.
    

    

    

    1. 

      In SQL*Plus, connect to the source database dbs1.example.com as an administrative user.
      

      See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
      

    2. 

      Determine the log file size used on the source database. The standby log file size must exactly match (or be larger than) the source database log file size. For example, if the source database log file size is 500 MB, then the standby log file size must be 500 MB or larger. You can determine the size of the redo log files at the source database (in bytes) by querying the V$LOG view at the source database.
      

      For example, query the V$LOG view:
      

      SELECT BYTES FROM V$LOG;

    3. 

      Determine the number of standby log file groups required on the downstream database. The number of standby log file groups must be at least one more than the number of online log file groups on the source database. For example, if the source database has two online log file groups, then the downstream database must have at least three standby log file groups. You can determine the number of source database online log file groups by querying the V$LOG view at the source database.
      

      For example, query the V$LOG view:
      

      SELECT COUNT(GROUP#) FROM V$LOG;

    4. 

      In SQL*Plus, connect to the downstream database dbs2.example.com as an administrative user.
      

    5. 

      Use the SQL statement ALTER DATABASE ADD STANDBY LOGFILE to add the standby log file groups to the downstream database.
      

      For example, assume that the source database has two online redo log file groups and is using a log file size of 500 MB. In this case, use the following statements to create the appropriate standby log file groups:
      

      ALTER DATABASE ADD STANDBY LOGFILE GROUP 3
   ('/oracle/dbs/slog3a.rdo', '/oracle/dbs/slog3b.rdo') SIZE 500M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
   ('/oracle/dbs/slog4.rdo', '/oracle/dbs/slog4b.rdo') SIZE 500M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
   ('/oracle/dbs/slog5.rdo', '/oracle/dbs/slog5b.rdo') SIZE 500M;

    6. 

      Ensure that the standby log file groups were added successfully by running the following query:
      

      SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS
   FROM V$STANDBY_LOG;

      

      You output should be similar to the following:
      

          GROUP#    THREAD#  SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
         3          0          0 YES UNASSIGNED
         4          0          0 YES UNASSIGNED
         5          0          0 YES UNASSIGNED

    7. 

      Ensure that log files from the source database are appearing in the location specified in the LOCATION attribute in Step 3. You might need to switch the log file at the source database to see files in the directory.
      

    



When these steps are complete, you are ready to configure a real-time downstream capture process. See the instructions in the following sections:











PKddPK+AOEBPS/config_simple.htm

Simple Oracle Streams Replication Configuration



2 Simple Oracle Streams Replication Configuration


This chapter describes simple methods for configuring Oracle Streams replication.


This chapter contains these topics:






Configuring Replication Using the Setup Streams Replication Wizard


The Oracle Streams tool in Oracle Enterprise Manager includes a Setup Streams Replication Wizard that configures an Oracle Streams replication environment. Using this wizard, you can configure an Oracle Streams replication environment with any of the following characteristics:


  • 

    Replicate changes to the entire source database, selected schemas in the source database, selected tablespaces in the source database, selected tables in the source database, or subsets of tables in the source database
    

  • 

    Maintain data manipulation language (DML) changes, data definition language (DDL) changes, or both.
    

  • 

    One-way or bi-directional replication
    

  • 

    Local capture or downstream capture
    



The wizard walks you through the process of configuring your replication environment, and you can run the wizard multiple times to configure a replication environment with more than two databases. There are some limits to the types of replication environments that can be configured with the wizard. For example, the wizard currently cannot configure synchronous capture.


You can choose to configure the Oracle Streams replication environment immediately, or you can use the wizard to generate a script. When you generate a script, you can review the script, and edit the script if necessary, before running the script to configure the replication environment.


To open the wizard, complete the following steps in Enterprise Manager:


  1. 

    Review the decisions described in "Decisions to Make Before Configuring Oracle Streams Replication". Make these decisions about the Oracle Streams replication environment before proceeding.
    

  2. 

    Complete the tasks to prepare for the Oracle Streams replication environment. See "Tasks to Complete Before Configuring Oracle Streams Replication".
    

    The wizard completes some tasks automatically, but you must complete the following tasks manually:
    


  3. 

    In Oracle Enterprise Manager, log in to the database as the Oracle Streams administrator. Log in to a database that will be a source database in the replication environment.
    

  4. 

    Go to the Database Home page.
    

  5. 

    Click Data Movement to open the Data Movement subpage.
    

  6. 

    Click Setup in the Streams section to open the Streams page.
    
Description of strep_setup.gif follows
    
Description of the illustration strep_setup.gif
    

  7. 

    In the Setup Streams Replication section, select the option for the type of replication environment you want to configure.
    

  8. 

    In the Host Credentials section, enter the username and password for the host computer that runs the source database.
    

  9. 

    Click Continue to open the Setup Streams Replication wizard.
    

    Here is the first wizard page when you select Replicate Tables on the Streams page.
    
Description of strep_wizard.gif follows
    
Description of the illustration strep_wizard.gif
    










Note:

By default, the Setup Streams Replication Wizard configures one-way replication. To configure bi-directional replication, open the Advanced Options section on the Replication Options page and select Setup Bi-directional replication. If bi-directional replication is configured, then conflict resolution might be required.













Configuring Replication Using the DBMS_STREAMS_ADM Package


You can configure an Oracle Streams replication environment using procedures in the DBMS_STREAMS_ADM package.


The following sections contain information about these procedures, instructions for preparing to run one of these procedures, and examples that illustrate common scenarios:










See Also:












The Oracle Streams Replication Configuration Procedures


The easiest way to configure an Oracle Streams replication environment is by running one of the following configuration procedures in the DBMS_STREAMS_ADM package:


  • 

    MAINTAIN_GLOBAL configures an Oracle Streams environment that replicates changes at the database level between two databases.
    

  • 

    MAINTAIN_SCHEMAS configures an Oracle Streams environment that replicates changes to specified schemas between two databases.
    

  • 

    MAINTAIN_SIMPLE_TTS clones a simple tablespace from a source database at a destination database and uses Oracle Streams to maintain this tablespace at both databases.
    

  • 

    MAINTAIN_TABLES configures an Oracle Streams environment that replicates changes to specified tables between two databases.
    

  • 

    MAINTAIN_TTS clones a set of tablespaces from a source database at a destination database and uses Oracle Streams to maintain these tablespaces at both databases.
    

  • 

    PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP configure an Oracle Streams environment that replicates changes either at the database level or to specified tablespaces between two databases. These procedures must be used together, and instantiation actions must be performed manually, to complete the Oracle Streams replication configuration. Typically, these procedures are used to perform database maintenance operations with little or no down time. See Oracle Streams Concepts and Administration for more information.
    



These procedures configure two databases at a time, and they require you to specify one database as the source database and the other database as the destination database. They can configure a replication environment with more than two databases by running them multiple times.


Table 2-1 describes the required parameters for these procedures.




Table 2-1 Required Parameters for the Oracle Streams Replication Configuration Procedures


ParameterProcedureDescription


source_directory_object



All procedures



The directory object for the directory on the computer system running the source database into which the generated Data Pump export dump file is placed.


Note: The specified directory object cannot point to an Automatic Storage Management (ASM) disk group.




destination_directory_object



All procedures



The directory object for the directory on the computer system running the destination database into which the generated Data Pump export dump file is transferred. The dump file is used to instantiate the replicated database objects at the destination database.


Note: The specified directory object cannot point to an Automatic Storage Management (ASM) disk group.




source_database



All procedures



The global name of the source database. The specified database must contain the database objects to be replicated.




destination_database



All procedures



The global name of the destination database. The database objects to be replicated are optional at the destination database. If they do not exist at the destination database, then they are instantiated by Data Pump export/import.


If the local database is not the destination database, then a database link from the local database to the destination database, with the same name as the global name of the destination database, must exist and must be accessible to the user who runs the procedure.




schema_names



MAINTAIN_SCHEMAS only



The schemas to be configured for replication.




tablespace_name



MAINTAIN_SIMPLE_TTS only



The tablespace to be configured for replication.




table_names



MAINTAIN_TABLES only



The tables to be configured for replication.




tablespace_names



MAINTAIN_TTS only



The tablespaces to be configured for replication.







In addition, each of these procedures has several optional parameters. The bi_directional parameter is an important optional parameter. If you want changes to the replicated database objects to be captured at each database and sent to the other database, then the bi_directional parameter must be set to TRUE. The default setting for this parameter is FALSE. When the bi_directional parameter is set to FALSE, the procedures configure a one-way replication environment, where the changes made at the destination database are not captured.


These procedures perform several tasks to configure an Oracle Streams replication environment. These tasks include:


  • 

    Configure supplemental logging for the replicated database objects at the source database.
    

  • 

    If the bi_directional parameter is set to TRUE, then configure supplemental logging for the replicated database objects at the destination database.
    

  • 

    Instantiate the database objects at the destination database. If the database objects do not exist at the destination database, then the procedures use Data Pump export/import to instantiate them at the destination database.
    

  • 

    Configure a capture process to capture changes to the replicated database objects at the source database. This capture process can be a local capture process or a downstream capture process. If the procedure is run at the database specified in the source_database parameter, then the procedure configures a local capture process on this database. If the procedure is run at a database other than the database specified in the source_database parameter, then the procedure configures a downstream capture process on the database that runs the procedure.
    

  • 

    If the bi_directional parameter is set to TRUE, then configure a capture process to capture changes to the replicated database objects at the destination database. This capture process must be a local capture process.
    

  • 

    Configure one or more queues at each database to store captured changes.
    

  • 

    Configure a propagation to send changes made to the database objects at the source database to the destination database.
    

  • 

    If the bi_directional parameter is set to TRUE, then configure a propagation to send changes made to the database objects at the destination database to the source database
    

  • 

    Configure an apply process at the destination database to apply changes from the source database.
    

  • 

    If the bi_directional parameter is set to TRUE, then configure an apply process at the source database to apply changes from the destination database.
    

  • 

    Configure rule sets and rules for each capture process, propagation, and apply process. The rules instruct the Oracle Streams clients to replicate changes to the specified database objects.
    

  • 

    Set the instantiation SCN for the replicated database objects at the destination database.
    

  • 

    If the bi_directional parameter is set to TRUE, then set the instantiation SCN for the replicated database objects at the source database.
    










Tip:

To view all of the actions performed by one of these procedures in detail, use the procedure to generate a script, and view the script in a text editor. You can use the perform_actions, script_name, and script_directory_object parameters to generate a script.






These procedures always configure tags for a hub-and-spoke replication environment. The following are important considerations about these procedures and tags:


  • 

    If you are configuring a two-database replication environment, then you can use these procedures to configure it. These procedures configure tags in a two-database environment to avoid change cycling. If you plan to expand the replication environment beyond two databases in the future, then it is important to understand how the tags are configured. If the expanded database environment is not a hub-and-spoke environment, then you might need to modify the tags to avoid change cycling.
    

  • 

    If you are configuring a replication environment that involves three or more databases, then these procedures can only be used to configure a hub-and-spoke replication environment. These procedures configure tags in a hub-and-spoke environment to avoid change cycling.
    

  • 

    If you are configuring an n-way replication environment, then do not use these procedures to configure it. Change cycling might result if you do so.
    










Note:

Currently, these configuration procedures configure only capture processes to capture changes. You cannot use these procedures to configure a replication environment that uses synchronous captures. You can configure a synchronous capture using the ADD_TABLE_RULES and ADD_SUBSET_RULES procedures in the DBMS_STREAMS_ADM package.













Important Considerations for the Configuration Procedures


This section describes important considerations for the configuration procedures. It also discusses several procedure parameters related to these considerations.


This section contains these topics:










See Also:

Oracle Database PL/SQL Packages and Types Reference for information about all of the parameters in these procedures









Local or Downstream Capture for the Source Database


These procedures can either configure local capture or downstream capture for the database specified in the source_database parameter. The database that captures changes made to the source database is called the capture database. See "Decide Whether to Configure Local or Downstream Capture for the Source Database" for more information.


The database on which the procedure is run is configured as the capture database for changes made to the source database. Therefore, to configure local capture at the source database, run the procedure at the source database. To configure downstream capture at the destination database, run the procedure at the database specified in the destination_database parameter. To configure downstream capture at the at a third database, run the procedure at a database that is not specified in the source_database or destination_database parameter.


If the source database or a third database is the capture database, then these procedures configure a propagation to send changes from the capture database to the destination database. If the destination database is the capture database and you are not configuring bi-directional replication, then this propagation between databases is not needed. In this case, the propagation is not configured if the capture_queue_name and apply_queue_name parameters have the same value. If these values are different, then a propagation is configured between the two queues within the destination database.









Note:


  • 

    When these procedures configure downstream capture, they always configure archived-log downstream capture. These procedures do not configure real-time downstream capture. However, you can configure redo transport services for real-time downstream capture before running a procedure, and then set the downstream_real_time_mine capture process parameter to Y after the procedure completes. You can also modify the scripts generated by these procedures to configure real-time downstream capture.
    

  • 

    If these procedures configure bi-directional replication, then the capture process for the destination database always is a local capture process. That is, these procedures always configure the capture process for changes made to the destination database to run on the destination database.
    

  • 

    Synchronous capture cannot be configured with the configuration procedures.
    
















Perform Configuration Actions Directly or With a Script


These procedures can configure the Oracle Streams replication environment directly, or they can generate a script that configures the environment. Using a procedure to configure replication directly is simpler than running a script, and the environment is configured immediately. However, you might choose to generate a script for the following reasons:


  • 

    You want to review the actions performed by the procedure before configuring the environment.
    

  • 

    You want to modify the script to customize the configuration.
    



For example, you might want an apply process to use apply handlers for customized processing of the changes to certain tables before applying these changes. In this case, you can use the procedure to generate a script and modify the script to add the apply handlers.


You also might want to maintain DML changes for several tables, but you might want to maintain DDL changes for a subset of these tables. In this case, you can generate a script by running the MAINTAIN_TABLES procedure with the include_ddl parameter set to FALSE. You can modify the script to maintain DDL changes for the appropriate tables.


The perform_actions parameter controls whether the procedure configures the replication environment directly:


  • 

    To configure an Oracle Streams replication environment directly when you run one of these procedures, set the perform_actions parameter to TRUE. The default value for this parameter is TRUE.
    

  • 

    To generate a configuration script when you run one of these procedures, set the perform_actions parameter to FALSE, and use the script_name and script_directory_object parameters to specify the name and location of the configuration script.
    










Note:

The script_directory_object parameter cannot point to an Automatic Storage Management (ASM) disk group.













Oracle Streams Components Configured by These Procedures


These procedures configure the following Oracle Streams clients:


  • 

    These procedures configure a capture process that captures changes to the source database. If bi-directional replication is configured, then these procedures also configure a capture process that captures changes to the destination database.
    

  • 

    If the capture database and the destination database are different databases, then these procedures configure a propagation that sends changes from the capture database to the destination database.
    

  • 

    If the capture database and the destination database are the same database, then the queue names determine whether a propagation is created:
    

    • 

      If the capture_queue_name and apply_queue_name parameters specify different queue names, then a propagation is created between the two queues within the destination database.
      

    • 

      If the capture_queue_name and apply_queue_name parameters specify the same queue name, then a propagation is not created, and the downstream capture process and the apply process use the same queue. This configuration is possible only if the bi_directional parameter is set to FALSE to configure a single source replication environment.
      

    

  • 

    If bi-directional replication is configured, then these procedures configure a propagation that sends changes from the destination database to the source database.
    

  • 

    These procedures configure an apply process that applies changes at the destination database. These changes originated at the source database. If bi-directional replication is configured, then these procedures also configure an apply process that applies changes to the source database. These changes originated at the destination database.
    



By default, the capture_queue_name and apply_queue_name parameters are set to NULL. When these parameters are set to NULL, these procedures configure a separate queue for each capture process and apply process. The Oracle Streams replication environment might operate more efficiently if each Oracle Streams client has its own separate queue.


However, two Oracle Streams clients share a queue in the following configurations:


  • 

    The configuration described previously in this section in which the downstream capture process and the apply process at the destination database share a queue.
    

  • 

    A configuration in which all of the following conditions are met:
    

    • 

      The capture database is the source database or a third database.
      

    • 

      The bi_directional parameter is set to TRUE.
      

    • 

      The same queue name is specified for the capture_queue_name and apply_queue_name parameters.
      

    

    In this case, the local capture process and the apply process at the destination database share the same queue. If the source database is the capture database, then the local capture process and the apply process at the source database also share the same queue.
    



Also, the capture_name and capture_queue_name parameters must be set to NULL when both of the following conditions are met:


  • 

    The destination database is the capture database.
    

  • 

    The bi_directional parameter is set to TRUE.
    



When both of these conditions are met, these procedure configure two capture processes at the destination database, and these capture processes must have different names. One capture process is the downstream capture process for the source database, while the other capture process is the local capture process that captures changes made to the destination database. When the capture_name and capture_queue_name parameters are set to NULL, the system generates a different name for the capture processes. These procedures raise an error if both conditions are met and either the capture_name parameter or the capture_queue_name parameter is set to a non-NULL value.









One-Way or Bi-Directional Replication


These procedures set up either a one-way (or single-source) Oracle Streams configuration with the database specified in the source_database parameter as the source database, or a bi-directional Oracle Streams configuration with both databases acting as source and destination databases. See "Decide Whether Changes Are Allowed at One Database or at Multiple Databases" for more information.


The bi_directional parameter in each procedure controls whether the Oracle Streams configuration is single source or bi-directional:


  • 

    If the bi_directional parameter is FALSE, then a capture process captures changes made to the source database and an apply process at the destination database applies these changes. If the destination database is not the capture database, then a propagation sends the captured changes to the destination database. The default value for this parameter is FALSE.
    

  • 

    If the bi_directional parameter is TRUE, then a separate capture process captures changes made to each database, propagations send these changes to the other database, and each database applies changes from the other database.
    



When a replication environment is not bi-directional, and no changes are allowed at the destination database, Oracle Streams keeps the shared database objects synchronized at the databases. However, when a replication environment is not bi-directional, and independent changes are allowed at the destination database, the shared database objects might diverge between the databases. Independent changes can be made by users, by applications, or by replication with a third database.









Note:


  • 

    You might need to configure conflict resolution if bi-directional replication is configured.
    

  • 

    If you set the bi_directional parameter to TRUE when you run one of these procedures, then do not allow data manipulation language (DML) or data definition language (DDL) changes to the shared database objects at the destination database while the procedure, or the script generated by the procedure, is running. This restriction does not apply if a procedure is configuring a single-source replication environment.
    

  • 

    These procedures do not configure the replicated tables to be read-only at the destination database. If you set the bi_directional parameter to FALSE when you run one of these procedures, and the replicated tables should be read only at the destination database, then configure privileges at the destination databases accordingly. However, the apply user for the apply process must be able to make DML changes to the replicated database objects. See Oracle Database Security Guide for information about configuring privileges.
    













Change Cycling and Tags


Change cycling happens when a change is sent back to the database where it originated. Typically, change cycling should be avoided because it can result in each change going through endless loops back to the database where it originated. Such loops can result in unintended data in the database and tax the networking and computer resources of an environment.


If the bi_directional parameter is set to TRUE, then these procedures configure bi-directional replication. To prevent change cycling in a bi-directional Oracle Streams replication environment, these procedures configure the environment in the following way:


  • 

    The apply process at each database applies each change with an apply tag that is unique to the environment. An apply tag is an Oracle Streams tag that is part of each redo record created by the apply process. For example, if a procedure configures databases sfdb.net and nydb.net for bi-directional replication, then the apply tag for the apply process at sfdb.net might be the hexidecimal equivalent of '1', and the apply tag for the apply process at nydb.net might be the hexidecimal equivalent of '2'. In this case, an applied change with a tag that is the hexidecimal equivalent of '1' originated at the nydb.net database, while an applied change with a tag that is the hexidecimal equivalent of '2' originated at the sfdb.net database.
    

  • 

    The capture process at each database captures all changes to the shared database objects, regardless of tags in the redo records for the changes to these database objects.
    

  • 

    Each propagation sends all changes made to the shared database objects to the other database in the bi-directional replication environment, except for changes that originated at the other database. Continuing the example, the propagation at sfdb.net sends all changes to nydb.net, except for changes with a tag value that is the hexidecimal equivalent of '1', because these changes originated at nydb.net. Similarly, the propagation at nydb.net sends all changes to sfdb.net, except for changes with a tag value that is the hexidecimal equivalent of '2'. A change that is not propagated because of its tag value is discarded.
    



These procedures cannot be used to configure multi-directional replication where changes can be cycled back to a source database by a third database in the environment. For example, these procedures cannot be used to configure an Oracle Streams replication environment with three databases where each database shares changes with the other two databases in the environment. Such an environment is sometimes called an "n-way" replication environment. If these procedures were used to configure this type of a three way replication environment, then changes made at a source database would be cycled back to the same source database. In a valid three way replication environment, a particular change is made only once at each database.


These procedures can configure an Oracle Streams replication environment that includes more than two databases, if changes made at a source database cannot cycle back to the same source database. For example, a procedure can be run multiple times to configure an environment in which a primary database shares changes with multiple secondary databases. Such an environment is sometimes called a "hub-and-spoke" replication environment.


You can configure the Oracle Streams environment manually to replicate changes in a multiple source environment where each source database shares changes with the other source databases, or you can modify generated scripts to achieve this.











Data Definition Language (DDL) Changes


The include_ddl parameter controls whether the procedure configures Oracle Streams replication to maintain DDL changes:


  • 

    To configure an Oracle Streams replication environment that does not maintain DDL changes, set the include_ddl parameter to FALSE when you run one of these procedures. The default value for this parameter is FALSE.
    

  • 

    To configure an Oracle Streams replication environment that maintains DDL changes, set the include_ddl parameter to TRUE when you run one of these procedures.
    










Note:

The MAINTAIN_SIMPLE_TTS procedure does not include the include_ddl parameter. An Oracle Streams replication environment configured by the MAINTAIN_SIMPLE_TTS procedure only maintains DML changes.













Instantiation


The MAINTAIN_GLOBAL, MAINTAIN_SCHEMAS, and MAINTAIN_TABLES procedures provide options for instantiation. Instantiation is the process of preparing database objects for instantiation at a source database, optionally copying the database objects from a source database to a destination database, and setting the instantiation SCN for each instantiated database object.


When you run one of these three procedures, you can choose to perform the instantiation in one of the following ways:


  • 

    Data Pump Export Dump File Instantiation: This option performs a Data Pump export of the shared database objects at the source database and a Data Pump import of the export dump file at the destination database. The instantiation SCN is set for each shared database object during import.
    

    To specify this instantiation option, set the instantiation parameter to one of the following values:
    

    • 

      DBMS_STREAMS_ADM.INSTANTIATION_FULL if you run the MAINTAIN_GLOBAL procedure
      

    • 

      DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA if you run the MAINTAIN_SCHEMAS procedure
      

    • 

      DBMS_STREAMS_ADM.INSTANTIATION_TABLE if you run the MAINTAIN_TABLES procedure
      

    

    If the bi_directional parameter is set to TRUE, then the procedure also sets the instantiation SCN for each shared database object at the source database.
    

    When you use this option, you must create directory objects to hold the Data Pump files. See "Creating the Required Directory Objects".
    

  • 

    Data Pump Network Import Instantiation: This option performs a network Data Pump import of the shared database objects. A network import means that Data Pump performs the import without using an export dump file. Therefore, directory objects do not need to be created for instantiation purposes when you use this option. The instantiation SCN is set for each shared database object during import.
    

    To specify this instantiation option, set the instantiation parameter to one of the following values:
    

    • 

      DBMS_STREAMS_ADM.INSTANTIATION_FULL_NETWORK if you run the MAINTAIN_GLOBAL procedure
      

    • 

      DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA_NETWORK if you run the MAINTAIN_SCHEMAS procedure
      

    • 

      DBMS_STREAMS_ADM.INSTANTIATION_TABLE_NETWORK if you run the MAINTAIN_TABLES procedure
      

    

    If the bi_directional parameter is set to TRUE, then the procedure also sets the instantiation SCN for each shared database object at the source database.
    

  • 

    Generate a Configuration Script with No Instantiation Specified: This option does not perform an instantiation. This setting is valid only if the perform_actions parameter is set to FALSE, and the procedure generates a configuration script. In this case, the configuration script does not perform an instantiation and does not set the instantiation SCN for each shared database object. Instead, you must perform the instantiation and ensure that instantiation SCN values are set properly.
    

    To specify this instantiation option, set the instantiation parameter to DBMS_STREAMS_ADM.INSTANTIATION_NONE in each procedure.
    



When one of these procedures performs a table instantiation, the tablespace that contains the table must exist at the destination database. When one of these procedures performs a schema instantiation, the tablespace that contains the schema must exist at the destination database.


When these procedures perform a dump file or network instantiation and an instantiated database object does not exist at the destination database, the database object is imported at the destination database, including its supplemental logging specifications from the source database and its supporting database objects, such as indexes and triggers. However, if the database object already exists at the destination database before instantiation, then it is not imported at the destination database. Therefore, the supplemental logging specifications from the source database are not specified for the database object at the destination database, and the supporting database objects are not imported.


The PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures do not perform an instantiation. You must perform any required instantiation actions manually after running PRE_INSTANTIATION_SETUP and before running POST_INSTANTIATION_SETUP. You also must perform any required instantiation actions manually if you use the MAINTAIN_GLOBAL, MAINTAIN_SCHEMAS, and MAINTAIN_TABLES procedures and set the instantiation parameter to DBMS_STREAMS_ADM.INSTANTIATION_NONE.


In these cases, you can use any instantiation method. For example, you can use Recovery Manager (RMAN) to perform a database instantiation using the RMAN DUPLICATE or CONVERT DATABASE command or a tablespace instantiation using the RMAN TRANSPORT TABLESPACE command. If the bi_directional parameter is set to TRUE, then ensure that the instantiation SCN values are set properly at the source database and the destination database.









Note:


  • 

    The MAINTAIN_SIMPLE_TTS and MAINTAIN_TTS procedures do not provide these instantiation options. These procedures always perform an instantiation by cloning the tablespace or tablespace set, transferring the files required for instantiation to the destination database, and attaching the tablespace or tablespace set at the destination database.
    

  • 

    If one of these procedures performs an instantiation, then the database objects, tablespace, or tablespaces set being configured for replication must exist at the source database.
    

  • 

    If the RMAN DUPLICATE or CONVERT DATABASE command is used for database instantiation, then the destination database cannot be the capture database.
    

  • 

    When the MAINTAIN_TABLES procedure performs a dump file or network instantiation and the instantiated table already exist at the destination database before instantiation, the procedure does not set the instantiation SCN for the table. In this case, you must set the instantiation SCN for the table manually after the procedure completes.
    


















Creating the Required Directory Objects


A directory object is similar to an alias for a directory on a file system. The following directory objects might be required when you run one of these procedures:


  • 

    A script directory object is required if you decided to generate a configuration script. The configuration script is placed in this directory on the computer system where the procedure is run. Use the script_directory_object parameter when you run one of these procedures to specify the script directory object.
    

  • 

    A source directory object is required if you decided to perform a Data Pump export dump file instantiation, and you will use one of the following procedures: MAINTAIN_GLOBAL, MAINTAIN_SCHEMAS, MAINTAIN_SIMPLE_TTS, MAINTAIN_TABLES, or MAINTAIN_TTS. The Data Pump export dump file and log file are placed in this directory on the computer system running the source database. Use the source_directory_object parameter when you run one of these procedures to specify the source directory object. This directory object is not required if you will use the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures.
    

  • 

    A destination directory object is required if you decided to perform a Data Pump export dump file instantiation, and you will use one of the following procedures: MAINTAIN_GLOBAL, MAINTAIN_SCHEMAS, MAINTAIN_SIMPLE_TTS, MAINTAIN_TABLES, or MAINTAIN_TTS. The Data Pump export dump file is transferred from the computer system running the source database to the computer system running the destination database and placed in this directory on the computer system running the destination database. Use the destination_directory_object parameter when you run one of these procedures to specify the destination directory object. This directory object is not required if you will use the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures.
    



Each directory object must be created using the SQL statement CREATE DIRECTORY, and the user who invokes one of the procedures must have READ and WRITE privilege on each directory object.


For example, complete the following steps to create a directory object named db_dir that corresponds to the /usr/db_files directory:


  1. 

    In SQL*Plus, connect to the database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Create the directory object:
    

    CREATE DIRECTORY db_dir AS '/usr/db_files';



The user who creates the directory object automatically has READ and WRITE privilege on the directory object. When you are configuring an Oracle Streams replication environment, typically the Oracle Streams administrator creates the directory objects.









Note:

The directory objects cannot point to an Automatic Storage Management (ASM) disk group.













Examples That Configure Two-Database Replication with Local Capture


Each of the following examples configures a two-database replication environment that uses one or more local capture processes:






Configuring Two-Database Global Replication with Local Capture


You can use the following procedures in the DBMS_STREAMS_ADM package to configure replication at the database level:



The MAINTAIN_GLOBAL procedure automatically excludes database objects that are not supported by Oracle Streams from the replication environment. The PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures do not automatically exclude database objects. Instead, these procedures enable you to specify which database objects to exclude from the replication environment. Query the DBA_STREAMS_UNSUPPORTED data dictionary view to determine which database objects are not supported by Oracle Streams. If unsupported database objects are not excluded, then capture errors will result.


The following table lists the decisions that were made about the Oracle Streams replication environment configured in this example.




DecisionAssumption for This Example
Decide Which Type of Replication Environment to Configure
This example configures bi-directional replication in a two database environment where both databases are read/write.
Decide Whether to Configure Local or Downstream Capture for the Source Database
This example configures local capture for each source database.
Decide Whether Changes Are Allowed at One Database or at Multiple Databases
This example allows changes to the replicate database objects at both databases.
Decide Whether the Replication Environment Will Have Nonidentical Replicas
This example configures identical shared database objects at the databases.
Decide Whether the Replication Environment Will Use Apply Handlers
This example does not configure apply handlers.
Decide Whether to Maintain DDL Changes
This example maintains DDL changes.
Decide How to Configure the Replication Environment
This example uses the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures to configure the environment.





In this example, the procedures will configure the replication environment directly. Configuration scripts will not be generated. An RMAN database instantiation will be performed.


As noted in the previous table, this example uses the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures to configure database replication. The replication configuration will exclude all database objects that are not supported by Oracle Streams. In this example, the source database is dbs1.example.com, and the destination database is dbs2.example.com.


Figure 2-1 provides an overview of the replication environment created in this example.




Figure 2-1 Sample Oracle Streams Environment That Replicates an Entire Database

Description of Figure 2-1 follows

Description of "Figure 2-1 Sample Oracle Streams Environment That Replicates an Entire Database"












Note:

A capture process never captures changes in the SYS, SYSTEM, or CTXSYS schemas. Changes to these schemas are not maintained by Oracle Streams in the replication configuration described in this section.













See Also:

Oracle Streams Concepts and Administration for instructions on determining which database objects are not supported by Oracle Streams






Complete the following steps to use the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures to configure the replication environment:


  1. 

    Complete the required tasks before running the PRE_INSTANTIATION_SETUP procedure. See "Tasks to Complete Before Configuring Oracle Streams Replication" for instructions.
    

    For this configuration, the following tasks must be completed:
    


    A database link is required from the destination database to the source database. However, because RMAN will be used for database instantiation, this database link must be created after instantiation. This database link is required because the replication environment will be bi-directional and because RMAN will be used for database instantiation.
    

  2. 

    In SQL*Plus, connect to the source database dbs1.example.com as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the PRE_INSTANTIATION_SETUP procedure:
    

    DECLARE
  empty_tbs  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET; 
BEGIN
  DBMS_STREAMS_ADM.PRE_INSTANTIATION_SETUP(
    maintain_mode        => 'GLOBAL',
    tablespace_names     => empty_tbs,
    source_database      => 'dbs1.example.com',
    destination_database => 'dbs2.example.com',
    perform_actions      => TRUE,
    bi_directional       => TRUE,
    include_ddl          => TRUE,
    start_processes      => TRUE,
    exclude_schemas      => '*',
    exclude_flags        => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED + 
                            DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML + 
                            DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

    

    Notice that the start_processes parameter is set to TRUE. Therefore, each capture process and apply process created during the configuration is started automatically.
    

    Also, notice the values specified for the exclude_schemas and exclude_flags parameters. The asterisk (*) specified for exclude_schemas indicates that certain database objects in every schema in the database might be excluded from the replication environment. The value specified for the exclude_flags parameter indicates that DML and DDL changes for all unsupported database objects are excluded from the replication environment. Rules are placed in the negative rule sets for the capture processes to exclude these database objects.
    

    Because the procedure is run at the source database, local capture is configured at the source database.
    

    Because this procedure configures a bi-directional replication environment, do not allow DML or DDL changes to the shared database objects at the destination database while the procedure is running.
    

    The procedure does not specify the apply_name parameter. Therefore, the default, NULL, is specified for this parameter. When the apply_name parameter is set to NULL, no apply process that applies changes from the source database can exist on the destination database. If an apply process that applies changes from the source database exists at the destination database, then specify a non-NULL value for the apply_name parameter.
    

    To monitor the progress of the configuration operation, follow the instructions in "Monitoring Oracle Streams Configuration Progress".
    

    If this procedure encounters an error and stops, then see "Recovering from Operation Errors" for information about either recovering from the error or rolling back the configuration operation.
    

  4. 

    Perform the instantiation. You can use any of the methods described in Chapter 8, "Instantiation and Oracle Streams Replication" to complete the instantiation. This example uses the RMAN DUPLICATE command to perform the instantiation by performing the following steps:
    

    1. 

      Create a backup of the source database if one does not exist. RMAN requires a valid backup for duplication. In this example, create a backup of dbs1.example.com if one does not exist.
      

      


      

      

      Note:
      
A backup of the source database is not necessary if you use the FROM ACTIVE DATABASE option when you run the RMAN DUPLICATE command. For large databases, the FROM ACTIVE DATABASE option requires significant network resources. This example does not use this option.
      

      

      

    2. 

      In SQL*Plus, connect to the source database dbs1.example.com as the Oracle Streams administrator.
      

      See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
      

    3. 

      Determine the until SCN for the RMAN DUPLICATE command:
      

      SET SERVEROUTPUT ON SIZE 1000000
DECLARE
  until_scn NUMBER;
BEGIN
  until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
      DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);
END;
/

      

      Make a note of the until SCN returned. You will use this number in Step h. For this example, assume that the returned until SCN is 45442631.
      

    4. 

      In SQL*Plus, connect to the source database dbs1.example.com as an administrative user.
      

    5. 

      Archive the current online redo log:
      

      ALTER SYSTEM ARCHIVE LOG CURRENT;

    6. 

      Prepare your environment for database duplication, which includes preparing the destination database as an auxiliary instance for duplication. See Oracle Database Backup and Recovery User's Guide for instructions.
      

    7. 

      Start the RMAN client, and connect to the source database dbs1.example.com as TARGET and to the destination database dbs2.example.com as AUXILIARY.
      

      


      

      

      See Also:
      
Oracle Database Backup and Recovery Reference for more information about the RMAN CONNECT command
      

      

      

    8. 

      Use the RMAN DUPLICATE command with the OPEN RESTRICTED option to instantiate the source database at the destination database. The OPEN RESTRICTED option is required. This option enables a restricted session in the duplicate database by issuing the following SQL statement: ALTER SYSTEM ENABLE RESTRICTED SESSION. RMAN issues this statement immediately before the duplicate database is opened.
      

      You can use the UNTIL SCN clause to specify an SCN for the duplication. Use the until SCN determined in Step c for this clause. Archived redo logs must be available for the until SCN specified and for higher SCN values. Therefore, Step e archived the redo log containing the until SCN.
      

      Ensure that you use TO database_name in the DUPLICATE command to specify the name of the duplicate database. In this example, the duplicate database is dbs2.example.com. Therefore, the DUPLICATE command for this example includes TO dbs2.example.com.
      

      The following is an example of an RMAN DUPLICATE command:
      

      RMAN> RUN
      { 
        SET UNTIL SCN 45442631;
        ALLOCATE AUXILIARY CHANNEL dbs2 DEVICE TYPE sbt; 
        DUPLICATE TARGET DATABASE TO dbs2 
        NOFILENAMECHECK
        OPEN RESTRICTED;
      }

      

      


      

      

      See Also:
      
Oracle Database Backup and Recovery Reference for more information about the RMAN DUPLICATE command
      

      

      

    9. 

      In SQL*Plus, connect to the destination database as an administrative user.
      

    10. 

      Rename the global name. After an RMAN database instantiation, the destination database has the same global name as the source database. Rename the global name of the destination database back to its original name with the following statement:
      

      ALTER DATABASE RENAME GLOBAL_NAME TO dbs2.example.com;

    11. 

      In SQL*Plus, connect to the destination database dbs2.example.com as the Oracle Streams administrator.
      

    12. 

      Drop the database link from the source database to the destination database that was cloned from the source database:
      

      DROP DATABASE LINK dbs2.example.com;

    

  5. 

    While still connected to the destination database as the Oracle Streams administrator, create a database link from the destination database to the source database:
    

    CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin 
  IDENTIFIED BY password USING 'dbs1.example.com';

    

    See Step 1 for information about why this database link is required.
    

  6. 

    In SQL*Plus, connect to the source database dbs1.example.com as the Oracle Streams administrator.
    

  7. 

    Run the POST_INSTANTIATION_SETUP procedure:
    

    DECLARE
  empty_tbs  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET; 
BEGIN
  DBMS_STREAMS_ADM.POST_INSTANTIATION_SETUP(
    maintain_mode        => 'GLOBAL',
    tablespace_names     => empty_tbs,
    source_database      => 'dbs1.example.com',
    destination_database => 'dbs2.example.com',
    perform_actions      => TRUE,
    bi_directional       => TRUE,
    include_ddl          => TRUE,
    start_processes      => TRUE,
    instantiation_scn    => 45442630,
    exclude_schemas      => '*',
    exclude_flags        => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED + 
                            DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML + 
                            DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL);
END;
/

    

    The parameter values specified in both the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures must match, except for the values of the following parameters: perform_actions, script_name, script_directory_object, and start_processes.
    

    Also, notice that the instantiation_scn parameter is set to 45442630. The RMAN DUPLICATE command duplicates the database up to one less than the SCN value specified in the UNTIL SCN clause. Therefore, you should subtract one from the until SCN value that you specified when you ran the DUPLICATE command in Step 4h. In this example, the until SCN was set to 45442631. Therefore, the instantiation_scn parameter should be set to 45442631 - 1, or 45442630.
    

    If the instantiation SCN was set for the shared database objects at the destination database during instantiation, then the instantiation_scn parameter should be set to NULL. For example, the instantiation SCN might be set during a full database export/import.
    

    Because this procedure configures a bi-directional replication environment, do not allow DML or DDL changes to the shared database objects at the destination database while the procedure is running.
    

    To monitor the progress of the configuration operation, follow the instructions in "Monitoring Oracle Streams Configuration Progress".
    

    If this procedure encounters an error and stops, then see "Recovering from Operation Errors" for information about either recovering from the error or rolling back the configuration operation.
    

  8. 

    At the destination database, connect as an administrative user in SQL*Plus and use the ALTER SYSTEM statement to disable the RESTRICTED SESSION:
    

    ALTER SYSTEM DISABLE RESTRICTED SESSION;

  9. 

    Configure conflict resolution for the shared database objects if necessary.
    

    Typically, conflicts are possible in a bi-directional replication environment. If conflicts are possible in the environment created by the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures, then configure conflict resolution before you allow users to make changes to the shared database objects.
    

    See Chapter 9, "Oracle Streams Conflict Resolution" for more information.
    



The bi-directional replication environment configured in this example has the following characteristics:


  • 

    Database supplemental logging is configured at both databases.
    

  • 

    The dbs1.example.com database has two queues and queue tables with system-generated names. One queue is for the local capture process, and one queue is for the apply process.
    

  • 

    The dbs2.example.com database has two queues and queue tables with system-generated names. One queue is for the local capture process, and one queue is for the apply process.
    

  • 

    At the dbs1.example.com database, a capture process with a system-generated name captures DML and DDL changes to all of the database objects in the database that are supported by Oracle Streams.
    

  • 

    At the dbs2.example.com database, a capture process with a system-generated name captures DML and DDL changes to all of the database objects in the database that are supported by Oracle Streams.
    

  • 

    A propagation running on the dbs1.example.com database with a system-generated name sends the captured changes from a queue at the dbs1.example.com database to a queue at the dbs2.example.com database.
    

  • 

    A propagation running on the dbs2.example.com database with a system-generated name sends the captured changes from a queue at the dbs2.example.com database to a queue at the dbs1.example.com database.
    

  • 

    At the dbs1.example.com database, an apply process with a system-generated name dequeues the changes from its queue and applies them to the database objects.
    

  • 

    At the dbs2.example.com database, an apply process with a system-generated name dequeues the changes from its queue and applies them to the database objects.
    

  • 

    Tags are used to avoid change cycling. Specifically, each apply process uses an apply tag so that redo records for changes applied by the apply process include the tag. Each apply process uses an apply tag that is unique in the replication environment. Each propagation discards changes that have the tag of the apply process running on the same database. See "Change Cycling and Tags" for more information.
    









Configuring Two-Database Schema Replication with Local Capture


This example configures an Oracle Streams replication environment that replicates data manipulation language (DML) changes to all of the tables in the hr schema. This example configures a two-database replication environment with local capture processes to capture changes. This example uses the global database names db1.example.com and db2.example.com. However, you can substitute databases in your environment to complete the example.


The following table lists the decisions that were made about the Oracle Streams replication environment configured in this example.




DecisionAssumption for This Example
Decide Which Type of Replication Environment to Configure
This example provides instructions for configuring either one-way or bi-directional replication. To configure bi-directional replication, you must complete additional steps and set the bi_directional parameter to TRUE when you run the configuration procedure.
Decide Whether to Configure Local or Downstream Capture for the Source Database
This example configures local capture for the source database.
Decide Whether Changes Are Allowed at One Database or at Multiple Databases
This example lets you choose whether to allow changes at one database or both databases.
Decide Whether the Replication Environment Will Have Nonidentical Replicas
This example configures identical shared database objects at the databases.
Decide Whether the Replication Environment Will Use Apply Handlers
This example does not configure apply handlers.
Decide Whether to Maintain DDL Changes
This example maintains DDL changes.
Decide How to Configure the Replication Environment
This example uses the MAINTAIN_SCHEMAS procedure to configure the environment.





The database objects being configured for replication might or might not exist at the destination database when you run the MAINTAIN_SCHEMAS procedure. If the database objects do not exist at the destination database, then the MAINTAIN_SCHEMAS procedure instantiates them at the destination database using a Data Pump export/import. During instantiation, the instantiation SCN is set for these database objects. If the database objects already exist at the destination database, then the MAINTAIN_SCHEMAS procedure retains the existing database objects and sets the instantiation SCN for them. In this example, the hr schema exists at both the db1.example.com database and the db2.example.com database before the MAINTAIN_SCHEMAS procedure is run.


In this example, the MAINTAIN_SCHEMAS procedure will configure the replication environment directly. A configuration script will not be generated. A Data Pump export dump file instantiation will be performed.


Figure 2-2 provides an overview of the environment created in this example. The additional components required for bi-directional replication are shown in gray, and their actions are indicated by dashed lines.




Figure 2-2 Two-Database Replication Environment with Local Capture Processes

Description of Figure 2-2 follows

Description of "Figure 2-2 Two-Database Replication Environment with Local Capture Processes"





Complete the following steps to use the MAINTAIN_SCHEMAS procedure to configure the environment:


  1. 

    Complete the following tasks to prepare for the two-database replication environment:
    

    1. 

      Configure network connectivity so that the db1.example.com database can communicate with the db2.example.com database.
      

      See Oracle Database 2 Day DBA for information about configuring network connectivity between databases.
      

    2. 

      Configure an Oracle Streams administrator at each database that will participate in the replication environment. See "Configuring an Oracle Streams Administrator on All Databases" for instructions. This example assumes that the Oracle Streams administrator is strmadmin.
      

    3. 

      Create a database link from the db1.example.com database to the db2.example.com database.
      

      The database link should be created in the Oracle Streams administrator's schema. Also, the database link should connect to the Oracle Streams administrator at the other database. Both the name and the service name of the database link must be db2.example.com. See "Configuring Network Connectivity and Database Links" for instructions.
      

    4. 

      Configure the db1.example.com database to run in ARCHIVELOG mode. For a capture process to capture changes generated at a source database, the source database must be running in ARCHIVELOG mode. See Oracle Database Administrator's Guide for information about configuring a database to run in ARCHIVELOG mode.
      

    

  2. 

    To configure a bi-directional replication environment, complete the following steps. If you are configuring a one-way replication environment, then these steps are not required, and you can move on to Step 3.
    

    1. 

      Create a database link from the db2.example.com database to the db1.example.com database.
      

      The database link should be created in the Oracle Streams administrator's schema. Also, the database link should connect to the Oracle Streams administrator at the other database. Both the name and the service name of the database link must be db1.example.com. See "Configuring Network Connectivity and Database Links" for instructions.
      

    2. 

      Configure the db2.example.com database to run in ARCHIVELOG mode. For a capture process to capture changes generated at a source database, the source database must be running in ARCHIVELOG mode. See Oracle Database Administrator's Guide for information about configuring a database to run in ARCHIVELOG mode.
      

    

  3. 

    Set initialization parameters properly at each database that will participate in the Oracle Streams replication environment. See "Setting Initialization Parameters Relevant to Oracle Streams""Setting Initialization Parameters Relevant to Oracle Streams" for instructions.
    

  4. 

    Create the following required directory objects:
    

    • 

      A source directory object at the source database. This example assumes that this directory object is source_directory.
      

    • 

      A destination directory object at the destination database. This example assumes that this directory object is dest_directory.
      

    

    See "Creating the Required Directory Objects" for instructions.
    

  5. 

    In SQL*Plus, connect to the db1.example.com database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
    

  6. 

    Run the MAINTAIN_SCHEMAS procedure to configure replication of the hr schema between the db1.example.com database and the db2.example.com database.
    

    Ensure that the bi_directional parameter is set properly for the replication environment that you are configuring. Either set this parameter to FALSE for one-way replication, or set it to TRUE for bi-directional replication.
    

    BEGIN
  DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
    schema_names                 => 'hr',
    source_directory_object      => 'source_directory',
    destination_directory_object => 'dest_directory',
    source_database              => 'db1.example.com',
    destination_database         => 'db2.example.com',
    bi_directional               => FALSE); -- Set to TRUE for bi-directional
END;
/

    

    The MAINTAIN_SCHEMAS procedure can take some time to run because it is performing many configuration tasks. Do not allow data manipulation language (DML) or data definition language (DDL) changes to the replicated database objects at the destination database while the procedure is running.
    

    When a configuration procedure is run, information about its progress is recorded in the following data dictionary views: DBA_RECOVERABLE_SCRIPT, DBA_RECOVERABLE_SCRIPT_PARAMS, DBA_RECOVERABLE_SCRIPT_BLOCKS, and DBA_RECOVERABLE_SCRIPT_ERRORS. If the procedure stops because it encounters an error, then see Oracle Streams Replication Administrator's Guide for instructions about using the RECOVER_OPERATION procedure in the DBMS_STREAMS_ADM package to recover from these errors.
    

  7. 

    If you configured bi-directional replication, then configure latest time conflict resolution for all of the tables in the hr schema at both databases. This schema includes the countries, departments, employees, jobs, job_history, locations, and regions tables. See Chapter 9, "Oracle Streams Conflict Resolution" for instructions.
    










See Also:

Oracle Database 2 Day + Data Replication and Integration Guide for an example that configures this replication environment using Oracle Enterprise Manager












Configuring Two-Database Table Replication with Local Capture


You can use the MAINTAIN_TABLES procedure in the DBMS_STREAMS_ADM package to configure table replication. The example in this section uses this procedure to configure an Oracle Streams replication environment that maintains specific tables in the hr schema. The source database is dbs1.example.com, and the destination database is dbs2.example.com.


The following table lists the decisions that were made about the Oracle Streams replication environment configured in this example.




DecisionAssumption for This Example
Decide Which Type of Replication Environment to Configure
This example configures one-way replication in a two database environment where the source database is read/write and the destination database is read-only.
Decide Whether to Configure Local or Downstream Capture for the Source Database
This example configures local capture for the source database.
Decide Whether Changes Are Allowed at One Database or at Multiple Databases
This example configures a replication environment that allows changes only at the source database.
Decide Whether the Replication Environment Will Have Nonidentical Replicas
This example configures identical shared database objects at the databases.
Decide Whether the Replication Environment Will Use Apply Handlers
This example does not configure apply handlers.
Decide Whether to Maintain DDL Changes
This example maintains DDL changes for a subset of the shared database objects.
Decide How to Configure the Replication Environment
This example uses the MAINTAIN_TABLES procedure to configure the environment.





The replication environment maintains the following DML and DDL changes for the shared database objects:


  • 

    The replication environment will maintain DML changes to the following tables in the hr schema:
    

    • 

      departments
      

    • 

      employees
      

    • 

      countries
      

    • 

      regions
      

    • 

      locations
      

    • 

      jobs
      

    • 

      job_history
      

    

  • 

    The replication environment will maintain DDL changes to the following tables in the hr schema:
    

    • 

      departments
      

    • 

      employees
      

    



The replication environment does not maintain DDL changes to the following tables in the hr schema:


  • 

    countries
    

  • 

    regions
    

  • 

    locations
    

  • 

    jobs
    

  • 

    job_history
    



In this example, the MAINTAIN_TABLES procedure will not configure the replication environment directly. Instead, a configuration script will be generated, and this script will be modified so that DDL changes to the following tables are maintained: departments and employees. A Data Pump network import instantiation will be performed.


Ensure that you do not try to replicate tables that are not supported by Oracle Streams.


Figure 2-3 provides an overview of the replication environment created in this example.




Figure 2-3 Sample Oracle Streams Environment That Replicates Tables

Description of Figure 2-3 follows

Description of "Figure 2-3 Sample Oracle Streams Environment That Replicates Tables"












See Also:

Oracle Streams Concepts and Administration for instructions on determining which database objects are not supported by Oracle Streams






Complete the following steps to use the MAINTAIN_TABLES procedure to configure the environment:


  1. 

    Complete the required tasks before running the MAINTAIN_TABLES procedure. See "Tasks to Complete Before Configuring Oracle Streams Replication" for instructions.
    

    For this configuration, the following tasks must be completed:
    


  2. 

    Create a script directory object at the source database. This example assumes that this directory object is script_directory.
    

    See "Creating the Required Directory Objects" for instructions.
    

  3. 

    In SQL*Plus, connect to the source database dbs1.example.com as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  4. 

    Run the MAINTAIN_TABLES procedure:
    

    DECLARE
  tables DBMS_UTILITY.UNCL_ARRAY;
  BEGIN
    tables(1) := 'hr.departments';
    tables(2) := 'hr.employees';
    tables(3) := 'hr.countries';
    tables(4) := 'hr.regions';
    tables(5) := 'hr.locations';
    tables(6) := 'hr.jobs';
    tables(7) := 'hr.job_history';
    DBMS_STREAMS_ADM.MAINTAIN_TABLES(
      table_names                  => tables,
      source_directory_object      => NULL,
      destination_directory_object => NULL,
      source_database              => 'dbs1.example.com',
      destination_database         => 'dbs2.example.com',
      perform_actions              => FALSE,
      script_name                  => 'configure_rep.sql',
      script_directory_object      => 'script_directory',
      bi_directional               => FALSE,
      include_ddl                  => FALSE,
      instantiation      => DBMS_STREAMS_ADM.INSTANTIATION_TABLE_NETWORK);
END;
/

    

    The configure_rep.sql script generated by the procedure uses default values for the parameters that are not specified in the procedure call. The script uses system-generated names for the ANYDATA queues, queue tables, capture process, propagation, and apply process it creates. You can specify different names by using additional parameters available in the MAINTAIN_TABLES procedure. Notice that the include_ddl parameter is set to FALSE. Therefore, the script does not configure the replication environment to maintain DDL changes to the tables.
    

    The procedure does not specify the apply_name parameter. Therefore, the default, NULL, is specified for this parameter. When the apply_name parameter is set to NULL, no apply process that applies changes from the source database can exist on the destination database. If an apply process that applies changes from the source database exists at the destination database, then specify a non-NULL value for the apply_name parameter.
    

  5. 

    Modify the configure_rep.sql script:
    

    1. 

      Navigate to the directory that corresponds with the script_directory directory object on the computer system running the source database.
      

    2. 

      Open the configure_rep.sql script in a text editor. Consider making a backup of this script before modifying it.
      

    3. 

      In the script, find the ADD_TABLE_RULES and ADD_TABLE_PROPAGATION_RULES procedure calls that create the table rules for the hr.departments and hr.employees tables. For example, the procedure calls for the capture process look similar to the following:
      

      dbms_streams_adm.add_table_rules(
    table_name => '"HR"."DEPARTMENTS"', 
    streams_type => 'CAPTURE', 
    streams_name => '"DBS1$CAP"', 
    queue_name => '"STRMADMIN"."DBS1$CAPQ"', 
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => TRUE,
    source_database => 'DBS1.EXAMPLE.COM', 
    inclusion_rule => TRUE,
    and_condition => get_compatible);

dbms_streams_adm.add_table_rules(
    table_name => '"HR"."EMPLOYEES"', 
    streams_type => 'CAPTURE', 
    streams_name => '"DBS1$CAP"', 
    queue_name => '"STRMADMIN"."DBS1$CAPQ"', 
    include_dml => TRUE,
    include_ddl => FALSE,
    include_tagged_lcr => TRUE,
    source_database => 'DBS1.EXAMPLE.COM', 
    inclusion_rule => TRUE,
    and_condition => get_compatible);

    4. 

      In the procedure calls that you found in Step c, change the setting of the include_ddl parameter to TRUE. For example, the procedure calls for the capture process should look similar to the following after the modification:
      

      dbms_streams_adm.add_table_rules(
    table_name => '"HR"."DEPARTMENTS"', 
    streams_type => 'CAPTURE', 
    streams_name => '"DBS1$CAP"', 
    queue_name => '"STRMADMIN"."DBS1$CAPQ"', 
    include_dml => TRUE,
    include_ddl => TRUE,
    include_tagged_lcr => TRUE,
    source_database => 'DBS1.EXAMPLE.COM', 
    inclusion_rule => TRUE,
    and_condition => get_compatible);

dbms_streams_adm.add_table_rules(
    table_name => '"HR"."EMPLOYEES"', 
    streams_type => 'CAPTURE', 
    streams_name => '"DBS1$CAP"', 
    queue_name => '"STRMADMIN"."DBS1$CAPQ"', 
    include_dml => TRUE,
    include_ddl => TRUE,
    include_tagged_lcr => TRUE,
    source_database => 'DBS1.EXAMPLE.COM', 
    inclusion_rule => TRUE,
    and_condition => get_compatible);

      

      Remember to change the procedure calls for all capture processes, propagations, and apply processes.
      

    5. 

      Save and close the configure_rep.sql script.
      

    

  6. 

    In SQL*Plus, connect to the source database dbs1.example.com as the Oracle Streams administrator.
    

  7. 

    At the source database, run the configuration script:
    

    SET ECHO ON
SPOOL configure_rep.out
@configure_rep.sql

    

    The script prompts you to supply information about the database names and the Oracle Streams administrators. When this configuration script completes, the Oracle Streams single-source replication environment is configured. The script also starts the queues, capture process, propagations, and apply process.
    



The resulting single-source replication environment has the following characteristics:


  • 

    At the source database, supplemental logging is configured for the shared database objects.
    

  • 

    The source database dbs1.example.com has a queue and queue table with system-generated names.
    

  • 

    The destination database dbs2.example.com has a queue and queue table with system-generated names.
    

  • 

    At the source database, a capture process with a system-generated name captures DML changes to all of the tables in the hr schema and DDL changes to the hr.departments and hr.employees tables.
    

  • 

    A propagation running on the source database with a system-generated name sends the captured changes from the queue at the source database to the queue at the destination database.
    

  • 

    At the destination database, an apply process with a system-generated name dequeues the changes from the queue and applies them to the tables at the destination database.
    











Examples That Configure Two-Database Replication with Downstream Capture


Each of the following examples configures a two-database replication environment that uses a downstream capture process:






Configuring Tablespace Replication with Downstream Capture at Destination


You can use the following procedures in the DBMS_STREAMS_ADM package to configure tablespace replication:



You can use the MAINTAIN_SIMPLE_TTS procedure to configure Oracle Streams replication for a simple tablespace, and you can use the MAINTAIN_TTS procedure to configure Oracle Streams replication for a set of self-contained tablespaces. These procedures use transportable tablespaces, Data Pump, the DBMS_STREAMS_TABLESPACE_ADM package, and the DBMS_FILE_TRANSFER package to configure the environment.


A self-contained tablespace has no references from the tablespace pointing outside of the tablespace. For example, if an index in the tablespace is for a table in a different tablespace, then the tablespace is not self-contained. A simple tablespace is a self-contained tablespace that uses only one data file. When there are multiple tablespaces in a tablespace set, a self-contained tablespace set has no references from inside the set of tablespaces pointing outside of the set of tablespaces.


These procedures clone the tablespace or tablespaces being configured for replication from the source database to the destination database. The MAINTAIN_SIMPLE_TTS procedure uses the CLONE_SIMPLE_TABLESPACE procedure in the DBMS_STREAMS_TABLESPACE_ADM package, and the MAINTAIN_TTS procedure uses the CLONE_TABLESPACES procedure in the DBMS_STREAMS_TABLESPACE_ADM package. When a tablespace is cloned, it is made read-only automatically until the clone operation is complete.


The example in this section uses the MAINTAIN_TTS procedure to configure an Oracle Streams replication environment that maintains the following tablespaces using Oracle Streams:


  • 

    tbs1
    

  • 

    tbs2
    



The source database is dbs1.example.com, and the destination database is dbs2.example.com.


The following table lists the decisions that were made about the Oracle Streams replication environment configured in this example.




DecisionAssumption for This Example
Decide Which Type of Replication Environment to Configure
This example configures one-way replication in a two database environment where the source database is read/write and the destination database is read-only.
Decide Whether to Configure Local or Downstream Capture for the Source Database
This example configures a downstream capture process running on the destination database (dbs2.example.com) that captures changes made to the source database (dbs1.example.com). The downstream capture process will be an archived-log downstream capture process.
Decide Whether Changes Are Allowed at One Database or at Multiple Databases
This example configures a replication environment that allows changes only at the source database.
Decide Whether the Replication Environment Will Have Nonidentical Replicas
This example configures identical shared database objects at the databases.
Decide Whether the Replication Environment Will Use Apply Handlers
This example does not configure apply handlers.
Decide Whether to Maintain DDL Changes
This example maintains DDL changes to the tablespaces and the database objects in the tablespaces.
Decide How to Configure the Replication Environment
This example uses the MAINTAIN_TTS procedure to configure the environment.





In this example, the MAINTAIN_TTS procedure will configure the replication environment directly. A configuration script will not be generated. In addition, this example makes the following assumptions:


  • 

    The tablespaces tbs1 and tbs2 make a self-contained tablespace set at the source database dbs1.example.com.
    

  • 

    The data files for the tablespace set are both in the /orc/dbs directory at the source database dbs1.example.com.
    

  • 

    The dbs2.example.com database does not contain the tablespace set currently.
    



The MAINTAIN_SIMPLE_TTS and MAINTAIN_TTS procedures automatically exclude database objects that are not supported by Oracle Streams from the replication environment by adding rules to the negative rule set of each capture and apply process. The PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures enable you to specify which database objects to exclude from the replication environment.


Query the DBA_STREAMS_UNSUPPORTED data dictionary view to determine which database objects are not supported by Oracle Streams. If unsupported database objects are not excluded, then capture errors will result.


Figure 2-4 provides an overview of the replication environment created in this example.




Figure 2-4 Sample Oracle Streams Environment That Replicates Tablespaces

Description of Figure 2-4 follows

Description of "Figure 2-4 Sample Oracle Streams Environment That Replicates Tablespaces"












See Also:

Oracle Streams Concepts and Administration for instructions on determining which database objects are not supported by Oracle Streams






Complete the following steps to use the MAINTAIN_TTS procedure to configure the environment:


  1. 

    Complete the required tasks before running the MAINTAIN_TTS procedure. See "Tasks to Complete Before Configuring Oracle Streams Replication" for instructions.
    

    For this configuration, the following tasks must be completed:
    


  2. 

    Create the following required directory objects:
    

    • 

      A source directory object at the source database. This example assumes that this directory object is source_directory.
      

    • 

      A destination directory object at the destination database. This example assumes that this directory object is dest_directory.
      

    

    See "Creating the Required Directory Objects" for instructions.
    

  3. 

    In SQL*Plus, connect to the database that contains the tablespace set as the Oracle Streams administrator. In this example, connect to the dbs1.example.com database.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  4. 

    Create a directory object for the directory that contains the data files for the tablespaces in the tablespace set. For example, the following statement creates a directory object named tbs_directory that corresponds to the /orc/dbs directory:
    

    CREATE DIRECTORY tbs_directory AS '/orc/dbs';

    

    If the data files are in multiple directories, then a directory object must exist for each of these directories, and the user who runs the MAINTAIN_TTS procedure in Step 6 must have READ privilege on these directory objects. In this example, the Oracle Streams administrator has this privilege because this user creates the directory object.
    

  5. 

    In SQL*Plus, connect to the destination database dbs2.example.com as the Oracle Streams administrator.
    

  6. 

    Run the MAINTAIN_TTS procedure:
    

    DECLARE
  t_names  DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
  -- Tablespace names
  t_names(1) := 'TBS1';
  t_names(2) := 'TBS2';
  DBMS_STREAMS_ADM.MAINTAIN_TTS(
     tablespace_names             => t_names,
     source_directory_object      => 'source_directory',
     destination_directory_object => 'dest_directory',
     source_database              => 'dbs1.example.com',
     destination_database         => 'dbs2.example.com',
     perform_actions              => TRUE,
     capture_name                 => 'capture_tts',
     capture_queue_table          => 'streams_queue_table',
     capture_queue_name           => 'streams_queue',
     apply_name                   => 'apply_tts',
     apply_queue_table            => 'streams_queue_table',
     apply_queue_name             => 'streams_queue');
     bi_directional               => FALSE,
     include_ddl                  => TRUE);
END;
/

    

    When this procedure completes, the Oracle Streams single-source replication environment is configured.
    

    Because the procedure is run at the destination database, downstream capture is configured at the destination database for changes to the source database. When you use a configuration procedure to configure downstream capture, the parameters that specify the queue and queue table names are important. In such a configuration, it is more efficient for the capture process and apply process to use the same queue at the downstream capture database to avoid propagating changes between queues. To improve efficiency in this sample configuration, notice that streams_queue is specified for both the capture_queue_name and apply_queue_name parameters. Also, streams_queue_table is specified for both the capture_queue_table and apply_queue_table parameters.
    

    To monitor the progress of the configuration operation, follow the instructions in "Monitoring Oracle Streams Configuration Progress".
    

    If this procedure encounters an error and stops, then see "Recovering from Operation Errors" for information about either recovering from the error or rolling back the configuration operation.
    



The resulting single-source replication environment has the following characteristics:


  • 

    Supplemental logging is configured for the shared database objects at the source database dbs1.example.com.
    

  • 

    The dbs1.example.com database has a queue named streams_queue which uses a queue table named streams_queue_table. This queue is for the apply process.
    

  • 

    The dbs2.example.com database has a queue named streams_queue which uses a queue table named streams_queue_table. This queue is shared by the downstream capture process and the apply process.
    

  • 

    At the dbs2.example.com database, an archived-log downstream capture process named capture_tts captures changes made to the source database. Specifically, this downstream capture process captures DML changes made to the tables in the tbs1 and tbs2 tablespaces and DDL changes to these tablespaces and the database objects in them.
    

    If the capture process is not enabled after an inordinately long time, then check the alert log for errors. See Oracle Streams Concepts and Administration for more information.
    

  • 

    At the dbs2.example.com database, an apply process named apply_tts dequeues the changes from its queue and applies them to the shared database objects.
    









Configuring Schema Replication with Downstream Capture at Destination


This example configures an Oracle Streams replication environment that replicates data manipulation language (DML) changes to all of the tables in the hr schema. This example configures a two-database replication environment with a downstream capture process at the destination database. This example uses the global database names src.example.com and dest.example.com. However, you can substitute databases in your environment to complete the example. See "Decide Which Type of Replication Environment to Configure" for more information about two-database replication environments.


In this example, the downstream capture process runs on the destination database dest.example.com. Therefore, the resources required to capture changes are freed at the source database src.example.com. This example configures a real-time downstream capture process, not an archived-log downstream capture process. The advantage of real-time downstream capture is that it reduces the amount of time required to capture the changes made at the source database. The time is reduced because the real-time downstream capture process does not need to wait for the redo log file to be archived before it can capture data from it.


The following table lists the decisions that were made about the Oracle Streams replication environment configured in this example.




DecisionAssumption for This Example
Decide Which Type of Replication Environment to Configure
This example configures one-way replication in a two database environment where the source database is read/write and the destination database is read-only.
Decide Whether to Configure Local or Downstream Capture for the Source Database
This example configures a downstream capture process running on the destination database (dest.example.com) that captures changes made to the source database (src.example.com). The downstream capture process will be a real-time downstream capture process.
Decide Whether Changes Are Allowed at One Database or at Multiple Databases
This example configures a replication environment that allows changes only at the source database.
Decide Whether the Replication Environment Will Have Nonidentical Replicas
This example configures identical shared database objects at the databases.
Decide Whether the Replication Environment Will Use Apply Handlers
This example does not configure apply handlers.
Decide Whether to Maintain DDL Changes
This example maintains DDL changes to the tablespaces and the database objects in the tablespaces.
Decide How to Configure the Replication Environment
This example uses the MAINTAIN_SCHEMAS procedure to configure the environment.





The database objects being configured for replication might or might not exist at the destination database when you run the MAINTAIN_SCHEMAS procedure. If the database objects do not exist at the destination database, then the MAINTAIN_SCHEMAS procedure instantiates them at the destination database using a Data Pump export/import. During instantiation, the instantiation SCN is set for these database objects. If the database objects already exist at the destination database, then the MAINTAIN_SCHEMAS procedure retains the existing database objects and sets the instantiation SCN for them. In this example, the hr schema exists at both the src.example.com database and the dest.example.com database before the MAINTAIN_SCHEMAS procedure is run.


In this example, the MAINTAIN_SCHEMAS procedure will configure the replication environment directly. A configuration script will not be generated. A Data Pump export dump file instantiation will be performed.


Figure 2-5 provides an overview of the environment created in this example.




Figure 2-5 Two-Database Replication Environment with a Downstream Capture Process

Description of Figure 2-5 follows

Description of "Figure 2-5 Two-Database Replication Environment with a Downstream Capture Process"





Complete the following steps to use the MAINTAIN_SCHEMAS procedure to configure the environment:


  1. 

    Complete the following tasks to prepare for the two-database replication environment:
    

    1. 

      Configure network connectivity so that the src.example.com database and the dest.example.com database can communicate with each other.
      

      See Oracle Database 2 Day DBA for information about configuring network connectivity between databases.
      

    2. 

      Configure an Oracle Streams administrator at each database that will participate in the replication environment. See "Configuring an Oracle Streams Administrator on All Databases" for instructions. This example assumes that the Oracle Streams administrator is strmadmin.
      

    3. 

      Create a database link from the source database to the destination database and from the destination database to the source database. In this example, create the following database links:
      

      • 

        From the src.example.com database to the dest.example.com database. Both the name and the service name of the database link must be dest.example.com.
        

      • 

        From the dest.example.com database to the src.example.com database. Both the name and the service name of the database link must be src.example.com.
        

      

      The database link from the dest.example.com database to the src.example.com database is necessary because the src.example.com database is the source database for the downstream capture process at the dest.example.com database. This database link simplifies the creation and configuration of the capture process.
      

      Each database link should be created in the Oracle Streams administrator's schema. Also, each database link should connect to the Oracle Streams administrator at the other database. See "Configuring Network Connectivity and Database Links" for instructions.
      

    4. 

      Set initialization parameters properly at each database that will participate in the Oracle Streams replication environment. See "Setting Initialization Parameters Relevant to Oracle Streams" for instructions.
      

    5. 

      Configure both databases to run in ARCHIVELOG mode. For a downstream capture process to capture changes generated at a source database, both the source database and the downstream capture database must be running in ARCHIVELOG mode. In this example, the src.example.com and dest.example.com databases must be running in ARCHIVELOG mode. See Oracle Database Administrator's Guide for information about configuring a database to run in ARCHIVELOG mode.
      

    6. 

      Because the destination database (dest.example.com) will be the capture database for changes made to the source database, configure log file copying from the source database src.example.com to the destination database dest.example.com. See "Configuring Log File Transfer to a Downstream Capture Database".
      

    7. 

      Because this example configures a real-time downstream capture process, add standby redo logs at the downstream database. See "Adding Standby Redo Logs for Real-Time Downstream Capture".
      

    

  2. 

    Create the following required directory objects:
    

    • 

      A source directory object at the source database. This example assumes that this directory object is source_directory.
      

    • 

      A destination directory object at the destination database. This example assumes that this directory object is dest_directory.
      

    

    See "Creating the Required Directory Objects" for instructions.
    

  3. 

    In SQL*Plus, connect to the dest.example.com database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
    

  4. 

    While still connected to the dest.example.com database as the Oracle Streams administrator, run the MAINTAIN_SCHEMAS procedure to configure replication between the src.example.com database and the dest.example.com database:
    

    BEGIN
  DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
    schema_names                 => 'hr',
    source_directory_object      => 'source_directory',
    destination_directory_object => 'dest_directory',
    source_database              => 'src.example.com',
    destination_database         => 'dest.example.com',
    capture_name                 => 'capture',
    capture_queue_table          => 'streams_queue_qt',
    capture_queue_name           => 'streams_queue',
    apply_name                   => 'apply',
    apply_queue_table            => 'streams_queue_qt',
    apply_queue_name             => 'streams_queue');
END;
/

    

    The MAINTAIN_SCHEMAS procedure can take some time to run because it is performing many configuration tasks. Do not allow data manipulation language (DML) or data definition language (DDL) changes to the replicated database objects at the destination database while the procedure is running.
    

    In the MAINTAIN_SCHEMAS procedure, only the following parameters are required: schema_names, source_directory_object, destination_directory_object, source_database, and destination_database.
    

    This example specifies the other parameters to show that you can choose the name for the capture process, capture process's queue table, capture process's queue, apply process, apply process's queue table, and apply process's queue. If you do not specify these parameters, then system-generated names are used.
    

    When you use a configuration procedure to configure downstream capture, the parameters that specify the queue and queue table names are important. In such a configuration, it is more efficient for the capture process and apply process to use the same queue at the downstream capture database to avoid propagating changes between queues. To improve efficiency in this sample configuration, notice that streams_queue is specified for both the capture_queue_name and apply_queue_name parameters. Also, streams_queue_qt is specified for both the capture_queue_table and apply_queue_table parameters.
    

    When a configuration procedure is run, information about its progress is recorded in the following data dictionary views: DBA_RECOVERABLE_SCRIPT, DBA_RECOVERABLE_SCRIPT_PARAMS, DBA_RECOVERABLE_SCRIPT_BLOCKS, and DBA_RECOVERABLE_SCRIPT_ERRORS. If the procedure stops because it encounters an error, then see Oracle Streams Replication Administrator's Guide for instructions about using the RECOVER_OPERATION procedure in the DBMS_STREAMS_ADM package to recover from these errors.
    

    Wait until the procedure completes successfully before proceeding to the next step.
    

  5. 

    While still connected to the dest.example.com database as the Oracle Streams administrator, set the downstream_real_time_mine capture process parameter to Y:
    

    BEGIN
  DBMS_CAPTURE_ADM.SET_PARAMETER(
    capture_name => 'capture',
    parameter    => 'downstream_real_time_mine',
    value        => 'Y');
END;
/

  6. 

    In SQL*Plus, connect to the source database src.example.com as an administrative user.
    

  7. 

    Archive the current log file at the source database:
    

    ALTER SYSTEM ARCHIVE LOG CURRENT;

    

    Archiving the current log file at the source database starts real-time mining of the source database redo log.
    

    If the capture process appears to be waiting for redo data for an inordinately long time, then check the alert log for errors. See Oracle Streams Concepts and Administration for more information.
    










See Also:

Oracle Database 2 Day + Data Replication and Integration Guide for an example that configures this replication environment using Oracle Enterprise Manager












Configuring Schema Replication with Downstream Capture at Third Database


You can use the MAINTAIN_SCHEMAS procedure in the DBMS_STREAMS_ADM package to configure schema replication. The example in this section uses this procedure to configure an Oracle Streams replication environment that maintains the hr schema. The source database is dbs1.example.com, and the destination database is dbs3.example.com.


The following table lists the decisions that were made about the Oracle Streams replication environment configured in this example.




DecisionAssumption for This Example
Decide Which Type of Replication Environment to Configure
This example configures bi-directional replication in a two database environment where both databases are read/write.
Decide Whether to Configure Local or Downstream Capture for the Source Database
This example configures a downstream capture process running on a third database named dbs2.example.com that captures changes made to the source database (dbs1.example.com), and a propagation at dbs2.example.com will propagate these captured changes to the destination database (dbs3.example.com). The downstream capture process will be a real-time downstream capture process.
Decide Whether Changes Are Allowed at One Database or at Multiple Databases
This example configures a replication environment that allows changes to the replicated database objects at both databases.
Decide Whether the Replication Environment Will Have Nonidentical Replicas
This example configures identical shared database objects at the databases.
Decide Whether the Replication Environment Will Use Apply Handlers
This example does not configure apply handlers.
Decide Whether to Maintain DDL Changes
This example maintains DDL changes to hr schema and the database objects in the hr schema will be maintained.
Decide How to Configure the Replication Environment
This example uses the MAINTAIN_SCHEMAS procedure to configure the environment.





In this example, the MAINTAIN_SCHEMAS procedure will configure the replication environment directly. A configuration script will not be generated. A Data Pump export dump file instantiation will be performed.


The MAINTAIN_SCHEMAS procedure automatically excludes database objects that are not supported by Oracle Streams from the replication environment by adding rules to the negative rule set of each capture and apply process. Query the DBA_STREAMS_UNSUPPORTED data dictionary view to determine which database objects are not supported by Oracle Streams. If unsupported database objects are not excluded, then capture errors will result.


Figure 2-6 provides an overview of the replication environment created in this example.




Figure 2-6 Sample Oracle Streams Environment That Replicates a Schema

Description of Figure 2-6 follows

Description of "Figure 2-6 Sample Oracle Streams Environment That Replicates a Schema"












See Also:

Oracle Streams Concepts and Administration for instructions on determining which database objects are not supported by Oracle Streams






Complete the following steps to use the MAINTAIN_SCHEMAS procedure to configure the environment:


  1. 

    Complete the required tasks before running the MAINTAIN_SCHEMAS procedure. See "Tasks to Complete Before Configuring Oracle Streams Replication" for instructions.
    

    For this configuration, the following tasks must be completed:
    

    • 

      Configure an Oracle Streams administrator at all three databases. See "Configuring an Oracle Streams Administrator on All Databases".
      

    • 

      Configure network connectivity and database links:
      

      • 

        Configure network connectivity between all three databases: the source database dbs1.example.com, the destination database dbs3.example.com, and the third database dbs2.example.com.
        

      • 

        Create a database link from the source database dbs1.example.com to the destination database dbs3.example.com.
        

      • 

        Because downstream capture will be configured at the third database, create a database link from the third database dbs2.example.com to the source database dbs1.example.com.
        

      • 

        Because downstream capture will be configured at the third database, create a database link from the third database dbs2.example.com to the destination database dbs3.example.com.
        

      • 

        Because the replication environment will be bi-directional, create a database link from the destination database dbs3.example.com to the source database dbs1.example.com.
        

      

      See "Configuring Network Connectivity and Database Links".
      

    • 

      Ensure that the source database, the destination databases, and the third database are in ARCHIVELOG mode. See "Ensuring That Each Source Database Is In ARCHIVELOG Mode".
      

    • 

      Ensure that the initialization parameters are set properly at all databases. See "Setting Initialization Parameters Relevant to Oracle Streams".
      

    • 

      Configure the Oracle Streams pool properly at both databases. See "Configuring the Oracle Streams Pool".
      

    • 

      Because a third database (dbs2.example.com) will be the capture database for changes made to the source database, configure log file copying from the source database dbs1.example.com to the third database dbs2.example.com. See "Configuring Log File Transfer to a Downstream Capture Database".
      

    • 

      Because this example configures a real-time downstream capture process, add standby redo logs at the downstream database (dbs2.example.com). See "Adding Standby Redo Logs for Real-Time Downstream Capture".
      

    

  2. 

    Create the following required directory objects:
    

    • 

      A source directory object at the source database. This example assumes that this directory object is source_directory.
      

    • 

      A destination directory object at the destination database. This example assumes that this directory object is dest_directory.
      

    

    See "Creating the Required Directory Objects" for instructions.
    

  3. 

    In SQL*Plus, connect to the third database dbs2.example.com as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  4. 

    Run the MAINTAIN_SCHEMAS procedure:
    

    BEGIN
  DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
    schema_names                 => 'hr',
    source_directory_object      => 'source_directory',
    destination_directory_object => 'dest_directory',
    source_database              => 'dbs1.example.com',
    destination_database         => 'dbs3.example.com',
    perform_actions              => TRUE,
    dump_file_name               => 'export_hr.dmp',
    capture_queue_table          => 'rep_capture_queue_table',
    capture_queue_name           => 'rep_capture_queue',
    capture_queue_user           => NULL,
    apply_queue_table            => 'rep_dest_queue_table',
    apply_queue_name             => 'rep_dest_queue',
j,    apply_queue_user             => NULL,
    capture_name                 => 'capture_hr',
    propagation_name             => 'prop_hr',
    apply_name                   => 'apply_hr',
    log_file                     => 'export_hr.clg',
    bi_directional               => TRUE,
    include_ddl                  => TRUE,
    instantiation                => DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA);
END;
/

    

    Because this procedure configures a bi-directional replication environment, do not allow DML or DDL changes to the shared database objects at the destination database while the procedure is running.
    

    Because the procedure is run at the third database, downstream capture is configured at the third database for changes to the source database.
    

    To monitor the progress of the configuration operation, follow the instructions in "Monitoring Oracle Streams Configuration Progress".
    

    If this procedure encounters an error and stops, then see "Recovering from Operation Errors" for information about either recovering from the error or rolling back the configuration operation.
    

  5. 

    Set the downstream_real_time_mine capture process parameter to Y:
    

    BEGIN
  DBMS_CAPTURE_ADM.SET_PARAMETER(
    capture_name => 'capture_hr',
    parameter    => 'downstream_real_time_mine',
    value        => 'Y');
END;
/

  6. 

    Connect to the source database dbs1.example.com as an administrative user with the necessary privileges to switch log files.
    

  7. 

    Archive the current log file at the source database:
    

    ALTER SYSTEM ARCHIVE LOG CURRENT;

    

    Archiving the current log file at the source database starts real time mining of the source database redo log.
    

    If the capture process appears to be waiting for redo data for an inordinately long time, then check the alert log for errors. See Oracle Streams Concepts and Administration for more information.
    

  8. 

    Configure conflict resolution for the shared database objects if necessary.
    

    Typically, conflicts are possible in a bi-directional replication environment. If conflicts are possible in the environment created by the MAINTAIN_SCHEMAS procedure, then configure conflict resolution before you allow users to make changes to the shared database objects.
    

    See Chapter 9, "Oracle Streams Conflict Resolution" for information.
    



The bi-directional replication environment configured in this example has the following characteristics:


  • 

    Supplemental logging is configured for the shared database objects at the source and destination databases.
    

  • 

    The dbs1.example.com database has a queue named rep_dest_queue which uses a queue table named rep_dest_queue_table. This queue is for the apply process.
    

  • 

    The dbs3.example.com database has a queue named rep_capture_queue which uses a queue table named rep_capture_queue_table. This queue is for the local capture process.
    

  • 

    The dbs3.example.com database has a queue named rep_dest_queue which uses a queue table named rep_dest_queue_table. This queue is for the apply process.
    

  • 

    The dbs2.example.com database has a queue named rep_capture_queue which uses a queue table named rep_capture_queue_table. This queue is for the downstream capture process.
    

  • 

    At the dbs2.example.com database, a real-time downstream capture process named capture_hr captures DML and DDL changes to the hr schema and the database objects in the schema at the source database.
    

  • 

    At the dbs3.example.com database, a local capture process named capture_hr captures DML and DDL changes to the hr schema and the database objects in the schema at the destination database.
    

  • 

    A propagation running on the dbs2.example.com database named prop_hr sends the captured changes from the queue in the dbs2.example.com database to the queue in the dbs3.example.com database.
    

  • 

    A propagation running on the dbs3.example.com database named prop_hr sends the captured changes from the queue in the dbs3.example.com database to the queue in the dbs1.example.com database.
    

  • 

    At the dbs1.example.com database, an apply process named apply_hr dequeues the changes from rep_dest_queue and applies them to the database objects.
    

  • 

    At the dbs3.example.com database, an apply process named apply_hr dequeues the changes from rep_dest_queue and applies them to the database objects.
    

  • 

    Tags are used to avoid change cycling. Specifically, each apply process uses an apply tag so that redo records for changes applied by the apply process include the tag. Each apply process uses an apply tag that is unique in the replication environment. Each propagation discards changes that have the tag of the apply process running on the same database. See "Change Cycling and Tags" for more information.
    











Example That Configures Hub-and-Spoke Replication


This example configures an Oracle Streams hub-and-spoke replication environment that replicates data manipulation language (DML) changes to all of the tables in the hr schema. This example uses a capture process at each database to capture these changes. Hub-and-spoke replication means that a central hub database replicates changes with one or more spoke databases. The spoke databases do not communicate with each other directly. In this sample configuration, the hub database sends changes generated at one spoke database to the other spoke database.


In this example, the global name of the hub database is hub.example.com, and the global names of the spoke databases are spoke1.example.com and spoke2.example.com. However, you can substitute databases in your environment to complete the example.


The following table lists the decisions that were made about the Oracle Streams replication environment configured in this example.




DecisionAssumption for This Example
Decide Which Type of Replication Environment to Configure
This example configures a hub-and-spoke replication environment in which the global name of the hub database is hub.example.com, and the global names of the spoke databases are spoke1.example.com and spoke2.example.com. All of the databases in the environment are read/write.
Decide Whether to Configure Local or Downstream Capture for the Source Database
This example configures local capture at each database.
Decide Whether Changes Are Allowed at One Database or at Multiple Databases
This example configures a replication environment that allows changes to the replicated database objects at all three databases.
Decide Whether the Replication Environment Will Have Nonidentical Replicas
This example configures identical shared database objects at the databases.
Decide Whether the Replication Environment Will Use Apply Handlers
This example does not configure apply handlers.
Decide Whether to Maintain DDL Changes
This example does not maintain DDL changes to the shared database objects.
Decide How to Configure the Replication Environment
This example uses the MAINTAIN_SCHEMAS procedure to configure the environment.





In this example, the MAINTAIN_SCHEMAS procedure will configure the replication environment directly. A configuration script will not be generated. A Data Pump export dump file instantiation will be performed.


The MAINTAIN_SCHEMAS procedure automatically excludes database objects that are not supported by Oracle Streams from the replication environment by adding rules to the negative rule set of each capture and apply process. Query the DBA_STREAMS_UNSUPPORTED data dictionary view to determine which database objects are not supported by Oracle Streams. If unsupported database objects are not excluded, then capture errors will result.


The database objects being configured for replication might or might not exist at the destination databases when you run the MAINTAIN_SCHEMAS procedure. If the database objects do not exist at a destination database, then the MAINTAIN_SCHEMAS procedure instantiates them at the destination database using a Data Pump export/import. During instantiation, the instantiation SCN is set for these database objects. If the database objects already exist at a destination database, then the MAINTAIN_SCHEMAS procedure retains the existing database objects and sets the instantiation SCN for them. In this example, the hr schema exists at each database before the MAINTAIN_SCHEMAS procedure is run.


Figure 2-7 provides an overview of the environment created in this example.




Figure 2-7 Hub-and-Spoke Environment with Capture Processes and Read/Write Spokes

Description of Figure 2-7 follows

Description of "Figure 2-7 Hub-and-Spoke Environment with Capture Processes and Read/Write Spokes"





Complete the following steps to use the MAINTAIN_SCHEMAS procedure to configure the environment:


  1. 

    Complete the following tasks to prepare for the hub-and-spoke replication environment:
    

    1. 

      Configure network connectivity so that the following databases can communicate with each other:
      

      • 

        The hub.example.com database and the spoke1.example.com database
        

      • 

        The hub.example.com database and the spoke2.example.com database
        

      

      See Oracle Database 2 Day DBA for information about configuring network connectivity between databases.
      

    2. 

      Configure an Oracle Streams administrator at each database that will participate in the replication environment. See "Configuring an Oracle Streams Administrator on All Databases" for instructions. This example assumes that the Oracle Streams administrator is strmadmin.
      

    3. 

      Create a database link from the hub database to each spoke database and from each spoke database to the hub database. In this example, create the following database links:
      

      • 

        From the hub.example.com database to the spoke1.example.com database. Both the name and the service name of the database link must be spoke1.example.com.
        

      • 

        From the hub.example.com database to the spoke2.example.com database. Both the name and the service name of the database link must be spoke2.example.com.
        

      • 

        From the spoke1.example.com database to the hub.example.com database. Both the name and the service name of the database link must be hub.example.com.
        

      • 

        From the spoke2.example.com database to the hub.example.com database. Both the name and the service name of the database link must be hub.example.com.
        

      

      Each database link should be created in the Oracle Streams administrator's schema. Also, each database link should connect to the Oracle Streams administrator at the destination database. See "Configuring Network Connectivity and Database Links" for instructions.
      

    4. 

      Set initialization parameters properly at each database that will participate in the Oracle Streams replication environment. See "Setting Initialization Parameters Relevant to Oracle Streams" for instructions.
      

    5. 

      Configure each source database to run in ARCHIVELOG mode. For a capture process to capture changes generated at a source database, the source database must be running in ARCHIVELOG mode. In this example, all databases must be running in ARCHIVELOG mode. See Oracle Database Administrator's Guide for information about configuring a database to run in ARCHIVELOG mode.
      

    

  2. 

    Create the following required directory objects:
    

    • 

      A directory object at the hub database hub.example.com. This example assumes that this directory object is hub_directory.
      

    • 

      A directory object at the spoke database spoke1.example.com. This example assumes that this directory object is spoke1_directory.
      

    • 

      A directory object at the spoke database spoke2.example.com. This example assumes that this directory object is spoke2_directory.
      

    

    See "Creating the Required Directory Objects" for instructions.
    

  3. 

    In SQL*Plus, connect to the hub.example.com database as the Oracle Streams administrator.
    

    See Oracle Database 2 Day DBA for more information about starting SQL*Plus.
    

  4. 

    Run the MAINTAIN_SCHEMAS procedure to configure replication between the hub.example.com database and the spoke1.example.com database:
    

    BEGIN
  DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
    schema_names                 => 'hr',
    source_directory_object      => 'hub_directory',
    destination_directory_object => 'spoke1_directory',
    source_database              => 'hub.example.com',
    destination_database         => 'spoke1.example.com',
    capture_name                 => 'capture_hns',
    capture_queue_table          => 'source_hns_qt',
    capture_queue_name           => 'source_hns',
    propagation_name             => 'propagation_spoke1',
    apply_name                   => 'apply_spoke1',
    apply_queue_table            => 'destination_spoke1_qt',
    apply_queue_name             => 'destination_spoke1',
    bi_directional               => TRUE);
END;
/

    

    The MAINTAIN_SCHEMAS procedure can take some time to run because it is performing many configuration tasks. Do not allow data manipulation language (DML) or data definition language (DDL) changes to the replicated database objects at the destination database while the procedure is running.
    

    In the MAINTAIN_SCHEMAS procedure, only the following parameters are required: schema_names, source_directory_object, destination_directory_object, source_database, and destination_database. Also, when you use a configuration procedure to configure bi-directional replication, the bi_directional parameter must be set to TRUE.
    

    This example specifies the other parameters to show that you can choose the name for the capture process, capture process's queue table, capture process's queue, propagation, apply process, apply process's queue table, and apply process's queue. If you do not specify these parameters, then system-generated names are used.
    

    When a configuration procedure is run, information about its progress is recorded in the following data dictionary views: DBA_RECOVERABLE_SCRIPT, DBA_RECOVERABLE_SCRIPT_PARAMS, DBA_RECOVERABLE_SCRIPT_BLOCKS, and DBA_RECOVERABLE_SCRIPT_ERRORS. If the procedure stops because it encounters an error, then see Oracle Streams Replication Administrator's Guide for instructions about using the RECOVER_OPERATION procedure in the DBMS_STREAMS_ADM package to recover from these errors.
    

  5. 

    While still connected in SQL*Plus to the hub.example.com database as the Oracle Streams administrator, run the MAINTAIN_SCHEMAS procedure to configure replication between the hub.example.com database and the spoke2.example.com database:
    

    BEGIN
  DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
    schema_names                 => 'hr',
    source_directory_object      => 'hub_directory',
    destination_directory_object => 'spoke2_directory',
    source_database              => 'hub.example.com',
    destination_database         => 'spoke2.example.com',
    capture_name                 => 'capture_hns',
    capture_queue_table          => 'source_hns_qt',
    capture_queue_name           => 'source_hns',
    propagation_name             => 'propagation_spoke2',
    apply_name                   => 'apply_spoke2',
    apply_queue_table            => 'destination_spoke2_qt',
    apply_queue_name             => 'destination_spoke2',
    bi_directional               => TRUE);
END;
/

  6. 

    Configure latest time conflict resolution for all of the tables in the hr schema at the hub.example.com, spoke1.example.com, and spoke2.example.com databases. This schema includes the countries, departments, employees, jobs, job_history, locations, and regions tables. See Chapter 9, "Oracle Streams Conflict Resolution" for instructions.
    










See Also:

Oracle Database 2 Day + Data Replication and Integration Guide for an example that configures this replication environment using Oracle Enterprise Manager












Monitoring Oracle Streams Configuration Progress


The following procedures in the DBMS_STREAMS_ADM package configure a replication environment that is maintained by Oracle Streams:



While one of these procedures configures the replication environment directly (with the perform_actions parameter is set to TRUE), you can monitor the progress of the configuration in a separate terminal window.


Complete the following steps to monitor the progress of the Oracle Stream configuration:


  1. 

    In SQL*Plus, connect to the capture database as the Oracle Streams administrator. Use a different terminal window than the one that is running the configuration procedure.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    For basic information about the configuration operation, run the following query:
    

    COLUMN SCRIPT_ID      HEADING 'Script ID'      FORMAT A40
COLUMN CREATION_TIME  HEADING 'Creation|Time'  FORMAT A20

SELECT SCRIPT_ID,
  TO_CHAR(CREATION_TIME,'HH24:Mi:SS MM/DD/YY') CREATION_TIME
  FROM DBA_RECOVERABLE_SCRIPT;

    

    Your output is similar to the following:
    

                                             Creation
Script ID                                Time
---------------------------------------- --------------------
64EE0DFCC374CE7EE040578C89174D3E         07:46:54 03/12/09

    

    This output shows the script ID for the configuration operation and the time when the operation started.
    

  3. 

    For detailed information about the progress of the configuration operation, run the following query:
    

    COLUMN STATUS           HEADING 'Status'          FORMAT A12
COLUMN PROGRESS         HEADING 'Steps|Completed' FORMAT A10
COLUMN ELAPSED_SECONDS  HEADING 'Elapsed|Seconds' FORMAT A10
COLUMN CURRENT_STEP     HEADING 'Current Step'    FORMAT A20
COLUMN PROCEDURE        HEADING 'Procedure'       FORMAT A20

SELECT  rs.STATUS,
    rs.DONE_BLOCK_NUM||' of '||rs.TOTAL_BLOCKS PROGRESS,
    TO_CHAR(TO_NUMBER(SYSDATE-rs.CREATION_TIME)*86400,9999.99) ELAPSED_SECONDS,
    SUBSTR(TO_CHAR(rsb.FORWARD_BLOCK),1,100) CURRENT_STEP,
    rs.INVOKING_PACKAGE||'.'||rs.INVOKING_PROCEDURE PROCEDURE
  FROM DBA_RECOVERABLE_SCRIPT rs, DBA_RECOVERABLE_SCRIPT_BLOCKS rsb
  WHERE rs.SCRIPT_ID  = rsb.SCRIPT_ID AND 
        rsb.BLOCK_NUM = rs.DONE_BLOCK_NUM + 1;

    

    Your output is similar to the following:
    

                 Steps      Elapsed
Status       Completed  Seconds    Current Step         Procedure
------------ ---------- ---------- -------------------- --------------------
EXECUTING    7 of 39    132        --                   DBMS_STREAMS_ADM.MAI
                                   -- Set up queue "STR NTAIN_SCHEMAS
                                   MADMIN"."PROD$APPQ"
                                   --
                                   BEGIN
                                     dbms_streams_adm.s
                                   et_up_queue(
                                       queue_ta

    

    This output shows the following information about the configuration operation:
    

    • 

      The current status of the configuration operation, either GENERATING, NOT EXECUTED, EXECUTING, EXECUTED, or ERROR
      

    • 

      The number of steps completed and the total number of steps required to complete the operation
      

    • 

      The amount of time, in seconds, that the configuration operation has been running
      

    • 

      The operation being performed by the current step
      

    • 

      The PL/SQL procedure being executed in the current step
      

    












PKPK+AOEBPS/instant.htm

Instantiation and Oracle Streams Replication



8 Instantiation and Oracle Streams Replication


This chapter contains conceptual information about instantiation and Oracle Streams replication. It also contains instructions for preparing database objects for instantiation, performing instantiations, setting instantiation system change numbers (SCNs), and monitoring instantiations.


This chapter contains these topics:






Overview of Instantiation and Oracle Streams Replication


In an Oracle Streams environment that replicates a database object within a single database or between multiple databases, a source database is the database where changes to the object are generated, and a destination database is the database where these changes are dequeued by an apply process. If a capture process or synchronous capture captures, or will capture, such changes, and the changes will be applied locally or propagated to other databases and applied at destination databases, then you must instantiate these source database objects before you can replicate changes to the objects. If a database where changes to the source database objects will be applied is a different database than the source database, then the destination database must have a copy of these database objects.


In Oracle Streams, the following general steps instantiate a database object:



  1. 

    Prepare the database object for instantiation at the source database.
    

  2. 

    If a copy of the database object does not exist at the destination database, then create a database object physically at the destination database based on a database object at the source database. You can use export/import, transportable tablespaces, or RMAN to copy database objects for instantiation. If the database object already exists at the destination database, then this step is not necessary.
    

  3. 

    Set the instantiation system change number (SCN) for the database object at the destination database. An instantiation SCN instructs an apply process at the destination database to apply only changes that committed at the source database after the specified SCN.
    



All of these instantiation steps can be performed automatically when you use one of the following Oracle-supplied procedures in the DBMS_STREAMS_ADM package that configure replication environments:



In some cases, Step 1 and Step 3 are completed automatically. For example, when you add rules for a database object to the positive rule set of a capture process by running a procedure in the DBMS_STREAMS_ADM package, the database object is prepared for instantiation automatically.


Also, when you use export/import, transportable tablespaces, or the RMAN TRANSPORT TABLESPACE command to copy database objects from a source database to a destination database, instantiation SCNs can be set for these database objects automatically.









Note:

The RMAN DUPLICATE command can instantiate an entire database, but this command does not set instantiation SCNs for database objects.






If the database object being instantiated is a table, then the tables at the source and destination database do not need to be an exact match. However, if some or all of the table data is replicated between the two databases, then the data that is replicated should be consistent when the table is instantiated. Whenever you plan to replicate changes to a database object, you must always prepare the database object for instantiation at the source database and set the instantiation SCN for the database object at the destination database. By preparing an object for instantiation, you are setting the lowest SCN for which changes to the object can be applied at destination databases. This SCN is called the ignore SCN. You should prepare a database object for instantiation after a capture process or synchronous capture has been configured to capture changes to the database object.


When you instantiate tables using export/import, transportable tablespaces, or RMAN, any supplemental log group specifications are retained for the instantiated tables. That is, after instantiation, log group specifications for imported tables at the import database are the same as the log group specifications for these tables at the export database. If you do not want to retain supplemental log group specifications for tables at the import database, then you can drop specific supplemental log groups after import.


Database supplemental logging specifications are not retained during export/import, even if you perform a full database export/import. However, the RMAN DUPLICATE command retains database supplemental logging specifications at the instantiated database.









Note:


  • 

    During an export for an Oracle Streams instantiation, ensure that no data definition language (DDL) changes are made to objects being exported.
    

  • 

    When you export a database or schema that contains rules with non-NULL action contexts, the database or the default tablespace of the schema that owns the rules must be writeable. If the database or tablespace is read-only, then export errors result.
    
















See Also:















Capture Rules and Preparation for Instantiation


The following subprograms in the DBMS_CAPTURE_ADM package prepare database objects for instantiation:


  • 

    The PREPARE_TABLE_INSTANTIATION procedure prepares a single table for instantiation when changes to the table will be captured by a capture process.
    

  • 

    The PREPARE_SYNC_INSTANTIATION function prepares a single table or multiple tables for instantiation when changes to the table or tables will be captured by a synchronous capture.
    

  • 

    The PREPARE_SCHEMA_INSTANTIATION procedure prepares for instantiation all of the database objects in a schema and all database objects added to the schema in the future. This procedure should only be used when changes will be captured by a capture process.
    

  • 

    The PREPARE_GLOBAL_INSTANTIATION procedure prepares for instantiation all of the database objects in a database and all database objects added to the database in the future. This procedure should only be used when changes will be captured by a capture process.
    



These procedures record the lowest system change number (SCN) of each object for instantiation. SCNs after the lowest SCN for an object can be used for instantiating the object.


If you use a capture process to capture changes, then these procedures also populate the Oracle Streams data dictionary for the relevant capture processes, propagations, and apply processes that capture, propagate, or apply changes made to the table, schema, or database being prepared for instantiation. In addition, if you use a capture process to capture changes, then these procedures optionally can enable supplemental logging for key columns or all columns in the tables that are being prepared for instantiation.









Note:

Replication with synchronous capture does not use the Oracle Streams data dictionary and does not require supplemental logging.










DBMS_STREAMS_ADM Package Procedures Automatically Prepare Objects


When you add rules to the positive rule set for a capture process or synchronous capture by running a procedure in the DBMS_STREAMS_ADM package, a procedure or function in the DBMS_CAPTURE_ADM package is run automatically on the database objects where changes will be captured. Table 8-1 lists which procedure or function is run in the DBMS_CAPTURE_ADM package when you run a procedure in the DBMS_STREAMS_ADM package.




Table 8-1 DBMS_CAPTURE_ADM Package Procedures That Are Run Automatically


When you run this procedure in the DBMS_STREAMS_ADM packageThis procedure or function in the DBMS_CAPTURE_ADM package is run automatically


ADD_TABLE_RULES


ADD_SUBSET_RULES



PREPARE_TABLE_INSTANTIATION when rules are added to a capture process rule set


PREPARE_SYNC_INSTANTIATION when rules are added to a synchronous capture rule set




ADD_SCHEMA_RULES



PREPARE_SCHEMA_INSTANTIATION




ADD_GLOBAL_RULES



PREPARE_GLOBAL_INSTANTIATION







Multiple calls to prepare for instantiation are allowed. If you are using downstream capture, and the downstream capture process uses a database link from the downstream database to the source database, then the database objects are prepared for instantiation automatically when you run one of these procedures in the DBMS_STREAMS_ADM package. However, if the downstream capture process does not use a database link from the downstream database to the source database, then you must prepare the database objects for instantiation manually.


When capture process rules are created by the DBMS_RULE_ADM package instead of the DBMS_STREAMS_ADM package, you must run the appropriate procedure manually to prepare each table, schema, or database whose changes will be captured for instantiation, if you plan to apply changes that result from the capture process rules with an apply process.


In addition, some procedures automatically run these procedures. For example, the DBMS_STREAMS_ADM.MAINTAIN_TABLES procedure automatically runs the ADD_TABLE_RULES procedure.









Note:

A synchronous capture only captures changes based on rules created by the ADD_TABLE_RULES or ADD_SUBSET_RULES procedures.













When Preparing for Instantiation Is Required


Whenever you add, or modify the condition of, a capture process, propagation, or apply process rule for a database object that is in a positive rule set, you must run the appropriate procedure to prepare the database object for instantiation at the source database if any of the following conditions are met:


  • 

    One or more rules are added to the positive rule set for a capture process that instruct the capture process to capture changes made to the object.
    

  • 

    One or more conditions of rules in the positive rule set for a capture process are modified to instruct the capture process to capture changes made to the object.
    

  • 

    One or more rules are added to the positive rule set for a propagation that instruct the propagation to propagate changes made to the object.
    

  • 

    One or more conditions of rules in the positive rule set for a propagation are modified to instruct the propagation to propagate changes made to the object.
    

  • 

    One or more rules are added to the positive rule set for an apply process that instruct the apply process to apply changes that were made to the object at the source database.
    

  • 

    One or more conditions of rules in the positive rule set for an apply process are modified to instruct the apply process to apply changes that were made to the object at the source database.
    



Whenever you remove, or modify the condition of, a capture process, propagation, or apply process rule for a database object that is in a negative rule set, you must run the appropriate procedure to prepare the database object for instantiation at the source database if any of the following conditions are met:


  • 

    One or more rules are removed from the negative rule set for a capture process to instruct the capture process to capture changes made to the object.
    

  • 

    One or more conditions of rules in the negative rule set for a capture process are modified to instruct the capture process to capture changes made to the object.
    

  • 

    One or more rules are removed from the negative rule set for a propagation to instruct the propagation to propagate changes made to the object.
    

  • 

    One or more conditions of rules in the negative rule set for a propagation are modified to instruct the propagation to propagate changes made to the object.
    

  • 

    One or more rules are removed from the negative rule set for an apply process to instruct the apply process to apply changes that were made to the object at the source database.
    

  • 

    One or more conditions of rules in the negative rule set for an apply process are modified to instruct the apply process to apply changes that were made to the object at the source database.
    



When any of these conditions are met for changes to a positive or negative rule set, you must prepare the relevant database objects for instantiation at the source database to populate any relevant Oracle Streams data dictionary that requires information about the source object, even if the object already exists at a remote database where the rules were added or changed.


The relevant Oracle Streams data dictionaries are populated asynchronously for both the local dictionary and all remote dictionaries. The procedure that prepares for instantiation adds information to the redo log at the source database. The local Oracle Streams data dictionary is populated with the information about the object when a capture process captures these redo entries, and any remote Oracle Streams data dictionaries are populated when the information is propagated to them.


Synchronous captures do not use Oracle Streams data dictionaries. However, when you are capturing changes to a database object with synchronous capture, you must prepare the database object for instantiation when you add rules for the database object to the synchronous capture rule set. Preparing the database object for instantiation is required when rules are added because it records the lowest SCN for instantiation for the database object. Preparing the database object for instantiation is not required when synchronous capture rules are modified, but modifications cannot change the database object name or schema in the rule condition.









See Also:















Supplemental Logging Options During Preparation for Instantiation


If a replication environment uses a capture process to capture changes, then supplemental logging is required. Supplemental logging places additional column data into a redo log whenever an operation is performed. The procedures in the DBMS_CAPTURE_ADM package that prepare database objects for instantiation include PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, and PREPARE_GLOBAL_INSTANTIATION. These procedures have a supplemental_logging parameter which controls the supplemental logging specifications for the database objects being prepared for instantiation.


Table 8-2 describes the values for the supplemental_logging parameter for each procedure.




Table 8-2 Supplemental Logging Options During Preparation for Instantiation


Proceduresupplemental_logging Parameter SettingDescription


PREPARE_TABLE_INSTANTIATION



keys



The procedure enables supplemental logging for primary key, unique key, bitmap index, and foreign key columns in the table being prepared for instantiation. The procedure places the logged columns for the table in three separate log groups: the primary key columns in an unconditional log group, the unique key columns and bitmap index columns in a conditional log group, and the foreign key columns in a conditional log group.




PREPARE_TABLE_INSTANTIATION



all



The procedure enables supplemental logging for all columns in the table being prepared for instantiation. The procedure places all of the columns for the table in an unconditional log group.




PREPARE_SCHEMA_INSTANTIATION



keys



The procedure enables supplemental logging for primary key, unique key, bitmap index, and foreign key columns in the tables in the schema being prepared for instantiation and for any table added to this schema in the future. Primary key columns are logged unconditionally. Unique key, bitmap index, and foreign key columns are logged conditionally.




PREPARE_SCHEMA_INSTANTIATION



all



The procedure enables supplemental logging for all columns in the tables in the schema being prepared for instantiation and for any table added to this schema in the future. The columns are logged unconditionally.




PREPARE_GLOBAL_INSTANTIATION



keys



The procedure enables database supplemental logging for primary key, unique key, bitmap index, and foreign key columns in the tables in the database being prepared for instantiation and for any table added to the database in the future. Primary key columns are logged unconditionally. Unique key, bitmap index, and foreign key columns are logged conditionally.




PREPARE_GLOBAL_INSTANTIATION



all



The procedure enables supplemental logging for all columns in all of the tables in the database being prepared for instantiation and for any table added to the database in the future. The columns are logged unconditionally.




Any Prepare Procedure



none



The procedure does not enable supplemental logging for any columns in the tables being prepared for instantiation.







If the supplemental_logging parameter is not specified when one of prepare procedures is run, then keys is the default. Some procedures in the DBMS_STREAMS_ADM package prepare tables for instantiation when they add rules to a positive capture process rule set. In this case, the default supplemental logging option, keys, is specified for the tables being prepared for instantiation.









Note:


  • 

    When all is specified for the supplemental_logging parameter, supplemental logging is not enabled for columns of the following types: LOB, LONG, LONG RAW, user-defined type, and Oracle-supplied type.
    

  • 

    Specifying keys for the supplemental_logging parameter does not enable supplemental logging of bitmap join index columns.
    

  • 

    Oracle Database 10g Release 2 introduced the supplemental_logging parameter for the prepare procedures. By default, running these procedures enables supplemental logging. Before this release, these procedures did not enable supplemental logging. If you remove an Oracle Streams environment, or if you remove certain database objects from an Oracle Streams environment, then you can also remove the supplemental logging enabled by these procedures to avoid unnecessary logging.
    
















Preparing Database Objects for Instantiation at a Source Database


If you use the DBMS_STREAMS_ADM package to create rules for a capture process or a synchronous capture, then any objects referenced in the system-created rules are prepared for instantiation automatically. If you use the DBMS_RULE_ADM package to create rules for a capture process, then you must prepare the database objects referenced in these rules for instantiation manually. In this case, you should prepare a database object for instantiation after a capture process has been configured to capture changes to the database object. Synchronous captures ignore rules created by the DBMS_RULE_ADM package.


See "Capture Rules and Preparation for Instantiation" for information about the PL/SQL subprograms that prepare database objects for instantiation. If you run one of these procedures while a long running transaction is modifying one or more database objects being prepared for instantiation, then the procedure waits until the long running transaction is complete before it records the ignore SCN for the objects. The ignore SCN is the SCN below which changes to an object cannot be applied at destination databases. Query the V$STREAMS_TRANSACTION dynamic performance view to monitor long running transactions being processed by a capture process or apply process.


The following sections contain examples that prepare database objects for instantiation:










See Also:

Oracle Streams Concepts and Administration for more information about the instantiation SCN and ignore SCN for an apply process









Preparing Tables for Instantiation


This section contains these topics:






Preparing a Table for Instantiation Using DBMS_STREAMS_ADM When a Capture Process Is Used


The example in this section prepares a table for instantiation using the DBMS_STREAMS_ADM package when a capture process captures changes to the table. To prepare the hr.regions table for instantiation and enable supplemental logging for any primary key, unique key, bitmap index, and foreign key columns in the table, add rules for the hr.regions table to the positive rule set for a capture process using a procedure in the DBMS_STREAMS_ADM package. If the capture process is a local capture process or a downstream capture process with a database link to the source database, then the procedure that you run prepares this table for instantiation automatically.


The following procedure adds rules to the positive rule set of a capture process named strm01_capture and prepares the hr.regions table for instantiation:


BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name     => 'hr.regions',   
    streams_type   => 'capture',
    streams_name   => 'strm01_capture',
    queue_name     => 'strmadmin.strm01_queue',
    include_dml    => TRUE,
    include_ddl    => TRUE,
    inclusion_rule => TRUE);
END;
/










Preparing a Table for Instantiation Using DBMS_CAPTURE_ADM When a Capture Process Is Used


The example in this section prepares a table for instantiation using the DBMS_CAPTURE_ADM package when a capture process captures changes to the table. To prepare the hr.regions table for instantiation and enable supplemental logging for any primary key, unique key, bitmap index, and foreign key columns in the table, run the following procedure:


BEGIN
  DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
    table_name           => 'hr.regions',
    supplemental_logging => 'keys');
END;
/



The default value for the supplemental_logging parameter is keys. Therefore, if this parameter is not specified, then supplemental logging is enabled for any primary key, unique key, bitmap index, and foreign key columns in the table that is being prepared for instantiation.









Preparing Tables for Instantiation Using DBMS_STREAMS_ADM When a Synchronous Capture Is Used


The example in this section prepares all of the tables in the hr schema for instantiation using the DBMS_STREAMS_ADM package when a synchronous capture captures changes to the tables.Add rules for the hr.jobs_transport and hr.regions_transport tables to the positive rule set for a synchronous capture using a procedure in the DBMS_STREAMS_ADM package. The procedure that you run prepares the tables for instantiation automatically.


The following procedure adds a rule to the positive rule set of a synchronous capture named sync_capture and prepares the hr.regions table for instantiation:


BEGIN 
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name   => 'hr.regions',
    streams_type => 'sync_capture',
    streams_name => 'sync_capture',
    queue_name   => 'strmadmin.streams_queue');
END;
/







Preparing Tables for Instantiation Using DBMS_CAPTURE_ADM When a Synchronous Capture Is Used


The example in this section prepares all of the tables in the hr schema for instantiation using the DBMS_CAPTURE_ADM package when a synchronous capture captures changes to the tables. To prepare the tables in the hr schema for instantiation, run the following function:


SET SERVEROUTPUT ON
DECLARE
  tables       DBMS_UTILITY.UNCL_ARRAY;
  prepare_scn  NUMBER;
  BEGIN
    tables(1) := 'hr.departments';
    tables(2) := 'hr.employees';
    tables(3) := 'hr.countries';
    tables(4) := 'hr.regions';
    tables(5) := 'hr.locations';
    tables(6) := 'hr.jobs';
    tables(7) := 'hr.job_history';
    prepare_scn := DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION(
                      table_names => tables);
  DBMS_OUTPUT.PUT_LINE('Prepare SCN = ' || prepare_scn);
END;
/









Preparing the Database Objects in a Schema for Instantiation


This section contains these topics:






Preparing the Database Objects in a Schema for Instantiation Using DBMS_STREAMS_ADM


The example in this section prepares the database objects in a schema for instantiation using the DBMS_STREAMS_ADM package when a capture process captures changes to these objects.


To prepare the database objects in the hr schema for instantiation and enable supplemental logging for the all columns in the tables in the hr schema, run the following procedure, add rules for the hr schema to the positive rule set for a capture process using a procedure in the DBMS_STREAMS_ADM package. If the capture process is a local capture process or a downstream capture process with a database link to the source database, then the procedure that you run prepares the objects in the hr schema for instantiation automatically.


The following procedure adds rules to the positive rule set of a capture process named strm01_capture and prepares the hr schema, and all of its database objects, for instantiation:


BEGIN
  DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
    schema_name     =>  'hr',
    streams_type    =>  'capture',
    streams_name    =>  'strm01_capture',
    queue_name      =>  'strm01_queue',
    include_dml     =>  TRUE,
    include_ddl     =>  TRUE,
    inclusion_rule  =>  TRUE);
END;
/



If the specified capture process does not exist, then this procedure creates it.


In addition, supplemental logging is enabled for any primary key, unique key, bitmap index, and foreign key columns in the tables that are being prepared for instantiation.






Preparing the Database Objects in a Schema for Instantiation Using DBMS_CAPTURE_ADM


The example in this section prepares the database objects in a schema for instantiation using the DBMS_CAPTURE_ADM package when a capture process captures changes to these objects. To prepare the database objects in the hr schema for instantiation and enable supplemental logging for the all columns in the tables in the hr schema, run the following procedure:


BEGIN
  DBMS_CAPTURE_ADM.PREPARE_SCHEMA_INSTANTIATION(
    schema_name          => 'hr',
    supplemental_logging => 'all');
END;
/



After running this procedure, supplemental logging is enabled for all of the columns in the tables in the hr schema and for all of the columns in the tables added to the hr schema in the future.













Preparing All of the Database Objects in a Database for Instantiation


This section contains these topics:






Preparing All of the Database Objects in a Database for Instantiation Using DBMS_STREAMS_ADM


The example in this section prepares the database objects in a database for instantiation using the DBMS_STREAMS_ADM package when a capture process captures changes to these objects. To prepare all of the database objects in a database for instantiation, run the ADD_GLOBAL_RULES procedure in the DBMS_STREAMS_ADM package:


BEGIN
  DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
    streams_type   => 'capture',
    streams_name   => 'capture_db',
    queue_name     => 'strmadmin.streams_queue',
    include_dml    => TRUE,
    include_ddl    => TRUE,
    inclusion_rule => TRUE);
END;
/



If the specified capture process does not exist, then this procedure creates it.


In addition, supplemental logging is enabled for any primary key, unique key, bitmap index, and foreign key columns in the tables that are being prepared for instantiation.






Preparing All of the Database Objects in a Database for Instantiation Using DBMS_CAPTURE_ADM


The example in this section prepares the database objects in a database for instantiation using the DBMS_CAPTURE_ADM package when a capture process captures changes to these objects. To prepare all of the database objects in a database for instantiation, run the following procedure:


BEGIN
  DBMS_CAPTURE_ADM.PREPARE_GLOBAL_INSTANTIATION(
    supplemental_logging => 'none');
END;
/



Because none is specified for the supplemental_logging parameter, this procedure does not enable supplemental logging for any columns. However, you can specify supplemental logging manually using an ALTER TABLE or ALTER DATABASE statement.















Aborting Preparation for Instantiation at a Source Database


The following procedures in the DBMS_CAPTURE_ADM package abort preparation for instantiation:


  • 

    ABORT_TABLE_INSTANTIATION reverses the effects of PREPARE_TABLE_INSTANTIATION and removes any supplemental logging enabled by the PREPARE_TABLE_INSTANTIATION procedure.
    

  • 

    ABORT_SYNC_INSTANTIATION reverses the effects of PREPARE_SYNC_INSTANTIATION
    

  • 

    ABORT_SCHEMA_INSTANTIATION reverses the effects of PREPARE_SCHEMA_INSTANTIATION and removes any supplemental logging enabled by the PREPARE_SCHEMA_INSTANTIATION and PREPARE_TABLE_INSTANTIATION procedures.
    

  • 

    ABORT_GLOBAL_INSTANTIATION reverses the effects of PREPARE_GLOBAL_INSTANTIATION and removes any supplemental logging enabled by the PREPARE_GLOBAL_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, and PREPARE_TABLE_INSTANTIATION procedures.
    



These procedures remove data dictionary information related to the potential instantiation of the relevant database objects.


For example, to abort the preparation for instantiation of the hr.regions table, run the following procedure:


BEGIN
  DBMS_CAPTURE_ADM.ABORT_TABLE_INSTANTIATION(
    table_name  => 'hr.regions');
END;
/









Oracle Data Pump and Oracle Streams Instantiation


The following sections contain information about performing Oracle Streams instantiations using Oracle Data Pump:










See Also:












Data Pump Export and Object Consistency


During export, Oracle Data Pump automatically uses Oracle Flashback to ensure that the exported data and the exported procedural actions for each database object are consistent to a single point in time. When you perform an instantiation in an Oracle Streams environment, some degree of consistency is required. Using the Data Pump Export utility is sufficient to ensure this consistency for Oracle Streams instantiations.


If you are using an export dump file for other purposes in addition to an Oracle Streams instantiation, and these other purposes have more stringent consistency requirements than those provided by Data Pump's default export, then you can use the Data Pump Export utility parameters FLASHBACK_SCN or FLASHBACK_TIME for Oracle Streams instantiations. For example, if an export includes objects with foreign key constraints, then more stringent consistency might be required.








Oracle Data Pump Import and Oracle Streams Instantiation


The following sections provide information about Oracle Data Pump import and Oracle Streams instantiation:






Instantiation SCNs and Data Pump Imports


During a Data Pump import, an instantiation SCN is set at the import database for each database object that was prepared for instantiation at the export database before the Data Pump export was performed. The instantiation SCN settings are based on metadata obtained during Data Pump export.









Instantiation SCNs and Oracle Streams Tags Resulting from Data Pump Imports


A Data Pump import session can set its Oracle Streams tag to the hexadecimal equivalent of '00' to avoid cycling the changes made by the import. Redo entries resulting from such an import have this tag value.


Whether the import session tag is set to the hexadecimal equivalent of '00' depends on the export that is being imported. Specifically, the import session tag is set to the hexadecimal equivalent of '00' in either of the following cases:


  • 

    The Data Pump export was in FULL or SCHEMA mode.
    

  • 

    The Data Pump export was in TABLE or TABLESPACE mode and at least one table included in the export was prepared for instantiation at the export database before the export was performed.
    



If neither one of these conditions is true for a Data Pump export that is being imported, then the import session tag is NULL.









Note:


  • 

    If you perform a network import using Data Pump, then an implicit export is performed in the same mode as the import. For example, if the network import is in schema mode, then the implicit export is in schema mode also.
    

  • 

    The import session tag is not set if the Data Pump import is performed in TRANSPORTABLE TABLESPACE mode. An import performed in this mode does not generate any redo data for the imported data. Therefore, setting the session tag is not required.
    
















The STREAMS_CONFIGURATION Data Pump Import Utility Parameter


The STREAMS_CONFIGURATION Data Pump Import utility parameter specifies whether to import any general Oracle Streams metadata that is present in the export dump file. This import parameter is relevant only if you are performing a full database import. By default, the STREAMS_CONFIGURATION Import utility parameter is set to y. Typically, specify y if an import is part of a backup or restore operation.


The following objects are imported regardless of the STREAMS_CONFIGURATION setting if the information is present in the export dump file:


  • 

    ANYDATA queues and their queue tables
    

  • 

    Queue subscribers
    

  • 

    Advanced Queuing agents
    

  • 

    Rules, including their positive and negative rule sets and evaluation contexts. All rules are imported, including Oracle Streams rules and non-Oracle Streams rules. Oracle Streams rules are rules generated by the system when certain procedures in the DBMS_STREAMS_ADM package are run, while non-Oracle Streams rules are rules created using the DBMS_RULE_ADM package.
    

    If the STREAMS_CONFIGURATION parameter is set to n, then information about Oracle Streams rules is not imported into the following data dictionary views: ALL_STREAMS_RULES, ALL_STREAMS_GLOBAL_RULES, ALL_STREAMS_SCHEMA_RULES, ALL_STREAMS_TABLE_RULES, DBA_STREAMS_RULES, DBA_STREAMS_GLOBAL_RULES, DBA_STREAMS_SCHEMA_RULES, and DBA_STREAMS_TABLE_RULES. However, regardless of the STREAMS_CONFIGURATION parameter setting, information about these rules is imported into the ALL_RULES, ALL_RULE_SETS, ALL_RULE_SET_RULES, DBA_RULES, DBA_RULE_SETS, DBA_RULE_SET_RULES, USER_RULES, USER_RULE_SETS, and USER_RULE_SET_RULES data dictionary views.
    



When the STREAMS_CONFIGURATION Import utility parameter is set to y, the import includes the following information, if the information is present in the export dump file; when the STREAMS_CONFIGURATION Import utility parameter is set to n, the import does not include the following information:


  • 

    Capture processes that capture local changes, including the following information for each capture process:
    

    • 

      Name of the capture process
      

    • 

      State of the capture process
      

    • 

      Capture process parameter settings
      

    • 

      Queue owner and queue name of the queue used by the capture process
      

    • 

      Rule set owner and rule set name of each positive and negative rule set used by the capture process
      

    • 

      Capture user for the capture process
      

    • 

      The time that the status of the capture process last changed. This information is recorded in the DBA_CAPTURE data dictionary view.
      

    • 

      If the capture process disabled or aborted, then the error number and message of the error that was the cause. This information is recorded in the DBA_CAPTURE data dictionary view.
      

    

  • 

    Synchronous captures, including the following information for each synchronous capture:
    

    • 

      Name of the synchronous capture
      

    • 

      Queue owner and queue name of the queue used by the synchronous capture
      

    • 

      Rule set owner and rule set name of each rule set used by the synchronous capture
      

    • 

      Capture user for the synchronous capture
      

    

  • 

    If any tables have been prepared for instantiation at the export database, then these tables are prepared for instantiation at the import database.
    

  • 

    If any schemas have been prepared for instantiation at the export database, then these schemas are prepared for instantiation at the import database.
    

  • 

    If the export database has been prepared for instantiation, then the import database is prepared for instantiation.
    

  • 

    The state of each ANYDATA queue that is used by an Oracle Streams client, either started or stopped. Oracle Streams clients include capture processes, synchronous captures, propagations, apply process, and messaging clients. ANYDATA queues themselves are imported regardless of the STREAMS_CONFIGURATION Import utility parameter setting.
    

  • 

    Propagations, including the following information for each propagation:
    

    • 

      Name of the propagation
      

    • 

      Queue owner and queue name of the source queue
      

    • 

      Queue owner and queue name of the destination queue
      

    • 

      Destination database link
      

    • 

      Rule set owner and rule set name of each positive and negative rule set used by the propagation
      

    • 

      Oracle Scheduler jobs related to Oracle Streams propagations
      

    

  • 

    Apply processes, including the following information for each apply process:
    

    • 

      Name of the apply process
      

    • 

      State of the apply process
      

    • 

      Apply process parameter settings
      

    • 

      Queue owner and queue name of the queue used by the apply process
      

    • 

      Rule set owner and rule set name of each positive and negative rule set used by the apply process
      

    • 

      Whether the apply process applies captured LCRs in a buffered queue or messages in a persistent queue
      

    • 

      Apply user for the apply process
      

    • 

      Message handler used by the apply process, if one exists
      

    • 

      DDL handler used by the apply process, if one exists.
      

    • 

      Precommit handler used by the apply process, if one exists
      

    • 

      Tag value generated in the redo log for changes made by the apply process
      

    • 

      Apply database link, if one exists
      

    • 

      Source database for the apply process
      

    • 

      The information about apply progress in the DBA_APPLY_PROGRESS data dictionary view, including applied message number, oldest message number (oldest SCN), apply time, and applied message create time
      

    • 

      Apply errors
      

    • 

      The time that the status of the apply process last changed. This information is recorded in the DBA_APPLY data dictionary view
      

    • 

      If the apply process disabled or aborted, then the error number and message of the error that was the cause. This information is recorded in the DBA_APPLY data dictionary view.
      

    

  • 

    DML handlers (including both statement DML handlers and procedure DML handlers)
    

  • 

    Error handlers
    

  • 

    Update conflict handlers
    

  • 

    Substitute key columns for apply tables
    

  • 

    Instantiation SCN for each apply object
    

  • 

    Ignore SCN for each apply object
    

  • 

    Messaging clients, including the following information for each messaging client:
    

    • 

      Name of the messaging client
      

    • 

      Queue owner and queue name of the queue used by the messaging client
      

    • 

      Rule set owner and rule set name of each positive and negative rule set used by the messaging client
      

    • 

      Message notification settings
      

    

  • 

    Some data dictionary information about Oracle Streams rules. The rules themselves are imported regardless of the setting for the STREAMS_CONFIGURATION parameter.
    

  • 

    Data dictionary information about Oracle Streams administrators, messaging clients, message rules, extra attributes included in logical change records (LCRs) captured by a capture process or synchronous capture, and extra attributes used in message rules
    










Note:

Downstream capture processes are not included in an import regardless of the STREAMS_CONFIGURATION setting.














Instantiating Objects Using Data Pump Export/Import


The example in this section describes the steps required to instantiate objects in an Oracle Streams environment using Oracle Data Pump export/import. This example makes the following assumptions:


  • 

    You want to capture changes to all of the database objects in the hr schema at a source database and apply these changes at a separate destination database.
    

  • 

    The hr schema exists at the source database but does not exist at the destination database. For the purposes of this example, you can drop the hr user at the destination database using the following SQL statement:
    

    DROP USER hr CASCADE;

    

    The Data Pump import re-creates the user and the user's database objects at the destination database.
    

  • 

    You have configured an Oracle Streams administrator at the source database and the destination database named strmadmin. At each database, the Oracle Streams administrator is granted DBA role.
    










Note:

The example in this section uses the command line Data Pump utility. You can also use the DBMS_DATAPUMP package for Oracle Streams instantiations.













See Also:









Given these assumptions, complete the following steps to instantiate the hr schema using Data Pump export/import:



  1. 

    In SQL*Plus, connect to the source database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Create a directory object to hold the export dump file and export log file:
    

    CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir';

  3. 

    Prepare the database objects in the hr schema for instantiation. See "Preparing the Database Objects in a Schema for Instantiation" for instructions.
    

  4. 

    While still connected to the source database as the Oracle Streams administrator, determine the current system change number (SCN) of the source database:
    

    SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;

    

    The SCN value returned by this query is specified for the FLASHBACK_SCN Data Pump export parameter in Step 5. Because the hr schema includes foreign key constraints between tables, the FLASHBACK_SCN export parameter, or a similar export parameter, must be specified during export. In this example, assume that the query returned 876606.
    

    After you perform this query, ensure that no DDL changes are made to the objects being exported until after the export is complete.
    

  5. 

    On a command line, use Data Pump to export the hr schema at the source database.
    

    Perform the export by connecting as an administrative user who is granted EXP_FULL_DATABASE role. This user also must have READ and WRITE privilege on the directory object created in Step 2. This example connects as the Oracle Streams administrator strmadmin.
    

    The following is a sample Data Pump export command:
    

    expdp strmadmin SCHEMAS=hr DIRECTORY=DPUMP_DIR DUMPFILE=hr_schema_dp.dmp 
FLASHBACK_SCN=876606

    

    


    

    

    See Also:
    
Oracle Database Utilities for information about performing a Data Pump export
    

    

    

  6. 

    In SQL*Plus, connect to the destination database as the Oracle Streams administrator.
    

  7. 

    Create a directory object to hold the import dump file and import log file:
    

    CREATE DIRECTORY DPUMP_DIR AS '/usr/dpump_dir';

  8. 

    Transfer the Data Pump export dump file hr_schema_dp.dmp to the destination database. You can use the DBMS_FILE_TRANSFER package, binary FTP, or some other method to transfer the file to the destination database. After the file transfer, the export dump file should reside in the directory that corresponds to the directory object created in Step 7.
    

  9. 

    On a command line at the destination database, use Data Pump to import the export dump file hr_schema_dp.dmp. Ensure that no changes are made to the tables in the schema being imported at the destination database until the import is complete. Performing the import automatically sets the instantiation SCN for the hr schema and all of its database objects at the destination database.
    

    Perform the import by connecting as an administrative user who is granted IMP_FULL_DATABASE role. This user also must have READ and WRITE privilege on the directory object created in Step 7. This example connects as the Oracle Streams administrator strmadmin.
    

    The following is a sample import command:
    

    impdp strmadmin SCHEMAS=hr DIRECTORY=DPUMP_DIR DUMPFILE=hr_schema_dp.dmp










Note:

Any table supplemental log groups for the tables exported from the export database are retained when the tables are imported at the import database. You can drop these supplemental log groups if necessary.













See Also:

Oracle Database Utilities for information about performing a Data Pump import














Recovery Manager (RMAN) and Oracle Streams Instantiation


The RMAN TRANSPORT TABLESPACE command can instantiate a tablespace or set of tablespaces, and the RMAN DUPLICATE and CONVERT DATABASE commands can instantiate an entire database. Using RMAN for instantiation usually is faster than other instantiation methods.


The following sections contain information about using these RMAN commands for instantiation:






Instantiating Objects in a Tablespace Using Transportable Tablespace or RMAN


The RMAN TRANSPORT TABLESPACE command uses Data Pump and an RMAN-managed auxiliary instance to export the database objects in a tablespace or tablespace set while the tablespace or tablespace set remains online in the source database. RMAN automatically starts an auxiliary instance with a system-generated name. The RMAN TRANSPORT TABLESPACE command produces a Data Pump export dump file and data files for the tablespace or tablespaces.


You can use Data Pump to import the dump file at the destination database, or you can use the ATTACH_TABLESPACES procedure in the DBMS_STREAMS_TABLESPACE_ADM package to attach the tablespace or tablespaces to the destination database. Also, instantiation SCN values for the database objects in the tablespace or tablespaces are set automatically at the destination database when the tablespaces are imported or attached.









Note:

The RMAN TRANSPORT TABLESPACE command does not support user-managed auxiliary instances.






The examples in this section describe the steps required to instantiate the database objects in a tablespace using transportable tablespace or RMAN. These instantiation options usually are faster than export/import. The following examples instantiate the database objects in a tablespace:


  • 

    "Instantiating Objects Using Transportable Tablespace" uses the transportable tablespace feature to complete the instantiation. Data Pump exports the tablespace at the source database and imports the tablespace at the destination database. The tablespace is read-only during the export.
    

  • 

    "Instantiating Objects Using Transportable Tablespace From Backup With RMAN" uses the RMAN TRANSPORT TABLESPACE command to generate a Data Pump export dump file and data files for a tablespace or set of tablespaces at the source database while the tablespace or tablespaces remain online. Either Data Pump import or the ATTACH_TABLESPACES procedure in the DBMS_STREAMS_TABLESPACE_ADM package can add the tablespace or tablespaces to the destination database.
    



These examples instantiate a tablespace set that includes a tablespace called jobs_tbs, and a tablespace called regions_tbs. To run the examples, connect to the source database in SQL*Plus as an administrative user and create the new tablespaces:


CREATE TABLESPACE jobs_tbs DATAFILE '/usr/oracle/dbs/jobs_tbs.dbf' SIZE 5 M;

CREATE TABLESPACE regions_tbs DATAFILE '/usr/oracle/dbs/regions_tbs.dbf' SIZE 5 M;



Place the new table hr.jobs_transport in the jobs_tbs tablespace:


CREATE TABLE hr.jobs_transport TABLESPACE jobs_tbs AS 
  SELECT * FROM hr.jobs;



Place the new table hr.regions_transport in the regions_tbs tablespace:


CREATE TABLE hr.regions_transport TABLESPACE regions_tbs AS 
  SELECT * FROM hr.regions;



Both of the examples make the following assumptions:


  • 

    You want to capture all of the changes to the hr.jobs_transport and hr.regions_transport tables at a source database and apply these changes at a separate destination database.
    

  • 

    The hr.jobs_transport table exists at a source database, and a single self-contained tablespace named jobs_tbs contains the table. The jobs_tbs tablespace is stored in a single data file named jobs_tbs.dbf.
    

  • 

    The hr.regions_transport table exists at a source database, and a single self-contained tablespace named regions_tbs contains the table. The regions_tbs tablespace is stored in a single data file named regions_tbs.dbf.
    

  • 

    The jobs_tbs and regions_tbs tablespaces do not contain data from any other schemas.
    

  • 

    The hr.jobs_transport table, the hr.regions_transport table, the jobs_tbs tablespace, and the regions_tbs tablespace do not exist at the destination database.
    

  • 

    You have configured an Oracle Streams administrator at both the source database and the destination database named strmadmin, and you have granted this Oracle Streams administrator DBA role at both databases.
    







Instantiating Objects Using Transportable Tablespace


This example uses transportable tablespace to instantiate the database objects in a tablespace set. In addition to the assumptions listed in "Instantiating Objects in a Tablespace Using Transportable Tablespace or RMAN", this example makes the following assumptions:


  • 

    The Oracle Streams administrator at the source database is granted the EXP_FULL_DATABASE role to perform the transportable tablespaces export. The DBA role is sufficient because it includes the EXP_FULL_DATABASE role. In this example, the Oracle Streams administrator performs the transportable tablespaces export.
    

  • 

    The Oracle Streams administrator at the destination database is granted the IMP_FULL_DATABASE role to perform the transportable tablespaces import. The DBA role is sufficient because it includes the IMP_FULL_DATABASE role. In this example, the Oracle Streams administrator performs the transportable tablespaces export.
    










See Also:

Oracle Database Administrator's Guide for more information about using transportable tablespaces and for information about limitations that might apply






Complete the following steps to instantiate the database objects in the jobs_tbs and regions_tbs tablespaces using transportable tablespace:



  1. 

    In SQL*Plus, connect to the source database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Create a directory object to hold the export dump file and export log file:
    

    CREATE DIRECTORY TRANS_DIR AS '/usr/trans_dir';

  3. 

    Prepare the hr.jobs_transport and hr.regions_transport tables for instantiation. See "Preparing Tables for Instantiation" for instructions.
    

  4. 

    Make the tablespaces that contain the objects you are instantiating read-only. In this example, the jobs_tbs and regions_tbs tablespaces contain the database objects.
    

    ALTER TABLESPACE jobs_tbs READ ONLY;

ALTER TABLESPACE regions_tbs READ ONLY;

  5. 

    On a command line, use the Data Pump Export utility to export the jobs_tbs and regions_tbs tablespaces at the source database using transportable tablespaces export parameters. The following is a sample export command that uses transportable tablespaces export parameters:
    

    expdp strmadmin TRANSPORT_TABLESPACES=jobs_tbs, regions_tbs 
DIRECTORY=TRANS_DIR DUMPFILE=tbs_ts.dmp

    

    When you run the export command, ensure that you connect as an administrative user who was granted EXP_FULL_DATABASE role and has READ and WRITE privileges on the directory object.
    

    


    

    

    See Also:
    
Oracle Database Utilities for information about performing an export
    

    

    

  6. 

    In SQL*Plus, connect to the destination database as the Oracle Streams administrator.
    

  7. 

    Create a directory object to hold the import dump file and import log file:
    

    CREATE DIRECTORY TRANS_DIR AS '/usr/trans_dir';

  8. 

    Transfer the data files for the tablespaces and the export dump file tbs_ts.dmp to the destination database. You can use the DBMS_FILE_TRANSFER package, binary FTP, or some other method to transfer these files to the destination database. After the file transfer, the export dump file should reside in the directory that corresponds to the directory object created in Step 7.
    

  9. 

    On a command line at the destination database, use the Data Pump Import utility to import the export dump file tbs_ts.dmp using transportable tablespaces import parameters. Performing the import automatically sets the instantiation SCN for the hr.jobs_transport and hr.regions_transport tables at the destination database.
    

    The following is an example import command:
    

    impdp strmadmin DIRECTORY=TRANS_DIR DUMPFILE=tbs_ts.dmp 
TRANSPORT_DATAFILES=/usr/orc/dbs/jobs_tbs.dbf,/usr/orc/dbs/regions_tbs.dbf

    

    When you run the import command, ensure that you connect as an administrative user who was granted IMP_FULL_DATABASE role and has READ and WRITE privileges on the directory object.
    

    


    

    

    See Also:
    
Oracle Database Utilities for information about performing an import
    

    

    

  10. 

    If necessary, at both the source database and the destination database, connect as the Oracle Streams administrator and put the tablespaces into read/write mode:
    

    ALTER TABLESPACE jobs_tbs READ WRITE;

ALTER TABLESPACE regions_tbs READ WRITE;










Note:

Any table supplemental log groups for the tables exported from the export database are retained when tables are imported at the import database. You can drop these supplemental log groups if necessary.













Instantiating Objects Using Transportable Tablespace From Backup With RMAN


The RMAN TRANSPORT TABLESPACE command uses Data Pump and an RMAN-managed auxiliary instance to export the database objects in a tablespace or tablespace set while the tablespace or tablespace set remains online in the source database. The RMAN TRANSPORT TABLESPACE command produces a Data Pump export dump file and data files, and you can use these files to perform a Data Pump import of the tablespace or tablespaces at the destination database. You can also use the ATTACH_TABLESPACES procedure in the DBMS_STREAMS_TABLESPACE_ADM package to attach the tablespace or tablespaces at the destination database.


In addition to the assumptions listed in "Instantiating Objects in a Tablespace Using Transportable Tablespace or RMAN", this example makes the following assumptions:


  • 

    The source database is tts1.example.com.
    

  • 

    The destination database is tts2.example.com.
    










See Also:

Oracle Database Backup and Recovery User's Guide for instructions on using the RMAN TRANSPORT TABLESPACE command






Complete the following steps to instantiate the database objects in the jobs_tbs and regions_tbs tablespaces using transportable tablespaces and RMAN:


  1. 

    Create a backup of the source database that includes the tablespaces being instantiated, if a backup does not exist. RMAN requires a valid backup for tablespace cloning. In this example, create a backup of the source database that includes the jobs_tbs and regions_tbs tablespaces if one does not exist.
    

  2. 

    In SQL*Plus, connect to the source database tts1.example.com as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Optionally, create a directory object to hold the export dump file and export log file:
    

    CREATE DIRECTORY SOURCE_DIR AS '/usr/db_files';

    

    This step is optional because the RMAN TRANSPORT TABLESPACE command creates a directory object named STREAMS_DIROBJ_DPDIR on the auxiliary instance if the DATAPUMP DIRECTORY parameter is omitted when you run this command in Step 9.
    

  4. 

    Prepare the hr.jobs_transport and hr.regions_transport tables for instantiation. See "Preparing Tables for Instantiation" for instructions.
    

  5. 

    Determine the until SCN for the RMAN TRANSPORT TABLESPACE command:
    

    SET SERVEROUTPUT ON SIZE 1000000
DECLARE
  until_scn NUMBER;
BEGIN
  until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
      DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);
END;
/

    

    Make a note of the until SCN returned. You will use this number in Step 9. For this example, assume that the returned until SCN is 7661956.
    

    Optionally, you can skip this step. In this case, do not specify the until clause in the RMAN TRANSPORT TABLESPACE command in Step 9. When no until clause is specified, RMAN uses the last archived redo log file to determine the until SCN automatically.
    

  6. 

    In SQL*Plus, connect to the source database tts1.net as an administrative user.
    

  7. 

    Archive the current online redo log:
    

    ALTER SYSTEM ARCHIVE LOG CURRENT;

  8. 

    Start the RMAN client, and connect to the source database tts1.example.com as TARGET.
    

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

  9. 

    At the source database tts1.example.com, use the RMAN TRANSPORT TABLESPACE command to generate the dump file for the tablespace set:
    

    RMAN> RUN
      { 
        TRANSPORT TABLESPACE 'jobs_tbs', 'regions_tbs'
        UNTIL SCN 7661956
        AUXILIARY DESTINATION '/usr/aux_files'
        DATAPUMP DIRECTORY SOURCE_DIR 
        DUMP FILE 'jobs_regions_tbs.dmp' 
        EXPORT LOG 'jobs_regions_tbs.log'
        IMPORT SCRIPT 'jobs_regions_tbs_imp.sql'
        TABLESPACE DESTINATION '/orc/dbs';
      }

    

    The TRANSPORT TABLESPACE command places the files in the following directories on the computer system that runs the source database:
    

    • 

      The directory that corresponds to the SOURCE_DIR directory object (/usr/db_files) contains the export dump file and export log file.
      

    • 

      The /orc/dbs directory contains the generated data files for the tablespaces and the import script. You use this script to complete the instantiation by attaching the tablespace at the destination database.
      

    

  10. 

    Modify the import script, if necessary. You might need to modify one or both of the following items in the script:
    

    • 

      You might want to change the method used to make the exported tablespaces part of the destination database. The import script includes two ways to make the exported tablespaces part of the destination database: a Data Pump import command (impdp), and a script for attaching the tablespaces using the ATTACH_TABLESPACES procedure in the DBMS_STREAMS_TABLESPACE_ADM package.
      

      The default script uses the attach tablespaces method. The Data Pump import command is commented out. To use Data Pump import, remove the comment symbols (/* and */) surrounding the impdp command, and either surround the attach tablespaces script with comments or remove the attach tablespaces script. The attach tablespaces script starts with SET SERVEROUTPUT ON and continues to the end of the file.
      

    • 

      You might need to change the directory paths specified in the script. In Step 11, you will transfer the import script (jobs_regions_tbs_imp.sql), the Data Pump export dump file (jobs_regions_tbs.dmp), and the generated data file for each tablespace (jobs_tbs.dbf and regions_tbs.dbf) to one or more directories on the computer system running the destination database. Ensure that the directory paths specified in the script are the correct directory paths.
      

    

  11. 

    Transfer the import script (jobs_regions_tbs_imp.sql), the Data Pump export dump file (jobs_regions_tbs.dmp), and the generated data file for each tablespace (jobs_tbs.dbf and regions_tbs.dbf) to the destination database. You can use the DBMS_FILE_TRANSFER package, binary FTP, or some other method to transfer the file to the destination database. After the file transfer, these files should reside in the directories specified in the import script.
    

  12. 

    In SQL*Plus, connect to the destination database tts2.example.com as the Oracle Streams administrator.
    

  13. 

    Run the import script:
    

    SET ECHO ON
SPOOL jobs_tbs_imp.out
@jobs_tbs_imp.sql

    

    When the script completes, check the jobs_tbs_imp.out spool file to ensure that all actions finished successfully.
    












Instantiating an Entire Database Using RMAN


The Recovery Manager (RMAN) DUPLICATE command creates a copy of the target database in another location. The command uses an RMAN auxiliary instance to restore backups of the target database files and create a new database. In an Oracle Streams instantiation, the target database is the source database and the new database that is created is the destination database. The RMAN DUPLICATE command requires that the source and destination database run on the same platform.


The RMAN CONVERT DATABASE command generates the data files and an initialization parameter file for a new destination database on a different platform. It also generates a script that creates the new destination database. These files can instantiate an entire destination database that runs on a different platform than the source database but has the same endian format as the source database.


The RMAN DUPLICATE and CONVERT DATABASE commands do not set the instantiation SCN values for the database objects. The instantiation SCN values must be set manually during instantiation.


The examples in this section describe the steps required to instantiate an entire database using the RMAN DUPLICATE command or CONVERT DATABASE command. To use one of these RMAN commands for full database instantiation, complete the following general steps:


  1. 

    Copy the entire source database to the destination site using the RMAN command.
    

  2. 

    Remove the Oracle Streams configuration at the destination site using the REMOVE_STREAMS_CONFIGURATION procedure in the DBMS_STREAMS_ADM package.
    

  3. 

    Configure Oracle Streams destination site, including configuration of one or more apply processes to apply changes from the source database.
    



You can complete this process without stopping any running capture processes or propagations at the source database.


Follow the instructions in one of these sections:










Note:


  • 

    To configure an Oracle Streams replication environment that replicates all of the supported changes for an entire database, you can use the PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP procedures in the DBMS_STREAMS_ADM package. See "Configuring Two-Database Global Replication with Local Capture" for instructions.
    

  • 

    Oracle recommends that you do not use RMAN for instantiation in an environment where distributed transactions are possible. Doing so can cause in-doubt transactions that must be corrected manually. Use export/import or transportable tablespaces for instantiation instead.
    
















See Also:

"Configuring an Oracle Streams Administrator on All Databases" for information about configuring an Oracle Streams administrator









Instantiating an Entire Database on the Same Platform Using RMAN


The example in this section instantiates an entire database using the RMAN DUPLICATE command. The example makes the following assumptions:


  • 

    You want to capture all of the changes made to a source database named dpx1.example.com, propagate these changes to a separate destination database named dpx2.example.com, and apply these changes at the destination database.
    

  • 

    You have configured an Oracle Streams administrator at the source database named strmadmin. See "Configuring an Oracle Streams Administrator on All Databases".
    

  • 

    The dpx1.example.com and dpx2.example.com databases run on the same platform.
    










See Also:

Oracle Database Backup and Recovery User's Guide for instructions about using the RMAN DUPLICATE command






Complete the following steps to instantiate an entire database using RMAN when the source and destination databases run on the same platform:


  1. 

    Create a backup of the source database if one does not exist. RMAN requires a valid backup for duplication. In this example, create a backup of dpx1.example.com if one does not exist.
    

    


    

    

    Note:
    
A backup of the source database is not necessary if you use the FROM ACTIVE DATABASE option when you run the RMAN DUPLICATE command. For large databases, the FROM ACTIVE DATABASE option requires significant network resources. This example does not use this option.
    

    

    

  2. 

    In SQL*Plus, connect to the source database dpx1.example.com as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Create an ANYDATA queue to stage the changes from the source database if such a queue does not already exist. This queue will stage changes that will be propagated to the destination database after it has been configured.
    

    For example, the following procedure creates a queue named streams_queue:
    

    EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

    

    Remain connected as the Oracle Streams administrator in SQL*Plus at the source database through Step 9.
    

  4. 

    Create a database link from dpx1.example.com to dpx2.example.com:
    

    CREATE DATABASE LINK dpx2.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'dpx2.example.com';

  5. 

    Create a propagation from the source queue at the source database to the destination queue at the destination database. The destination queue at the destination database does not exist yet, but creating this propagation ensures that logical change records (LCRs) enqueued into the source queue will remain staged there until propagation is possible. In addition to captured LCRs, the source queue will stage internal messages that will populate the Oracle Streams data dictionary at the destination database.
    

    The following procedure creates the dpx1_to_dpx2 propagation:
    

    BEGIN
  DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES(
    streams_name            => 'dpx1_to_dpx2', 
    source_queue_name       => 'strmadmin.streams_queue',
    destination_queue_name  => 'strmadmin.streams_queue@dpx2.example.com',
    include_dml             => TRUE,
    include_ddl             => TRUE,
    source_database         => 'dpx1.example.com',
    inclusion_rule          => TRUE,
    queue_to_queue          => TRUE);
END;
/

  6. 

    Stop the propagation you created in Step 5.
    

    BEGIN
  DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
    propagation_name  => 'dpx1_to_dpx2');
END;
/

  7. 

    Prepare the entire source database for instantiation, if it has not been prepared for instantiation previously. See "Preparing All of the Database Objects in a Database for Instantiation" for instructions.
    

    If there is no capture process that captures all of the changes to the source database, then create this capture process using the ADD_GLOBAL_RULES procedure in the DBMS_STREAMS_ADM package. If the capture process is a local capture process or a downstream capture process with a database link to the source database, then running this procedure automatically prepares the entire source database for instantiation. If such a capture process already exists, then ensure that the source database has been prepared for instantiation by querying the DBA_CAPTURE_PREPARED_DATABASE data dictionary view.
    

  8. 

    If you created a capture process in Step 7, then start the capture process:
    

    BEGIN
  DBMS_CAPTURE_ADM.START_CAPTURE(
    capture_name  => 'capture_db');
END;
/

  9. 

    Determine the until SCN for the RMAN DUPLICATE command:
    

    SET SERVEROUTPUT ON SIZE 1000000
DECLARE
  until_scn NUMBER;
BEGIN
  until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
      DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn);
END;
/

    

    Make a note of the until SCN returned. You will use this number in Step 14. For this example, assume that the returned until SCN is 3050191.
    

  10. 

    In SQL*Plus, connect to the source database dpx1.example.com as an administrative user.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  11. 

    Archive the current online redo log:
    

    ALTER SYSTEM ARCHIVE LOG CURRENT;

  12. 

    Prepare your environment for database duplication, which includes preparing the destination database as an auxiliary instance for duplication. See Oracle Database Backup and Recovery User's Guide for instructions.
    

  13. 

    Start the RMAN client, and connect to the source database dpx1.example.com as TARGET and to the destination database dpx2.example.com as AUXILIARY.
    

    See Oracle Database Backup and Recovery Reference for more information about the RMAN CONNECT command.
    

  14. 

    Use the RMAN DUPLICATE command with the OPEN RESTRICTED option to instantiate the source database at the destination database. The OPEN RESTRICTED option is required. This option enables a restricted session in the duplicate database by issuing the following SQL statement: ALTER SYSTEM ENABLE RESTRICTED SESSION. RMAN issues this statement immediately before the duplicate database is opened.
    

    You can use the UNTIL SCN clause to specify an SCN for the duplication. Use the until SCN determined in Step 9 for this clause. The until SCN specified for the RMAN DUPLICATE command must be higher than the SCN when the database was prepared for instantiation in Step 7. Also, archived redo logs must be available for the until SCN specified and for higher SCN values. Therefore, Step 11 archived the redo log containing the until SCN.
    

    Ensure that you use TO database_name in the DUPLICATE command to specify the name of the duplicate database. In this example, the duplicate database name is dpx2. Therefore, the DUPLICATE command for this example includes TO dpx2.
    

    The following is an example of an RMAN DUPLICATE command:
    

    RMAN> RUN
      { 
        SET UNTIL SCN 3050191;
        ALLOCATE AUXILIARY CHANNEL dpx2 DEVICE TYPE sbt; 
        DUPLICATE TARGET DATABASE TO dpx2 
        NOFILENAMECHECK
        OPEN RESTRICTED;
      }

    

    


    

    

    See Also:
    
Oracle Database Backup and Recovery Reference for more information about the RMAN DUPLICATE command
    

    

    

  15. 

    At the destination database, connect as an administrative user in SQL*Plus and rename the database global name. After the RMAN DUPLICATE command, the destination database has the same global name as the source database.
    

    ALTER DATABASE RENAME GLOBAL_NAME TO DPX2.EXAMPLE.COM;

  16. 

    At the destination database, connect as an administrative user in SQL*Plus and run the following procedure:
    

    


    

    

    Caution:
    
Ensure that you are connected to the destination database, not the source database, when you run this procedure because it removes the local Oracle Streams configuration.
    

    

    

    EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

    

    


    

    

    Note:
    
Any supplemental log groups for the tables at the source database are retained at the destination database, and the REMOVE_STREAMS_CONFIGURATION procedure does not drop them. You can drop these supplemental log groups if necessary.
    

    

    

    


    

    

    See Also:
    
Oracle Database PL/SQL Packages and Types Reference for more information about the REMOVE_STREAMS_CONFIGURATION procedure
    

    

    

  17. 

    At the destination database, use the ALTER SYSTEM statement to disable the RESTRICTED SESSION:
    

    ALTER SYSTEM DISABLE RESTRICTED SESSION;

  18. 

    At the destination database, connect as the Oracle Streams administrator. See "Configuring an Oracle Streams Administrator on All Databases".
    

  19. 

    At the destination database, create the queue specified in Step 5.
    

    For example, the following procedure creates a queue named streams_queue:
    

    EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

  20. 

    At the destination database, configure the Oracle Streams environment.
    

    


    

    

    Note:
    
Do not start any apply processes at the destination database until after you set the global instantiation SCN in Step 22.
    

    

    

  21. 

    At the destination database, create a database link from the destination database to the source database:
    

    CREATE DATABASE LINK dpx1.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'dpx1.example.com';

    

    This database link is required because the next step runs the SET_GLOBAL_INSTANTIATION_SCN procedure with the recursive parameter set to TRUE.
    

  22. 

    At the destination database, set the global instantiation SCN for the source database. The RMAN DUPLICATE command duplicates the database up to one less than the SCN value specified in the UNTIL SCN clause. Therefore, you should subtract one from the until SCN value that you specified when you ran the DUPLICATE command in Step 14. In this example, the until SCN was set to 3050191. Therefore, the instantiation SCN should be set to 3050191 - 1, or 3050190.
    

    For example, to set the global instantiation SCN to 3050190 for the dpx1.example.com source database, run the following procedure:
    

    BEGIN
  DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN(
    source_database_name   =>  'dpx1.example.com',
    instantiation_scn      =>  3050190,
    recursive              =>  TRUE);
END;
/

    

    Notice that the recursive parameter is set to TRUE to set the instantiation SCN for all schemas and tables in the destination database.
    

  23. 

    At the destination database, you can start any apply processes that you configured.
    

  24. 

    At the source database, start the propagation you stopped in Step 6:
    

    BEGIN
  DBMS_PROPAGATION_ADM.START_PROPAGATION(
    queue_name  => 'dpx1_to_dpx2');
END;
/










Instantiating an Entire Database on Different Platforms Using RMAN


The example in this section instantiates an entire database using the RMAN CONVERT DATABASE command. The example makes the following assumptions:


  • 

    You want to capture all of the changes made to a source database named cvx1.example.com, propagate these changes to a separate destination database named cvx2.example.com, and apply these changes at the destination database.
    

  • 

    You have configured an Oracle Streams administrator at the source database named strmadmin. See "Configuring an Oracle Streams Administrator on All Databases".
    

  • 

    The cvx1.example.com and cvx2.example.com databases run on different platforms, and the platform combination is supported by the RMAN CONVERT DATABASE command. You can use the DBMS_TDB package to determine whether a platform combination is supported.
    



The RMAN CONVERT DATABASE command produces converted data files, an initialization parameter file (PFILE), and a SQL script. The converted data files and PFILE are for use with the destination database, and the SQL script creates the destination database on the destination platform.









See Also:

Oracle Database Backup and Recovery User's Guide for instructions about using the RMAN CONVERT DATABASE command






Complete the following steps to instantiate an entire database using RMAN when the source and destination databases run on different platforms:


  1. 

    Create a backup of the source database if one does not exist. RMAN requires a valid backup. In this example, create a backup of cvx1.example.com if one does not exist.
    

  2. 

    In SQL*Plus, connect to the source database cvx1.example.com as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Create an ANYDATA queue to stage the changes from the source database if such a queue does not already exist. This queue will stage changes that will be propagated to the destination database after it has been configured.
    

    For example, the following procedure creates a queue named streams_queue:
    

    EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

    

    Remain connected as the Oracle Streams administrator in SQL*Plus at the source database through Step 8.
    

  4. 

    Create a database link from cvx1.example.com to cvx2.example.com:
    

    CREATE DATABASE LINK cvx2.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'cvx2.example.com';

  5. 

    Create a propagation from the source queue at the source database to the destination queue at the destination database. The destination queue at the destination database does not exist yet, but creating this propagation ensures that logical change records (LCRs) enqueued into the source queue will remain staged there until propagation is possible. In addition to captured LCRs, the source queue will stage internal messages that will populate the Oracle Streams data dictionary at the destination database.
    

    The following procedure creates the cvx1_to_cvx2 propagation:
    

    BEGIN
  DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES(
    streams_name            => 'cvx1_to_cvx2', 
    source_queue_name       => 'strmadmin.streams_queue',
    destination_queue_name  => 'strmadmin.streams_queue@cvx2.example.com',
    include_dml             => TRUE,
    include_ddl             => TRUE,
    source_database         => 'cvx1.example.com',
    inclusion_rule          => TRUE,
    queue_to_queue          => TRUE);
END;
/

  6. 

    Stop the propagation you created in Step 5.
    

    BEGIN
  DBMS_PROPAGATION_ADM.STOP_PROPAGATION(
    propagation_name  => 'cvx1_to_cvx2');
END;
/

  7. 

    Prepare the entire source database for instantiation, if it has not been prepared for instantiation previously. See "Preparing All of the Database Objects in a Database for Instantiation" for instructions.
    

    If there is no capture process that captures all of the changes to the source database, then create this capture process using the ADD_GLOBAL_RULES procedure in the DBMS_STREAMS_ADM package. If the capture process is a local capture process or a downstream capture process with a database link to the source database, then running this procedure automatically prepares the entire source database for instantiation. If such a capture process already exists, then ensure that the source database has been prepared for instantiation by querying the DBA_CAPTURE_PREPARED_DATABASE data dictionary view.
    

  8. 

    If you created a capture process in Step 7, then start the capture process:
    

    BEGIN
  DBMS_CAPTURE_ADM.START_CAPTURE(
    capture_name  => 'capture_db');
END;
/

  9. 

    In SQL*Plus, connect to the source database as an administrative user.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  10. 

    Archive the current online redo log:
    

    ALTER SYSTEM ARCHIVE LOG CURRENT;

  11. 

    Prepare your environment for database conversion, which includes opening the source database in read-only mode. Complete the following steps:
    

    1. 

      If the source database is open, then shut it down and start it in read-only mode.
      

    2. 

      Run the CHECK_DB and CHECK_EXTERNAL functions in the DBMS_TDB package. Check the results to ensure that the conversion is supported by the RMAN CONVERT DATABASE command.
      

    

    


    

    

    See Also:
    
Oracle Database Backup and Recovery User's Guide for more information about these steps
    

    

    

  12. 

    Determine the current SCN of the source database:
    

    SET SERVEROUTPUT ON SIZE 1000000
DECLARE
  current_scn NUMBER;
BEGIN
  current_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER;
      DBMS_OUTPUT.PUT_LINE('Current SCN: ' || current_scn);
END;
/

    

    Make a note of the SCN value returned. You will use this number in Step 24. For this example, assume that the returned value is 46931285.
    

  13. 

    Start the RMAN client, and connect to the source database cvx1.example.com as TARGET.
    

    See Oracle Database Backup and Recovery Reference for more information about the RMAN CONNECT command.
    

  14. 

    Run the CONVERT DATABASE command.
    

    Ensure that you use NEW DATABASE database_name in the CONVERT DATABASE command to specify the name of the destination database. In this example, the destination database name is cvx2. Therefore, the CONVERT DATABASE command for this example includes NEW DATABASE cvx2.
    

    The following is an example of an RMAN CONVERT DATABASE command for a destination database that is running on the Linux IA (64-bit) platform:
    

    CONVERT DATABASE NEW DATABASE 'cvx2'
          TRANSPORT SCRIPT '/tmp/convertdb/transportscript.sql'     
          TO PLATFORM 'Linux IA (64-bit)'
          DB_FILE_NAME_CONVERT '/home/oracle/dbs','/tmp/convertdb';

  15. 

    Transfer the data files, PFILE, and SQL script produced by the RMAN CONVERT DATABASE command to the computer system that will run the destination database.
    

  16. 

    On the computer system that will run the destination database, modify the SQL script so that the destination database always opens with restricted session enabled.
    

    The following is a sample script with the necessary modifications in bold font:
    

    -- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- The contents of online logs will be lost and all backups will
-- be invalidated. Use this only if online logs are damaged.
 
-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE
 
STARTUP NOMOUNT PFILE='init_00gd2lak_1_0.ora'
CREATE CONTROLFILE REUSE SET DATABASE "CVX2" RESETLOGS  NOARCHIVELOG
    MAXLOGFILES 32
    MAXLOGMEMBERS 2
    MAXDATAFILES 32
    MAXINSTANCES 1
    MAXLOGHISTORY 226
LOGFILE
  GROUP 1 '/tmp/convertdb/archlog1'  SIZE 25M,
  GROUP 2 '/tmp/convertdb/archlog2'  SIZE 25M
DATAFILE
  '/tmp/convertdb/systemdf',
  '/tmp/convertdb/sysauxdf',
  '/tmp/convertdb/datafile1',
  '/tmp/convertdb/datafile2',
  '/tmp/convertdb/datafile3'
CHARACTER SET WE8DEC
;
 
-- NOTE: This ALTER SYSTEM statement is added to enable restricted session.

ALTER SYSTEM ENABLE RESTRICTED SESSION;

-- Database can now be opened zeroing the online logs.
ALTER DATABASE OPEN RESETLOGS;
 
-- No tempfile entries found to add.
--
 
set echo off
prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
prompt * Your database has been created successfully!
prompt * There are many things to think about for the new database. Here
prompt * is a checklist to help you stay on track:
prompt * 1. You may want to redefine the location of the directory objects.
prompt * 2. You may want to change the internal database identifier (DBID) 
prompt *    or the global database name for this database. Use the 
prompt *    NEWDBID Utility (nid).
prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
SHUTDOWN IMMEDIATE 
-- NOTE: This startup has the UPGRADE parameter.
-- It already has restricted session enabled, so no change is needed.
STARTUP UPGRADE PFILE='init_00gd2lak_1_0.ora'
@@ ?/rdbms/admin/utlirp.sql 
SHUTDOWN IMMEDIATE 
-- NOTE: The startup below is generated without the RESTRICT clause.
-- Add the RESTRICT clause.
STARTUP RESTRICT PFILE='init_00gd2lak_1_0.ora'
-- The following step will recompile all PL/SQL modules.
-- It may take serveral hours to complete.
@@ ?/rdbms/admin/utlrp.sql 
set feedback 6;

    

    Other changes to the script might be necessary. For example, the data file locations and PFILE location might need to be changed to point to the correct locations on the destination database computer system.
    

  17. 

    At the destination database, connect as an administrative user in SQL*Plus and run the following procedure:
    

    


    

    

    Caution:
    
Ensure that you are connected to the destination database, not the source database, when you run this procedure because it removes the local Oracle Streams configuration.
    

    

    

    EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION();

    

    


    

    

    Note:
    
Any supplemental log groups for the tables at the source database are retained at the destination database, and the REMOVE_STREAMS_CONFIGURATION procedure does not drop them. You can drop these supplemental log groups if necessary.
    

    

    

    


    

    

    See Also:
    
Oracle Database PL/SQL Packages and Types Reference for more information about the REMOVE_STREAMS_CONFIGURATION procedure
    

    

    

  18. 

    In SQL*Plus, connect to the destination database cvx2.example.com as the Oracle Streams administrator.
    

  19. 

    Drop the database link from the source database to the destination database that was cloned from the source database:
    

    DROP DATABASE LINK cvx2.example.com;

  20. 

    At the destination database, use the ALTER SYSTEM statement to disable the RESTRICTED SESSION:
    

    ALTER SYSTEM DISABLE RESTRICTED SESSION;

  21. 

    At the destination database, create the queue specified in Step 5.
    

    For example, the following procedure creates a queue named streams_queue:
    

    EXEC DBMS_STREAMS_ADM.SET_UP_QUEUE();

  22. 

    At the destination database, connect as the Oracle Streams administrator and configure the Oracle Streams environment. See "Configuring an Oracle Streams Administrator on All Databases".
    

    


    

    

    Note:
    
Do not start any apply processes at the destination database until after you set the global instantiation SCN in Step 24.
    

    

    

  23. 

    At the destination database, create a database link to the source database:
    

    CREATE DATABASE LINK cvx1.example.com CONNECT TO strmadmin 
   IDENTIFIED BY password USING 'cvx1.example.com';

    

    This database link is required because the next step runs the SET_GLOBAL_INSTANTIATION_SCN procedure with the recursive parameter set to TRUE.
    

  24. 

    At the destination database, set the global instantiation SCN for the source database to the SCN value returned in Step 12.
    

    For example, to set the global instantiation SCN to 46931285 for the cvx1.example.com source database, run the following procedure:
    

    BEGIN
  DBMS_APPLY_ADM.SET_GLOBAL_INSTANTIATION_SCN(
    source_database_name   =>  'cvx1.example.com',
    instantiation_scn      =>  46931285,
    recursive              =>  TRUE);
END;
/

    

    Notice that the recursive parameter is set to TRUE to set the instantiation SCN for all schemas and tables in the destination database.
    

  25. 

    At the destination database, you can start any apply processes that you configured.
    

  26. 

    At the source database, start the propagation you stopped in Step 6:
    

    BEGIN
  DBMS_PROPAGATION_ADM.START_PROPAGATION(
    propagation_name  => 'cvx1_to_cvx2');
END;
/














Setting Instantiation SCNs at a Destination Database


An instantiation system change number (SCN) instructs an apply process at a destination database to apply changes that committed after a specific SCN at a source database. You can set instantiation SCNs in one of the following ways:


  • 

    Export the relevant database objects at the source database and import them at the destination database. In this case, the export/import creates the database objects at the destination database, populates them with the data from the source database, and sets the relevant instantiation SCNs. You can use Data Pump export/import for instantiations. See "Setting Instantiation SCNs Using Export/Import" for information about the instantiation SCNs that are set for different types of export/import operations.
    

  • 

    Perform a metadata only export/import using Data Pump. If you use Data Pump export/import, then set the CONTENT parameter to METADATA_ONLY during export at the source database or import at the destination database, or both. Instantiation SCNs are set for the database objects, but no data is imported. See "Setting Instantiation SCNs Using Export/Import" for information about the instantiation SCNs that are set for different types of export/import operations.
    

  • 

    Use transportable tablespaces to copy the objects in one or more tablespaces from a source database to a destination database. An instantiation SCN is set for each schema in these tablespaces and for each database object in these tablespaces that was prepared for instantiation before the export. See "Instantiating Objects in a Tablespace Using Transportable Tablespace or RMAN".
    

  • 

    Set the instantiation SCN using the SET_TABLE_INSTANTIATION_SCN, SET_SCHEMA_INSTANATIATION_SCN, and SET_GLOBAL_INSTANTIATION_SCN procedures in the DBMS_APPLY_ADM package. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package".
    







Setting Instantiation SCNs Using Export/Import


This section discusses setting instantiation SCNs by performing an export/import. The information in this section applies to both metadata export/import operations and to export/import operations that import rows. You can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.


The following sections describe how the instantiation SCNs are set for different types of export/import operations. These sections refer to prepared tables. Prepared tables are tables that have been prepared for instantiation using the PREPARE_TABLE_INSTANTIATION procedure, PREPARE_SYNC_INSTANTIATION function, PREPARE_SCHEMA_INSTANTIATION procedure, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package. A table must be a prepared table before export in order for an instantiation SCN to be set for it during import. However, the database and schemas do not need to be prepared before the export in order for their instantiation SCNs to be set for them during import.





Full Database Export and Full Database Import


A full database export and full database import sets the following instantiation SCNs at the import database:


  • 

    The database, or global, instantiation SCN
    

  • 

    The schema instantiation SCN for each imported user
    

  • 

    The table instantiation SCN for each prepared table that is imported
    









Full Database or User Export and User Import


A full database or user export and user import sets the following instantiation SCNs at the import database:


  • 

    The schema instantiation SCN for each imported user
    

  • 

    The table instantiation SCN for each prepared table that is imported
    









Full Database, User, or Table Export and Table Import


Any export that includes one or more tables and a table import sets the table instantiation SCN for each prepared table that is imported at the import database.









Note:


  • 

    If a non-NULL instantiation SCN already exists for a database object at a destination database that performs an import, then the import updates the instantiation SCN for that database object.
    

  • 

    During an export for an Oracle Streams instantiation, ensure that no data definition language (DDL) changes are made to objects being exported.
    

  • 

    Any table supplemental logging specifications for the tables exported from the export database are retained when the tables are imported at the import database.
    
















See Also:

















Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package


You can set an instantiation SCN at a destination database for a specified table, a specified schema, or an entire database using one of the following procedures in the DBMS_APPLY_ADM package:



If you set the instantiation SCN for a schema using SET_SCHEMA_INSTANTIATION_SCN, then you can set the recursive parameter to TRUE when you run this procedure to set the instantiation SCN for each table in the schema. Similarly, if you set the instantiation SCN for a database using SET_GLOBAL_INSTANTIATION_SCN, then you can set the recursive parameter to TRUE when you run this procedure to set the instantiation SCN for the schemas in the database and for each table owned by these schemas.









Note:


  • 

    If you set the recursive parameter to TRUE in the SET_SCHEMA_INSTANTIATION_SCN procedure or the SET_GLOBAL_INSTANTIATION_SCN procedure, then a database link from the destination database to the source database is required. This database link must have the same name as the global name of the source database and must be accessible to the user who executes the procedure.
    

  • 

    When setting an instantiation SCN for a database object, always specify the name of the schema and database object at the source database, even if a rule-based transformation or apply handler is configured to change the schema name or database object name.
    

  • 

    If a relevant instantiation SCN is not present, then an error is raised during apply.
    

  • 

    These procedures can set an instantiation SCN for changes captured by capture processes and synchronous captures.
    









Table 8-3 lists each procedure and the types of statements for which they set an instantiation SCN.




Table 8-3 Set Instantiation SCN Procedures and the Statements They Cover


ProcedureSets Instantiation SCN forExamples


SET_TABLE_INSTANTIATION_SCN



DML and DDL statements on tables, except CREATE TABLE


DDL statements on table indexes and table triggers



UPDATE


ALTER TABLE


DROP TABLE


CREATE, ALTER, or DROP INDEX on a table


CREATE, ALTER, or DROP TRIGGER on a table




SET_SCHEMA_INSTANTIATION_SCN



DDL statements on users, except CREATE USER


DDL statements on all database objects that have a non-PUBLIC owner, except for those DDL statements handled by a table-level instantiation SCN



CREATE TABLE


ALTER USER


DROP USER


CREATE PROCEDURE




SET_GLOBAL_INSTANTIATION_SCN



DDL statements on database objects other than users with no owner


DDL statements on database objects owned by public


CREATE USER statements



CREATE USER


CREATE TABLESPACE










Setting the Instantiation SCN While Connected to the Source Database


The user who runs the examples in this section must have access to a database link from the source database to the destination database. In these examples, the database link is hrdb2.example.com. The following example sets the instantiation SCN for the hr.departments table at the hrdb2.example.com database to the current SCN by running the following procedure at the source database hrdb1.example.com:


DECLARE
  iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@HRDB2.EXAMPLE.COM(
    source_object_name    => 'hr.departments',
    source_database_name  => 'hrdb1.example.com',
    instantiation_scn     => iscn);
END;
/



The following example sets the instantiation SCN for the oe schema and all of its objects at the hrdb2.example.com database to the current source database SCN by running the following procedure at the source database hrdb1.example.com:


DECLARE
  iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN@HRDB2.EXAMPLE.COM(
    source_schema_name    => 'oe',
    source_database_name  => 'hrdb1.example.com',
    instantiation_scn     => iscn,
    recursive             => TRUE);
END;
/



Because the recursive parameter is set to TRUE, running this procedure sets the instantiation SCN for each database object in the oe schema.









Note:

When you set the recursive parameter to TRUE, a database link from the destination database to the source database is required, even if you run the procedure while you are connected to the source database. This database link must have the same name as the global name of the source database and must be accessible to the current user.












Setting the Instantiation SCN While Connected to the Destination Database


The user who runs the examples in this section must have access to a database link from the destination database to the source database. In these examples, the database link is hrdb1.example.com. The following example sets the instantiation SCN for the hr.departments table at the hrdb2.example.com database to the current source database SCN at hrdb1.example.com by running the following procedure at the destination database hrdb2.example.com:


DECLARE
  iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER@HRDB1.EXAMPLE.COM;
  DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN(
    source_object_name    => 'hr.departments',
    source_database_name  => 'hrdb1.example.com',
    instantiation_scn     => iscn);
END;
/



The following example sets the instantiation SCN for the oe schema and all of its objects at the hrdb2.example.com database to the current source database SCN at hrdb1.example.com by running the following procedure at the destination database hrdb2.example.com:


DECLARE
  iscn  NUMBER;         -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER@HRDB1.EXAMPLE.COM;
  DBMS_APPLY_ADM.SET_SCHEMA_INSTANTIATION_SCN(
    source_schema_name    => 'oe',
    source_database_name  => 'hrdb1.example.com',
    instantiation_scn     => iscn,
    recursive             => TRUE);
END;
/



Because the recursive parameter is set to TRUE, running this procedure sets the instantiation SCN for each database object in the oe schema.









Note:

If an apply process applies changes to a remote non-Oracle database, then set the apply_database_link parameter to the database link used for remote apply when you set the instantiation SCN.













See Also:



















Monitoring Instantiation


The following sections contain queries that you can run to determine which database objects are prepared for instantiation at a source database and the instantiation SCN for database objects at a destination database:






Determining Which Database Objects Are Prepared for Instantiation


See "Capture Rules and Preparation for Instantiation" for information about preparing database objects for instantiation.


To determine which database objects have been prepared for instantiation, query the following data dictionary views:


  • 

    DBA_CAPTURE_PREPARED_TABLES
    

  • 

    DBA_SYNC_CAPTURE_PREPARED_TABS
    

  • 

    DBA_CAPTURE_PREPARED_SCHEMAS
    

  • 

    DBA_CAPTURE_PREPARED_DATABASE
    



For example, to list all of the tables that have been prepared for instantiation by the PREPARE_TABLE_INSTANTIATION procedure, the SCN for the time when each table was prepared, and the time when each table was prepared, run the following query:


COLUMN TABLE_OWNER HEADING 'Table Owner' FORMAT A15
COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A15
COLUMN SCN HEADING 'Prepare SCN' FORMAT 99999999999
COLUMN TIMESTAMP HEADING 'Time Ready for|Instantiation'

SELECT TABLE_OWNER, 
       TABLE_NAME, 
       SCN, 
       TO_CHAR(TIMESTAMP, 'HH24:MI:SS MM/DD/YY') TIMESTAMP
  FROM DBA_CAPTURE_PREPARED_TABLES;



Your output looks similar to the following:


                                                  Time Ready for
Table Owner     Table Name            Prepare SCN Instantiation
--------------- --------------- ----------------- -----------------
HR              COUNTRIES                  196655 12:59:30 02/28/02
HR              DEPARTMENTS                196658 12:59:30 02/28/02
HR              EMPLOYEES                  196659 12:59:30 02/28/02
HR              JOBS                       196660 12:59:30 02/28/02
HR              JOB_HISTORY                196661 12:59:30 02/28/02
HR              LOCATIONS                  196662 12:59:30 02/28/02
HR              REGIONS                    196664 12:59:30 02/28/02










Determining the Tables for Which an Instantiation SCN Has Been Set


An instantiation SCN is set at a destination database. It controls which captured logical change records (LCRs) for a database object are ignored by an apply process and which captured LCRs for a database object are applied by an apply process. If the commit SCN of an LCR for a table from a source database is less than or equal to the instantiation SCN for that table at a destination database, then the apply process at the destination database discards the LCR. Otherwise, the apply process applies the LCR. The LCRs can be captured by a capture process or a synchronous capture. See "Setting Instantiation SCNs at a Destination Database".


To determine which database objects have a set instantiation SCN, query the following corresponding data dictionary views:


  • 

    DBA_APPLY_INSTANTIATED_OBJECTS
    

  • 

    DBA_APPLY_INSTANTIATED_SCHEMAS
    

  • 

    DBA_APPLY_INSTANTIATED_GLOBAL
    



The following query lists each table for which an instantiation SCN has been set at a destination database and the instantiation SCN for each table:


COLUMN SOURCE_DATABASE HEADING 'Source Database' FORMAT A20
COLUMN SOURCE_OBJECT_OWNER HEADING 'Object Owner' FORMAT A15
COLUMN SOURCE_OBJECT_NAME HEADING 'Object Name' FORMAT A15
COLUMN INSTANTIATION_SCN HEADING 'Instantiation SCN' FORMAT 99999999999

SELECT SOURCE_DATABASE, 
       SOURCE_OBJECT_OWNER, 
       SOURCE_OBJECT_NAME, 
       INSTANTIATION_SCN 
  FROM DBA_APPLY_INSTANTIATED_OBJECTS
  WHERE APPLY_DATABASE_LINK IS NULL;



Your output looks similar to the following:


Source Database     Object Owner    Object Name     Instantiation SCN
-------------------- --------------- --------------- -----------------
DBS1.EXAMPLE.COM     HR              REGIONS                    196660
DBS1.EXAMPLE.COM     HR              COUNTRIES                  196660
DBS1.EXAMPLE.COM     HR              LOCATIONS                  196660










Note:

You can also display instantiation SCNs for changes that are applied to remote non-Oracle databases. This query does not display these instantiation SCNs because it lists an instantiation SCN only if the APPLY_DATABASE_LINK column is NULL.















PK>{{PK+A
OEBPS/toc.ncx*



      
      
      
      


   Oracle® Streams Replication Administrator's Guide, 11g Release 2 (11.2)




   Cover

   



   Table of Contents

   



   Oracle Streams Replication Administrator's Guide, 11g Release 2 (11.2)

   



   Preface

   



   Configuring Oracle Streams Replication

   



   Preparing for Oracle Streams Replication

   



   Simple Oracle Streams Replication Configuration

   



   Flexible Oracle Streams Replication Configuration

   



   Adding to an Oracle Streams Replication Environment

   



   Configuring Implicit Capture

   



   Configuring Queues and Propagations

   



   Configuring Implicit Apply

   



   Instantiation and Oracle Streams Replication

   



   Oracle Streams Conflict Resolution

   



   Oracle Streams Tags

   



   Oracle Streams Heterogeneous Information Sharing

   



   Administering Oracle Streams Replication

   



   Managing Oracle Streams Replication

   



   Comparing and Converging Data

   



   Managing Logical Change Records (LCRs)

   



   Oracle Streams Replication Best Practices

   



   Best Practices for Oracle Streams Replication Databases

   



   Best Practices for Capture

   



   Best Practices for Propagation

   



   Best Practices for Apply

   



   Appendixes

   



   Migrating Advanced Replication to Oracle Streams

   



   Index

   



   Copyright

   



PKЃPK+AOEBPS/man_gen_rep.htm

Managing Oracle Streams Replication



12 Managing Oracle Streams Replication


This chapter contains instructions for managing an Oracle Streams replication environment.


This chapter contains these topics:






About Managing Oracle Streams


After an Oracle Streams replication environment is in place, you can manage the Oracle Streams components at each database. Management includes administering the components. For example, you can set capture process parameters to modify the behavior of a capture process. Management also includes monitoring the Oracle Streams components and troubleshooting them if there are problems.


The following documentation provides instructions for managing Oracle Streams:


  • 

    Oracle Streams Concepts and Administration provides detailed instructions about managing Oracle Streams components.
    

  • 

    Oracle Database 2 Day + Data Replication and Integration Guide provides instructions about performing the most common management tasks.
    

  • 

    Oracle Streams Replication Administrator's Guide (this document) provides instructions that are specific to an Oracle Streams replication environment.
    

  • 

    The online help for the Oracle Streams interface in Oracle Enterprise Manager provides information about managing Oracle Streams with Oracle Enterprise Manager.
    









Tracking LCRs Through a Stream


A logical change record (LCR) typically flows through a stream in the following way:


  1. 

    A database change is captured, formatted into an LCR, and enqueued. A capture process or a synchronous capture can capture database changes implicitly. An application or user can construct and enqueue LCRs to capture database changes explicitly.
    

  2. 

    One or more propagations send the LCR to other databases in the Oracle Streams environment.
    

  3. 

    One or more apply processes dequeue the LCR and process it.
    



You can track an LCR through a stream using one of the following methods:


  • 

    When LCRs are captured by a capture process, you can set the message_tracking_frequency capture process parameter to 1 or another relatively low value.
    

  • 

    When LCRs are captured by a capture process or a synchronous capture, or when LCRs are constructed by an application, you can run the SET_MESSAGE_TRACKING procedure in the DBMS_STREAMS_ADM package.
    



LCR tracking is useful if LCRs are not being applied as expected by one or more apply processes. When this happens, you can use LCR tracking to determine where the LCRs are stopping in the stream and address the problem at that location.


After using one of these methods to track LCRs, use the V$STREAMS_MESSAGE_TRACKING view to monitor the progress of LCRs through a stream. By tracking an LCR through the stream, you can determine where the LCR is blocked. After LCR tracking is started, each LCR includes a tracking label.


When LCR tracking is started using the message_tracking_frequency capture process parameter, the tracking label is capture_process_name:AUTOTRACK, where capture_process_name is the name of the capture process. Only the first 20 bytes of the capture process name are used; the rest is truncated if it exceeds 20 bytes.


The SET_MESSAGE_TRACKING procedure enables you to specify a tracking label that becomes part of each LCR generated by the current session. Using this tracking label, you can query the V$STREAMS_MESSAGE_TRACKING view to track the LCRs through the stream and see how they were processed by each Oracle Streams client. When you use the SET_MESSAGE_TRACKING procedure, the following LCRs are tracked:


  • 

    When a capture process or a synchronous capture captures an LCR, and a tracking label is set for the session that made the captured database change, the tracking label is included in the LCR automatically.
    

  • 

    When a user or application constructs an LCR and a tracking label is set for the session that constructs the LCR, the tracking label is included in the LCR automatically.
    



To track LCRs through a stream, complete the following steps:


  1. 

    Start LCR tracking.
    

    You can start LCR tracking in one of the following ways:
    


    1. 

      In SQL*Plus, start a session. To use a tracking label for database changes captured by a capture process or synchronous capture, connect to the source database for the capture process or synchronous capture.
      

    2. 

      Begin message tracking:
      

      BEGIN
  DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
    tracking_label => 'TRACK_LCRS');
END;
/

      

      You can use any label you choose to track LCRs. This example uses the TRACK_LCRS label.
      

      Information about the LCRs is tracked in memory, and the V$STREAMS_MESSAGE_TRACKING dynamic performance view is populated with information about the LCRs.
      

    3. 

      Optionally, to ensure that message tracking is set in the session, query the tracking label:
      

      SELECT DBMS_STREAMS_ADM.GET_MESSAGE_TRACKING() TRACKING_LABEL FROM DUAL;

      

      This query should return the tracking label you specified in Step b:
      

      TRACKING_LABEL
--------------------------------------------------------------------------
TRACK_LCRS

    

  2. 

    Make changes to the source database that will be captured by the capture process or synchronous capture that starts the stream, or construct and enqueue the LCRs you want to track. Typically, these LCRs are for testing purposes only. For example, you can insert several dummy rows into a table and then modify these rows. When the testing is complete, you can delete the rows.
    

  3. 

    Monitor the entire Oracle Streams environment to track the LCRs. To do so, query the V$STREAMS_MESSAGE_TRACKING view at each database that processes the LCRs.
    

    For example, run the following query at each database:
    

    COLUMN COMPONENT_NAME HEADING 'Component|Name' FORMAT A10
COLUMN COMPONENT_TYPE HEADING 'Component|Type' FORMAT A12
COLUMN ACTION HEADING 'Action' FORMAT A11
COLUMN SOURCE_DATABASE_NAME HEADING 'Source|Database' FORMAT A10
COLUMN OBJECT_OWNER HEADING 'Object|Owner' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COMMAND_TYPE HEADING 'Command|Type' FORMAT A7
 
SELECT COMPONENT_NAME,
       COMPONENT_TYPE,
       ACTION,
       SOURCE_DATABASE_NAME,
       OBJECT_OWNER,
       OBJECT_NAME,
       COMMAND_TYPE
   FROM V$STREAMS_MESSAGE_TRACKING;

    

    Ensure that you specify the correct tracking label in the WHERE clause.
    

    These queries will show how the LCRs were processed at each database. If the LCRs are not being applied at destination databases, then these queries will show where in the stream the LCRs are stopping.
    

    For example, the output at a source database with a synchronous capture is similar to the following:
    

    Component  Component                Source     Object Object     Command
Name       Type         Action      Database   Owner  Name       Type
---------- ------------ ----------- ---------- ------ ---------- -------
CAPTURE    SYNCHRONOUS  Create      HUB.EXAMPL HR     EMPLOYEES  UPDATE
           CAPTURE                  E.COM
CAPTURE    SYNCHRONOUS  Rule evalua HUB.EXAMPL HR     EMPLOYEES  UPDATE
           CAPTURE      tion        E.COM
CAPTURE    SYNCHRONOUS  Enqueue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
           CAPTURE                  E.COM

    

    The output at a destination database with an apply process is similar to the following:
    

    Component  Component                Source     Object Object     Command
Name       Type         Action      Database   Owner  Name       Type
---------- ------------ ----------- ---------- ------ ---------- -------
APPLY_SYNC APPLY READER Dequeue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
_CAP                                E.COM
APPLY_SYNC APPLY READER Dequeue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
_CAP                                E.COM
APPLY_SYNC APPLY READER Dequeue     HUB.EXAMPL HR     EMPLOYEES  UPDATE
_CAP                                E.COM

    

    You can query additional columns in the V$STREAMS_MESSAGE_TRACKING view to display more information. For example, the ACTION_DETAILS column provides detailed information about each action.
    

  4. 

    Stop message tracking. Complete one of the following actions based your choice in Step 1:
    

    • 

      If you set the message_tracking_frequency capture process parameter in Step 1, then set this parameter back to its default value. The default is to track every two-millionth message.
      

      To set this capture process parameter back to its default value, connect to database running the capture process and set the message_tracking_frequency capture process parameter to NULL.
      

      See Oracle Database 2 Day + Data Replication and Integration Guide or Oracle Streams Concepts and Administration for information about setting capture process parameters.
      

    • 

      If you started message tracking in the current session, then stop message tracking in the session.
      

      To stop message tracking in the current session, set the tracking_label parameter to NULL in the SET_MESSAGE_TRACKING procedure:
      

      BEGIN
  DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
    tracking_label => NULL,
    actions        => DBMS_STREAMS_ADM.ACTION_MEMORY);
END;
/

    










See Also:

Oracle Database PL/SQL Packages and Types Reference for information about the message_tracking_frequency capture process parameter












Splitting and Merging an Oracle Streams Destination


The following sections describe how to split and merge streams and provide examples that do so:






About Splitting and Merging Oracle Streams


Splitting and merging an Oracle Streams destination is useful under the following conditions:


  • 

    A single capture process captures changes that are sent to two or more apply processes.
    

  • 

    An apply process stops accepting changes captured by the capture process. The apply process might stop accepting changes if, for example, the apply process is disabled, the database that contains the apply process goes down, there is a network problem, the computer system running the database that contains the apply process goes down, or for some other reason.
    



When these conditions are met, it is best to split the problem destination off from the other destinations. The reason to split the destination off depends on whether the configuration uses the combined capture and apply optimization:


  • 

    If the apply process at the problem destination is part of a combined capture and apply optimization and the destination is not split off, then performance will suffer when the destination becomes available again. In this case, the capture process must capture the changes that must now be applied at the destination previously split off. The other destinations will not receive more recent changes until the problem destination has caught up. However, if the problem destination is split off, then it can catch up to the other destinations independently, without affecting the other destinations.
    

  • 

    If the apply process at the destination is not part of a combined capture and apply optimization, then captured changes that cannot be sent to the problem destination queue remain in the source queue, causing the source queue size to increase. Eventually, the source queue will spill captured logical change records (LCRs) to hard disk, and the performance of the Oracle Streams replication environment will suffer.
    



Split and merge operations are possible in the following types of Oracle Streams replication environments:


  • 

    Changes captured by a single capture process are sent to multiple remote destinations using propagations and are applied by apply processes at the remote destinations.
    

  • 

    Changes captured by a single capture process are applied locally by multiple apply processes on the same database that is running the capture process.
    

  • 

    Changes captured by a single capture process are sent to one or more remote destinations using propagations and are applied locally by one or more apply processes on the same database that is running the capture process.
    



For environment with local capture and apply, split and merge operations are possible when the capture process and apply processes share the same queue, and when a propagation sends changes from the capture process's queue to an apply process's queue within the one database.


Figure 12-1 shows an Oracle Streams replication environment that uses propagations to send changes to multiple destinations. In this example, destination database A is down.




Figure 12-1 Problem Destination in an Oracle Streams Replication Environment

Description of Figure 12-1 follows

Description of "Figure 12-1 Problem Destination in an Oracle Streams Replication Environment"





You can use the following data dictionary views to determine when there is a problem with a stream:


  • 

    Query the V$BUFFERED_QUEUES view to identify how many messages are in a buffered queue and how many of these messages have spilled to hard disk.
    

  • 

    When propagations are used, query the DBA_PROPAGATION and V$PROPAGATION_SENDER views to show the propagations in a database and the status of each propagation
    



To avoid degraded performance in this situation, split the stream that flows to the problem database off from the other streams flowing from the capture process. When the problem is corrected, merge the stream back into the other streams flowing from the capture process.


You can configure capture process parameters to split and merge a problem stream automatically, or you can split and merge a problem stream manually. Either way, the SPLIT_STREAMS, MERGE_STREAMS_JOB, and MERGE_STREAMS procedures in the DBMS_STREAMS_ADM package are used. The SPLIT_STREAMS procedure splits off the stream for the problem destination from all of the other streams flowing from a capture process to other destinations. The SPLIT_STREAMS procedure always clones the capture process and the queue. The SPLIT_STREAMS procedure also clones the propagation in an environment that sends changes to remote destination databases. The cloned versions of these components are used by the stream that is split off. While the problem stream is split off, the streams to other destinations proceed as usual.


Figure 12-2 shows the cloned stream created by the SPLIT_STREAMS procedure.




Figure 12-2 Splitting Oracle Streams

Description of Figure 12-2 follows

Description of "Figure 12-2 Splitting Oracle Streams"





When the problem destination becomes available again, the cloned stream begins to send captured changes to the destination database again.


Figure 12-3 shows a destination database A that is up and running and a cloned capture process that is enabled at the capture database. The cloned stream begins to flow and starts to catch up to the original streams.




Figure 12-3 Cloned Stream Begins Flowing and Starts to Catch Up to One Original Stream

Description of Figure 12-3 follows

Description of "Figure 12-3 Cloned Stream Begins Flowing and Starts to Catch Up to One Original Stream"





When the cloned stream catches up to one of the original streams, one of the following procedures merges the streams:


  • 

    The MERGE_STREAMS procedure merges the stream that was split off back into the other streams flowing from the original capture process.
    

  • 

    The MERGE_STREAMS_JOB procedure determines whether the streams are within the user-specified merge threshold. If they are, then the MERGE_STREAMS_JOB procedure runs the MERGE_STREAMS procedure. If the streams are not within the merge threshold, then the MERGE_STREAMS_JOB procedure does nothing.
    



Typically, it is best to run the MERGE_STREAMS_JOB procedure instead of running the MERGE_STREAMS procedure directly, because the MERGE_STREAMS_JOB procedure automatically determines whether the streams are ready to merge before merging them.


Figure 12-4 shows the results of running the MERGE_STREAMS procedure. The Oracle Streams replication environment has its original components, and all of the streams are flowing normally.




Figure 12-4 Merging Oracle Streams

Description of Figure 12-4 follows

Description of "Figure 12-4 Merging Oracle Streams"












See Also:

Oracle Streams Concepts and Administration for information about combined capture and apply












Split and Merge Options


The following split and merge options are available:






Automatic Split and Merge


You can set two capture process parameters, split_threshold and merge_theshold, so that Oracle Streams performs split and merge operations automatically. When these parameters are set to specify automatic split and merge, an Oracle Scheduler job monitors the streams flowing from the capture process. When an Oracle Scheduler job identifies a problem with a stream, the job splits the problem stream off from the other streams flowing from the capture process. When a split operation is complete, a new Oracle Scheduler merge job monitors the split stream. When the problem is corrected, this job merges the stream back with the other streams.


When the split_threshold capture process parameter is set to INFINITE, automatic splitting is disabled. When the split_threshold parameter is not set to INFINITE, automatic splitting is enabled. Automatic splitting only occurs when communication with an apply process has been lost for the number of seconds specified in the split_threshold parameter. For example, communication with an apply process is lost when an apply process becomes disabled or a destination database goes down. Automatic splitting does not occur when one stream is processing changes slower than other streams.


When a stream is split, a cloned capture process is created. The cloned capture process might be enabled or disabled after the split depending on whether the configuration uses the combined capture and apply optimization:


  • 

    If the apply process is part of a combined capture and apply optimization, then the cloned capture process is enabled. The cloned capture process does not capture any changes until the apply process is enabled and communication is established with the apply process.
    

  • 

    If the apply process is not part of a combined capture and apply optimization, then the cloned capture process is disabled so that LCRs do not build up in a queue. When the apply process is enabled and the cloned stream can flow, you can start the cloned capture process manually.
    



The split stream is merged back with the original streams automatically when the difference, in seconds, between CAPTURE_MESSAGE_CREATE_TIME in the GV$STREAMS_CAPTURE view of the cloned capture process and the original capture process is less than or equal to the value specified for the merge_threshold capture process parameter. The CAPTURE_MESSAGE_CREATE_TIME records the time when a captured change was recorded in the redo log. If the difference is greater than the value specified by this capture process parameter, then automatic merge does not begin, and the value is recorded in the LAG column of the DBA_STREAMS_SPLIT_MERGE view.


When the capture process and the apply process for a stream run in different database instances, automatic split and merge is always possible for the stream. When a capture process and apply process for a stream run on the same database instance, automatic split and merge is possible only when all of the following conditions are met:


  • 

    The capture process and apply process use the same queue.
    

  • 

    The apply process has no errors in its error queue.
    

  • 

    The apply process is not an XStream outbound server.
    

  • 

    The apply process is stopped.
    

  • 

    No messages have spilled from the buffered queue to the hard disk.
    










See Also:















Manual Split and Automatic Merge


When you split streams manually with the SPLIT_STREAMS procedure, the auto_merge_threshold procedure parameter gives you the option of automatically merging the stream back to the original capture process when the problem at the destination is corrected. After the apply process for the problem stream is accepting changes, you can start the cloned capture process and wait for the cloned capture process to catch up to the original capture process. When the cloned capture process nearly catches up, the auto_merge_threshold parameter setting determines whether the split stream is merged automatically or manually:


  • 

    When auto_merge_threshold is set to a positive number, the SPLIT_STREAMS procedure creates an Oracle Scheduler job with a schedule. The job runs the MERGE_STREAMS_JOB procedure and specifies a merge threshold equal to the value specified in the auto_merge_threshold parameter. You can modify the schedule for a job after it is created.
    

    In this case, the split stream is merged back with the original streams automatically when the difference, in seconds, between CAPTURE_MESSAGE_CREATE_TIME in the GV$STREAMS_CAPTURE view of the cloned capture process and the original capture process is less than or equal to the value specified for the auto_merge_threshold parameter. The CAPTURE_MESSAGE_CREATE_TIME records the time when a captured change was recorded in the redo log.
    

  • 

    When auto_merge_threshold is set to NULL or 0 (zero), the split stream is not merged back with the original streams automatically. To merge the split stream with the original streams, run the MERGE_STREAMS_JOB or MERGE_STREAMS procedure manually.
    










Manual Split and Merge With Generated Scripts


The SPLIT_STREAMS and MERGE_STREAMS procedures can perform actions directly or generate a script that performs the actions when the script is run. Using a procedure to perform actions directly is simpler than running a script, and the split or merge operation is performed immediately. However, you might choose to generate a script for the following reasons:


  • 

    You want to review the actions performed by the procedure before splitting or merging streams.
    

  • 

    You want to modify the script to customize its actions.
    



For example, you might choose to modify the script if you want to change the rules in the rule set for the cloned capture process. In some Oracle Streams replication environments, only a subset of the changes made to the source database are sent to each destination database, and each destination database might receive a different subset of the changes. In such an environment, you can modify the rule set for the cloned capture process so that it only captures changes that are propagated by the cloned propagation.


The perform_actions parameter in each procedure controls whether the procedure performs actions directly:


  • 

    To split or merge streams directly when you run one of these procedures, set the perform_actions parameter to TRUE. The default value for this parameter is TRUE.
    

  • 

    To generate a script when you run one of these procedures, set the perform_actions parameter to FALSE, and use the script_name and script_directory_object parameters to specify the name and location of the script.
    












Examples That Split and Merge Oracle Streams


The following sections provide instructions for splitting and merging streams:



These examples make the following assumptions about the Oracle Streams replication environment:


  • 

    A single capture process named strms_capture captures changes that are sent to three destination databases.
    

  • 

    The propagations that send these changes to the destination queues at the destination databases are the following:
    

    • 

      strms_prop_a
      

    • 

      strms_prop_b
      

    • 

      strms_prop_c
      

    

  • 

    A queue named streams_queue is the source queue for all three propagations.
    

  • 

    There is a problem at the destination for the strms_prop_a propagation. This propagation cannot send messages to the destination queue.
    

  • 

    The other two propagations (strms_prop_b and strms_prop_c) are propagating messages normally.
    







Splitting and Merging an Oracle Streams Destination Automatically


Before reviewing this example, see the following sections:



Complete the following steps to split and merge a stream automatically:


  1. 

    In SQL*Plus, connect as the Oracle Streams administrator to the database with the capture process.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Ensure that the following parameters are set properly for the strms_capture capture process to enable automatic split and merge:
    

    • 

      split_threshold: Ensure that this parameter is not set to INFINITE. The default setting for this parameter is 1800 seconds.
      

    • 

      merge_threshold: Ensure that this parameter is not set to a negative value. The default setting for this parameter is 60 seconds.
      

    

    To check the settings for these parameters, query the DBA_CAPTURE_PARAMETERS view. See Oracle Streams Concepts and Administration for instructions.
    

  3. 

    If you must reset one or both of the capture process parameters described in Step 2, then use Oracle Enterprise Manager or the SET_PARAMETER procedure in the DBMS_CAPTURE_ADM package to reset the parameters. See Oracle Database 2 Day + Data Replication and Integration Guide for instructions about using Oracle Enterprise Manager. See Oracle Streams Concepts and Administration for instructions about using the SET_PARAMETER procedure.
    

  4. 

    Monitor the DBA_STREAMS_SPLIT_MERGE view periodically to check whether an automatic split and merge operation is in process.
    

    When an automatic split occurs, certain components, such as the capture process, queue, and propagation, are cloned, and each is given a system-generated name. The DBA_STREAMS_SPLIT_MERGE view contains the name of each cloned component, and other information about the split and merge operation.
    

    Query the DBA_STREAMS_SPLIT_MERGE view to determine whether a stream has been split off from the original capture process:
    

    COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original|Capture|Process' FORMAT A10
COLUMN ACTION_TYPE HEADING 'Action|Type' FORMAT A7
COLUMN STATUS_UPDATE_TIME HEADING 'Status|Update|Time' FORMAT A15
COLUMN STATUS HEADING 'Status' FORMAT A16
COLUMN JOB_NEXT_RUN_DATE HEADING 'Next Job|Run Date' FORMAT A20
 
SELECT ORIGINAL_CAPTURE_NAME,
       ACTION_TYPE,
       STATUS_UPDATE_TIME, 
       STATUS, 
       JOB_NEXT_RUN_DATE 
  FROM DBA_STREAMS_SPLIT_MERGE 
  ORDER BY STATUS_UPDATE_TIME DESC;

    

    If a stream has been split off from the original capture process, then your output looks similar to the following:
    

    Original           Status
Capture    Action  Update                           Next Job
Process    Type    Time            Status           Run Date
---------- ------- --------------- ---------------- --------------------
DB$CAP     MERGE   01-APR-09 06.49 NOTHING TO MERGE 01-APR-09 06.54.29.0
                   .29.204804 AM                    00000 AM -07:00
DB$CAP     SPLIT   01-APR-09 06.49 SPLIT DONE       01-APR-09 06.47.59.0
                   .17.389146 AM                    00000 AM -07:00

    

    This output shows that an automatic split was performed. The merge job was run at 01-APR-09 06.49.29.204804 AM, but the status shows NOTHING TO MERGE because the split stream is not ready to merge yet. The SPLIT DONE status indicates that the stream was split off at the following date and time: 01-APR-09 06.49.17.389146 AM.
    

  5. 

    After an automatic split is performed, correct the problem with the destination. The problem is corrected when the apply process at the destination database can accept changes from the cloned capture process. An Oracle Scheduler job performs an automatic merge when the problem is corrected.
    

  6. 

    If the cloned capture process is disabled, then start the cloned capture process. The cloned capture process is disabled only if the stream is not a combined capture and apply optimization. See Oracle Streams Concepts and Administration for instructions for starting a capture process.
    



The cloned capture process captures changes that satisfy its rule sets. These changes are sent to the apply process.


During this time, an Oracle Scheduler job runs the MERGE_STREAMS_JOB procedure according to its schedule. The MERGE_STREAMS_JOB procedure queries the CAPTURE_MESSAGE_CREATE_TIME in the GV$STREAMS_CAPTURE view. When the difference between CAPTURE_MESSAGE_CREATE_TIME of the cloned capture process and the original capture process is less than or equal to the value of the merge_threshold capture process parameter, the MERGE_STREAMS_JOB procedure determines that the streams are ready to merge. The MERGE_STREAMS_JOB procedure runs the MERGE_STREAMS procedure automatically to merge the streams back together.


The LAG column in the DBA_STREAMS_SPLIT_MERGE view tracks the time in seconds that the cloned capture process lags behind the original capture process. The following query displays the lag time:


COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original Capture Process' FORMAT A25
COLUMN CLONED_CAPTURE_NAME HEADING 'Cloned Capture Process' FORMAT A25
COLUMN LAG HEADING 'Lag' FORMAT 999999999999999
 
SELECT ORIGINAL_CAPTURE_NAME,
       CLONED_CAPTURE_NAME,
       LAG
 FROM DBA_STREAMS_SPLIT_MERGE
 WHERE ACTION_TYPE = 'MERGE';



Your output looks similar to the following:


Original Capture Process  Cloned Capture Process                 Lag
------------------------- ------------------------- ----------------
DB$CAP                    CLONED$_DB$CAP_5                      2048



This output shows that there is a lag of 2,048 seconds between the CAPTURE_MESSAGE_CREATE_TIME values for the original capture process and the cloned capture process. When the cloned capture process is within the threshold, the merge job can start the MERGE_STREAMS procedure. By default, the merge threshold is 60 seconds.


The MERGE_STREAMS procedure performs the following actions:


  • 

    Stops the cloned capture process.
    

  • 

    Re-creates the original propagation called strms_prop_a.
    

  • 

    Drops the cloned propagation.
    

  • 

    Drops the cloned capture process.
    

  • 

    Drops the cloned queue.
    



Repeat the query in Step 4 periodically to monitor the split and merge operation. After the merge operation is complete, the output for this query is similar to the following:


Original           Status
Capture    Action  Update                           Next Job
Process    Type    Time            Status           Run Date
---------- ------- --------------- ---------------- --------------------
DB$CAP     MERGE   01-APR-09 07.32 NOTHING TO MERGE 01-APR-09 07.37.04.0
                   .04.820795 AM                    00000 AM -07:00
DB$CAP     MONITOR 01-APR-09 07.32 MERGE DONE       01-APR-09 07.36.20.0
                   .04.434925 AM                    00000 AM -07:00
DB$CAP     SPLIT   01-APR-09 06.49 SPLIT DONE       01-APR-09 06.47.59.0
                   .17.389146 AM                    00000 AM -07:00



This output shows that the split stream was merged back into the original capture process at the following date an time: 01-APR-09 07.32.04.434925 AM. The next status shows NOTHING TO MERGE because there are no remaining split streams.


After the streams are merged, the Oracle Streams replication environment has the same components as it had before the split and merge operation. Information about the completed split and merge operation is stored in the DBA_STREAMS_SPLIT_MERGE_HIST for future reference.









See Also:

Oracle Streams Concepts and Administration for information about monitoring automatic split and merge operations












Splitting an Oracle Streams Destination Manually and Merging It Automatically


Before reviewing this example, see the following sections:



The example in this section splits the stream manually and merges it automatically. That is, the perform_actions parameter is set to TRUE in the SPLIT_STREAMS procedure. Also, the example merges the streams automatically at the appropriate time because the auto_merge_threshold parameter is to set a positive number (60) in the SPLIT_STREAMS procedure.


Complete the following steps to split streams directly and merge streams automatically:


  1. 

    In SQL*Plus, connect as the Oracle Streams administrator to the database with the capture process.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Run the following procedure to split the stream flowing through propagation strms_prop_a from the other propagations flowing from the strms_capture capture process:
    

    DECLARE
    schedule_name  VARCHAR2(30);
    job_name       VARCHAR2(30);
BEGIN
    schedule_name := 'merge_job1_schedule';
    job_name      := 'merge_job1';
  DBMS_STREAMS_ADM.SPLIT_STREAMS(
    propagation_name        => 'strms_prop_a',
    cloned_propagation_name => 'cloned_prop_a',
    cloned_queue_name       => 'cloned_queue',
    cloned_capture_name     => 'cloned_capture',
    perform_actions         => TRUE,
    auto_merge_threshold    => 60,
    schedule_name           => schedule_name,
    merge_job_name          => job_name);
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates a new queue called cloned_queue.
      

    • 

      Creates a new propagation called cloned_prop_a that propagates messages from the cloned_queue queue to the existing destination queue used by the strms_prop_a propagation. The cloned propagation cloned_prop_a uses the same rule set as the original propagation strms_prop_a.
      

    • 

      Stops the capture process strms_capture.
      

    • 

      Queries the acknowledge SCN for the original propagation strms_prop_a. The acknowledged SCN is the last SCN acknowledged by the apply process that applies the changes sent by the propagation. The ACKED_SCN value in the DBA_PROPAGATION view shows the acknowledged SCN for a propagation.
      

    • 

      Creates a new capture process called cloned_capture. The start SCN for cloned_capture is set to the value of the acknowledged SCN for the strms_prop_a propagation. The cloned capture process cloned_capture uses the same rule set as the original capture process strms_capture.
      

    • 

      Drops the original propagation strms_prop_a.
      

    • 

      Starts the original capture process strms_capture with the start SCN set to the value of the acknowledged SCN for the strms_prop_a propagation.
      

    • 

      Creates an Oracle Scheduler job named merge_job1 with a schedule named merge_job1_schedule. Both the job and the schedule are owned by the user who ran the SPLIT_STREAMS procedure. The schedule starts to run when the SPLIT_STREAMS procedure completes. The system defines the initial schedule, but you can modify it in the same way that you would modify any Oracle Scheduler job. See Oracle Database Administrator's Guide for instructions.
      

    

  3. 

    Correct the problem with the destination of cloned_prop_a. The problem is corrected when the apply process at the destination database can accept changes from the cloned capture process.
    

  4. 

    While connected as the Oracle Streams administrator, start the cloned capture process by running the following procedure:
    

    exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');



After the cloned capture process cloned_capture starts running, it captures changes that satisfy its rule sets from the acknowledged SCN forward. These changes are propagated by the cloned_prop_a propagation and processed by the apply process at the destination database.


During this time, the Oracle Scheduler job runs the MERGE_STREAMS_JOB procedure according to its schedule. The MERGE_STREAMS_JOB procedure queries the CAPTURE_MESSAGE_CREATE_TIME in the GV$STREAMS_CAPTURE view. When the difference between CAPTURE_MESSAGE_CREATE_TIME of the cloned capture process cloned_capture and the original capture process strms_capture is less than or equal 60 seconds, the MERGE_STREAMS_JOB procedure determines that the streams are ready to merge. The MERGE_STREAMS_JOB procedure runs the MERGE_STREAMS procedure automatically to merge the streams back together.


The following query displays the CAPTURE_MESSAGE_CREATE_TIME for the original capture process and cloned capture process:


COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A17
COLUMN STATE HEADING 'State' FORMAT A20
COLUMN CREATE_MESSAGE HEADING 'Last Message|Create Time'
 
SELECT CAPTURE_NAME,
 STATE,
 TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') CREATE_MESSAGE
 FROM V$STREAMS_CAPTURE;



Your output looks similar to the following:


Capture                                Last Message
Name              State                Create Time
----------------- -------------------- -----------------
DB$CAP            CAPTURING CHANGES    07:22:55 04/01/09
CLONED$_DB$CAP_5  CAPTURING CHANGES    06:50:39 04/01/09



This output shows that there is more than a 30 minute difference between the CAPTURE_MESSAGE_CREATE_TIME values for the original capture process and the cloned capture process. When the cloned capture process is within the threshold, the merge job can start the MERGE_STREAMS procedure. By default, the merge threshold is 60 seconds.


The MERGE_STREAMS procedure performs the following actions:


  • 

    Stops the cloned capture process cloned_capture.
    

  • 

    Re-creates the propagation called strms_prop_a.
    

  • 

    Drops the cloned propagation cloned_prop_a.
    

  • 

    Drops the cloned capture process cloned_capture.
    

  • 

    Drops the cloned queue cloned_queue.
    



After the streams are merged, the Oracle Streams replication environment has the same components as it had before the split and merge operation. Information about the completed split and merge operation is stored in the DBA_STREAMS_SPLIT_MERGE_HIST for future reference.








Splitting and Merging an Oracle Streams Destination Manually With Scripts


Before reviewing this example, see the following sections:



The example in this section splits and merges streams by generating and running scripts. That is, the perform_actions parameter is set to FALSE in the SPLIT_STREAMS procedure. Also, the example merges the streams manually at the appropriate time because the auto_merge_threshold parameter is set to NULL in the SPLIT_STREAMS procedure.


Complete the following steps to use scripts to split and merge streams:


  1. 

    In SQL*Plus, connect as the Oracle Streams administrator to the database with the capture process.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    If it does not already exist, then create a directory object named db_dir to hold the scripts generated by the procedures:
    

    CREATE DIRECTORY db_dir AS '/usr/db_files';

  3. 

    Run the following procedure to generate a script to split the streams:
    

    DECLARE
    schedule_name  VARCHAR2(30);
    job_name       VARCHAR2(30);
BEGIN
  DBMS_STREAMS_ADM.SPLIT_STREAMS(
    propagation_name        => 'strms_prop_a',
    cloned_propagation_name => 'cloned_prop_a',
    cloned_queue_name       => 'cloned_queue',
    cloned_capture_name     => 'cloned_capture',
    perform_actions         => FALSE,
    script_name             => 'split.sql',
    script_directory_object => 'db_dir',
    auto_merge_threshold    => NULL,
    schedule_name           => schedule_name,
    merge_job_name          => job_name);
END;
/

    

    Running this procedure generates the split.sql script. The script contains the actions that will split the stream flowing through propagation strms_prop_a from the other propagations flowing from the strms_capture capture process.
    

  4. 

    Go to the directory used by the db_dir directory object, and open the split.sql script with a text editor.
    

  5. 

    Examine the script and make modifications, if necessary.
    

  6. 

    Save and close the script.
    

  7. 

    While connected as the Oracle Streams administrator in SQL*Plus, run the script:
    

    @/usr/db_files/split.sql

    

    Running the script performs the following actions:
    

    • 

      Runs the SET_UP_QUEUE procedure in the DBMS_STREAMS_ADM package to create a queue called cloned_queue.
      

    • 

      Runs the CREATE_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package to create a propagation called cloned_prop_a. This new propagation propagates messages from the cloned_queue queue to the existing destination queue used by the strms_prop_a propagation. The cloned propagation cloned_prop_a uses the same rule set as the original propagation strms_prop_a.
      

      The CREATE_PROPAGATION procedure sets the original_propagation_name parameter to strms_prop_a and the auto_merge_threshold parameter to NULL.
      

    • 

      Runs the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package to stop the capture process strms_capture.
      

    • 

      Queries the acknowledge SCN for the original propagation strms_prop_a. The acknowledged SCN is the last SCN acknowledged by the apply process that applies the changes sent by the propagation. The ACKED_SCN value in the DBA_PROPAGATION view shows the acknowledged SCN for a propagation.
      

    • 

      Runs the CREATE_CAPTURE procedure in the DBMS_CAPTURE_ADM package to create a capture process called cloned_capture. The start SCN for cloned_capture is set to the value of the acknowledged SCN for the strms_prop_a propagation. The cloned capture process cloned_capture uses the same rule set as the original capture process strms_capture.
      

    • 

      Runs the DROP_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package to drop the original propagation strms_prop_a.
      

    • 

      Runs the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package to start the original capture process strms_capture with the start SCN set to the value of the acknowledged SCN for the strms_prop_a propagation.
      

    

  8. 

    Correct the problem with the destination of cloned_prop_a. The problem is corrected when the apply process at the destination database can accept changes from the cloned capture process.
    

  9. 

    While connected as the Oracle Streams administrator, start the cloned capture process by running the following procedure:
    

    exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');

  10. 

    Monitor the Oracle Streams replication environment until the cloned capture process catches up to, or nearly catches up to, the original capture process. Specifically, query the CAPTURE_MESSAGE_CREATION_TIME column in the GV$STREAMS_CAPTURE view for each capture process.
    

    Run the following query to check the CAPTURE_MESSAGE_CREATE_TIME for each capture process periodically:
    

    SELECT CAPTURE_NAME,
       TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') 
   FROM GV$STREAMS_CAPTURE;

    

    Do not move on to the next step until the difference between CAPTURE_MESSAGE_CREATE_TIME of the cloned capture process cloned_capture and the original capture process strms_capture is relatively small.
    

  11. 

    Run the following procedure to generate a script to merge the streams:
    

    BEGIN
  DBMS_STREAMS_ADM.MERGE_STREAMS(
    cloned_propagation_name => 'cloned_prop_a',
    perform_actions         => FALSE,
    script_name             => 'merge.sql',
    script_directory_object => 'db_dir');
END;
/

    

    Running this procedure generates the merge.sql script. The script contains the actions that will merge the stream flowing through propagation cloned_prop_a with the other propagations flowing from the strms_capture capture process.
    

  12. 

    Go to the directory used by the db_dir directory object, and open the merge.sql script with a text editor.
    

  13. 

    Examine the script and make modifications, if necessary.
    

  14. 

    Save and close the script.
    

  15. 

    While connected as the Oracle Streams administrator in SQL*Plus, run the script:
    

    @/usr/db_files/merge.sql

    

    Running the script performs the following actions:
    

    • 

      Runs the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package to stop the cloned capture process cloned_capture.
      

    • 

      Runs the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package to stop the original capture process strms_capture.
      

    • 

      Runs the CREATE_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package to re-create the propagation called strms_prop_a.
      

    • 

      Starts the original capture process strms_capture from the lower SCN value of these two SCN values:
      

      • 

        The acknowledged SCN of the cloned propagation cloned_prop_a.
        

      • 

        The lowest acknowledged SCN of the other propagations that propagate changes captured by the original capture process (propagations strms_prop_b and strms_prop_c in this example).
        

      

      When the strms_capture capture process is started, it might recapture changes that it already captured, or it might capture changes that were already captured by the cloned capture process cloned_capture. In either case, the relevant apply processes will discard any duplicate changes they receive.
      

    • 

      Runs the DROP_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package to drop the cloned propagation cloned_prop_a.
      

    • 

      Runs the DROP_CAPTURE procedure in the DBMS_CAPTURE_ADM package to drop the cloned capture process cloned_capture.
      

    • 

      Runs the REMOVE_QUEUE procedure in the DBMS_STREAMS_ADM package to drop the cloned queue cloned_queue.
      

    



After the script runs successfully, the streams are merged, and the Oracle Streams replication environment has the same components as it had before the split and merge operation. Information about the completed split and merge operation is stored in the DBA_STREAMS_SPLIT_MERGE_HIST for future reference.












Changing the DBID or Global Name of a Source Database


Typically, database administrators change the DBID and global name of a database when it is a clone of another database. You can view the DBID of a database by querying the DBID column in the V$DATABASE dynamic performance view, and you can view the global name of a database by querying the GLOBAL_NAME static data dictionary view. When you change the DBID or global name of a source database, any existing capture processes that capture changes originating at this source database become unusable. The capture processes can be local capture processes or downstream capture processes that capture changes that originated at the source database. Also, any existing apply processes that apply changes from the source database become unusable. However, existing synchronous captures and propagations do not need to be re-created, although modifications to propagation rules might be necessary.


If a capture process or synchronous capture is capturing changes to a source database for which you have changed the DBID or global name, then complete the following steps:


  1. 

    Shut down the source database.
    

  2. 

    Restart the source database with RESTRICTED SESSION enabled using STARTUP RESTRICT.
    

  3. 

    Drop the capture process using the DROP_CAPTURE procedure in the DBMS_CAPTURE_ADM package. The capture process can be a local capture process at the source database or a downstream capture process at a remote database. Synchronous captures do not need to be dropped.
    

  4. 

    At the source database, run the ALTER SYSTEM SWITCH LOGFILE statement on the database.
    

  5. 

    If any changes have been captured from the source database, then manually resynchronize the data at all destination databases that apply changes originating at this source database. If the database never captured any changes, then this step is not necessary.
    

  6. 

    Modify any rules that use the source database name as a condition. The source database name should be changed to the new global name of the source database where appropriate in these rules. You might need to modify capture process rules, propagation rules, and apply process rules at the local database and at remote databases in the environment. Typically, synchronous capture rules do not contain a condition for the source database.
    

  7. 

    Drop the apply processes that apply changes from the capture process that you dropped in Step 3. Use the DROP_APPLY procedure in the DBMS_APPLY_ADM package to drop an apply process. Apply processes that apply changes captured by synchronous capture do not need to be dropped.
    

  8. 

    At each destination database that applies changes from the source database, re-create the apply processes you dropped in Step 7. You might want to associate the each apply process with the same rule sets it used before it was dropped. See Chapter 7, "Configuring Implicit Apply" for instructions.
    

  9. 

    Re-create the capture process you dropped in Step 3, if necessary. You might want to associate the capture process with the same rule sets used by the capture process you dropped in Step 3. See "Configuring a Capture Process" for instructions.
    

  10. 

    At the source database, prepare database objects whose changes will be captured by the re-created capture process for instantiation. See "Preparing Database Objects for Instantiation at a Source Database".
    

  11. 

    At each destination database that applies changes from the source database, set the instantiation SCN for all databases objects to which changes from the source database will be applied. See "Setting Instantiation SCNs at a Destination Database" for instructions.
    

  12. 

    Disable the restricted session using the ALTER SYSTEM DISABLE RESTRICTED SESSION statement.
    

  13. 

    At each destination database that applies changes from the source database, start the apply processes you created in Step 8.
    

  14. 

    At the source database, start the capture process you created in Step 9.
    










See Also:

Oracle Database Utilities for more information about changing the DBID of a database using the DBNEWID utility












Resynchronizing a Source Database in a Multiple-Source Environment


A multiple-source environment is one in which there is more than one source database for any of the shared data. If a source database in a multiple-source environment cannot be recovered to the current point in time, then you can use the method described in this section to resynchronize the source database with the other source databases in the environment. Some reasons why a database cannot be recovered to the current point in time include corrupted archived redo logs or the media failure of an online redo log group.


For example, a bidirectional Oracle Streams environment is one in which exactly two databases share the replicated database objects and data. In this example, assume that database A is the database that must be resynchronized and that database B is the other source database in the environment. To resynchronize database A in this bidirectional Oracle Streams environment, complete the following steps:


  1. 

    Verify that database B has applied all of the changes sent from database A. You can query the V$BUFFERED_SUBSCRIBERS data dictionary view at database B to determine whether the apply process that applies these changes has any unapplied changes in its queue. See the example on viewing propagations dequeuing LCRs from each buffered queue in Oracle Streams Concepts and Administration for an example of such a query. Do not continue until all of these changes have been applied.
    

  2. 

    Remove the Oracle Streams configuration from database A by running the REMOVE_STREAMS_CONFIGURATION procedure in the DBMS_STREAMS_ADM package. See Oracle Database PL/SQL Packages and Types Reference for more information about this procedure.
    

  3. 

    At database B, drop the apply process that applies changes from database A. Do not drop the rule sets used by this apply process because you will re-create the apply process in a subsequent step.
    

  4. 

    Complete the steps in "Adding a New Database to an Existing Multiple-Source Environment" to add database A back into the Oracle Streams environment.
    









Performing Database Point-in-Time Recovery in an Oracle Streams Environment


Point-in-time recovery is the recovery of a database to a specified noncurrent time, SCN, or log sequence number. The following sections discuss performing point-in-time recovery in an Oracle Streams replication environment:










See Also:

Oracle Database Backup and Recovery User's Guide for more information about point-in-time recovery









Performing Point-in-Time Recovery on the Source in a Single-Source Environment


A single-source Oracle Streams replication environment is one in which there is only one source database for shared data. If database point-in-time recovery is required at the source database in a single-source Oracle Streams environment, and any capture processes that capture changes generated at a source database are running, then you must stop these capture processes before you perform the recovery operation. Both local and downstream capture process that capture changes generated at the source database must be stopped. Typically, database administrators reset the log sequence number of a database during point-in-time recovery. The ALTER DATABASE OPEN RESETLOGS statement is an example of a statement that resets the log sequence number.


The instructions in this section assume that the single-source replication environment has the following characteristics:


  • 

    Only one capture process named strm01_capture, which can be a local or downstream capture process
    

  • 

    Only one destination database with the global name dest.example.com
    

  • 

    Only one apply process named strm01_apply at the destination database
    



If point-in-time recovery must be performed on the source database, then you can follow these instructions to recover as many transactions as possible at the source database by using transactions applied at the destination database. These instructions assume that you can identify the transactions applied at the destination database after the source point-in-time SCN and execute these transactions at the source database.









Note:

Oracle recommends that you set the apply process parameter commit_serialization to FULL when performing point-in-time recovery in a single-source Oracle Streams replication environment.






Complete the following steps to perform point-in-time recovery on the source database in a single-source Oracle Streams replication environment:



  1. 

    Perform point-in-time recovery on the source database if you have not already done so. Note the point-in-time recovery SCN because it is needed in subsequent steps.
    

  2. 

    Ensure that the source database is in restricted mode.
    

  3. 

    Connect to the database running the capture process and list the rule sets used by the capture process.
    

    To list the rule sets used by the capture process, run the following query:
    

    COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15
 
SELECT CAPTURE_NAME, 
       RULE_SET_OWNER, 
       RULE_SET_NAME, 
       NEGATIVE_RULE_SET_OWNER, 
       NEGATIVE_RULE_SET_NAME
   FROM DBA_CAPTURE;

    

    Make a note of the rule sets used by the capture process. You will need to specify these rule sets for the new capture process in Step 12.
    

  4. 

    Connect to the destination database and list the rule sets used by the apply process.
    

    To list the rule sets used by the capture process, run the following query:
    

    COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A15
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15
 
SELECT APPLY_NAME, 
       RULE_SET_OWNER, 
       RULE_SET_NAME, 
       NEGATIVE_RULE_SET_OWNER, 
       NEGATIVE_RULE_SET_NAME
   FROM DBA_APPLY;

    

    Make a note of the rule sets used by the apply process. You will need to specify these rule sets for the new apply process in Step k.
    

  5. 

    Stop the capture process using the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
    

  6. 

    At the source database, perform a data dictionary build:
    

    SET SERVEROUTPUT ON
DECLARE
  scn  NUMBER;
BEGIN
  DBMS_CAPTURE_ADM.BUILD(
    first_scn => scn);
  DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/

    

    Note the SCN value returned because it is needed in Step 12.
    

  7. 

    At the destination database, wait until all of the transactions from the source database in the apply process's queue have been applied. The apply processes should become idle when these transactions have been applied. You can query the STATE column in both the V$STREAMS_APPLY_READER and V$STREAMS_APPLY_SERVER. The state should be IDLE for the apply process in both views before you continue.
    

  8. 

    Perform a query at the destination database to determine the highest SCN for a transaction that was applied.
    

    If the apply process is running, then perform the following query:
    

    SELECT HWM_MESSAGE_NUMBER FROM V$STREAMS_APPLY_COORDINATOR
  WHERE APPLY_NAME = 'STRM01_APPLY';

    

    If the apply process is disabled, then perform the following query:
    

    SELECT APPLIED_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS
  WHERE APPLY_NAME = 'STRM01_APPLY';

    

    Note the highest apply SCN returned by the query because it is needed in subsequent steps.
    

  9. 

    If the highest apply SCN obtained in Step 8 is less than the point-in-time recovery SCN noted in Step 1, then proceed to Step 10. Otherwise, if the highest apply SCN obtained in Step 8 is greater than or equal to the point-in-time recovery SCN noted in Step 1, then the apply process has applied some transactions from the source database after point-in-time recovery SCN, and you must complete the following steps:
    

    1. 

      Manually execute the transactions that were applied after the point-in-time SCN at the source database. When you execute these transactions at the source database, ensure that you set an Oracle Streams tag in the session so that the transactions will not be captured by the capture process. If no such Oracle Streams session tag is set, then these changes can be cycled back to the destination database. See "Managing Oracle Streams Tags for the Current Session" for instructions.
      

    2. 

      Disable the restricted session at the source database.
      

    3. 

      Proceed to Step 11. Do not complete Step 10.
      

    

  10. 

    If the highest apply SCN obtained in Step 8 is less than the point-in-time recovery SCN noted in Step 1, then the apply process has not applied any transactions from the source database after point-in-time recovery SCN, and you must complete the following steps:
    

    1. 

      Disable the restricted session at the source database.
      

    2. 

      Ensure that the apply process is running at the destination database.
      

    3. 

      Set the maximum_scn capture process parameter of the original capture process to the point-in-time recovery SCN using the SET_PARAMETER procedure in the DBMS_CAPTURE_ADM package.
      

    4. 

      Set the start SCN of the original capture process to the oldest SCN of the apply process. You can determine the oldest SCN of a running apply process by querying the OLDEST_SCN_NUM column in the V$STREAMS_APPLY_READER dynamic performance view at the destination database. To set the start SCN of the capture process, specify the start_scn parameter when you run the ALTER_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
      

    5. 

      Ensure that the capture process writes information to the alert log by running the following procedure:
      

      BEGIN
  DBMS_CAPTURE_ADM.SET_PARAMETER(
    capture_name => 'strm01_capture',
    parameter    => 'write_alert_log', 
    value        => 'Y');
END;
/

    6. 

      Start the original capture process using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
      

    7. 

      Ensure that the original capture process has captured all changes up to the maximum_scn setting by querying the CAPTURED_SCN column in the DBA_CAPTURE data dictionary view. When the value returned by the query is equal to or greater than the maximum_scn value, the capture process should stop automatically. When the capture process is stopped, proceed to the next step.
      

    8. 

      Find the value of the LAST_ENQUEUE_MESSAGE_NUMBER in the alert log. Note this value because it is needed in subsequent steps.
      

    9. 

      At the destination database, wait until all the changes are applied. You can monitor the applied changes for the apply process strm01_apply by running the following queries at the destination database:
      

      SELECT DEQUEUED_MESSAGE_NUMBER
  FROM V$STREAMS_APPLY_READER
  WHERE APPLY_NAME = 'STRM01_APPLY' AND
        DEQUEUED_MESSAGE_NUMBER = last_enqueue_message_number;

      

      Substitute the LAST_ENQUEUE_MESSAGE_NUMBER found in the alert log in Step h for last_enqueue_message_number on the last line of the query. When this query returns a row, all of the changes from the capture database have been applied at the destination database.
      

      Also, ensure that the state of the apply process reader server and each apply server is IDLE. For example, run the following queries for an apply process named strm01_apply:
      

      SELECT STATE FROM V$STREAMS_APPLY_READER 
  WHERE APPLY_NAME = 'STRM01_APPLY';

SELECT STATE FROM V$STREAMS_APPLY_SERVER 
  WHERE APPLY_NAME = 'STRM01_APPLY';

      

      When both of these queries return IDLE, move on to the next step.
      

    10. 

      At the destination database, drop the apply process using the DROP_APPLY procedure in the DBMS_APPLY_ADM package.
      

    11. 

      At the destination database, create a new apply process. The new apply process should use the same queue and rule sets used by the original apply process.
      

    12. 

      At the destination database, start the new apply process using the START_APPLY procedure in the DBMS_APPLY_ADM package.
      

    

  11. 

    Drop the original capture process using the DROP_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
    

  12. 

    Create a new capture process using the CREATE_CAPTURE procedure in the DBMS_CAPTURE_ADM package to replace the capture process you dropped in Step 11. Specify the SCN returned by the data dictionary build in Step 6 for both the first_scn and start_scn parameters. The new capture process should use the same queue and rule sets as the original capture process.
    

  13. 

    Start the new capture process using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
    









Performing Point-in-Time Recovery in a Multiple-Source Environment


A multiple-source environment is one in which there is more than one source database for any of the shared data. If database point-in-time recovery is required at a source database in a multiple-source Oracle Streams environment, then you can use another source database in the environment to recapture the changes made to the recovered source database after the point-in-time recovery.


For example, in a multiple-source Oracle Streams environment, one source database can become unavailable at time T2 and undergo point in time recovery to an earlier time T1. After recovery to T1, transactions performed at the recovered database between T1 and T2 are lost at the recovered database. However, before the recovered database became unavailable, assume that these transactions were propagated to another source database and applied. In this case, you can use this other source database to restore the lost changes to the recovered database.


Specifically, to restore changes made to the recovered database after the point-in-time recovery, you configure a capture process to recapture these changes from the redo logs at the other source database, a propagation to propagate these changes from the database where changes are recaptured to the recovered database, and an apply process at the recovered database to apply these changes.


Changes originating at the other source database that were applied at the recovered database between T1 and T2 also have been lost and must be recovered. To accomplish this, alter the capture process at the other source database to start capturing changes at an earlier SCN. This SCN is the oldest SCN for the apply process at the recovered database.


The following SCN values are required to restore lost changes to the recovered database:


  • 

    Point-in-time SCN: The SCN for the point-in-time recovery at the recovered database.
    

  • 

    Instantiation SCN: The SCN value to which the instantiation SCN must be set for each database object involved in the recovery at the recovered database while changes are being reapplied. At the other source database, this SCN value corresponds to one less than the commit SCN of the first transaction that was applied at the other source database and lost at the recovered database.
    

  • 

    Start SCN: The SCN value to which the start SCN is set for the capture process created to recapture changes at the other source database. This SCN value corresponds to the earliest SCN at which the apply process at the other source database started applying a transaction that was lost at the recovered database. This capture process can be a local or downstream capture process that uses the other source database for its source database.
    

  • 

    Maximum SCN: The SCN value to which the maximum_scn parameter for the capture process created to recapture lost changes should be set. The capture process stops capturing changes when it reaches this SCN value. The current SCN for the other source database is used for this value.
    



You should record the point-in-time SCN when you perform point-in-time recovery on the recovered database. You can use the GET_SCN_MAPPING procedure in the DBMS_STREAMS_ADM package to determine the other necessary SCN values.









See Also:

Oracle Database PL/SQL Packages and Types Reference for more information about the GET_SCN_MAPPING procedure












Performing Point-in-Time Recovery on a Destination Database


If database point-in-time recovery is required at a destination database in an Oracle Streams environment, then you must reapply the captured changes that had already been applied after the point-in-time recovery.


For each relevant capture process, you can choose either of the following methods to perform point-in-time recovery at a destination database in an Oracle Streams environment:


  • 

    Reset the start SCN for the existing capture process that captures the changes that are applied at the destination database.
    

  • 

    Create a new capture process to capture the changes that must be reapplied at the destination database.
    



Resetting the start SCN for the capture process is simpler than creating a new capture process. However, if the capture process captures changes that are applied at multiple destination databases, then the changes are resent to all the destination databases, including the ones that did not perform point-in-time recovery. If a change is already applied at a destination database, then it is discarded by the apply process, but you might not want to use the network and computer resources required to resend the changes to multiple destination databases. In this case, you can create and temporarily use a new capture process and a new propagation that propagates changes only to the destination database that was recovered.


The following sections provide instructions for each task:



If there are multiple apply processes at the destination database where you performed point-in-time recovery, then complete one of the tasks in this section for each apply process.


Neither of these methods should be used if any of the following conditions are true regarding the destination database you are recovering:


  • 

    A propagation propagates persistent LCRs to the destination database. Both of these methods reapply only captured LCRs at the destination database, not persistent LCRs.
    

  • 

    In a directed networks configuration, the destination database is used to propagate LCRs from a capture process to other databases, but the destination database does not apply LCRs from this capture process.
    

  • 

    The oldest message number for an apply process at the destination database is lower than the first SCN of a capture process that captures changes for this apply process. The following query at a destination database lists the oldest message number (oldest SCN) for each apply process:
    

    SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

    

    The following query at a source database lists the first SCN for each capture process:
    

    SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;

  • 

    The archived log files that contain the intended start SCN are no longer available.
    



If any of these conditions are true in your environment, then you cannot use the methods described in this section. Instead, you must manually resynchronize the data at all destination databases.









Note:

If you are using combined capture and apply in a single-source replication environment, and the destination database has undergone point-in-time recovery, then the Oracle Streams capture process automatically detects where to capture changes upon restart, and no extra steps are required for it. See Oracle Streams Concepts and Administration for more information.










Resetting the Start SCN for the Existing Capture Process to Perform Recovery


If you decide to reset the start SCN for the existing capture process to perform point-in-time recovery, then complete the following steps:


  1. 

    If the destination database is also a source database in a multiple-source Oracle Streams environment, then complete the actions described in "Performing Point-in-Time Recovery in a Multiple-Source Environment".
    

  2. 

    Drop the propagation that propagates changes from the source queue at the source database to the destination queue at the destination database. Use the DROP_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package to drop the propagation.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then drop the propagation at each intermediate database in the path to the destination database, including the propagation at the source database.
    

    Do not drop the rule sets used by the propagations you drop.
    

    If the existing capture process is a downstream capture process that is configured at the destination database, then the downstream capture process is recovered to the same point-in-time as the destination database when you perform point-in-time recovery in Step 3. In this case, the remaining steps in this section after Step 3 are not required. Ensure that the required redo log files are available to the capture process.
    

    


    

    

    Note:
    
You must drop the appropriate propagation(s). Disabling them is not sufficient. You will re-create the propagation(s) in Step 7, and dropping them now ensures that only LCRs created after resetting the start SCN for the capture process are propagated.
    

    

    

    


    

    

    See Also:
    
Oracle Streams Concepts and Administration for more information about directed networks
    

    

    

  3. 

    Perform the point-in-time recovery at the destination database.
    

  4. 

    Query for the oldest message number (oldest SCN) from the source database for the apply process at the destination database. Make a note of the results of the query. The oldest message number is the earliest system change number (SCN) that might need to be applied.
    

    The following query at a destination database lists the oldest message number for each apply process:
    

    SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

  5. 

    Stop the existing capture process using the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
    

  6. 

    Reset the start SCN of the existing capture process.
    

    To reset the start SCN for an existing capture process, run the ALTER_CAPTURE procedure in the DBMS_CAPTURE_ADM package and set the start_scn parameter to the value you recorded from the query in Step 4. For example, to reset the start SCN for a capture process named strm01_capture to the value 829381993, run the following ALTER_CAPTURE procedure:
    

    BEGIN
  DBMS_CAPTURE_ADM.ALTER_CAPTURE(
    capture_name  =>  'strm01_capture',
    start_scn     =>  829381993);
END;
/

  7. 

    If you are not using directed networks between the source database and destination database, then create a new propagation to propagate changes from the source queue to the destination queue using the CREATE_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package. Specify any rule sets used by the original propagation when you create the propagation.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then create a new propagation at each intermediate database in the path to the destination database, including the propagation at the source database.
    

  8. 

    Start the existing capture process using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
    









Creating a New Capture Process to Perform Recovery


If you decide to create a capture process to perform point-in-time recovery, then complete the following steps:



  1. 

    If the destination database is also a source database in a multiple-source Oracle Streams environment, then complete the actions described in "Performing Point-in-Time Recovery in a Multiple-Source Environment".
    

  2. 

    If you are not using directed networks between the source database and destination database, then drop the propagation that propagates changes from the source queue at the source database to the destination queue at the destination database. Use the DROP_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package to drop the propagation.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then drop the propagation that propagates LCRs between the last intermediate database and the destination database. You do not need to drop the propagations at the other intermediate databases nor at the source database.
    

    


    

    

    Note:
    
You must drop the appropriate propagation. Disabling it is not sufficient.
    

    

    

    


    

    

    See Also:
    
Oracle Streams Concepts and Administration for more information about directed networks
    

    

    

  3. 

    Perform the point-in-time recovery at the destination database.
    

  4. 

    Query for the oldest message number (oldest SCN) from the source database for the apply process at the destination database. Make a note of the results of the query. The oldest message number is the earliest system change number (SCN) that might need to be applied.
    

    The following query at a destination database lists the oldest message number for each apply process:
    

    SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

  5. 

    Create a queue at the source database to be used by the capture process using the SET_UP_QUEUE procedure in the DBMS_STREAMS_ADM package.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then create a queue at each intermediate database in the path to the destination database, including the new queue at the source database. Do not create a new queue at the destination database.
    

  6. 

    If you are not using directed networks between the source database and destination database, then create a new propagation to propagate changes from the source queue created in Step 5 to the destination queue using the CREATE_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package. Specify any rule sets used by the original propagation when you create the propagation.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then create a propagation at each intermediate database in the path to the destination database, including the propagation from the source database to the first intermediate database. These propagations propagate changes captured by the capture process you will create in Step 7 between the queues created in Step 5.
    

  7. 

    Create a new capture process at the source database using the CREATE_CAPTURE procedure in the DBMS_CAPTURE_ADM package. Set the source_queue parameter to the local queue you created in Step 5 and the start_scn parameter to the value you recorded from the query in Step 4. Also, specify any rule sets used by the original capture process. If the rule sets used by the original capture process instruct the capture process to capture changes that should not be sent to the destination database that was recovered, then you can create and use smaller, customized rule sets that share some rules with the original rule sets.
    

  8. 

    Start the capture process you created in Step 7 using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
    

  9. 

    When the oldest message number of the apply process at the recovered database is approaching the capture number of the original capture process at the source database, stop the original capture process using the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package.
    

    At the destination database, you can use the following query to determine the oldest message number from the source database for the apply process:
    

    SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

    

    At the source database, you can use the following query to determine the capture number of the original capture process:
    

    SELECT CAPTURE_NAME, CAPTURE_MESSAGE_NUMBER FROM V$STREAMS_CAPTURE;

  10. 

    When the oldest message number of the apply process at the recovered database is beyond the capture number of the original capture process at the source database, drop the new capture process created in Step 7.
    

  11. 

    If you are not using directed networks between the source database and destination database, then drop the new propagation created in Step 6.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then drop the new propagation at each intermediate database in the path to the destination database, including the new propagation at the source database.
    

  12. 

    If you are not using directed networks between the source database and destination database, then remove the queue created in Step 5.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then drop the new queue at each intermediate database in the path to the destination database, including the new queue at the source database. Do not drop the queue at the destination database.
    

  13. 

    If you are not using directed networks between the source database and destination database, then create a propagation that propagates changes from the original source queue at the source database to the destination queue at the destination database. Use the CREATE_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package to create the propagation. Specify any rule sets used by the original propagation when you create the propagation.
    

    If you are using directed networks, and there are intermediate databases between the source database and destination database, then re-create the propagation from the last intermediate database to the destination database. You dropped this propagation in Step 2.
    

  14. 

    Start the capture process you stopped in Step 9.
    



All of the steps after Step 8 can be deferred to a later time, or they can be done as soon as the condition described in Step 9 is met.












Running Flashback Queries in an Oracle Streams Replication Environment


Oracle Flashback Query enables you to view and repair historical data. You can perform queries on a database as of a certain clock time or system change number (SCN). In an Oracle Streams single-source replication environment, you can use Flashback Query at the source database and a destination database at a past time when the replicated database objects should be identical.


You can run the queries at corresponding SCNS at the source and destination databases to determine whether all of the changes to the replicated objects performed at the source database have been applied at the destination database. If there are apply errors at the destination database, then such a Flashback Query can show how the replicated objects looked at the time when the error was raised. This information could be useful in determining the cause of the error and the best way to correct the error.


Running a Flashback Query at each database can also check whether tables have certain rows at the corresponding SCNs. If the table data does not match at the corresponding SCNs, then there is a problem with the replication environment.


To run queries, the Oracle Streams replication environment must have the following characteristics:


  • 

    The replication environment must be a single-source environment, where changes to replicated objects are captured at only one database.
    

  • 

    No modifications are made to the replicated objects in the Stream. That is, no transformations, subset rules (row migration), or apply handlers modify the LCRs for the replicated objects.
    

  • 

    No DML or DDL changes are made to the replicated objects at the destination database.
    

  • 

    Both the source database and the destination database must be configured to use Oracle Flashback, and the Oracle Streams administrator at both databases must be able to execute subprograms in the DBMS_FLASHBACK package.
    

  • 

    The information in the undo tablespace must go back far enough to perform the query at each database. Oracle Flashback features use the Automatic Undo Management system to obtain historical data and metadata for a transaction. The UNDO_RETENTION initialization parameter at each database must be set to a value that is large enough to perform the Flashback Query.
    



Because Oracle Streams replication is asynchronous, you cannot use a past time in the Flashback Query. However, you can use the GET_SCN_MAPPING procedure in the DBMS_STREAMS_ADM package to determine the SCN at the destination database that corresponds to an SCN at the source database.


These instructions assume that you know the SCN for the Flashback Query at the source database. Using this SCN, you can determine the corresponding SCN for the Flashback Query at the destination database. To run these queries, complete the following steps:



  1. 

    At the destination database, ensure that the archived redo log file for the approximate time of the Flashback Query is available to the database. The GET_SCN_MAPPING procedure requires that this redo log file be available.
    

  2. 

    In SQL*Plus, connect to the destination database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the GET_SCN_MAPPING procedure. In this example, assume that the SCN for the source database is 52073983 and that the name of the apply process that applies changes from the source database is strm01_apply:
    

    SET SERVEROUTPUT ON
DECLARE
  dest_scn   NUMBER;
  start_scn  NUMBER;
  dest_skip  DBMS_UTILITY.NAME_ARRAY;
BEGIN
  DBMS_STREAMS_ADM.GET_SCN_MAPPING(
    apply_name             => 'strm01_apply',
    src_pit_scn            => '52073983',
    dest_instantiation_scn => dest_scn,
    dest_start_scn         => start_scn,
    dest_skip_txn_ids      => dest_skip);
  IF dest_skip.count = 0 THEN
    DBMS_OUTPUT.PUT_LINE('No Skipped Transactions');
    DBMS_OUTPUT.PUT_LINE('Destination SCN: ' || dest_scn);
  ELSE
    DBMS_OUTPUT.PUT_LINE('Destination SCN invalid for Flashback Query.');
    DBMS_OUTPUT.PUT_LINE('At least one transaction was skipped.');
  END IF;
END;
/

    

    If a valid destination SCN is returned, then proceed to Step 4.
    

    If the destination SCN was not valid for Flashback Query because one or more transactions were skipped by the apply process, then the apply process parameter commit_serialization was set to DEPENDENT_TRANSACTIONS, and nondependent transactions have been applied out of order. There is at least one transaction with a source commit SCN less than src_pit_scn that was committed at the destination database after the returned dest_instantiation_scn. Therefore, tables might not be the same at the source and destination databases for the specified source SCN. You can choose a different source SCN and restart at Step 1.
    

  4. 

    Run the Flashback Query at the source database using the source SCN.
    

  5. 

    Run the Flashback Query at the destination database using the SCN returned in Step 3.
    

  6. 

    Compare the results of the queries in Steps 4 and 5 and take any necessary action.
    










See Also:















Recovering from Operation Errors


You can recover from the following operations using the RECOVER_OPERATION procedure in the DBMS_STREAMS_ADM package:



Information about the operation is stored in the following data dictionary views when the operation is in process:










Note:

If the perform_actions parameter is set to FALSE when one of the configuration procedures is run, and a script is used to configure the Oracle Streams replication environment, then these data dictionary views are not populated, and the RECOVER_OPERATION procedure cannot be used for the operation.






When the operation completes successfully, metadata about the operation is moved from the DBA_RECOVERABLE_SCRIPT view to the DBA_RECOVERABLE_SCRIPT_HIST view. The other views, DBA_RECOVERABLE_SCRIPT_PARAMS, DBA_RECOVERABLE_SCRIPT_BLOCKS, and DBA_RECOVERABLE_SCRIPT_ERRORS, retain information about the operation until it is purged automatically after 30 days.


When the operation encounters an error, you can use the RECOVER_OPERATION procedure in the DBMS_STREAMS_ADM package to either roll the operation forward, roll the operation back, or purge the metadata about the operation. Specifically, the operation_mode parameter in the RECOVER_OPERATION procedure provides the following options:


  • 

    FORWARD: This option attempts to complete the operation from the point at which it failed. Before specifying this option, correct the conditions that caused the errors reported in the DBA_RECOVERABLE_SCRIPT_ERRORS view.
    

    You can also use the FORWARD option to obtain more information about what caused the error. To do so, run SET SERVEROUTPUT ON in SQL*Plus and run the RECOVER_OPERATION procedure with the appropriate script ID. The RECOVER_OPERATION procedure shows the actions that lead to the error and the error numbers and messages.
    

  • 

    ROLLBACK: This option rolls back all of the actions performed by the operation. If the rollback is successful, then this option also moves the metadata about the operation from the DBA_RECOVERABLE_SCRIPT view to the DBA_RECOVERABLE_SCRIPT_HIST view. The other views retain information about the operation for 30 days.
    

  • 

    PURGE: This option moves the metadata about the operation from the DBA_RECOVERABLE_SCRIPT view to the DBA_RECOVERABLE_SCRIPT_HIST view without rolling the operation back. The other views retain information about the operation for 30 days.
    



When a recovery operation is complete, information about the operation is stored in the DBA_RECOVERABLE_SCRIPT_HIST view. The STATUS column shows either EXECUTED or PURGED for each recovery operation.









Note:

To run the RECOVER_OPERATION procedure, both databases must be Oracle Database 10g Release 2 or later databases.













See Also:












Recovery Scenario


This section contains a scenario in which the MAINTAIN_SCHEMAS procedure stops because it encounters an error. Assume that the following procedure encountered an error when it was run at the capture database:


BEGIN
  DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
    schema_names                 => 'hr',
    source_directory_object      => 'SOURCE_DIRECTORY',
    destination_directory_object => 'DEST_DIRECTORY',
    source_database              => 'dbs1.example.com',
    destination_database         => 'dbs2.example.com',
    perform_actions              => TRUE,
    dump_file_name               => 'export_hr.dmp',
    capture_queue_table          => 'rep_capture_queue_table',
    capture_queue_name           => 'rep_capture_queue',
    capture_queue_user           => NULL,
    apply_queue_table            => 'rep_dest_queue_table',
    apply_queue_name             => 'rep_dest_queue',
    apply_queue_user             => NULL,
    capture_name                 => 'capture_hr',
    propagation_name             => 'prop_hr',
    apply_name                   => 'apply_hr',
    log_file                     => 'export_hr.clg',
    bi_directional               => FALSE,
    include_ddl                  => TRUE,
    instantiation                => DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA);
END;
/



Complete the following steps to diagnose the problem and recover the operation:


  1. 

    In SQL*Plus, connect to the capture database as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Determine the SCRIPT_ID value for the operation by running the following query:
    

    SELECT SCRIPT_ID FROM DBA_RECOVERABLE_SCRIPT ORDER BY CREATION_TIME DESC;

    

    This query assumes that the most recent configuration operation is the one that encountered errors. Therefore, if more than one SCRIPT_ID is returned by the query, then use the first SCRIPT_ID in the list.
    

  3. 

    Query the DBA_RECOVERABLE_SCRIPT_ERRORS data dictionary view to determine the error and specify the SCRIPT_ID returned in Step 2 in the WHERE clause.
    

    For example, if the SCRIPT_ID is F73ED2C9E96B27B0E030578CB10B2424, then run the following query:
    

    COLUMN SCRIPT_ID     HEADING 'Script ID'     FORMAT A35
COLUMN BLOCK_NUM     HEADING 'Block|Number' FORMAT 999999
COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A33

SELECT BLOCK_NUM, ERROR_MESSAGE 
  FROM DBA_RECOVERABLE_SCRIPT_ERRORS
  WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424';

    

    The query returns the following output:
    

    Block
Number Error Message
------- ---------------------------------
     12 ORA-39001: invalid argument value

  4. 

    Query the DBA_RECOVERABLE_SCRIPT_BLOCKS data dictionary view for the script ID returned in Step 2 and block number returned in Step 3 for information about the block in which the error occurred.
    

    For example, if the script ID is F73ED2C9E96B27B0E030578CB10B2424 and the block number is 12, run the following query:
    

    COLUMN FORWARD_BLOCK        HEADING 'Forward Block'               FORMAT A50
COLUMN FORWARD_BLOCK_DBLINK HEADING 'Forward Block|Database Link' FORMAT A13
COLUMN STATUS               HEADING 'Status'                      FORMAT A12

SET LONG 10000
SELECT FORWARD_BLOCK,
       FORWARD_BLOCK_DBLINK,
       STATUS
  FROM DBA_RECOVERABLE_SCRIPT_BLOCKS
  WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424' AND
        BLOCK_NUM = 12;

    

    The output contains the following information:
    

    • 

      The FORWARD_BLOCK column contains detailed information about the actions performed by the procedure in the specified block. If necessary, spool the output into a file. In this scenario, the FORWARD_BLOCK column for block 12 contains the code for the Data Pump export.
      

    • 

      The FORWARD_BLOCK_DBLINK column shows the database where the block is executed. In this scenario, the FORWARD_BLOCK_DBLINK column for block 12 shows DBS1.EXAMPLE.COM because the Data Pump export was being performed on DBS1.EXAMPLE.COM when the error occurred.
      

    • 

      The STATUS column shows the status of the block execution. In this scenario, the STATUS column for block 12 shows ERROR.
      

    

  5. 

    Optionally, run the RECOVER_OPERATION procedure operation at the capture database with SET SERVEROUTPUT ON to display more information about the errors:
    

    SET SERVEROUTPUT ON
BEGIN
  DBMS_STREAMS_ADM.RECOVER_OPERATION(
    script_id       => 'F73ED2C9E96B27B0E030578CB10B2424',
    operation_mode  => 'FORWARD');
END;
/

    

    With server output on, the actions that caused the error run again, and the actions and the resulting errors are displayed.
    

  6. 

    Interpret the output from the previous steps and diagnose the problem. The output returned in Step 3 provides the following information:
    

    • 

      The unique identifier for the configuration operation is F73ED2C9E96B27B0E030578CB10B2424. This value is the RAW value returned in the SCRIPT_ID field.
      

    • 

      Only one Oracle Streams configuration procedure is in the process of running because only one row was returned by the query. If multiple rows were returned by the query, then query the DBA_RECOVERABLE_SCRIPT and DBA_RECOVERABLE_SCRIPT_PARAMS views to determine which script ID applies to the configuration operation.
      

    • 

      The cause in Oracle Database Error Messages for the ORA-39001 error is the following: The user specified API parameters were of the wrong type or value range. Subsequent messages supplied by DBMS_DATAPUMP.GET_STATUS will further describe the error.
      

    • 

      The query on the DBA_RECOVERABLE_SCRIPT_BLOCKS view shows that the error occurred during Data Pump export.
      

    

    The output from the queries shows that the MAINTAIN_SCHEMAS procedure encountered a Data Pump error. Notice that the instantiation parameter in the MAINTAIN_SCHEMAS procedure was set to DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA. This setting means that the MAINTAIN_SCHEMAS procedure performs the instantiation using a Data Pump export and import. A Data Pump export dump file is generated to complete the export/import.
    

    Data Pump errors usually are caused by one of the following conditions:
    

    • 

      One or more of the directory objects used to store the export dump file do not exist.
      

    • 

      The user running the procedure does not have access to specified directory objects.
      

    • 

      An export dump file with the same name as the one generated by the procedure already exists in a directory specified in the source_directory_object or destination_directory_object parameter.
      

    

  7. 

    Query the DBA_RECOVERABLE_SCRIPT_PARAMS data dictionary view at the capture database to determine the names of the directory objects specified when the MAINTAIN_SCHEMAS procedure was run:
    

    COLUMN PARAMETER HEADING 'Parameter' FORMAT A30
COLUMN VALUE     HEADING 'Value'     FORMAT A45

SELECT PARAMETER,
       VALUE
       FROM DBA_RECOVERABLE_SCRIPT_PARAMS
       WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424';

    

    The query returns the following output:
    

    Parameter                      Value
------------------------------ ---------------------------------------------
SOURCE_DIRECTORY_OBJECT        SOURCE_DIRECTORY
DESTINATION_DIRECTORY_OBJECT   DEST_DIRECTORY
SOURCE_DATABASE                DBS1.EXAMPLE
DESTINATION_DATABASE           DBS2.EXAMPLE
CAPTURE_QUEUE_TABLE            REP_CAPTURE_QUEUE_TABLE
CAPTURE_QUEUE_OWNER            STRMADMIN
CAPTURE_QUEUE_NAME             REP_CAPTURE_QUEUE
CAPTURE_QUEUE_USER
APPLY_QUEUE_TABLE              REP_DEST_QUEUE_TABLE
APPLY_QUEUE_OWNER              STRMADMIN
APPLY_QUEUE_NAME               REP_DEST_QUEUE
APPLY_QUEUE_USER
CAPTURE_NAME                   CAPTURE_HR
APPLY_NAME                     APPLY_HR
PROPAGATION_NAME               PROP_HR
INSTANTIATION                  INSTANTIATION_SCHEMA
BI_DIRECTIONAL                 TRUE
INCLUDE_DDL                    TRUE
LOG_FILE                       export_hr.clg
DUMP_FILE_NAME                 export_hr.dmp
SCHEMA_NAMES                   HR

  8. 

    Ensure that the directory object specified for the source_directory_object parameter exists at the source database, and ensure that the directory object specified for the destination_directory_object parameter exists at the destination database. Check for these directory objects by querying the DBA_DIRECTORIES data dictionary view.
    

    For this scenario, assume that the SOURCE_DIRECTORY directory object does not exist at the source database, and the DEST_DIRECTORY directory object does not exist at the destination database. The Data Pump error occurred because the directory objects used for the export dump file did not exist.
    

  9. 

    Create the required directory objects at the source and destination databases using the SQL statement CREATE DIRECTORY. See "Creating the Required Directory Objects" for instructions.
    

  10. 

    Run the RECOVER_OPERATION procedure at the capture database:
    

    BEGIN
  DBMS_STREAMS_ADM.RECOVER_OPERATION(
    script_id       => 'F73ED2C9E96B27B0E030578CB10B2424',
    operation_mode  => 'FORWARD');
END;
/

    

    Notice that the script_id parameter is set to the value determined in Step 3, and the operation_mode parameter is set to FORWARD to complete the configuration. Also, the RECOVER_OPERATION procedure must be run at the database where the configuration procedure was run.
    











PKBTPK+AOEBPS/content.opfA


      Oracle® Streams Replication Administrator's Guide, 11g Release 2 (11.2)
      en-US
      
      E10705-09
      Oracle Corporation
      Oracle Corporation
      Oracle® Streams Replication Administrator's Guide, 11g Release 2 (11.2)
      2011-08-01T12:45:53Z
      Contains instructions for configuring and managing an Oracle Streams replication environment. It also includes best practices for Oracle Streams replication environments and instructions for migrating from Advanced Replication to Oracle Streams replication.


   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
    
    
    
    


   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   





PK]yVAAPK+AOEBPS/dcommon/prodbig.gif	GIF87a!!!)))111BBBZZZsss{{ZRRcZZ!!1!91)JB9B9)kkcJJB991ssc絽Zcc!!{祽BZc!9B!c{!)c{9{Z{{cZB1)sJk{{Z{kBsZJ91)Z{!{BcsRsBc{9ZZk甽kBkR!BZ9c)JJc{!))BZks{BcR{JsBk9k)Zck!!BZ1k!ZcRBZcZJkBk1Z9c!R!c9kZRZRBZ9{99!R1{99R{1!1)c1J)1B!BJRkk{ƽ絵ތkk絵RRs{{{{JJsssBBkkk!!9ss{{ZZssccJJZZRRccRRZZ))cBBJJ99JJ!!c11991199Z11!c!!))Z!!!1BRck{)!cJBkZRZ,HP)XRÇEZ֬4jJ0 @	"8pYҴESY3CƊ@*U:lY0_0#
 5tX1E: C_xޘeKTV%ȣ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_KNs8g1^CeКÿE;{+Y\ O5|Y{/o+LVcO;7Zx-Ek&dpzbӱ+TaB0gNy׭
3^cT\$⫫?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@Š(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((Z5/tbS($`Dǂ7Tg4*-ƫ8@$x	=qh(o^4[7zծ-;UR!PNW|N_w}4x^+%{7iX;e-'N=rnn^i}FeC`qU.66nč?2Oq@U=7VuvK4,$g{xAѮTwWI8#>ƀ5(7zwp]ɝA GRO<6\K0DF
dOhJ+Ş#wu&vCr;`p
ؠϋ]wClg>g?&6\}Q%u6uBJrHRN2@ϸ
J+?St}ll<kH3XvqX]wk&vMDlppAX_r^_ik7<4\X2Hgzvv Ү`GlNO@QEW̟	h><֩]P۪ȊB#dF9˞Qg\Da.S&ѹ#ۻn }EORմn5MBp%8'ƀ.QYf~oNc%K9v5bLKXi2ǁ@hy]Oh.}]",ˀr0=jgvgdH$F PwZݾhQlXQR__r^_ik7<4\X2Hy?(*mz[L|f$V_Q
9
'+yc	P__r^_ik7<4\X2HXzepZZǍO $<^WtZn1u46lB0nFһh>%EվmݤNױ".D!F{玴A<7V\[J6dGjJЭl|=Yh(̍PmÃԚqj03Y.X	,@84rnn^i}FeC`qFi5jK%-p3N=\/:5ޛc; u"b# 1gքuoż9#`FApA$(((((((((((((( >Úg$.HIVcsv U(Š|u{_-CVcD8۸!xk~!Dou4Qyn>.
r[zI 6YZ1Hлcv Ic'SKO53]ZlV,	Xpː7ÿ
yҷzM%Oo3"hyz-cvJYfQrcf9!xpj>un=>LDqv@xs?v$*G^(<7m:t-d漙r'.I/NskOq]V)pȆC`Nr[MmK-/W(Z̲lTq+g'dQP.4
nחb82ZeIysD /|.xŚVg֕PHI-k6s1$8\]Ưx5ݕ^%i
YG#[d{#kKM."o91
 8'+،'tEK04bKI&x{Úž{jKOy${a7RJ݈TQ;Hzh$]/(٬f"137S`.M7şA'"ie+1mэ`:r-5	4LEt^bnkv#МpGE~G6$]\=H`YX9y;rNMe]Gkt
jiG===jEE@<o㟊~7TiZkO'UZOR7TBП~^N퉿>_g6|M7?gn֚
q]#eKvG1;#85!	x9dQy
*1tϖ|Tccoc$QdxS\yV_>$PВ=%(p6@2|&޽
Yi~ԵkRQ v (=qZֵ Z}K)ARf#PFzIaY?TUc㇆'a._@fޑc`rFӻcܝLjڔ:6}\,,`*Xp=Ex4aŚk;,O۬)e
u?K5XZ#	
$eXqGWxGqٞ%[˹cqX"ap9ҥ`X⏇$%kmQg.bK37̹#+P?/Ku`d0W&S\޳|4缗7XXlu9$v IN3e#$f6g
N?.+XaME 'Z|
+j2
ĨZ	;voRi'Nj-	fxr@`9!Y	<3}JJ-ⴒ+ۅHB6Ok63xoMП̳{s~2I$ DM$J
o]$:Du_§FAInQjxkRFGj#AeCq"bbH~7-O7>9{E'rwXNP[uzFm4;wvپ.dg2+O
ooKi$BlGF̜ɒlC&٠IKz~euea%ޅ>`m#9>]ƳixZ;{*M32pc`Hu9gk7כ%gbl^?1kI6/
v=.+(KTll2TasO^:ښfkg4)xKH|0 +5υsώ I^)1)h`c":Wp_/;褂:JgPvm#8r;_Ht/x҉(>
|;𯋼yi_kPxU,xAd#Տ]}3agkk0vQrRƗւr\XTEd<`sƥA-E5^	XFp}Mu%|5yi(gdD]m`vq&?:g'>wko7n-]qdA|
zrIym^lKyu54
JA`[Ma,|Sk{.t36w+~;e|WW{Nş
A`((((((((((((((_w%JU#GBkRo	5Ӵ0QIAF`a
[F%gKY%32y&\	˒z(b-h:YZukpā˷LuމxGIխc>2-웶aʐG 
hQ@,m:?.$NPNk>5ߊ-x/hӼ?hGY&;FrNr=emCۿG^U,;9, 1"6#*x8 €<Eux#ƉCJc3!8<=]–fC @KɂH,qq+R!($	qUE81RP>m^tNϺu*s QzXM;zC#HY+L;H}t&xsGImc.-w1cO$MhQ@~:>K2II%F',y>{mPj(k$eJ
j^Lӭ,mbHaME(ֱI
x:ܑ,hgm1;s5Q@C L-$ew-nqfx75?(SxPя[PXѭ$׍4CUi:ݵ\F626r7{?1W_.HlVo)>PzPKsG7_$|
wVŨjvs*([D_MP1<rO
ռW4x䍃+sv6?15
y	W;rP?:uhܖ֨|#	Vcd`JP'TۊgiiҀ=ŠX{-5_jCq)c 隿⏂~<+jp3oUhYXpyWվ3zXv}-|7,f
rppy5ω[/*cFfvF*p9 Wj?eûOoxnw
W_§FAInQzA/<%~0WVP:*Zô*!܋)MXt0xN}CBԭk(=lv6Ǒz<	_|1h>Wm6pzWa^?J
o[kÿH-縍Ih"``G%۸ExᯉݗWzzs쿀K3岗!G9</PzF`%Lf8厀NPƺ<+ujZCFuM
S\/.W}\c|{x'vk뺷uSZdBѰ(`̀G:Bյ)hroæ#h1m*?3rs^Xѭ𶡬ϡZ"wsѳۍ򯙹`(>
xSgό/=}NJ1Fz88#{&g6X\]y=qIs&wLʠ9$䑞S@+Uk^5W>juE m0U%PW'+gk5=CUO+|}aCf>+k1P6[`H|
]'Huo{ȎjbI	ldOMAw4-+0b;F0s~xCc߱0j3!=H???6޽
↭O3Bmcn߻]6J
qG|Y`Z
+,֩·rZZΓP.O@%Yӻ/LӾӠxUQ~c
.VHc?6⽂?$>;g]}wǥXψ>*U𖅪ex{G:{+S\eu۝k1'(((i6Rjumj-2fC2vp95|+l3y4r;q%
1XiEPEPEPEPEPEPEPEPEPEPEPEPbԼy,ﷷ{˗i0|U;U'{y{z_GKVUHTPF3أ"['sPï	'V{ed,\QU68ciŸ|'MLH4U{e6s^[c$qϠxZo.44Z\ںF8!ՔGăsHNncݡp*áVR
 			//NLH>(qݜc99#Cn,\F+#8>,gZ^G<귱s
+qׂ:zq]<7Qo4:jʲł,j6Fx8Q6;y_]覨QSݝB[:A@eFkԞմuKiy-hԩ# 	!пJ$???6޽#-4;	'~ǝsHucکZo5T9[[,.]#a򤑘B:/CcaSm$](RSЮ9"(62@ξ
YRY,QFU?tn}IH<9x[K]7E9}KcԳ1%AOPX驳aV0WIInQSxYTwԬve]HYV zWQ+M|{q":vTR3Ҁ$'
*E-yŹ,𖿩gxx=,(RNjF~v潓IaѴk.ݤh,㷍 TP3+~|uḀvA/~GCW_*>Vr)ך=oNO2YR0	/U@!"]w2V7ַcΖp<*8`09-4;	'~ǝsHucڀ9>(2y#[6;;ph
ǁ*7kcծ/Vy
WxU8]ULOVx.}.Ok,H>B'&<#.c]$r1J
o^\߉<YеKEEr6*It#
E?5[K<*S8;plkMf̺&+hpp_G#X6$Y]hr2n@HPN02NW'c<*9Us'PG%[ӊH +{x$qơU8I^v_;[=?EzdƻU䂻Avmany&ұC]vb\ ~pCǒ	33(R	ặXTeu# 8 s^7~>F,y2U܍22"8?ZWyOs4m:8)K>ysS/qp#fX[rSzڶmR}B-0{_ۋycg_((ۜze_	S
mYbĠ	$#s旧hrkwWG$Bctr8TF1z4mV1R:e 2КV4k=„|9(uP_Jg_5Ku`5]`	5^x7/{ĺgu+,=s$C˘]lNTCW+hOjmޙyo8<feA
OPEPEPEPEPEPEPEPEPEPEPEPEs~5]-5
@*Qs(Fx[:\:ZR9vZ!Q\d>tm>kui5KA(f%Br
m#(+E_k:ϋ4qO\Gn(tmU$ڽR
(
(
+u~.<=kK]#PxB]0ID,N}Kğ>ۮ.&6kc,G%X||@=a}oryQ$о7#T2V(Z7i/VF1 ܢ{k{|ZjU+
-tpQ׹OC>"h4Ox_KKX#
TG.[V4yڽ
(O
1j7GΠP#2( FH9:+<g}m+ϲypvn{n{>|BlAc*V\p(7򑵹#9=?w:׆Iywi
`$rv!oa}oryQ$о7#T2@(((((((((((((+C'C?IWWN
A`(CaQn+'n.%"BI#TP2I'5?Nѷ,XY]]i›<:Q{[x~YN0!Ql[p>#'Zuq["IUh8'p۹N!iXK0K.z"GSA5[𮙣n弥I88(>7;?Uo'2Ilq֮|ExDoBcP%Y#&~gK|T-['[JuS%ٙg7tsⷁaZ	\䓀S~
ih4F2G+uQ

iVW\8ɉӓ2XeOx<+_N-Wdwq)| gk8xgcWѭ{}OOuҭ
dJ0H6O":w?XIM7z$|ǽs,dTMz?BR FܛR<AW?][oqSY	PȒ38t	CᏀoǨzơVUd0Nz_W/1/=ά\q'eBʟQKIoQ%y?mz}ۭΕl\S&RUVFqryOi7`Mv#=!gc%*k,u{1$K}s̡H+SzsUռ5
I++ >#VJ]zۓk{$/9
h/
S3V}k}'lA
ぷk:NrO^GxH5-E>r@&@8\4|gw::гF2YpgHu?h#k8uY7P)<^9#wSkCJksKόz͝oTa ypEXֱ|AV=[KèN̬R2h(Y<7cpԡ.k_'Im)2!i	X88d+uSY|bLAãj[/Zh~/në!bg*!!\/>\|C͸
uv뇸q(rI=E?k	k~:{x/'5"sdyci8'[`iEK^^?G<+=('u^^?:	*O꽂
(n.%"BI#TP2I'4O<6\K0DF
dOkH1⟈P%:.oY$,hq?yNӚwڧrM+J{]z*3iZUevv(I9$I$@g߇='~i-vWv23u?/ݻ>fHv1cjP5p4V\HX)bH5!q+FR[,Xn:J(
(
(
(
(
(
(
(
(
(
(
(
(9oRF

tYZ6P6=q^o'zmRR_:Ǫ̇dl8?X[}wgtj|	xYKƥ@[ZE!#(iW_u+i}̐ۺ4͒rM9br}Oz{Öe>u|va[P	uewMq,z@gL!2<^q~u|AwS.o.6 nX;8Lޯ~>Yp$kpd9ެA$O|'o>a7pKjt'տ~w+|6;c8=묞n巸9
I]H#TP'/m.I]^K<4i4E^[C^K|e>
F-f}#]iKaH*ι2HPQ@GmJ&Oj|l2z}
՛}M=!82yHc1SS:'xB@g>~n׵s9OQYHbRgqR
A,`0e#P[RI|G"`,`Am  c޸9HÚEφg]$[rX$#
yJ(~GUl^V`'\g-t+c4xI״Ju)Ky{$]pF&BoKm=E]IH?bOTyNO?ZΫ6HKOg5P}z%Z܅w;9$5|}?Q^3t[- r6ms{Yo떞 յW]x@ۇʤVa|p1Q@OI󼟷ZKmݳz݌9ExX<쟈v<ϲZ[gl8k(+~xNlon>'k7[G,	v̪91k(
{-?=_]C,pv\6,pg5P=ZmGF{y"<H0A'=GNRk6o|IԯW[ds^EyxAUխa߾q&r9ƾԼQCeB.V
+
k,_WIExHuI~$OB"kw2¿>fֻ?X[}wgtk8GoGϴko2%oM|G/,[??`n<vr9j(#M2;;ڭy.I'
'$5x+uOjZn-}ŔayZŞ}Q'1[3m;OBvQe@k?hvZElbLc6'MhQ@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@PKڔqqPK+AOEBPS/dcommon/contbig.gif`GIF87a!!!111999BBBJJJRRRccckkksss{{{skk{{ZRRRJJƽ{sZRJRJB91)kcZB9)sskZRJ1޽ƽ{{ssskkkcƵZZRccZRRJJJB{BB9991ssckkZccR))!RRB!!JJ1))99!11ƌ)1R)k֔)s1RZJR{BJs9R1J!11J1J9k{csZk!1J!)cBR9J1B)91B!cRs{!)s!){1B!k!s!{ksksckckZc9B)1!)!)BJ9B1919έƌ!!)JJcZZ{!!!1RR{JJsBBkJJ{!!9BB{1!!J9)!!Z!!c1!!kR!!s9Z!BckJs)19!!c!!ZRZ,H
rrxB(Kh"	DժuICiи@S
z$G3TTʖ&7!f
b`D 0!A

 k,>SO[!\
*_t
 Exr%*_}!#U
#4
& ֩3|b]L]t b+Da&R_2lEٱZ`aC)/яmvUkS	r(-iPEVv_{z GLt\2s!FA#葡JY
r|AA,hB}q|B`du
}00(䡆<pb,G+oB
C0p/x$…– ]7	@2HFc	)	@AD
\0
LHG',(A``@SC)_"PH`}Y+_|1.K8pAKMA@?3҄$[JPA)+NH I
,@8G0/@RT,`pF8Ѓ)$^$DDTDlA@s;PKPK+AOEBPS/dcommon/darbbook.cssPKPK+A!OEBPS/dcommon/O_signature_clr.JPG"(JFIF``C		

 $.' ",#(7),01444'9=82<.342C			

2!!22222222222222222222222222222222222222222222222222"	
}!1AQa"q2#BR$3br	
%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz	
w!1AQaq"2B	#3Rbr
$4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz?(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(?O
'~MQ$Vz;OlJi8L%\]UFjޙ%ԯS;rA]5ފ<׈]j7Ouyq$z'TQuw7Ŀ
KX߁M2=S'TQt?.5w'97;~pq=" ~k?`'9q6E|yayM^Om'fkC&<5x'
?A?Zx'jß={=SßM
gVC.5+Hd֪xc^)Җufz{Cީ|DVkznq|+Xa+{50rx{|OG.OϞ~f/	xxX[2H )c+#jpUOZYX\=SGߨC|K@;_߆'e?LT?]:?>w
ڔ`D^So~xo[Ӡ3i7B:Q8Vc-ďoi:FM292~y_*_闱YN\Fr=xZ3鳎OwW_QEzW~c]REeaSM}}Hӏ4&.E]u=gMѠ+mF`rNn$w9gMa꺢nTuhf2Xv>އ
a(Û6߭?<=>z'TQuw7Ŀ
KX߁M2=S'TQt?.5Kko\.8S$TOX߀Gw?Zx汴X)C7~.i6(Щ=+4{mGӭ¸-]&'t_kV*I<1)4thtIsqpQJ+>
\m^[aJ5)ny:4o&QEnyAEPEEss
72,PDۢ׃K
W{Wjr+wگ
iM/;pd?~&?@;7E4gv8
$l'z'TQuw7Ŀ
Gֱ=ɿ&G?.
iR(5W*$|?w᫼gkmIbHe/_t>tg%y.l}N5[]+Mk0ĠeHdPrsst'UiC,y8`V%9ZIia|ܪvi מYG,o}+kk{YbyIeb*sAtի82zWoEK5z*o-eo;n(P	u-I)4Š(HQEQEQEQEhz(X/Đ?}Bk˩ݏrk0]4>8XzV?
}6$}d^F>nU	K	?Bտk_9׾x~w'ߞ		uDŽtL؈5c-E/"|_Oo.IH쐍=i*Iw5(ںw?t5s.)+tQ2dUt5Vĺ.jZ"@IRrZƅY4ߡ_;}ų(KyQf1Aǵt?sZg+?F5_oQR&Dg߿]6FuRDu>ڿxl7?IT8'shj^=.=J1rj1Wl$얲cPx;E,p$֟ˏkw qg"45(ǛkV/=+ũ)bYl~K#˝J_כ5&\F'I#8/|wʾ_Xj
Q:os^T1.M_|TO.;?_jF?g
N8nA2F%i=qW,G=5OU u8]Rq?wr'˻S+۾.ܼ
87Q^elo/T*?L|ۚ<%<,/v_OKs
B5f/29n0=zqQq(ª=VX@*J(э(f5qJN_EVǞQEOuoѕOuoa5}gO?:߂8Wא|cڽ~]N&O(
(<]>͠@VQ=^~U	̴m&\խ5i:}|}r~9՝f}_>'vVֲ$~^f30^in{\_.OF8to}?${φ|#x^#^n~w=~k~?'KRtO.㌡h![3Zu*ٷճ(ԟ]z_/W1(ԟ]v~g|Yq<ז0
;	b8֮s,w9\?uEyStKaª@\,))
(!EPEPEPEPEPzѧts{v>C/"N6`d*J2gGӧWqBq_1ZuΓ\X]r?=Ey88Mp&pKtO-"wR2
K^-Z<\c>V0^@O7x2WFjs<׻kZ(<Т(OFw/6$1[:ޯԯ#q~4|,LVPem=@=YLUxӃV}AUbcUB.Ds5*kٸAeG>PJxt͝	b88?*$~@ׯDVkraiJs}Q.20x&mXξ,Z]“A-J#`+-E/"<]\a'tZGy.(|lދ~gMK
OZdxDŽU9T6ϯ^<Ϡt5CZ]].t۫S=s`ڳ%8iVK:nqe+#<.T6U>zWoy3^I	{F?J~=G}k)K$$;$de8*G Uӟ4Ocºw}|]4=ݣ\x$ʠms?q^ipw\"ȿPs^ZQ_0GڼU.t}ROM[G#]8wٞӫ87}Cgw
vHȩBM55vof	=A_٭`Ygx[6P,5}>蚊(0(+?>+?>k|TuXq6_ +szk
:u_Z߶Ak_U}Jc2u/1[_»ݸG41-bሬ۴}}Eȹפ_c?5gi
@cL\L<68hF_Ih>X4K7UТ	sMj	=J7CKo>Օ5s:߀t
~ηaٿ?|gdL8+gG%o?x`دOqȱwc¨&TW_V_aI=dpG!wu۞սZ1yL50$(l3(:~'ַo
A}a3N*[0ǭ HKQV}G@֜$
9of$ArNqUOgË05#m?D)^_h//5_/<?4}Jį+GkpG4"$ 	r|>S4Ђ"S
1%R:ȝ 8;PKPzPK+AOEBPS/dcommon/feedback.gif7GIF89a'%(hp|fdx?AN5:dfeDGHɾTdQc`g*6DC\?ؘ||{;=E6JUՄfeA=>@,4`H.|`a	(Q 9:&[|ځ,4p Y&BDb,!2@,
$wPA'ܠǃ@CO~/d.`I @8ArHx9H75j L	3B/`	P#qD*s3A:3,H70P,R@ p!(Foԥ D;"0,6QBRɄHhI@@VDLCk8@NBBL2&pClA?DAk%$`I2
#Q+l7 "=&dL&PRSLIP)PɼirqМ'N8[_}w;PK-PK+AOEBPS/dcommon/booklist.gifGIF89a1޵֥΄kZ{Jk1Rs!BZ)B),@I9Z͓Ca%	Dz8Ȁ0FZЌ0P!x8!eL8aWȠFD(~@p+rMS|ӛR$v
"Z:]ZJJEc{*=AP
	BiA']j4$*
&	9qsMiO?jQ	=	
	, YFg4.778c&$c%9;PKː5PK+AOEBPS/dcommon/cpyr.htm1

Oracle Legal Notices

Oracle Legal Notices


Copyright Notice


Copyright © 1994-2012, Oracle and/or its affiliates. All rights reserved.


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.


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, the following notice is applicable:


U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.


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.


Third-Party Content, Products, and Services Disclaimer


This software or hardware and documentation may provide access to or information on 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. 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.


Alpha and Beta Draft Documentation Notice


If this document is in prerelease status:


This documentation is in prerelease 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.


Oracle Logo


PKN61PK+AOEBPS/dcommon/masterix.gif.GIF89a1ޜΌscJk1Rs!Bc1J),@IS@0"1 Ѿb$b08PbL,acr
B@(fDnJx11+\%1 p {
	display: none;
}

/* Class Selectors */

.ProductTitle {
	font-family: sans-serif;
}

.BookTitle {
	font-family: sans-serif;
}

.VersionNumber {
	font-family: sans-serif;
}

.PrintDate {
	font-family: sans-serif;
	font-size: small;
}

.PartNumber {
	font-family: sans-serif;
	font-size: small;
}
PKeӺ1,PK+AOEBPS/dcommon/larrow.gif#GIF87a絵ƌֵƽ{{ss֜ƔZZ{{{{ZZssZZccJJJJRRBBJJJJ991111))!!{,@pH,Ȥrl:ШtpHc`

өb[.64ꑈ53=Z]'yuLG*)g^!8C?-6(29K"Ĩ0Яl;U+K9^u2,@@(\ȰË$P`lj8x I$4H	*(@͉0dа8tA
DсSPv"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-OJPK+AOEBPS/dcommon/index.gifGIF89a1޵ΥΥ{sc{BZs,@IM" ADB0
3.R~[D"0,]ШpRNC	 /&H&[%7TM/`vS+-+q

D
	go@"	4o'Uxcxcc&k/
qp
zUm(UHDDJBGMԃ;PK(PK+AOEBPS/dcommon/bookbig.gif	+GIF89a$!!!)))111999BBBJJJRRRZZZccckkksss{{{skkB991)))!!B11))1!JB9B9!!cZ9ƭƽssk{ZZRccZRRJJJBBB9c!!ν)1)k{s絽ƌkssֽZccJRRBJJ{9BB)11)99!!))11!!k!JZ!)RcJccBcs)1c)JZ!BR!)BZ)99J!Rk9!c11B)Z{)9Bkc1kB9BZ!Z{9Rs)Jkksk9kB1s1Jk9Rƥc{k9s)Z{1k91)s1Rk)Jc1J!))BZ!1k{csc{)19B!)Bcsc{ksc{kZs!RkJkJkքc{9Zks{ck9R)Bks9R9R1J!)Z1B!)c)9)99BR19kksBBJcc{ccBBZ))9kk!!199c11ZBB{9!!R!!Z!!c))!!kR!!s!!BcksRZ1c9B)R91c1)Z!R9B9k1)RcZ{)!1B9JB9B)!)J9B!&  Imported from GIF image: bookbig.gif,$!!!)))111999BBBJJJRRRZZZccckkksss{{{skkB991)))!!B11))1!JB9B9!!cZ9ƭƽssk{ZZRccZRRJJJBBB9c!!ν)1)k{s絽ƌkssֽZccJRRBJJ{9BB)11)99!!))11!!k!JZ!)RcJccBcs)1c)JZ!BR!)BZ)99J!Rk9!c11B)Z{)9Bkc1kB9BZ!Z{9Rs)Jkksk9kB1s1Jk9Rƥc{k9s)Z{1k91)s1Rk)Jc1J!))BZ!1k{csc{)19B!)Bcsc{ksc{kZs!RkJkJkքc{9Zks{ck9R)Bks9R9R1J!)Z1B!)c)9)99BR19kksBBJcc{ccBBZ))9kk!!199c11ZBB{9!!R!!Z!!c))!!kR!!s!!BcksRZ1c9B)R91c1)Z!R9B9k1)RcZ{)!1B9JB9B)!)J9BH`\Ȑ:pظа"A6DBH,V@Dڹ'G"v Æ ܥ;n;!;>xAܽ[G.\rQCwr}BŊQ A9ᾑ#5Y0VȒj0l-GqF>ZpM
rb;=.ސW-WѻWo	ha!}~ْ; t53:\4PcD,0 4*_l0K3-`l.j!c Aa|2L4/1C`@@md;(H*80L0L(h*҇҆o#N84pC (xO@ A)J6rVlFr	fry†$r_pl5xhA+@A=F rGU	a
1х4s&H Bdzt x#H%Rr
(Ѐ7P`#Rщ'x"	#0`@~i
`HA'Tk?3!$`-A@1l"PLhʖRG&8A`0DcBH sq@AXB4@&yQhPAppxCQ(rBW00@DP1E?@lP1%T`0 WB~nQ@;PKGC		PK+AOEBPS/dcommon/rarrow.gif/GIF87a絵ƌֵƽ{{ss֜ƔZZ{{{{ZZssZZccJJJJRRBBJJJJ991111))!!{,@pH,Ȥrl:ШLlԸ
NCqWEd)#34vwwpN|0yhX!'+-[F	'n5H	$/14w3%
C	.90"	qF7&E"D	mnB|,c96)I	@0BW{ᢦdNp!5"D`0T0-]ʜ$;PKJV^PK+AOEBPS/dcommon/mix.gifkGIF89aZZZBBBJJJkkk999sss!!!111cccֽ{{{RRR)))猌ƭ{s{sks!,@@pH,B$
8
t:<8
*'ntPP DQ@rIBJLNPTVEMOQUWfj^!
hhGH
kCúk_a
Ǥ^h`B		BeH
mm	#F`
I
lpǎ,p BJ\Y!T\(dǏ!Gdˆ
R53ټ	R;iʲ)G=@-xn.4Y	BuU(*BL0PX
v`[D! |
>!/;xP`	(Jj"M6 ;PK枰pkPK+AOEBPS/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
PK+AOEBPS/dcommon/toc.gifGIF89a1ΥΥ{c{Z{JkJk1Rk,@IK% 0| eJB,K-1i']Bt9dz0&pZ1o'q(؟dQ=3S
SZC8db f&3v2@VPsuk2Gsiw`"IzE%<C!.hC
IQ 3o?39T
ҍ;PKv
I
PK+AOEBPS/dcommon/topnav.gifGIF89a1ֽ筽ޭƔkZZk{Bc{,@	) l)-'KR$&84 SI)	XF
 P8te	NRtHPp;Q%Q@'#rR4P fSQ
o0MX[)
v+
`i9gda/&L9i*1$#"%+
(
E'
n7Ȇ(,҅(L@(Q$\x8=6'נ9tJ&"[Epljt
p#ѣHb:f
F`A
=l|;&9lDP2ncH
R`qtp!dȐYH›+?$4mBA9	i@@]@ꃤFxAD*^Ŵ#,(ε	
$H}F.xf,BD
Z;PK1FAPK+AOEBPS/dcommon/bp_layout.css#
@charset "utf-8";
/*
  bp_layout.css
  Copyright 2007, Oracle and/or its affiliates. All rights reserved.
*/

body {
  margin: 0ex;
  padding: 0ex;
}
h1 {
  display: none;
}
#FOOTER {
  border-top: #0d4988 solid 10px;
  background-color: inherit;  
  color: #e4edf3;  
  clear: both;
}
#FOOTER p {
  font-size: 80%;
  margin-top: 0em;
  margin-left: 1em;
}
#FOOTER a {
  background-color: inherit;
  color: gray;  
}
#LEFTCOLUMN {
  float: left;
  width: 50%;
}
#RIGHTCOLUMN {
  float: right;
  width: 50%;
  clear: right; /* IE hack */
}
#LEFTCOLUMN div.portlet {
  margin-left: 2ex;
  margin-right: 1ex;
}
#RIGHTCOLUMN div.portlet {
  margin-left: 1ex;
  margin-right: 2ex;
}
div.portlet {
  margin: 2ex 1ex;
  padding-left: 0.5em;
  padding-right: 0.5em;
  border: 1px #bcc solid;
  background-color: #f6f6ff;
  color: black;
}
div.portlet h2 {
  margin-top: 0.5ex;
  margin-bottom: 0ex;
  font-size: 110%;
}
div.portlet p {
  margin-top: 0ex;
}
div.portlet ul {
  list-style-type: none;
  padding-left: 0em;
  margin-left: 0em; /* IE Hack */
}
div.portlet li {
  text-align: right;
}
div.portlet li cite {
  font-style: normal;
  float: left;
}
div.portlet li a {
  margin: 0px 0.2ex;
  padding: 0px 0.2ex;
  font-size: 95%;
}
#NAME {
  margin: 0em;
  padding: 0em;
  position: relative;
  top: 0.6ex;
  left: 10px;
  width: 80%;
}
#PRODUCT {
  font-size: 180%;
}
#LIBRARY {
  color: #0b3d73;
  background: inherit;
  font-size: 180%;
  font-family: serif;
}
#RELEASE {
  position: absolute;
  top: 28px;
  font-size: 80%;
  font-weight: bold;
}
#TOOLS {
  list-style-type: none;
  position: absolute;
  top: 1ex;
  right: 2em;
  margin: 0em;
  padding: 0em;
  background: inherit;
  color: black;
}
#TOOLS a {
  background: inherit;
  color: black;
}
#NAV {
  float: left;
  width: 96%;
  margin: 3ex 0em 0ex 0em;
  padding: 2ex 0em 0ex 4%; /* Avoiding horizontal scroll bars. */
  list-style-type: none;
  background: transparent url(../gifs/nav_bg.gif) repeat-x bottom;
}
#NAV li {
  float: left;
  margin: 0ex 0.1em 0ex 0em;
  padding: 0ex 0em 0ex 0em;
}
#NAV li a {
  display: block;
  margin: 0em;
  padding: 3px 0.7em;
  border-top: 1px solid gray;
  border-right: 1px solid gray;
  border-bottom: none;
  border-left: 1px solid gray;
  background-color: #a6b3c8;
  color: #333;
}
#SUBNAV {
  float: right;
  width: 96%;
  margin: 0ex 0em 0ex 0em;
  padding: 0.1ex 4% 0.2ex 0em; /* Avoiding horizontal scroll bars. */
  list-style-type: none;
  background-color: #0d4988;
  color: #e4edf3;  
}
#SUBNAV li {
  float: right;
}
#SUBNAV li a {
  display: block;
  margin: 0em;
  padding: 0ex 0.5em;
  background-color: inherit;
  color: #e4edf3;
}
#SIMPLESEARCH {
  position: absolute;
  top: 5ex;
  right: 1em;
}
#CONTENT {
  clear: both;
}
#NAV a:hover,
#PORTAL_1 #OVERVIEW a,
#PORTAL_2 #OVERVIEW a,
#PORTAL_3 #OVERVIEW a,
#PORTAL_4 #ADMINISTRATION a,
#PORTAL_5 #DEVELOPMENT a,
#PORTAL_6 #DEVELOPMENT a,
#PORTAL_7 #DEVELOPMENT a,
#PORTAL_11 #INSTALLATION a,
#PORTAL_15 #ADMINISTRATION a,
#PORTAL_16 #ADMINISTRATION a {
  background-color: #0d4988;
  color: #e4edf3;
  padding-bottom: 4px;
  border-color: gray;
}

#SUBNAV a:hover,
#PORTAL_2 #SEARCH a,
#PORTAL_3 #BOOKS a,
#PORTAL_6 #WAREHOUSING a,
#PORTAL_7 #UNSTRUCTURED a,
#PORTAL_15 #INTEGRATION a,
#PORTAL_16 #GRID a {
  position: relative;
  top: 2px;
  background-color: white;
  color: #0a4e89;
}
PK3(
#
PK+AOEBPS/dcommon/bookicon.gif:GIF87a!!!)))111999BBBJJJRRRZZZccckkksss{{{ޭ{{ZRRcZZRJJJBB)!!skRB9{sν{skskcZRJ1)!֭ƽ{ZZRccZJJBBB999111)JJ9BB1ZZB!!ﭵBJJ9BB!!))Jk{)1!)BRZJ{BsR!RRJsJ!J{s!JsBkks{RsB{J{c1RBs1ZB{9BJ9JZ!1BJRRs!9R!!9Z9!1)J19JJRk19R1Z)!1B9R1RB!)J!J1R)J119!9J91!9BkksBBJ119BBR!))9!!!JB1JJ!)19BJRZckތ1)1J9B,H*\hp >"p`ƒFF
"a"E|ժOC&xCRzOBtX>XE*O>tdqAJ	+,WxP!CYpQ
HQzDHP)T
njJM2ꔀJ2T0d#+I:<жk
'ꤱFAB
@@nh
Wz' H|-7f\A#yNR5	/PM09u
UjćT|q~Yq@&0YZAPa`EzI/$AD Al!AAal2H@$PVAB&c*ؠ p
@%
p-`@b`uBal&`3Ap8槖X~	vX$Eh`.JhAepA\"Bl,	:Hk;PKx[?:PK+AOEBPS/dcommon/conticon.gif^GIF87a!!!)))111999BBBJJJRRRZZZccckkksss{{{ZRR޽{{ssskkkcccZ991ccRZZBBJJZck)19ZcsBJZ19J!k{k)Z1RZs1!B)!J91{k{)J!B!B911)k{cs!1s!9)s!9!B!k)k1c!)Z!R{9BJcckZZcBBJ99B119{{!!)BBRBBZ!))999R99Z!!999c1!9!)19B1)!B9R,oua\h2SYPa
aowwxYi	9SwyyxxyYSd$'^qYȵYvh
ч,/?g{н.J5fe{ڶyY#%/}‚e,Z|pAܠ
`KYx,ĉ&@iX9|`p ]lR1khٜ'E 6ÅB0J;tX bRP(*MÄ!2cLhPC <0Ⴁ

$4!B6lHC%<1e
H4p"
L`P!/,m*1F`#D0D^!AO@..(``_؅QWK>_*OY0J@pw'tVh;PKp*c^PK+AOEBPS/dcommon/blafdoc.cssL@charset "utf-8";
/*
  Copyright 2002, 2011, Oracle and/or its affiliates. All rights reserved.
  Author: Robert Crews
  Version: 2011.10.7
*/

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%;
}

h2 {
  font-size: 152%;
  font-weight: bold;
}

h3 {
  font-size: 139%;
  font-weight: bold;
}

h4 {
  font-size: 126%;
  font-weight: bold;
}

h5 {
  font-size: 113%;
  font-weight: bold;
  display: inline;
}

h6 {
  font-size: 100%;
  font-weight: bold;
  font-style: italic;
  display: inline;
}

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;
}

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: #e00;
  background: inherit;
}

.betadraftsubtitle {
  text-align: center;
  font-weight: bold;
  color: #e00;
  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;
  }
}
PKʍPK+AOEBPS/dcommon/rightnav.gif&GIF89a1ֽ筽ޭƔkZZk{Bc{,@	) l)-
$CҠҀ !	D1#:aS(	c4B0
AC8
ְ9!%MLj
Z*ctypJBa
H
t>#Sb(clhUԂ̗4DztSԙ9ZQҀEPEPEPEPEPEPEPM=iԍP	Giic*yF1׆@\&o!QY00_rlgV;)DGhCq7~..p&1c:u֫{fI>fJL$}BBP?JRWc<^j+χ5b[hֿ-
5_j?POkeQ^hֿ1L^
H
?Qi?z?+_xɔŪ\썽O]χ>)xxV/s)e6MI7*ߊޛv֗2J,;~E4yi3[nI`Ѱe9@zXF*W+]7QJ$$=&`a۾?]N
T䏟'X)Ɣkf:j
|>NBWzYx0t!*_KkoTZ?K
Gc+UyڹgNuh^iSo5{\ܹ3Yos}.>if FqR5\/TӮ#]HS0DKu{($"2xִ{SBJ8=}Y=.|Tsц2UЫ%.InaegKo
z
ݎ3ֹxxwM&2S%';+I',kW&-"_¿_
Vq^ܫ6pfT2RV
A^6RKetto^[{w\jPZ@ޢN4/XN#\42j\(z'j=~-I#:q[Eh|X:sp*bifp$TspZ-}NM*B-bb&*xUr#*$M|QWY
~p~-
fTED6O.#$m+t$˙H"Gk=t9r娮Y?
CzE[/*-{c*[w~o_?%ƔxZ:/5𨴟q}/]22p
qD\H"K]ZMKR&\C3zĽ[PJm]AS)Ia^km
M@dК)fT[ijW*hnuͲiw/bkExG£@f?Zu.s0(<`0ֹoxOaDx\zT-^ѧʧ_1+CP/p[w
9~U^[U<[tĽwPv[yzD1W='u$Oeak[^	|Gk2xv#2?¹TkSݕ|	rݞ[Vi_Kz*{\c(Ck_܏|?ujVڔ6ft?3nmZ6f%QAjJf9Rq
_j7Z-y.pG$Xb]0')[_k;$̭?&"0FOew7 z-cIX岛;$u=\an$zmrILu
uٞ%
_1xcUW%dtÀx885Y^gn;}ӭ)場QEQ@Q@Q@Q@Q@Q@!4xPm3w*]b`F_931˜[ן+(>
E ly;<;MF-qst+}DH
@YKlLmؤciN<|]IU)Lw(8t9FS(=>og<\Z~u_+X1ylsj'eՃ*U3`C!N9Q_WܱhKc93^ua>H	ƕGk=8~e#_?{ǀe-[2ٔ7;=&K挑5zsLdx(e8#{1wS+ΝVkXq9>&yஏh$zq^0~/j@:/«Vnce$$uoPp}MC{$-akH@ɫ1O !8R9s5ԦYmϧ'OUṡ5T,!Ԛ+s#1Veo=[)g>#<s)ƽُA^䠮ωFUj(ǩ|N3Jڷ睁ϱuږZYGOTsI<&drav?A^_f׻B$,O__ԿC`it{6>G׈C~&$y؎v1q9Sc1fH[ѽ>,gG'0'@Vw,BO
[#>ﱺg5ΒFVD%Yr:O5
Tu+O멃]ی38Ze}R&ѝ_xzc1DXgس;<,_,{ƽY'AS#oF.M#~cBuEx7G+Y)(5q+GCV;qF+CLQ)qEC&6z𿊘z}?&w=+)??&\g{;V??׻xGœdٿ׼-Nc')3K]N)iLTӿCdb7Q^aNsd>Fz[0S^s'Zi
 77D}kWusab~~H(>.fif9,~|Jk;YN3H8Y(t6Q݉k͇_÷Z+2߄&[
+Tr^藺97~c܎=[f1RrBǓ^kEMhxYVm<[џ6|	kqbѱ|
YA{G8p?\UM7Z66	g1U1igU69 u5Pƪ:VVZC=[@ҹ¨$kSmɳО\vFz~i3^aOsŧυ9Q}_3	όO{/wgoet39vO2ea;Ύ7$U#?k+Ek&dpzbӱ+TaB0gN{[N7Gי}U7&@?>Fz~E!a@s
?'67XxO*!?qi]֏TQN@tI+\^s8l0)2k!!iW8F$(yOּT.k,/#1:}8uT˾+5=O/`IWG֯b.-<= HOm;~so~hW5+kS8s.zwE|
?4ӿw/KN9?j(#0UT`Wzw}:_*9m>󑓀F?ELzv=8q:=WgJ`nDr	Zе<ֹ](Q@Q@Q@Q@Q@Q@Q@Q@'IdC0EYJVcMty_~u+Sw-aO
n<[YJgL#6i
g5ЖDZ14cʝ!!\/M}/_AYR__>oC?_?7_G#RERW쏞KB}JxGSkǕApƱơPm]hwB7U$Zq
M95"3q1ioATߚ{g.t
uu2k=;h#YB=fgS	:TdLԃ!44mFK{Hrd^7oz|BVr<{)6AXգV»|>*/hS܏z͆OM=Εq
(s|s׊LKQI :9NJ)P+!ʣoAF>+=@I}"x/}۠1aנc¹4emC:>p_xWKX`>R3_S½èųp3޺u3Ne
یbmͺ<_mnݮ1Op?Gm)Qb%N585'%Ahs\6yw!"&Ɨ._wk)}GP;Z!#\"<
*oƾ\)}N>"լ/~]Lg}pBG X?<zZ#x69S=6)jzx=y9O&>+e!!??s~k5Gʏ)?*ce7Ox~k5􇔾Q/e7/Ԑ#3OgNC0]
;_FiRl>Q.g>!%k#ú:Kn'&}?U@\pџPtp)v<{_i}Oվֲ3XIYIx~b<D?(=_JXH=bbi=Oh?_C_O)}oW쏜?
%Ƶ;-RYFi`wۭ{ϖZMtQ$"c_+ԃx1*0b;ԕ݋ESQEQEQEQEQEQEQEQEQEQZ(1F)h1K@XLRE&9P
(bf{RӨ&)PEPEPbԴPGKZ(iإbn(:A%S0(-&)P+	ڎԴP11F)h&:LRmQ@Q@Š(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((PKje88PK+AOEBPS/dcommon/help.gif!GIF89a1εֵ֜֜{kZsBc{,@	)sƠTQ$8(4ʔ%ŌCK$A HP`$h8ŒSd+ɡ\
H@%'6M
HO3SJM	/:Zi[7	\(	
R9r
ERI%	N=aq
 qƦs	*q-n/Sqj	
D XZ;PKއ{&!PK+A
OEBPS/toc.htm

Table of Contents



Contents


Title and Copyright Information


Preface



Part I Configuring Oracle Streams Replication


1 Preparing for Oracle Streams Replication



2 Simple Oracle Streams Replication Configuration



3 Flexible Oracle Streams Replication Configuration



4 Adding to an Oracle Streams Replication Environment



5 Configuring Implicit Capture



6 Configuring Queues and Propagations



7 Configuring Implicit Apply



8 Instantiation and Oracle Streams Replication



9 Oracle Streams Conflict Resolution



10 Oracle Streams Tags



11 Oracle Streams Heterogeneous Information Sharing



Part II Administering Oracle Streams Replication


12 Managing Oracle Streams Replication



13 Comparing and Converging Data



14 Managing Logical Change Records (LCRs)



Part III Oracle Streams Replication Best Practices


15 Best Practices for Oracle Streams Replication Databases



16 Best Practices for Capture



17 Best Practices for Propagation



18 Best Practices for Apply



Part IV Appendixes


A Migrating Advanced Replication to Oracle Streams



Index






PKf6oPK+AOEBPS/best_capture.htmE

Best Practices for Capture



16 Best Practices for Capture


This chapter describes the best practices for capturing changes with a capture process or a synchronous capture in an Oracle Streams replication environment. This chapter includes these topics:










See Also:












Best Practices for Capture Process Configuration


The following sections describe best practices for configuring capture processes:






Grant the Required Privileges to the Capture User


The capture user is the user in whose security domain a capture process captures changes that satisfy its rule sets and runs custom rule-based transformations configured for capture process rules.


The capture user for a capture process is configured when you create a capture process, and the capture user can be modified when you alter a capture process. Grant the following privileges to the apply user:


  • 

    EXECUTE privilege on the rule sets used by the capture process
    

  • 

    EXECUTE privilege on all rule-based transformation functions used in the positive rule set
    



These privileges can be granted directly to the capture user, or they can be granted through roles.


In addition, the capture user must be granted EXECUTE privilege on all packages, including Oracle-supplied packages, that are invoked in rule-based transformations run by the capture process. These privileges must be granted directly to the capture user. They cannot be granted through roles.









See Also:















Set Capture Process Parallelism


Set the parallelism of each capture process by specifying the parallelism parameter in the DBMS_CAPTURE_ADM.SET_PARAMETER procedure. The parallelism parameter controls the number of processes that concurrently mine the redo log for changes.


The default setting for the parallelism capture process parameter is 1, and the default parallelism setting is appropriate for most capture process configurations. Ensure that the PROCESSES initialization parameter is set appropriately when you set the parallelism capture process parameter.









Set the Checkpoint Retention Time


Set the checkpoint retention time for each capture process. Periodically, a capture process takes a checkpoint to facilitate quicker restart. These checkpoints are maintained in the SYSAUX tablespace by default. The checkpoint retention time for a capture process controls the amount of checkpoint data it retains. The checkpoint retention time specifies the number of days before the required checkpoint SCN to retain checkpoints. When a checkpoint is older than the specified time period, the capture process purges the checkpoint.


When checkpoints are purged, the first SCN for the capture process moves forward, and Oracle Database writes a message including the text "first scn changed" to the alert log. The first SCN is the lowest possible SCN available for capturing changes. The checkpoint retention time is set when you create a capture process, and it can be set when you alter a capture process. When the checkpoint retention time is exceeded, the first SCN is moved forward, and the Oracle Streams metadata tables before this new first SCN are purged. The space used by these tables in the SYSAUX tablespace is reclaimed. To alter the checkpoint retention time for a capture process, use the ALTER_CAPTURE procedure in the DBMS_CAPTURE_ADM package and specify the new retention time with the checkpoint_retention_time parameter.


The default value for the checkpoint retention time is 60 days. If checkpoints are available for a time in the past, then the capture process can recapture changes to recover a destination database. You should set the checkpoint retention time to an appropriate value for your environment. A typical setting is 7 days.









See Also:

















Best Practices for Capture Process Operation


The following sections describe best practices for operating existing capture processes:






Configure a Heartbeat Table at Each Source Database in an Oracle Streams Environment


You can use a heartbeat table to ensure that changes are being replicated in an Oracle Streams replication environment. Specifically, you can check the APPLIED_SCN value in the DBA_CAPTURE data dictionary view at the capture database to ensure that it is updated periodically. A heartbeat table is especially useful for databases that have a low activity rate because you can ensure that the replication environment is working properly even if there are few replicated changes.


An Oracle Streams capture process requests a checkpoint after every 10 MB of generated redo. During the checkpoint, the metadata for Oracle Streams is maintained if there are active transactions. Implementing a heartbeat table ensures that there are open transactions occurring regularly in the source database, thereby providing additional opportunities for the metadata to be updated frequently. Additionally, the heartbeat table provides quick feedback to the database administrator about the health of the Oracle Streams replication environment.


To implement a heartbeat table, complete the following steps:


  1. 

    Create a table at the source database that includes a date or time stamp column and the global name of the source database.
    

  2. 

    Instantiate the table at the destination database. If there are multiple destination databases, then instantiate the heartbeat table at each destination database.
    

  3. 

    Add a rule to the positive rule set for the capture process that captures changes to the source database. The rule instructs the capture process to capture changes to the heartbeat table.
    

  4. 

    Add a rule to the positive rule set for the propagation that propagates changes from the source database to the destination database. The rule instructs the propagation to propagate LCRs for the heartbeat table. If there are multiple propagations, then add the rule to the rule set for each propagation. If your environment uses directed networks, then you might need to add rules to propagations at several databases.
    

  5. 

    Add a rule to the positive rule set for the apply process that applies changes that originated at the source database. The rule instructs the apply process to apply changes to the heartbeat table. If there are multiple apply processes at multiple databases that apply the changes that originated at the source database, then add a rule to each the apply process.
    

  6. 

    Configure an automated job to update the heartbeat table at the source database periodically. For example, the table might be updated every minute.
    

  7. 

    Monitor the Oracle Streams replication environment to verify that changes to the heartbeat table at the source database are being replicated to the destination database.
    









Perform a Dictionary Build and Prepare Database Objects for Instantiation Periodically


Perform a data dictionary build in the source database redo periodically. Run the DBMS_CAPTURE_ADM.BUILD procedure to build a current copy of the data dictionary in the redo log. Ideally, database objects should be prepared for instantiation after a build is performed. Run one or more of the following procedures in the DBMS_CAPTURE_ADM package to prepare database objects for instantiation:


  • 

    PREPARE_GLOBAL_INSTANTIATION
    

  • 

    PREPARE_SCHEMA_INSTANTIATION
    

  • 

    PREPARE_TABLE_INSTANTIATION
    



Each of the database objects for which a capture process captures changes should be prepared for instantiation periodically. You can reduce the amount of redo data that must be processed if additional capture process are created or if an existing capture process must be re-created by performing a build and preparing shared objects for instantiation periodically.









Minimize the Performance Impact of Batch Processing


For best performance, the commit point for a batch processing job should be kept low. Also, if a large batch processing job must be run at a source database, then consider running it at each Oracle Streams replication database independently. If this technique is used, then ensure that the changes resulting from the batch processing job are not replicated. To accomplish this, run the DBMS_STREAMS.SET_TAG procedure in the session that runs the batch processing job, and set the session tag to a value that will not be captured by a capture process.











Best Practices for Synchronous Capture Configuration


Creating and managing a synchronous capture is simplified when you use the DBMS_STREAMS_ADM package. Specifically, use the following procedures in the DBMS_STREAMS_ADM package to create a synchronous capture and configure synchronous capture rules:


  • 

    ADD_TABLE_RULES
    

  • 

    ADD_SUBSET_RULES
    



Also, use the REMOVE_RULE procedure in the DBMS_STREAMS_ADM package to remove a rule from a synchronous capture rule set or to drop a rule in a synchronous capture rule set.









PKcKEEPK+AOEBPS/ptrep_admin.htm.

Administering Oracle Streams Replication



Part II



Administering Oracle Streams Replication


This part describes managing Oracle Streams replication and contains the following chapters:







PK}uPK+AOEBPS/cprop.htm\

Configuring Queues and Propagations



6 Configuring Queues and Propagations


The following topics describe configuring queues and propagations:



Each task described in this chapter should be completed by an Oracle Streams administrator that has been granted the appropriate privileges, unless specified otherwise.






Creating an ANYDATA Queue


A queue stores messages in an Oracle Streams environment. Messages can be enqueued, propagated from one queue to another, and dequeued. An ANYDATA queue stores messages whose payloads are of ANYDATA type. Therefore, an ANYDATA queue can store a message with a payload of nearly any type, if the payload is wrapped in an ANYDATA wrapper. Each Oracle Streams capture process, synchronous capture, apply process, and messaging client is associated with one ANYDATA queue, and each Oracle Streams propagation is associated with one ANYDATA source queue and one ANYDATA destination queue.


The easiest way to create an ANYDATA queue is to use the SET_UP_QUEUE procedure in the DBMS_STREAMS_ADM package. This procedure enables you to specify the following settings for the ANYDATA queue it creates:


  • 

    The queue table for the queue
    

  • 

    A storage clause for the queue table
    

  • 

    The queue name
    

  • 

    A queue user that will be configured as a secure queue user of the queue and granted ENQUEUE and DEQUEUE privileges on the queue
    

  • 

    A comment for the queue
    



If the specified queue table does not exist, then it is created. If the specified queue table exists, then the existing queue table is used for the new queue. If you do not specify any queue table when you create the queue, then, by default, streams_queue_table is specified.


For example, complete the following steps to create an ANYDATA queue with the SET_UP_QUEUE procedure:


  1. 

    Complete the following tasks in "Tasks to Complete Before Configuring Oracle Streams Replication" you create an ANYDATA queue:
    


  2. 

    In SQL*Plus, connect to the database that will contain the queue as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the SET_UP_QUEUE procedure to create the queue:
    

    BEGIN
  DBMS_STREAMS_ADM.SET_UP_QUEUE(
    queue_table => 'strmadmin.streams_queue_table',
    queue_name  => 'strmadmin.streams_queue',
    queue_user  => 'hr');
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates a queue table named streams_queue_table in the strmadmin schema. The queue table is created only if it does not already exist. Queues based on the queue table store messages of ANYDATA type. Queue table names can be a maximum of 24 bytes.
      

    • 

      Creates a queue named streams_queue in the strmadmin schema. The queue is created only if it does not already exist. Queue names can be a maximum of 24 bytes.
      

    • 

      Specifies that the streams_queue queue is based on the strmadmin.streams_queue_table queue table.
      

    • 

      Configures the hr user as a secure queue user of the queue, and grants this user ENQUEUE and DEQUEUE privileges on the queue.
      

    • 

      Starts the queue.
      

    

    Default settings are used for the parameters that are not explicitly set in the SET_UP_QUEUE procedure.
    



When the SET_UP_QUEUE procedure creates a queue table, the following DBMS_AQADM.CREATE_QUEUE_TABLE parameter settings are specified:


  • 

    If the database is Oracle Database 10g Release 2 or later, the sort_list setting is commit_time. If the database is a release before Oracle Database 10g Release 2, the sort_list setting is enq_time.
    

  • 

    The multiple_consumers setting is TRUE.
    

  • 

    The message_grouping setting is transactional.
    

  • 

    The secure setting is TRUE.
    



The other parameters in the CREATE_QUEUE_TABLE procedure are set to their default values.


You can use the CREATE_QUEUE_TABLE procedure in the DBMS_AQADM package to create a queue table of ANYDATA type with different properties than the default properties specified by the SET_UP_QUEUE procedure in the DBMS_STREAMS_ADM package. After you create the queue table with the CREATE_QUEUE_TABLE procedure, you can create a queue that uses the queue table. To do so, specify the queue table in the queue_table parameter of the SET_UP_QUEUE procedure.


Similarly, you can use the CREATE_QUEUE procedure in the DBMS_AQADM package to create a queue instead of SET_UP_QUEUE. Use CREATE_QUEUE if you require custom settings for the queue. For example, use CREATE_QUEUE to specify a custom retry delay or retention time. If you use CREATE_QUEUE, then you must start the queue manually.









Note:


  • 

    You can configure an entire Oracle Streams environment, including queues, using procedures in the DBMS_STREAMS_ADM package or Oracle Enterprise Manager. See Chapter 2, "Simple Oracle Streams Replication Configuration".
    

  • 

    A message cannot be enqueued unless a subscriber who can dequeue the message is configured.
    
















Creating Oracle Streams Propagations Between ANYDATA Queues


A propagation sends messages from an Oracle Streams source queue to an Oracle Streams destination queue. In addition, you can use the features of Oracle Streams Advanced Queuing (AQ) to manage Oracle Streams propagations.


You can use any of the following procedures to create a propagation between two ANYDATA queues:



Each of these procedures in the DBMS_STREAMS_ADM package creates a propagation with the specified name if it does not already exist, creates either a positive rule set or negative rule set for the propagation if the propagation does not have such a rule set, and can add table rules, schema rules, or global rules to the rule set.


The CREATE_PROPAGATION procedure creates a propagation, but does not create a rule set or rules for the propagation. However, the CREATE_PROPAGATION procedure enables you to specify an existing rule set to associate with the propagation, either as a positive or a negative rule set. All propagations are started automatically upon creation.


This section contains the following topics:










Note:

You can configure an entire Oracle Streams environment, including propagations, using procedures in the DBMS_STREAMS_ADM package or Oracle Enterprise Manager. See Chapter 2, "Simple Oracle Streams Replication Configuration".













See Also:












Preparing to Create a Propagation


The following tasks must be completed before you create a propagation:









Creating a Propagation Using DBMS_STREAMS_ADM


Complete the following steps to create a propagation using the ADD_TABLE_PROPAGATION_RULES procedure in the DBMS_STREAMS_ADM package:


  1. 

    Complete the tasks in "Preparing to Create a Propagation".
    

  2. 

    In SQL*Plus, connect to the database that contains the source queue for the propagation as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the ADD_TABLE_PROPAGATION_RULES procedure to create the propagation:
    

    BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES(
    table_name              => 'hr.departments',
    streams_name            => 'strm01_propagation',
    source_queue_name       => 'strmadmin.strm_a_queue',
    destination_queue_name  => 'strmadmin.strm_b_queue@dbs2.example.com',
    include_dml             => TRUE,
    include_ddl             => TRUE,
    include_tagged_lcr      => FALSE,
    source_database         => 'dbs1.example.com',
    inclusion_rule          => TRUE,
    queue_to_queue          => TRUE);
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates a propagation named strm01_propagation. The propagation is created only if it does not already exist.
      

    • 

      Specifies that the propagation propagates logical change records (LCRs) from strmadmin.strm_a_queue in the current database to strmadmin.strm_b_queue in the dbs2.example.com database. These queues must exist.
      

    • 

      Specifies that the propagation uses the dbs2.example.com database link to propagate the LCRs, because the destination_queue_name parameter contains @dbs2.example.com. This database link must exist.
      

    • 

      Creates a positive rule set and associates it with the propagation because the inclusion_rule parameter is set to TRUE. The rule set uses the evaluation context SYS.STREAMS$_EVALUATION_CONTEXT. The rule set name is system generated.
      

    • 

      Creates two rules. One rule evaluates to TRUE for row LCRs that contain the results of data manipulation language (DML) changes to the hr.departments table. The other rule evaluates to TRUE for DDL LCRs that contain data definition language (DDL) changes to the hr.departments table. The rule names are system generated.
      

    • 

      Adds the two rules to the positive rule set associated with the propagation. The rules are added to the positive rule set because the inclusion_rule parameter is set to TRUE.
      

    • 

      Specifies that the propagation propagates an LCR only if it has a NULL tag, because the include_tagged_lcr parameter is set to FALSE. This behavior is accomplished through the system-created rules for the propagation.
      

    • 

      Specifies that the source database for the LCRs being propagated is dbs1.example.com, which might or might not be the current database. This propagation does not propagate LCRs in the source queue that have a different source database.
      

    • 

      Creates a propagation job for the queue-to-queue propagation.
      

    










Note:

To use queue-to-queue propagation, the compatibility level must be 10.2.0 or higher for each database that contains a queue involved in the propagation.













See Also:















Creating a Propagation Using DBMS_PROPAGATION_ADM


Complete the following steps to create a propagation using the CREATE_PROPAGATION procedure in the DBMS_PROPAGATION_ADM package:


  1. 

    Complete the tasks in "Preparing to Create a Propagation".
    

  2. 

    In SQL*Plus, connect to the database that contains the source queue for the propagation as the Oracle Streams administrator.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Create the rule set that will be used by the propagation if it does not exist. In this example, assume that the rule set is strmadmin.strm01_rule_set. Optionally, you can also add rules to the rule set. See Oracle Streams Concepts and Administration for instructions.
    

  4. 

    Run the CREATE_PROPAGATION procedure to create the propagation:
    

    BEGIN
  DBMS_PROPAGATION_ADM.CREATE_PROPAGATION(
    propagation_name   => 'strm02_propagation',
    source_queue       => 'strmadmin.strm_a_queue',
    destination_queue  => 'strmadmin.strm_b_queue',
    destination_dblink => 'dbs2.example.com',
    rule_set_name      => 'strmadmin.strm01_rule_set',
    queue_to_queue     => TRUE);
END;
/

    

    Running this procedure performs the following actions:
    

    • 

      Creates a propagation named strm02_propagation. A propagation with the same name must not exist.
      

    • 

      Specifies that the propagation propagates messages from strmadmin.strm_a_queue in the current database to strmadmin.strm_b_queue in the dbs2.example.com database. These queues must exist. Depending on the rules in the rule sets for the propagation, the propagated messages can be LCRs or user messages, or both.
      

    • 

      Specifies that the propagation uses the dbs2.example.com database link to propagate the messages. This database link must exist.
      

    • 

      Associates the propagation with the rule set named strmadmin.strm01_rule_set. This rule set must exist. This rule set is the positive rule set for the propagation.
      

    • 

      Creates a propagation job for the queue-to-queue propagation.
      

    










Note:

To use queue-to-queue propagation, the compatibility level must be 10.2.0 or higher for each database that contains a queue involved in the propagation.














PKG\\PK+AOEBPS/man_comp.htm

Comparing and Converging Data



13 Comparing and Converging Data


This chapter contains instructions for comparing and converging data in database objects at two different databases using the DBMS_COMPARISON package. It also contains instructions for managing comparisons after they are created and for querying data dictionary views to obtain information about comparisons and comparison results.


This chapter contains these topics:










See Also:

Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_COMPARISON package









About Comparing and Converging Data


The DBMS_COMPARISON package enables you to compare database objects at different databases and identify differences in them. This package also enables you converge the database objects so that they are consistent at different databases. Typically, this package is used in environments that share a database object at multiple databases. When copies of the same database object exist at multiple databases, the database object is a shared database object.


Shared database objects might be maintained by data replication. For example, materialized views or Oracle Streams components might replicate the database objects and maintain them at multiple databases. A custom application might also maintain shared database objects. When a database object is shared, it can diverge at the databases that share it. You can use the DBMS_COMPARISON package to identify differences in the shared database objects. After identifying the differences, you can optionally use this package to synchronize the shared database objects.


The DBMS_COMPARISON package can compare the following types of database objects:


  • 

    Tables
    

  • 

    Single-table views
    

  • 

    Materialized views
    

  • 

    Synonyms for tables, single-table views, and materialized views
    



Database objects of different types can be compared and converged at different databases. For example, a table at one database and a materialized view at another database can be compared and converged with this package.


You create a comparison between two database objects using the CREATE_COMPARISON procedure in the DBMS_COMPARISON package. After you create a comparison, you can run the comparison at any time using the COMPARE function. When you run the COMPARE function, it records comparison results in the appropriate data dictionary views. Separate comparison results are generated for each execution of the COMPARE function.





Scans


Each time the COMPARE function is run, one or more new scans are performed for the specified comparison. A scan checks for differences in some or all of the rows in a shared database object at a single point in time. The comparison results for a single execution of the COMPARE function can include one or more scans. You can compare database objects multiple times, and a unique scan ID identifies each scan in the comparison results.








Buckets


A bucket is a range of rows in a database object that is being compared. Buckets improve performance by splitting the database object into ranges and comparing the ranges independently. Every comparison divides the rows being compared into an appropriate number of buckets. The number of buckets used depends on the size of the database object and is always less than the maximum number of buckets specified for the comparison by the max_num_buckets parameter in the CREATE_COMPARISON procedure.


When a bucket is compared using the COMPARE function, the following results are possible:


  • 

    No differences are found. In this case, the comparison proceeds to the next bucket.
    

  • 

    Differences are found. In this case, the comparison can split the bucket into smaller buckets and compare each smaller bucket. When differences are found in a smaller bucket, the bucket is split into still smaller buckets. This process continues until the minimum number of rows allowed in a bucket is reached. The minimum number of rows in a bucket for a comparison is specified by the min_rows_in_bucket parameter in the CREATE_COMPARISON procedure.
    

    When the minimum number of rows in a bucket is reached, the COMPARE function reports whether there are differences in the bucket. The COMPARE function includes the perform_row_dif parameter. This parameter controls whether the COMPARE function identifies each row difference in a bucket that has differences. When this parameter is set to TRUE, the COMPARE function identifies each row difference. When this parameter is set to FALSE, the COMPARE function does not identify specific row differences. Instead, it only reports that there are differences in the bucket.
    



You can adjust the max_num_buckets and min_rows_in_bucket parameters in the CREATE_COMPARISON procedure to achieve the best performance when comparing a particular database object. After a comparison is created, you can view the bucket specifications for the comparison by querying the MAX_NUM_BUCKETS and MIN_ROWS_IN_BUCKET columns in the DBA_COMPARISON data dictionary view.


The DBMS_COMPARISON package uses the ORA_HASH function on the specified columns in all the rows in a bucket to compute a hash value for the bucket. If the hash values for two corresponding buckets match, then the contents of the buckets are assumed to match. The ORA_HASH function is an efficient way to compare buckets because row values are not transferred between databases. Instead, only the hash value is transferred.









Note:

If an index column for a comparison is a VARCHAR2 or CHAR column, then the number of buckets might exceed the value specified for the max_num_buckets parameter.













See Also:















Parent Scans and Root Scans


Each time the COMPARE function splits a bucket into smaller buckets, it performs new scans of the smaller buckets. The scan that analyzes a larger bucket is the parent scan of each scan that analyzes the smaller buckets into which the larger bucket was split. The root scan in the comparison results is the highest level parent scan. The root scan does not have a parent. You can identify parent and root scan IDs by querying the DBA_COMPARISON_SCAN data dictionary view.


You can recheck a scan using the RECHECK function, and you can converge a scan using the CONVERGE procedure. When you want to recheck or converge all of the rows in the comparison results, specify the root scan ID for the comparison results in the appropriate subprogram. When you want to recheck or converge a portion of the rows in comparison results, specify the scan ID of the scan that contains the differences.


For example, a scan with differences in 20 buckets is the parent scan for 20 additional scans, if each bucket with differences has more rows than the specified minimum number of rows in a bucket for the comparison. To view the minimum number of rows in a bucket for the comparison, query the MIN_ROWS_IN_BUCKET column in the DBA_COMPARISON data dictionary view.









See Also:

Oracle Database Reference for information about the views related to the DBMS_COMPARISON package












How Scans and Buckets Identify Differences


This section describes two different comparison scenarios to show how scans and buckets identify differences in shared database objects. In each scenario, the max_num_buckets parameter is set to 3 in the CREATE_COMPARISON procedure. Therefore, when the COMPARE or RECHECK function is run for the comparison, the comparison uses a maximum of three buckets in each scan.


Figure 13-1 shows the first scenario.




Figure 13-1 Comparison with max_num_buckets=3 and Differences in Each Bucket of Each Scan

Description of Figure 13-1 follows

Description of "Figure 13-1 Comparison with max_num_buckets=3 and Differences in Each Bucket of Each Scan"





Figure 13-1 shows a line that represents the rows being compared in the shared database object. This figure illustrates how scans and buckets are used to identify differences when each bucket used by each scan has differences.


With the max_num_buckets parameter set to 3, the comparison is executed in the following steps:


  1. 

    The root scan compares all of the rows in the current comparison. The root scan uses three buckets, and differences are found in each bucket.
    

  2. 

    A separate scan is performed on the rows in each bucket that was used by the root scan in the previous step. The current step uses three scans, and each scan uses three buckets. Therefore, this step uses a total of nine buckets. Differences are found in each bucket. In Figure 13-1, arrows show how each bucket from the root scan is split into three buckets for each of the scans in the current step.
    

  3. 

    A separate scan is performed on the rows in each bucket used by the scans in Step 2. This step uses nine scans, and each scan uses three buckets. Therefore, this step uses a total of 27 buckets. In Figure 13-1, arrows show how each bucket from Step 2 is split into three buckets for each of the scans in the current step.
    



After Step 3, the comparison results are recorded in the appropriate data dictionary views.


Figure 13-2 shows the second scenario.




Figure 13-2 Comparison with max_num_buckets=3 and Differences in One Bucket of Each Scan

Description of Figure 13-2 follows

Description of "Figure 13-2 Comparison with max_num_buckets=3 and Differences in One Bucket of Each Scan"





Figure 13-2 shows a line that represents the rows being compared in the shared database object. This figure illustrates how scans and buckets are used to identify differences when only one bucket used by each scan has differences.


With the max_num_buckets parameter set to 3, the comparison is executed in the following steps:


  1. 

    The root scan compares all of the rows in the current comparison. The root scan uses three buckets, but differences are found in only one bucket.
    

  2. 

    A separate scan is performed on the rows in the one bucket that had differences. This step uses one scan, and the scan uses three buckets. Differences are found in only one bucket. In Figure 13-2, arrows show how the bucket with differences from the root scan is split into three buckets for the scan in the current step.
    

  3. 

    A separate scan is performed on the rows in the one bucket that had differences in Step 2. This step uses one scan, and the scan uses three buckets. In Figure 13-2, arrows show how the bucket with differences in Step 2 is split into three buckets for the scan in the current step.
    



After Step 3, the comparison results are recorded in the appropriate data dictionary views.









Note:

This section describes scenarios in which the max_num_buckets parameter is set to 3 in the CREATE_COMPARISON procedure. This setting was chosen to illustrate how scans and buckets identify differences. Typically, the max_num_buckets parameter is set to a higher value. The default for this parameter is 1000. You can adjust the parameter setting to achieve the best performance.















Other Documentation About the DBMS_COMPARISON Package


Please refer to the following documentation before completing the tasks described in this chapter:


  • 

    The Oracle Database 2 Day + Data Replication and Integration Guide contains basic information about the DBMS_COMPARISON package, including:
    

    • 

      Basic conceptual information about the DBMS_COMPARISON package
      

    • 

      Simple examples that describe using the package to compare and converge database objects
      

    • 

      Sample queries that show information about the differences between database objects at different databases based on comparison results
      

    

  • 

    The chapter about the DBMS_COMPARISON package in the Oracle Database PL/SQL Packages and Types Reference contains advanced conceptual information about the package and detailed information about the subprograms in the package, including:
    

    • 

      Requirements for using the package
      

    • 

      Descriptions of constants used in the package
      

    • 

      Descriptions of each subprogram in the package and its parameters
      

    









Preparing To Compare and Converge a Shared Database Object


Meet the following prerequisites before comparing and converging a shared database object at two databases:


  • 

    Configure network connectivity so that the two databases can communicate with each other. See Oracle Database Net Services Administrator's Guide for information about configuring network connectivity between databases.
    

  • 

    Identify or create a database user who will create, run, and manage comparisons. The database user must meet the privilege requirements described in the documentation for the DBMS_COMPARISON package in the Oracle Database PL/SQL Packages and Types Reference.
    

    After you identify or create a user with the required privileges, create a database link from the database that will run the subprograms in the DBMS_COMPARISON package to the other database that shares the database object. The identified user should own the database link, and the link should connect to a user with the required privileges on the remote database.
    

    For example, the following example creates a database link owned by a user named admin at the comp1.example.com database that connects to the admin user at the remote database comp2.example.com:
    

    1. 

      In SQL*Plus, connect to the local database as admin user.
      

      See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
      

    2. 

      Create the database link:
      

      CREATE DATABASE LINK comp2.example.com CONNECT TO admin
   IDENTIFIED BY password USING 'comp2.example.com';

    









Diverging a Database Object at Two Databases to Complete Examples


The following sections contain examples that compare and converge a shared database object at two databases:



Most of these examples compare and converge data in the oe.orders table. This table is part of the oe sample schema that is installed by default with Oracle Database. In these examples, the global names of the databases are comp1.example.com and comp2.example.com, but you can substitute any two databases in your environment that meet the prerequisites described in "Preparing To Compare and Converge a Shared Database Object".


For the purposes of the examples, make the oe.orders table diverge at two databases by completing the following steps:


  1. 

    In SQL*Plus, connect to the comp2.example.com database as oe user.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Delete the orders in the oe.orders table with a customer_id equal to 147:
    

    DELETE FROM oe.orders WHERE customer_id=147;

  3. 

    Modify the data in a row in the oe.orders table:
    

    UPDATE oe.orders SET sales_rep_id=163 WHERE order_id=2440;

  4. 

    Insert a row into the oe.orders table:
    

    INSERT INTO oe.orders VALUES(3000, TIMESTAMP '2006-01-01 2:00:00', 'direct', 107, 3, 16285.21, 156, NULL);

  5. 

    Commit your changes and exit SQL*Plus:
    

    COMMIT;
EXIT










Note:

Usually, these steps are not required. They are included to ensure that the oe.orders table diverges at the two databases.












Comparing a Shared Database Object at Two Databases


The examples in this section use the DBMS_COMPARISON package to compare the oe.orders table at the comp1.example.com and comp2.example.com databases. The examples use the package to create different types of comparisons and compare the tables with the comparisons.


This section contains the following examples:






Comparing a Subset of Columns in a Shared Database Object


The column_list parameter in the CREATE_COMPARISON procedure enables you to compare a subset of the columns in a database object. The following are reasons to compare a subset of columns:


  • 

    A database object contains extra columns that do not exist in the database object to which it is being compared. In this case, the column_list parameter must only contain the columns that exist in both database objects.
    

  • 

    You want to focus a comparison on a specific set of columns. For example, if a table contains hundreds of columns, then you might want to list specific columns in the column_list parameter to make the comparison more efficient.
    

  • 

    Differences are expected in some columns. In this case, exclude the columns in which differences are expected from the column_list parameter.
    



The columns in the column list must meet the following requirements:


  • 

    The column list must meet the index column requirements for the DBMS_COMPARISON package. See Oracle Database PL/SQL Packages and Types Reference for information about index column requirements.
    

  • 

    If you plan to use the CONVERGE procedure to make changes to a database object based on comparison results, then you must include in the column list any column in this database object that has a NOT NULL constraint but no default value.
    



This example compares the order_id, order_date, and customer_id columns in the oe.orders table at the comp1.example.com and comp2.example.com databases:


  1. 

    Complete the tasks described in "Preparing To Compare and Converge a Shared Database Object" and "Diverging a Database Object at Two Databases to Complete Examples".
    

  2. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the CREATE_COMPARISON procedure to create the comparison:
    

    BEGIN
  DBMS_COMPARISON.CREATE_COMPARISON(
    comparison_name => 'compare_subset_columns',
    schema_name     => 'oe',
    object_name     => 'orders',
    dblink_name     => 'comp2.example.com',
    column_list     => 'order_id,order_date,customer_id');
END;
/

    

    Note that the name of the new comparison is compare_subset_columns. This comparison is owned by the user who runs the CREATE_COMPARISON procedure.
    

  4. 

    Run the COMPARE function to compare the oe.orders table at the two databases:
    

    SET SERVEROUTPUT ON
DECLARE
  consistent   BOOLEAN;
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  consistent := DBMS_COMPARISON.COMPARE(
                  comparison_name => 'compare_subset_columns',
                  scan_info       => scan_info,
                  perform_row_dif => TRUE);
  DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
  IF consistent=TRUE THEN
    DBMS_OUTPUT.PUT_LINE('No differences were found.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Differences were found.');
  END IF;
END;
/

    

    Notice that the perform_row_dif parameter is set to TRUE in the COMPARE function. This setting instructs the COMPARE function to identify each individual row difference in the tables. When the perform_row_dif parameter is set to FALSE, the COMPARE function records whether there are differences in the tables, but does not record each individual row difference.
    

    Your output is similar to the following:
    

    Scan ID: 1
Differences were found.

PL/SQL procedure successfully completed.










See Also:















Comparing a Shared Database Object without Identifying Row Differences


When you run the COMPARE procedure for an existing comparison, the perform_row_dif parameter controls whether the COMPARE procedure identifies each individual row difference in the database objects:


  • 

    When the perform_row_dif parameter is set to TRUE, the COMPARE procedure records whether there are differences in the database objects, and it records each individual row difference. Set this parameter to TRUE when you must identify each difference in the database objects.
    

  • 
<p>When the perform_row_dif parameter is set to FALSE, the COMPARE procedure records whether there are differences in the database objects, but does not record each individual row difference. Set this parameter to FALSE when you want to know if there are differences in the database objects, but you do not need to identify each individual difference. Setting this parameter to FALSE is the most efficient way to perform a comparison.
    



See Oracle Database PL/SQL Packages and Types Reference for information about the perform_row_dif parameter in the COMPARE function.


This example compares the entire oe.orders table at the comp1.example.com and comp2.example.com databases without identifying individual row differences:


  1. 

    Complete the tasks described in "Preparing To Compare and Converge a Shared Database Object" and "Diverging a Database Object at Two Databases to Complete Examples".
    

  2. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the CREATE_COMPARISON procedure to create the comparison:
    

    BEGIN
  DBMS_COMPARISON.CREATE_COMPARISON(
    comparison_name => 'compare_orders',
    schema_name     => 'oe',
    object_name     => 'orders',
    dblink_name     => 'comp2.example.com');
END;
/

  4. 

    Run the COMPARE function to compare the oe.orders table at the two databases:
    

    SET SERVEROUTPUT ON
DECLARE
  consistent   BOOLEAN;
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  consistent := DBMS_COMPARISON.COMPARE(
                  comparison_name => 'compare_orders',
                  scan_info       => scan_info,
                  perform_row_dif => FALSE);
  DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
  IF consistent=TRUE THEN
    DBMS_OUTPUT.PUT_LINE('No differences were found.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Differences were found.');
  END IF;
END;
/

    

    Notice that the perform_row_dif parameter is set to FALSE in the COMPARE function.
    

    Your output is similar to the following:
    

    Scan ID: 4
Differences were found.

PL/SQL procedure successfully completed.










See Also:















Comparing a Random Portion of a Shared Database Object


The scan_percent and scan_mode parameters in the CREATE_COMPARISON procedure enable you to compare a random portion of a shared database object instead of the entire database object. Typically, you use this option under the following conditions:


  • 

    You are comparing a relatively large shared database object, and you want to determine whether there might be differences without devoting the resources and time to comparing the entire database object.
    

  • 

    You do not intend to use subsequent comparisons to compare different portions of the database object. If you want to compare different portions of the database object in subsequent comparisons, then see "Comparing a Shared Database Object Cyclically" for instructions.
    



This example compares a random portion of the oe.orders table at the comp1.example.com and comp2.example.com databases:


  1. 

    Complete the tasks described in "Preparing To Compare and Converge a Shared Database Object" and "Diverging a Database Object at Two Databases to Complete Examples".
    

  2. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the CREATE_COMPARISON procedure to create the comparison:
    

    BEGIN
  DBMS_COMPARISON.CREATE_COMPARISON(
    comparison_name => 'compare_random',
    schema_name     => 'oe',
    object_name     => 'orders',
    dblink_name     => 'comp2.example.com',
    scan_mode       =>  DBMS_COMPARISON.CMP_SCAN_MODE_RANDOM,
    scan_percent    =>  50);
END;
/

    

    Notice that the scan_percent parameter is set to 50 to specify that the comparison scans half of the table. The scan_mode parameter is set to DBMS_COMPARISON.CMP_SCAN_MODE_RANDOM to specify that the comparison compares random rows in the table.
    

  4. 

    Run the COMPARE function to compare the oe.orders table at the two databases:
    

    SET SERVEROUTPUT ON
DECLARE
  consistent   BOOLEAN;
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  consistent := DBMS_COMPARISON.COMPARE(
                  comparison_name => 'compare_random',
                  scan_info       => scan_info,
                  perform_row_dif => TRUE);
  DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
  IF consistent=TRUE THEN
    DBMS_OUTPUT.PUT_LINE('No differences were found.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Differences were found.');
  END IF;
END;
/

    

    Notice that the perform_row_dif parameter is set to TRUE in the COMPARE function. This setting instructs the COMPARE function to identify each individual row difference in the tables. When the perform_row_dif parameter is set to FALSE, the COMPARE function records whether there are differences in the tables, but does not record each individual row difference.
    

    Your output is similar to the following:
    

    Scan ID: 7
Differences were found.

PL/SQL procedure successfully completed.

    

    This comparison scan might or might not find differences, depending on the portion of the table that is compared.
    










See Also:















Comparing a Shared Database Object Cyclically


The scan_percent and scan_mode parameters in the CREATE_COMPARISON procedure enable you to compare a portion of a shared database object cyclically. A cyclic comparison scans a portion of the database object being compared during a single comparison. When the database object is compared again, another portion of the database object is compared, starting where the last comparison ended.


Typically, you use this option under the following conditions:


  • 

    You are comparing a relatively large shared database object, and you want to determine whether there might be differences without devoting the resources and time to comparing the entire database object.
    

  • 

    You want each comparison to compare a different portion of the shared database object, so that the entire database object is compared with the appropriate number of scans. For example, if you compare 25% of the shared database object, then the entire database object is compared after four comparisons. If you do not want to compare different portions of the database object in subsequent comparisons, see "Comparing a Random Portion of a Shared Database Object" for instructions.
    



This example compares oe.orders table cyclically at the comp1.example.com and comp2.example.com databases:


  1. 

    Complete the tasks described in "Preparing To Compare and Converge a Shared Database Object" and "Diverging a Database Object at Two Databases to Complete Examples".
    

  2. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the CREATE_COMPARISON procedure to create the comparison:
    

    BEGIN
  DBMS_COMPARISON.CREATE_COMPARISON(
    comparison_name => 'compare_cyclic',
    schema_name     => 'oe',
    object_name     => 'orders',
    dblink_name     => 'comp2.example.com',
    scan_mode       =>  DBMS_COMPARISON.CMP_SCAN_MODE_CYCLIC,
    scan_percent    =>  50);
END;
/

    

    Notice that the scan_percent parameter is set to 50 to specify that the comparison scans half of the table. The scan_mode parameter is set to DBMS_COMPARISON.CMP_SCAN_MODE_CYCLIC to specify that the comparison compares rows in the table cyclically.
    

  4. 

    Run the COMPARE function to compare the oe.orders table at the two databases:
    

    SET SERVEROUTPUT ON
DECLARE
  consistent   BOOLEAN;
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  consistent := DBMS_COMPARISON.COMPARE(
                  comparison_name => 'compare_cyclic',
                  scan_info       => scan_info,
                  perform_row_dif => TRUE);
  DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
  IF consistent=TRUE THEN
    DBMS_OUTPUT.PUT_LINE('No differences were found.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Differences were found.');
  END IF;
END;
/

    

    Notice that the perform_row_dif parameter is set to TRUE in the COMPARE function. This setting instructs the COMPARE function to identify each individual row difference in the tables. When the perform_row_dif parameter is set to FALSE, the COMPARE function records whether there are differences in the tables, but does not record each individual row difference.
    

    Your output is similar to the following:
    

    Scan ID: 8
Differences were found.

PL/SQL procedure successfully completed.

    

    This comparison scan might or might not find differences, depending on the portion of the table that is compared.
    

  5. 

    To compare the next portion of the database object, starting where the last comparison ended, rerun the COMPARE function that was run in Step 4. In this example, running the COMPARE function twice compares the entire database object because the scan_percent parameter was set to 50 in Step 3.
    










See Also:















Comparing a Custom Portion of a Shared Database Object


The scan_mode parameter in the CREATE_COMPARISON procedure enables you to compare a custom portion of a shared database object. After a comparison is created with the scan_mode parameter set to CMP_SCAN_MODE_CUSTOM in the CREATE_COMPARISON procedure, you can specify the exact portion of the database object to compare when you run the COMPARE function.


Typically, you use this option under the following conditions:


  • 

    You have a specific portion of a shared database object that you want to compare.
    

  • 

    You are comparing a relatively large shared database object, and you want to determine whether there might be difference in a specific portion of it without devoting the resources and time to comparing the entire database object.
    



See Oracle Database PL/SQL Packages and Types Reference for information about the scan_mode parameter in the CREATE_COMPARISON procedure.


This example compares a custom portion of the oe.orders table at the comp1.example.com and comp2.example.com databases:


  1. 

    Complete the tasks described in "Preparing To Compare and Converge a Shared Database Object" and "Diverging a Database Object at Two Databases to Complete Examples".
    

  2. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  3. 

    Run the CREATE_COMPARISON procedure to create the comparison:
    

    BEGIN
  DBMS_COMPARISON.CREATE_COMPARISON(
    comparison_name   => 'compare_custom',
    schema_name       => 'oe',
    object_name       => 'orders',
    dblink_name       => 'comp2.example.com',
    index_schema_name => 'oe',
    index_name        => 'order_pk',
    scan_mode         =>  DBMS_COMPARISON.CMP_SCAN_MODE_CUSTOM);
END;
/

    

    Notice that the scan_mode parameter is set to DBMS_COMPARISON.CMP_SCAN_MODE_CUSTOM. When you specify this scan mode, you should specify the index to use for the comparison. This example specifies the or.order_pk index.
    

  4. 

    Identify the index column or columns for the comparison created in Step 3 by running the following query:
    

    SELECT COLUMN_NAME, COLUMN_POSITION FROM DBA_COMPARISON_COLUMNS 
  WHERE COMPARISON_NAME = 'COMPARE_CUSTOM' AND
        INDEX_COLUMN    = 'Y';

    

    For a custom comparison, you use the index column to specify the portion of the table to compare when you run the COMPARE function in the next step. In this example, the query should return the following output:
    

    COLUMN_NAME                    COLUMN_POSITION
------------------------------ ---------------
ORDER_ID                                     1

    

    This output shows that the order_id column in the oe.orders table is the index column for the comparison.
    

    For other database objects, the CREATE_COMPARISON procedure might identify multiple index columns. If there are multiple index columns, then specify values for the lead index column in the next step. The lead index column shows 1 for its COLUMN_POSITION value.
    

  5. 

    Run the COMPARE function to compare the oe.orders table at the two databases:
    

    SET SERVEROUTPUT ON
DECLARE
  consistent   BOOLEAN;
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  consistent := DBMS_COMPARISON.COMPARE(
                  comparison_name => 'compare_custom',
                  scan_info       => scan_info,
                  min_value       => '2430',
                  max_value       => '2460',
                  perform_row_dif => TRUE);
  DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
  IF consistent=TRUE THEN
    DBMS_OUTPUT.PUT_LINE('No differences were found.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Differences were found.');
  END IF;
END;
/

    

    Notice the following parameter settings in the COMPARE function:
    

    • 

      The min_value and max_value parameters are set to 2430 and 2460, respectively. Therefore, the COMPARE function only compares the range of rows that begins with 2430 and ends with 2460 in the order_id column.
      

    • 

      The min_value and max_value parameters are specified as VARCHAR2 data type values, even though the column data type for the order_id column is NUMBER.
      

    • 

      The perform_row_dif parameter is set to TRUE in the COMPARE function. This setting instructs the COMPARE function to identify each individual row difference in the tables. When the perform_row_dif parameter is set to FALSE, the COMPARE function records whether there are differences in the tables, but does not record each individual row difference.
      

    

    Your output is similar to the following:
    

    Scan ID: 10
Differences were found.
 
PL/SQL procedure successfully completed.










See Also:















Comparing a Shared Database Object That Contains CLOB or BLOB Columns


The DBMS_COMPARISON package does not support directly comparing a shared database object that contains a column of either CLOB or BLOB data type. However, you can complete these basic steps to compare a table with a CLOB or BLOB column:


  1. 

    At each database, create a view based on the table and replace the CLOB or BLOB column with a RAW data type column that is generated using the DBMS_CRYPTO.HASH function.
    

  2. 

    Compare the views created in Step 1.
    



The illustrates how complete these steps for a simple table with a NUMBER column and a CLOB column. In this example, the global names of the databases are comp1.example.com and comp2.example.com, but you can substitute any two databases in your environment that meet the prerequisites described in "Preparing To Compare and Converge a Shared Database Object".









Note:

The DBMS_COMPARISON package cannot converge a shared database object that contains LOB columns.






Complete the following steps:


  1. 

    Complete the tasks described in "Preparing To Compare and Converge a Shared Database Object".
    

  2. 

    At the comp1.example.com database, ensure that the user who owns or will own the table with the CLOB or BLOB column has EXECUTE privilege on the DBMS_CRYPTO package.
    

    In this example, assume the user who will own the table is oe. Complete the following steps to grant this privilege to oe user:
    

    1. 

      In SQL*Plus, connect to the comp1.example.com database as an administrative user who can grant privileges.
      

    2. 

      Grant EXECUTE on the DBMS_CRYPTO package to the user:
      

      GRANT EXECUTE ON DBMS_CRYPTO TO oe;

    

  3. 

    At the comp2.example.com database, ensure that the user who owns or will own the table with the CLOB or BLOB column has EXECUTE privilege on the DBMS_CRYPTO package.
    

    In this example, assume the user who will own the table is oe. Complete the following steps to grant this privilege to oe user:
    

    1. 

      In SQL*Plus, connect to the comp2.example.com database as an administrative user who can grant privileges.
      

    2. 

      Grant EXECUTE on the DBMS_CRYPTO package to the user:
      

      GRANT EXECUTE ON DBMS_CRYPTO TO oe;

    

  4. 

    Create the table with the CLOB column and the view based on the table in the comp1.example.com database:
    

    1. 

      In SQL*Plus, connect to the comp1.example.com database as the user who will own the table.
      

      See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
      

    2. 

      Create the table:
      

      CREATE TABLE oe.tab_lob(
  c1 NUMBER PRIMARY KEY, 
  c2 CLOB DEFAULT to_clob('c2'));

    3. 

      Insert a row into the tab_lob table and commit the change:
      

      INSERT INTO oe.tab_lob VALUES(1, TO_CLOB('row 1'));COMMIT;

    4. 

      Create the view:
      

      BEGIN
  EXECUTE IMMEDIATE 'CREATE VIEW view_lob AS SELECT 
      c1, 
      DBMS_CRYPTO.HASH(c2, '||DBMS_CRYPTO.HASH_SH1||') c2_hash 
    FROM tab_lob';
END;
/

    

    


    

    

    See Also:
    
Oracle Database PL/SQL Packages and Types Reference for more information about the cryptographic hash functions used in the DBMS_CRYPTO package
    

    

    

  5. 

    Create the table with the CLOB column and the view based on the table in the comp2.example.com database:
    

    1. 

      In SQL*Plus, connect to the comp2.example.com database as the user who will own the table.
      

      See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
      

    2. 

      Create the table:
      

      CREATE TABLE oe.tab_lob(
  c1 NUMBER PRIMARY KEY, 
  c2 CLOB DEFAULT to_clob('c2'));

    3. 

      Insert a row into the tab_lob table and commit the change:
      

      INSERT INTO oe.tab_lob VALUES(1, TO_CLOB('row 1'));COMMIT;

    4. 

      Create the view:
      

      BEGIN
  EXECUTE IMMEDIATE 'CREATE VIEW view_lob AS SELECT 
      c1, 
      DBMS_CRYPTO.HASH(c2, '||DBMS_CRYPTO.HASH_SH1||') c2_hash 
    FROM tab_lob';
END;
/

    

  6. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

  7. 

    Run the CREATE_COMPARISON procedure to create the comparison:
    

    BEGIN
  DBMS_COMPARISON.CREATE_COMPARISON(
    comparison_name => 'compare_lob',
    schema_name     => 'oe',
    object_name     => 'view_lob',
    dblink_name     => 'comp2.example.com');
END;
/

    

    Notice that the schema_name and object_name parameters specify the view oe.view_lob and not the table that contains the CLOB column.
    

  8. 

    Run the COMPARE function to compare the oe.view_lob view at the two databases:
    

    SET SERVEROUTPUT ON
DECLARE
  consistent   BOOLEAN;
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  consistent := DBMS_COMPARISON.COMPARE(
                  comparison_name => 'compare_lob',
                  scan_info       => scan_info,
                  perform_row_dif => TRUE);
  DBMS_OUTPUT.PUT_LINE('Scan ID: '||scan_info.scan_id);
  IF consistent=TRUE THEN
    DBMS_OUTPUT.PUT_LINE('No differences were found.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Differences were found.');
  END IF;
END;
/
 
Scan ID: 1
No differences were found.
 
PL/SQL procedure successfully completed.

  9. 

    Make the oe.tab_lob table diverge at two databases by completing the following steps:
    

    1. 

      In SQL*Plus, connect to the comp1.example.com database as the user who owns the table.
      

      See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
      

    2. 

      Insert a row and commit the change:
      

      INSERT INTO oe.tab_lob VALUES(2, TO_CLOB('row a'));
COMMIT;

    3. 

      In SQL*Plus, connect to the comp2.example.com database as the user who owns the table.
      

      See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
      

    4. 

      Insert a row and commit the change:
      

      INSERT INTO oe.tab_lob VALUES(2, TO_CLOB('row b'));
COMMIT;

    

  10. 

    Run the COMPARE function again to compare the oe.view_lob view at the two databases. See Step 8.
    

    The shared table with the CLOB column has diverged at the two databases. Therefore, when you compare the view, the COMPARE function returns the following output:
    

    Scan ID: 2
Differences were found.
 
PL/SQL procedure successfully completed.











Viewing Information About Comparisons and Comparison Results


The following data dictionary views contain information about comparisons created with the DBMS_COMPARISON package:


  • 

    DBA_COMPARISON
    

  • 

    USER_COMPARISON
    

  • 

    DBA_COMPARISON_COLUMNS
    

  • 

    USER_COMPARISON_COLUMNS
    

  • 

    DBA_COMPARISON_SCAN
    

  • 

    USER_COMPARISON_SCAN
    

  • 

    DBA_COMPARISON_SCAN_VALUES
    

  • 

    USER_COMPARISON_SCAN_VALUES
    

  • 

    DBA_COMPARISON_ROW_DIF
    

  • 

    USER_COMPARISON_ROW_DIF
    



The following sections contain sample queries that you can use to monitor comparisons and comparison results:










See Also:

Oracle Database Reference for detailed information about the data dictionary views related to comparisons









Viewing General Information About the Comparisons in a Database


The DBA_COMPARISON data dictionary view contains information about the comparisons in the local database. The query in this section displays the following information about each comparison:


  • 

    The owner of the comparison
    

  • 

    The name of the comparison
    

  • 

    The schema that contains the database object compared by the comparison
    

  • 

    The name of the database object compared by the comparison
    

  • 

    The data type of the database object compared by the comparison
    

  • 

    The scan mode used by the comparison. The following scan modes are possible:
    

    • 

      FULL indicates that the entire database object is compared.
      

    • 

      RANDOM indicates that a random portion of the database object is compared.
      

    • 

      CYCLIC indicates that a portion of the database object is compared during a single comparison. When the database object is compared again, another portion of the database object is compared, starting where the last compare ended.
      

    • 

      CUSTOM indicates that the COMPARE function specifies the range to compare in the database object.
      

    

  • 

    The name of the database link used to connect with the remote database
    



To view this information, run the following query:


COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A22
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A8
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A8
COLUMN OBJECT_TYPE HEADING 'Object|Type' FORMAT A8
COLUMN SCAN_MODE HEADING 'Scan|Mode' FORMAT A6
COLUMN DBLINK_NAME HEADING 'Database|Link' FORMAT A15
 
SELECT OWNER,
       COMPARISON_NAME,
       SCHEMA_NAME,
       OBJECT_NAME,
       OBJECT_TYPE,
       SCAN_MODE,
       DBLINK_NAME
  FROM DBA_COMPARISON;



Your output is similar to the following:


Comparison Comparison             Schema   Object   Object   Scan   Database
Owner      Name                   Name     Name     Type     Mode   Link
---------- ---------------------- -------- -------- -------- ------ ----------
ADMIN      COMPARE_SUBSET_COLUMNS OE       ORDERS   TABLE    FULL   COMP2.EXAM
                                                                    PLE
ADMIN      COMPARE_ORDERS         OE       ORDERS   TABLE    FULL   COMP2.EXAM
                                                                    PLE
ADMIN      COMPARE_RANDOM         OE       ORDERS   TABLE    RANDOM COMP2.EXAM
                                                                    PLE
ADMIN      COMPARE_CYCLIC         OE       ORDERS   TABLE    CYCLIC COMP2.EXAM
                                                                    PLE
ADMIN      COMPARE_CUSTOM         OE       ORDERS   TABLE    CUSTOM COMP2.EXAM
                                                                    PLE



A comparison compares the local database object with a database object at a remote database. The comparison uses the database link shown by the query to connect to the remote database and perform the comparison.


By default, a comparison assumes that the owner, name, and data type of the database objects being compared are the same at both databases. However, they can be different at the local and remote databases. The query in this section does not display information about the remote database object, but you can query the REMOTE_SCHEMA_NAME, REMOTE_OBJECT_NAME, and REMOTE_OBJECT_TYPE columns to view this information.









See Also:

Comparing a Shared Database Object at Two Databases for information about creating the comparisons shown in the output of this query












Viewing Information Specific to Random and Cyclic Comparisons


When you create comparisons that use the scan modes RANDOM or CYCLIC, you specify the percentage of the shared database object to compare. The query in this section shows the following information about random and cyclic comparisons:


  • 

    The owner of the comparison
    

  • 

    The name of the comparison
    

  • 

    The schema that contains the database object compared by the comparison
    

  • 

    The name of the database object compared by the comparison
    

  • 

    The data type of the database object compared by the comparison
    

  • 

    The scan percentage for the comparison. Each time the COMPARE function is run to perform a comparison scan, the specified percentage of the database object is compared.
    

  • 

    The last lead index column value used by the comparison. The next time the COMPARE function is run, it will start with row that has a lead index column value that directly follows the value shown by the query. This value only applies to cyclic comparisons.
    



To view this information, run the following query:


COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A22
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A8
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A8
COLUMN OBJECT_TYPE HEADING 'Object|Type' FORMAT A8
COLUMN SCAN_PERCENT HEADING 'Scan|Percent' FORMAT 999
COLUMN CYCLIC_INDEX_VALUE HEADING 'Cyclic|Index|Value' FORMAT A10
 
SELECT OWNER,
       COMPARISON_NAME,
       SCHEMA_NAME,
       OBJECT_NAME,
       OBJECT_TYPE,
       SCAN_PERCENT,
       CYCLIC_INDEX_VALUE
  FROM DBA_COMPARISON
  WHERE SCAN_PERCENT IS NOT NULL;



Your output is similar to the following:


                                                                     Cyclic
Comparison Comparison             Schema   Object   Object      Scan Index
Owner      Name                   Name     Name     Type     Percent Value
---------- ---------------------- -------- -------- -------- ------- ----------
ADMIN      COMPARE_RANDOM         OE       ORDERS   TABLE         50
ADMIN      COMPARE_CYCLIC         OE       ORDERS   TABLE         50 2677










Viewing the Columns Compared by Each Comparison in a Database


When you create a comparison, you can specify that the comparison compares all of the columns in the shared database object or a subset of the columns. Also, you can specify an index for the comparison to use or let the system identify an index automatically.


The query in this section displays the following information:


  • 

    The owner of the comparison
    

  • 

    The name of the comparison
    

  • 

    The schema that contains the database object compared by the comparison
    

  • 

    The name of the database object compared by the comparison
    

  • 

    The column name of each column being compared in each database object
    

  • 

    The column position of each column
    

  • 

    Whether a column is an index column
    



To display this information, run the following query:


COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A15
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A10
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COLUMN_NAME HEADING 'Column|Name' FORMAT A12
COLUMN COLUMN_POSITION HEADING 'Column|Position' FORMAT 9999
COLUMN INDEX_COLUMN HEADING 'Index|Column?' FORMAT A7
 
SELECT c.OWNER,
       c.COMPARISON_NAME,
       c.SCHEMA_NAME,
       c.OBJECT_NAME,
       o.COLUMN_NAME,
       o.COLUMN_POSITION,
       o.INDEX_COLUMN
  FROM DBA_COMPARISON c, DBA_COMPARISON_COLUMNS o
  WHERE c.OWNER           = o.OWNER AND
        c.COMPARISON_NAME = o.COMPARISON_NAME
  ORDER BY COMPARISON_NAME, COLUMN_POSITION;



Your output is similar to the following:


Comparison Comparison      Schema     Object     Column         Column Index
Owner      Name            Name       Name       Name         Position Column?
---------- --------------- ---------- ---------- ------------ -------- -------
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_ID            1 Y
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_DATE          2 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_MODE          3 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     CUSTOMER_ID         4 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_STATUS        5 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     ORDER_TOTAL         6 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     SALES_REP_ID        7 N
ADMIN      COMPARE_CUSTOM  OE         ORDERS     PROMOTION_ID        8 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_ID            1 Y
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_DATE          2 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_MODE          3 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     CUSTOMER_ID         4 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_STATUS        5 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     ORDER_TOTAL         6 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     SALES_REP_ID        7 N
ADMIN      COMPARE_CYCLIC  OE         ORDERS     PROMOTION_ID        8 N
.
.
.










Viewing General Information About Each Scan in a Database


Each scan compares a bucket at the local database with a bucket at the remote database. The buckets being compared contain the same range of rows in the shared database object. The comparison results generated by a single execution of the COMPARE function can include multiple buckets and multiple scans. Each scan has a unique scan ID.


The query in this section shows the following information about each scan:


  • 

    The owner of the comparison that ran the scan
    

  • 

    The name of the comparison that ran the scan
    

  • 

    The schema that contains the database object compared by the scan
    

  • 

    The name of the database object compared by the scan
    

  • 

    The scan ID of the scan
    

  • 

    The status of the scan. The following status values are possible:
    

    • 

      SUC indicates that the two buckets in the two tables matched the last time this data dictionary row was updated.
      

    • 

      BUCKET DIF indicates that the two buckets in the two tables did not match. Each bucket consists of smaller buckets.
      

    • 

      FINAL BUCKET DIF indicates that the two buckets in the two tables did not match. Neither bucket is composed of smaller buckets. Because the perform_row_dif parameter in the COMPARE function or the RECHECK function was set to FALSE, individual row differences were not identified for the bucket.
      

    • 

      ROW DIF indicates that the two buckets in the two tables did not match. Neither bucket is composed of smaller buckets. Because the perform_row_dif parameter in the COMPARE function or the RECHECK function was set to TRUE, individual row differences were identified for the bucket.
      

    

  • 

    The number of rows compared in the scan
    

  • 

    The last time the scan was updated
    



To view this information, run the following query:


COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A15
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A6
COLUMN SCAN_ID HEADING 'Scan|ID' FORMAT 9999
COLUMN STATUS HEADING 'Scan|Status' FORMAT A10
COLUMN COUNT_ROWS HEADING 'Number|of|Rows' FORMAT 9999999
COLUMN SCAN_NULLS HEADING 'Scan|NULLs?' FORMAT A6
COLUMN LAST_UPDATE_TIME HEADING 'Last|Update' FORMAT A11

SELECT c.OWNER,
       c.COMPARISON_NAME,
       c.SCHEMA_NAME,
       c.OBJECT_NAME,
       s.SCAN_ID,
       s.STATUS,
       s.COUNT_ROWS,
       TO_CHAR(s.LAST_UPDATE_TIME, 'DD-MON-YYYY HH24:MI:SS') LAST_UPDATE_TIME 
  FROM DBA_COMPARISON c, DBA_COMPARISON_SCAN s
  WHERE c.OWNER           = s.OWNER AND
        c.COMPARISON_NAME = s.COMPARISON_NAME
  ORDER BY SCAN_ID;



Your output is similar to the following:


                                                            Number
Comparison Comparison      Schema Object  Scan Scan             of Last
Owner      Name            Name   Name      ID Status         Rows Update
---------- --------------- ------ ------ ----- ---------- -------- -----------
ADMIN      COMPARE_SUBSET_ OE     ORDERS     1 BUCKET DIF          20-DEC-2006
           COLUMNS                                                  09:46:34
ADMIN      COMPARE_SUBSET_ OE     ORDERS     2 ROW DIF         105 20-DEC-2006
           COLUMNS                                                  09:46:34
ADMIN      COMPARE_SUBSET_ OE     ORDERS     3 ROW DIF           1 20-DEC-2006
           COLUMNS                                                  09:46:35
ADMIN      COMPARE_ORDERS  OE     ORDERS     4 BUCKET DIF          20-DEC-2006
                                                                    09:47:02
ADMIN      COMPARE_ORDERS  OE     ORDERS     5 FINAL BUCK      105 20-DEC-2006
                                               ET DIF               09:47:02
ADMIN      COMPARE_ORDERS  OE     ORDERS     6 FINAL BUCK        1 20-DEC-2006
                                               ET DIF               09:47:02
ADMIN      COMPARE_RANDOM  OE     ORDERS     7 SUC                 20-DEC-2006
                                                                    09:47:37
ADMIN      COMPARE_CYCLIC  OE     ORDERS     8 BUCKET DIF          20-DEC-2006
                                                                    09:48:22
ADMIN      COMPARE_CYCLIC  OE     ORDERS     9 ROW DIF         105 20-DEC-2006
                                                                    09:48:22
ADMIN      COMPARE_CUSTOM  OE     ORDERS    10 BUCKET DIF          20-DEC-2006
                                                                    09:49:15
ADMIN      COMPARE_CUSTOM  OE     ORDERS    11 ROW DIF          16 20-DEC-2006
                                                                    09:49:15
ADMIN      COMPARE_CUSTOM  OE     ORDERS    12 ROW DIF          13 20-DEC-2006
                                                                    09:49:15



When a scan has a status of BUCKET DIF, FINAL BUCKET DIF, or ROW DIF, you can converge the differences found in the scan by running the CONVERGE procedure and specifying the scan ID. However, to converge the all of the rows in the comparison results instead of the portion checked in a specific scan, specify the root scan ID for the comparison results when you run the CONVERGE procedure.


Also, when a scan shows that differences were found, you can recheck the scan using the RECHECK function. To recheck all of the rows in the comparison results, run the RECHECK function and specify the root scan ID for the comparison results.









Viewing the Parent Scan ID and Root Scan ID for Each Scan in a Database


The query in this section shows the parent scan ID and root scan ID of each scan in the database. Specifically, the query shows the following information:


  • 

    The owner of the comparison that ran the scan
    

  • 

    The name of the comparison that ran the scan
    

  • 

    The schema that contains the database object compared by the scan
    

  • 

    The name of the database object compared by the scan
    

  • 

    The scan ID of the scan
    

  • 

    The scan ID of the scan's parent scan
    

  • 

    The scan ID of the scan's root scan
    



To view this information, run the following query:


COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A15
COLUMN SCHEMA_NAME HEADING 'Schema|Name' FORMAT A10
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN SCAN_ID HEADING 'Scan|ID' FORMAT 9999
COLUMN PARENT_SCAN_ID HEADING 'Parent|Scan ID' FORMAT 9999
COLUMN ROOT_SCAN_ID HEADING 'Root|Scan ID' FORMAT 9999
 
SELECT c.OWNER,
       c.COMPARISON_NAME,
       c.SCHEMA_NAME,
       c.OBJECT_NAME,
       s.SCAN_ID,
       s.PARENT_SCAN_ID,
       s.ROOT_SCAN_ID
  FROM DBA_COMPARISON c, DBA_COMPARISON_SCAN s
  WHERE c.OWNER           = s.OWNER AND
        c.COMPARISON_NAME = s.COMPARISON_NAME
  ORDER BY s.SCAN_ID;



Your output is similar to the following:


Comparison Comparison      Schema     Object      Scan  Parent    Root
Owner      Name            Name       Name          ID Scan ID Scan ID
---------- --------------- ---------- ---------- ----- ------- -------
ADMIN      COMPARE_SUBSET_ OE         ORDERS         1               1
           COLUMNS
ADMIN      COMPARE_SUBSET_ OE         ORDERS         2       1       1
           COLUMNS
ADMIN      COMPARE_SUBSET_ OE         ORDERS         3       1       1
           COLUMNS
ADMIN      COMPARE_ORDERS  OE         ORDERS         4               4
ADMIN      COMPARE_ORDERS  OE         ORDERS         5       4       4
ADMIN      COMPARE_ORDERS  OE         ORDERS         6       4       4
ADMIN      COMPARE_RANDOM  OE         ORDERS         7               7
ADMIN      COMPARE_CYCLIC  OE         ORDERS         8               8
ADMIN      COMPARE_CYCLIC  OE         ORDERS         9       8       8
ADMIN      COMPARE_CUSTOM  OE         ORDERS        10              10
ADMIN      COMPARE_CUSTOM  OE         ORDERS        11      10      10
ADMIN      COMPARE_CUSTOM  OE         ORDERS        12      10      10



This output shows, for example, that the scan with scan ID 1 is the root scan in the comparison results for the COMPARE_SUBSET_COLUMNS comparison. Differences were found in this root scan, and it was split into two smaller buckets. The scan with scan ID 2 and the scan with scan ID 3 are the scans for these smaller buckets.


To see if there were differences found in a specific scan, run the query in "Viewing General Information About Each Scan in a Database". When you RECHECK for differences or CONVERGE differences in a shared database object, you specify the scan ID of the scan you want to recheck or converge. To recheck or converge all of the rows in the comparison results, specify the root scan ID for the comparison results.









Viewing Detailed Information About the Row Differences Found in a Scan


The queries in this section display detailed information about the row differences found in comparison results. To view the information in the queries in this section, the perform_row_dif parameter in the COMPARE function or the RECHECK function that performed the comparison must have been set to TRUE.


If this parameter was set to FALSE, then you can query the STATUS column in the DBA_COMPARISON_SCAN view to determine whether the scan found any differences, without showing detailed information about the differences. See "Viewing General Information About Each Scan in a Database" for more information and a sample query.


The following query shows the total number of differences found for a scan with the scan ID of 8:


COLUMN OWNER HEADING 'Comparison Owner' FORMAT A16
COLUMN COMPARISON_NAME HEADING 'Comparison Name' FORMAT A25
COLUMN SCHEMA_NAME HEADING 'Schema Name' FORMAT A11
COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A11
COLUMN CURRENT_DIF_COUNT HEADING 'Differences' FORMAT 9999999

SELECT c.OWNER, 
       c.COMPARISON_NAME, 
       c.SCHEMA_NAME, 
       c.OBJECT_NAME, 
       s.CURRENT_DIF_COUNT 
  FROM DBA_COMPARISON c, DBA_COMPARISON_SCAN s
  WHERE c.COMPARISON_NAME = s.COMPARISON_NAME AND
        c.OWNER           = s.OWNER AND
        s.SCAN_ID         = 8;



Your output is similar to the following:


Comparison Owner Comparison Name           Schema Name Object Name Differences
---------------- ------------------------- ----------- ----------- -----------
ADMIN            COMPARE_CYCLIC            OE          ORDERS                6



To view detailed information about each row difference found in the scan with scan ID 8 of the comparison results for the COMPARE_CYCLIC comparison, run the following query:


COLUMN COLUMN_NAME HEADING 'Index Column' FORMAT A15
COLUMN INDEX_VALUE HEADING 'Index Value' FORMAT A15
COLUMN LOCAL_ROWID HEADING 'Local Row Exists?' FORMAT A20
COLUMN REMOTE_ROWID HEADING 'Remote Row Exists?' FORMAT A20

SELECT c.COLUMN_NAME,
       r.INDEX_VALUE, 
       DECODE(r.LOCAL_ROWID,
                NULL, 'No',
                      'Yes') LOCAL_ROWID,
       DECODE(r.REMOTE_ROWID,
                NULL, 'No',
                      'Yes') REMOTE_ROWID
  FROM DBA_COMPARISON_COLUMNS c,
       DBA_COMPARISON_ROW_DIF r,
       DBA_COMPARISON_SCAN s
  WHERE c.COMPARISON_NAME = 'COMPARE_CYCLIC' AND
        r.SCAN_ID         = s.SCAN_ID AND
        s.PARENT_SCAN_ID  = 8 AND
        r.STATUS          = 'DIF' AND
        c.INDEX_COLUMN    = 'Y' AND
        c.COMPARISON_NAME = r.COMPARISON_NAME AND
        c.OWNER           = r.OWNER
  ORDER BY r.INDEX_VALUE;



Your output is similar to the following:


Index Column    Index Value     Local Row Exists?    Remote Row Exists?
--------------- --------------- -------------------- --------------------
ORDER_ID        2366            Yes                  No
ORDER_ID        2385            Yes                  No
ORDER_ID        2396            Yes                  No
ORDER_ID        2425            Yes                  No
ORDER_ID        2440            Yes                  Yes
ORDER_ID        2450            Yes                  No



This output shows the index column for the table being compared and the index value for each row that is different in the shared database object. In this example, the index column is the primary key column for the oe.orders table (order_id). The output also shows the type of difference for each row:


  • 

    If Local Row Exists? and Remote Row Exists? are both Yes for a row, then the row exists in both instances of the database object, but the data in the row is different.
    

  • 

    If Local Row Exists? is Yes and Remote Row Exists? is No for a row, then the row exists in the local database object but not in the remote database object.
    

  • 

    If Local Row Exists? is No and Remote Row Exists? is Yes for a row, then the row exists in the remote database object but not in the local database object.
    









Viewing Information About the Rows Compared in Specific Scans


Each scan compares a range of rows in a shared database object. The query in this section provides the following information about the rows compared in each scan in the database:


  • 

    The owner of the comparison that ran the scan
    

  • 

    The name of the comparison that ran the scan
    

  • 

    The column position of the row values displayed by the query
    

  • 

    The minimum value for the range of rows compared by the scan
    

  • 

    The maximum value for the range of rows compared by the scan
    



A scan compares the row with the minimum value, the row with the maximum value, and all of the rows in between the minimum and maximum values in the database object. For each row returned by the query, the value displayed for the minimum value and the maximum value are the values for the column in the displayed the column position. The column position is an index column for the comparison.


To view this information, run the following query:


COLUMN OWNER HEADING 'Comparison|Owner' FORMAT A10
COLUMN COMPARISON_NAME HEADING 'Comparison|Name' FORMAT A22
COLUMN SCAN_ID HEADING 'Scan|ID' FORMAT 9999
COLUMN COLUMN_POSITION HEADING 'Column|Position' FORMAT 999
COLUMN MIN_VALUE HEADING 'Minimum|Value' FORMAT A15
COLUMN MAX_VALUE HEADING 'Maximum|Value' FORMAT A15
 
SELECT OWNER,
       COMPARISON_NAME,
       SCAN_ID,
       COLUMN_POSITION,
       MIN_VALUE,
       MAX_VALUE
  FROM DBA_COMPARISON_SCAN_VALUES
  ORDER BY SCAN_ID;



Your output is similar to the following:


Comparison Comparison              Scan   Column Minimum         Maximum
Owner      Name                      ID Position Value           Value
---------- ---------------------- ----- -------- --------------- ---------------
ADMIN      COMPARE_SUBSET_COLUMNS     1        1 2354            3000
ADMIN      COMPARE_SUBSET_COLUMNS     2        1 2354            2458
ADMIN      COMPARE_SUBSET_COLUMNS     3        1 3000            3000
ADMIN      COMPARE_ORDERS             4        1 2354            3000
ADMIN      COMPARE_ORDERS             5        1 2354            2458
ADMIN      COMPARE_ORDERS             6        1 3000            3000
ADMIN      COMPARE_RANDOM             7        1 2617.3400241505 2940.3400241505
                                                 667163579712423 667163579712423
                                                 44590999096     44590999096
ADMIN      COMPARE_CYCLIC             8        1 2354            2677
ADMIN      COMPARE_CYCLIC             9        1 2354            2458
ADMIN      COMPARE_CUSTOM            10        1 2430            2460
ADMIN      COMPARE_CUSTOM            11        1 2430            2445
ADMIN      COMPARE_CUSTOM            12        1 2446            2458



This output shows the rows that were compared in each scan. For some comparisons, the scan was split into smaller buckets, and the query shows the rows compared in each smaller bucket.


For example, consider the output for the comparison results of the COMPARE_CUSTOM comparison:


  • 

    Each scan in the comparison results displays column position 1. To determine which column is in column position 1 for the scan, run the query in "Viewing the Columns Compared by Each Comparison in a Database". In this example, the column in column position 1 for the COMPARE_CUSTOM comparison is the order_id column in the oe.orders table.
    

  • 

    Scan ID 10 is a root scan. This scan found differences, and the rows were split into two buckets that are represented by scan ID 11 and scan ID 12.
    

  • 

    Scan ID 11 compared the rows from the row with 2430 for order_id to the row with 2445 for order_id.
    

  • 

    Scan ID 12 compared the rows from the row with 2446 for order_id to the row with 2458 for order_id.
    



To recheck or converge the differences found in a scan, you can run the RECHECK function or CONVERGE procedure, respectively. Specify the scan ID of the scan you want to recheck or converge. To recheck or converge all of the rows in comparison results, specify the root scan ID for the comparison results.











Converging a Shared Database Object


The CONVERGE procedure in the DBMS_COMPARISON package synchronizes the portion of the database object compared by the specified comparison scan and returns information about the changes it made. The CONVERGE procedure only converges the differences identified in the specified scan. A scan might only identify differences in a subset of the rows or columns in a table, and differences might arise after the specified scan completed. In these cases, the CONVERGE procedure might not make the shared database object completely consistent.


To ensure that a scan has the most current differences, it is usually best to run the CONVERGE procedure as soon as possible after running the comparison scan that is being converged. Also, you should only converge rows that are not being updated on either database. For example, if the shared database object is updated by replication components, then only converge rows for which replication changes have already been applied and ensure that no new changes are in the process of being replicated for these rows.









Caution:

If a scan identifies that a row is different in the shared database object at two databases, and the row is modified after the scan, then it can result in unexpected data in the row after the CONVERGE procedure is run.






This section contains the following examples:



These examples converge the comparison results generated in "Comparing a Shared Database Object without Identifying Row Differences". In that example, the comparison name is compare_orders and the returned scan ID is 4. If you completed this example, then the scan ID returned on your system might have been different. Run the following query to determine the scan ID:


SELECT DISTINCT ROOT_SCAN_ID FROM DBA_COMPARISON_SCAN 
  WHERE COMPARISON_NAME = 'COMPARE_ORDERS';



If multiple values are returned, then the comparison was run more than once. In this case, use the largest scan ID returned.


When you want to converge all of the rows in comparison results, specify the root scan ID for the comparison results. If, however, you want to converge a portion of the rows in comparison results, then you can specify the scan ID of the scan that contains differences you want to converge.









See Also:












Converging a Shared Database Object for Consistency with the Local Object


The converge_options parameter in the CONVERGE procedure determines which database "wins" during a conversion. To specify that the local database wins, set the converge_options parameter to DBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINS. When you specify that the local database wins, the data in the database object at the local database replaces the data in the database object at the remote database for each difference found in the specified comparison scan.


To converge a scan of the compare_orders comparison so that both database objects are consistent with the local database, complete the following steps:


  1. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the comparison. The user must also have access to the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Run the CONVERGE procedure:
    

    SET SERVEROUTPUT ON
DECLARE
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  DBMS_COMPARISON.CONVERGE(
    comparison_name  => 'compare_orders',
    scan_id          => 4, -- Substitute the scan ID from your scan.
    scan_info        => scan_info,
    converge_options => DBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINS);
DBMS_OUTPUT.PUT_LINE('Local Rows Merged: '||scan_info.loc_rows_merged);
DBMS_OUTPUT.PUT_LINE('Remote Rows Merged: '||scan_info.rmt_rows_merged);
DBMS_OUTPUT.PUT_LINE('Local Rows Deleted: '||scan_info.loc_rows_deleted);
DBMS_OUTPUT.PUT_LINE('Remote Rows Deleted: '||scan_info.rmt_rows_deleted);
END;
/

    

    Your output is similar to the following:
    

    Local Rows Merged: 0
Remote Rows Merged: 6
Local Rows Deleted: 0
Remote Rows Deleted: 1
 
PL/SQL procedure successfully completed.









Converging a Shared Database Object for Consistency with the Remote Object


The converge_options parameter in the CONVERGE procedure determines which database "wins" during a conversion. To specify that the remote database wins, set the converge_options parameter to DBMS_COMPARISON.CMP_CONVERGE_REMOTE_WINS. When you specify that the remote database wins, the data in the database object at the remote database replaces the data in the database object at the local database for each difference found in the specified comparison scan.


To converge a scan of the compare_orders comparison so that both database objects are consistent with the remote database, complete the following steps:


  1. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the comparison. The user must also have access to the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Run the CONVERGE procedure:
    

    SET SERVEROUTPUT ON
DECLARE
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  DBMS_COMPARISON.CONVERGE(
    comparison_name  => 'compare_orders',
    scan_id          => 4, -- Substitute the scan ID from your scan.
    scan_info        => scan_info,
    converge_options => DBMS_COMPARISON.CMP_CONVERGE_REMOTE_WINS);
DBMS_OUTPUT.PUT_LINE('Local Rows Merged: '||scan_info.loc_rows_merged);
DBMS_OUTPUT.PUT_LINE('Remote Rows Merged: '||scan_info.rmt_rows_merged);
DBMS_OUTPUT.PUT_LINE('Local Rows Deleted: '||scan_info.loc_rows_deleted);
DBMS_OUTPUT.PUT_LINE('Remote Rows Deleted: '||scan_info.rmt_rows_deleted);
END;
/

    

    Your output is similar to the following:
    

    Local Rows Merged: 2
Remote Rows Merged: 0
Local Rows Deleted: 5
Remote Rows Deleted: 0

PL/SQL procedure successfully completed.









Converging a Shared Database Object with a Session Tag Set


If the shared database object being converged is part of an Oracle Streams replication environment, then you can set a session tag so that changes made by the CONVERGE procedure are not replicated. Typically, changes made by the CONVERGE procedure should not be replicated to avoid change cycling, which means sending a change back to the database where it originated. In an Oracle Streams replication environment, you can use session tags to ensure that changes made by the CONVERGE procedure are not captured by Oracle Streams capture processes or synchronous captures and therefore not replicated.


To set a session tag in the session running the CONVERGE procedure, use the following procedure parameters:


  • 

    The local_converge_tag parameter sets a session tag at the local database. Set this parameter to a value that prevents replication when the remote database wins and the CONVERGE procedure makes changes to the local database.
    

  • 

    The remote_converge_tag parameter sets a session tag at the remote database. Set this parameter to a value that prevents replication when the local database wins and the CONVERGE procedure makes changes to the remote database.
    



The appropriate value for a session tag depends on the Oracle Streams replication environment. Set the tag to a value that prevents capture processes and synchronous captures from capturing changes made by the session.



The example in this section specifies that the local database wins the converge operation by setting the converge_options parameter to DBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINS. Therefore, the example sets the remote_converge_tag parameter to the hexadecimal equivalent of '11'. The session tag can be set to any non-NULL value that prevents the changes made by the CONVERGE procedure to the remote database from being replicated.


To converge a scan of the compare_orders comparison so that the database objects are consistent with the local database and a session tag is set at the remote database, complete the following steps:


  1. 

    In SQL*Plus, connect to the comp1.example.com database as the administrative user who owns the comparison. The user must also have access to the database link created in "Preparing To Compare and Converge a Shared Database Object".
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Run the CONVERGE procedure:
    

    SET SERVEROUTPUT ON
DECLARE
  scan_info    DBMS_COMPARISON.COMPARISON_TYPE;
BEGIN
  DBMS_COMPARISON.CONVERGE(
    comparison_name     => 'compare_orders',
    scan_id             => 4, -- Substitute the scan ID from your scan.
    scan_info           => scan_info,
    converge_options    => DBMS_COMPARISON.CMP_CONVERGE_LOCAL_WINS,
    remote_converge_tag => HEXTORAW('11'));
DBMS_OUTPUT.PUT_LINE('Local Rows Merged: '||scan_info.loc_rows_merged);
DBMS_OUTPUT.PUT_LINE('Remote Rows Merged: '||scan_info.rmt_rows_merged);
DBMS_OUTPUT.PUT_LINE('Local Rows Deleted: '||scan_info.loc_rows_deleted);
DBMS_OUTPUT.PUT_LINE('Remote Rows Deleted: '||scan_info.rmt_rows_deleted);
END;
/

    

    Your output is similar to the following:
    

    Local Rows Merged: 0
Remote Rows Merged: 6
Local Rows Deleted: 0
Remote Rows Deleted: 1

PL/SQL procedure successfully completed.










Note:

The CREATE_COMPARISON procedure also enables you to set local and remote convergence tag values. If a tag parameter in the CONVERGE procedure is non-NULL, then it takes precedence over the corresponding tag parameter in the CREATE_COMPARISON procedure. If a tag parameter in the CONVERGE procedure is NULL, then it is ignored, and the corresponding tag value in the CREATE_COMPARISON procedure is used.














Rechecking the Comparison Results for a Comparison


You can recheck a previous comparison scan by using the RECHECK function in the DBMS_COMPARISON package. The RECHECK function checks the current data in the database objects for differences that were recorded in the specified comparison scan.


For example, to recheck the results for scan ID 4 of a comparison named compare_orders, log in to SQL*Plus as the owner of the comparison, and run the following procedure:


SET SERVEROUTPUT ON
DECLARE
  consistent   BOOLEAN;
BEGIN
  consistent := DBMS_COMPARISON.RECHECK(
                  comparison_name => 'compare_orders',
                  scan_id         => 4);
  IF consistent=TRUE THEN
    DBMS_OUTPUT.PUT_LINE('No differences were found.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Differences were found.');
  END IF;
END;
/



Your output is similar to the following:


Differences were found.

PL/SQL procedure successfully completed.



The function returns TRUE if no differences were found or FALSE if differences were found. The compare_orders comparison is created in "Comparing a Shared Database Object without Identifying Row Differences".









Note:


  • 

    The RECHECK function does not compare the shared database object for differences that were not recorded in the specified comparison scan. To check for those differences, run the COMPARE function.
    

  • 

    If the specified comparison scan did not complete successfully, then the RECHECK function starts where the comparison scan previously ended.
    
















See Also:

"Comparing a Shared Database Object at Two Databases" for information about the compare function












Purging Comparison Results


You can purge the comparison results of one or more comparisons when they are no longer needed by using the PURGE_COMPARISON procedure in the DBMS_COMPARISON package. You can either purge all of the comparison results for a comparison or a subset of the comparison results. When comparison results are purged, they can no longer be used to recheck the comparison or converge divergent data. Also, information about the comparison results is removed from data dictionary views.


This section contains these topics:







Purging All of the Comparison Results for a Comparison


To purge all of the comparison results for a comparison, specify the comparison name in the comparison_name parameter, and specify the default value of NULL for the scan_id and purge_time parameters.


For example, to purge all of the comparison results for a comparison named compare_orders, log in to SQL*Plus as the owner of the comparison, and run the following procedure:


BEGIN
  DBMS_COMPARISON.PURGE_COMPARISON(
    comparison_name => 'compare_orders',
    scan_id         => NULL,
    purge_time      => NULL);
END;
/







Purging the Comparison Results for a Specific Scan ID of a Comparison


To purge the comparison results for a specific scan of a comparison, specify the comparison name in the comparison_name parameter, and specify the scan ID in the scan_id parameter. The specified scan ID must identify a root scan. The root scan in comparison results is the highest level parent scan. The root scan does not have a parent. You can identify root scan IDs by querying the ROOT_SCAN_ID column of the DBA_COMPARISON_SCAN data dictionary view.


When you run the PURGE_COMPARISON procedure and specify a root scan, the root scan is purged. In addition, all direct and indirect child scans of the specified root scan are purged. Results for other scans are not purged.


For example, to purge the comparison results for scan ID 4 of a comparison named compare_orders, log in to SQL*Plus as the owner of the comparison, and run the following procedure:


BEGIN
  DBMS_COMPARISON.PURGE_COMPARISON(
    comparison_name => 'compare_orders',
    scan_id         => 4); -- Substitute the scan ID from your scan.
END;
/










Purging the Comparison Results of a Comparison Before a Specified Time


To purge the comparison results that were recorded on or before a specific date and time for a comparison, specify the comparison name in the comparison_name parameter, and specify the date and time in the purge_time parameter. Results are purged regardless of scan ID. Comparison results that were recorded after the specified date and time are retained.


For example, assume that the NLS_TIMESTAMP_FORMAT initialization parameter setting in the current session is YYYY-MM-DD HH24:MI:SS. To purge the results for any scans that were recorded before 1PM on August 16, 2006 for the compare_orders comparison, log in to SQL*Plus as the owner of the comparison, and run the following procedure:


BEGIN
  DBMS_COMPARISON.PURGE_COMPARISON(
    comparison_name => 'compare_orders',
    purge_time      => '2006-08-16 13:00:00');
END;
/









Dropping a Comparison


To drop a comparison and all of its comparison results, use the DROP_COMPARISON procedure in the DBMS_COMPARISON package. For example, to drop a comparison named compare_subset_columns, log in to SQL*Plus as the owner of the comparison, and run the following procedure:


exec DBMS_COMPARISON.DROP_COMPARISON('compare_subset_columns');







Using DBMS_COMPARISON in an Oracle Streams Replication Environment


This section describes the typical uses for the DBMS_COMPARISON package in an Oracle Streams replication environment. These uses are:






Checking for Consistency After Instantiation


After an instantiation, you can use the DBMS_COMPARISON package to verify the consistency of the database objects that were instantiated. Typically, you should verify consistency before the Oracle Streams replication environment is replicating changes. Ensure that you check for consistency before you allow changes to the source database object and the instantiated database object. Changes to these database objects are identified as differences by the DBMS_COMPARISON package.


To verify the consistency of instantiated database objects, complete the following steps:


  1. 

    Create a comparison for each database object that was instantiated using the CREATE_COMPARISON procedure. Each comparison should specify the database object that was instantiated and its corresponding database object at the source database.
    

    When you run the CREATE_COMPARISON procedure, ensure that the comparison_mode, scan_mode, and scan_percent parameters are set to their default values of CMP_COMPARE_MODE_OBJECT, CMP_SCAN_MODE_FULL, and NULL, respectively.
    

  2. 

    Run the COMPARE function to compare each database object that was instantiated. The database objects are consistent if no differences are found.
    

    When you run the COMPARE function, ensure that the min_value, max_value, and perform_row_dif parameters are set to their default values of NULL, NULL, and FALSE, respectively.
    

  3. 

    If differences are found by the COMPARE function, then you can either re-instantiate the database objects or use the CONVERGE procedure to converge them. If you use the CONVERGE procedure, then typically the source database object should "win" during convergence.
    

  4. 

    When the comparison results show that the database objects are consistent, you can purge the comparison results using the PURGE_COMPARISON procedure.
    










See Also:















Checking for Consistency in a Running Oracle Streams Replication Environment


Oracle Streams replication environments continually replicate changes to database objects. Therefore, the following applies to the replicated database objects:


  • 

    Replicated database objects should be nearly synchronized most of the time because Oracle Streams components replicate and apply changes to keep them synchronized.
    

  • 

    If there are differences in replicated database objects, then Oracle Streams components will typically send and apply changes to synchronize the database objects in the near future. That is, a COMPARE function might show differences that are in the process of being replicated.
    



Because differences are expected in database objects while changes are being replicated, using the DBMS_COMPARISON package to compare replicated database objects can be challenging. For example, assume that there is an existing comparison that compares an entire table at two databases, and consider the following scenario:


  1. 

    A change is made to a row in the table at one of the databases.
    

  2. 

    The change is captured by an Oracle Streams capture process, but it has not yet been propagated to the other database.
    

  3. 

    The COMPARE function is run to compare the table tables at the two databases.
    

  4. 

    The COMPARE function identifies a difference in the row that was changed in Step 1.
    

  5. 

    The change is propagated and applied at the destination database. Therefore, the difference identified in Step 4 no longer exists.
    



When differences are found, and you suspect that the differences are transient, you can run the RECHECK function after some time has passed. If Oracle Streams has synchronized the database objects, then the differences will disappear.


If some rows in a replicated database object are constantly updated, then these rows might always show differences in comparison results. In this case, as you monitor the environment, ensure the following:


  • 

    No apply errors are accumulating at the destination database for these rows.
    

  • 

    The rows are being updated correctly by the Oracle Streams apply process at the destination database. You can query the table that contains the rows at the destination database to ensure that the replicated changes are being applied.
    



When both of these statements are true for the rows, then you can ignore differences in the comparison results for them.


Because the COMPARE function might show differences that are in the process of being replicated, it is best to run this function during times when there is the least amount of replication activity in your environment. During times of relatively little replication activity, comparison results show the following types of differences in an Oracle Streams replication environment:


  • 

    Differences resulting when rows are manually manipulated at only one database by an administrator or procedure. For example, an administrator or procedure might set a session tag before making changes, and the session tag might prevent a capture process from capturing the changes.
    

  • 

    Differences resulting from recovery situations in which data is lost at one database and must be identified and recovered from another database.
    

  • 

    Differences resulting from apply errors. In this case, the error transactions are not applied at one database because of apply errors.
    



In any of these situations, you can run the CONVERGE procedure to synchronize the database objects if it is appropriate. For example, if there are apply errors, and it is not easy to reexecute the error transactions, then you can use the CONVERGE procedure to synchronize the database objects.









See Also:

















PKhZAPK+AOEBPS/best_gen.htm

Best Practices for Oracle Streams Replication Databases



15 Best Practices for Oracle Streams Replication Databases


An Oracle Streams replication database is a database that participates in an Oracle Streams replication environment. An Oracle Streams replication environment uses Oracle Streams clients to replicate database changes from one database to another. Oracle Streams clients include capture processes, synchronous captures, propagations, and apply processes. This chapter describes general best practices for Oracle Streams replication databases.


This chapter contains these topics:






Best Practices for Oracle Streams Database Configuration


For your Oracle Streams replication environment to run properly and efficiently, follow the best practices in this section when you are configuring the environment. This section contains these topics:










See Also:

Chapter 1, "Preparing for Oracle Streams Replication" describes best practices to follow when preparing for Oracle Streams replication









Use a Separate Queue for Capture and Apply Oracle Streams Clients


Configure a separate queue for each capture process, for each synchronous capture, and for each apply process, and ensure that each queue has its own queue table. Using separate queues is especially important when configuring bidirectional replication between two databases or when a single database receives messages from several other databases.


For example, suppose a database called db1 is using a capture process to capture changes that will be sent to other databases and is receiving changes from a database named db2. The changes received from db2 are applied by an apply process running on db1. In this scenario, create a separate queue for the capture process and apply process at db1, and ensure that these queues use different queue tables.


The following example creates the queue for the capture process. The queue name is capture_queue, and this queue uses queue table qt_capture_queue:


BEGIN
  DBMS_STREAMS_ADM.SET_UP_QUEUE(
    queue_table => 'strmadmin.qt_capture_queue',
    queue_name  => 'strmadmin.capture_queue');
END;
/



The following example creates the queue for the apply process. The queue name is apply_queue, and this queue uses queue table qt_apply_queue:


BEGIN
  DBMS_STREAMS_ADM.SET_UP_QUEUE(
    queue_table => 'strmadmin.qt_apply_queue',
    queue_name  => 'strmadmin.apply_queue');
END;
/



Subsequently, specify the queue strmadmin.capture_queue when you configure the capture process at db1, and specify the queue strmadmin.apply_queue when you configure the apply process at db1. If necessary, the SET_UP_QUEUE procedure lets you specify a storage_clause parameter to configure separate tablespace and storage specifications for each queue table.


If you automate the configuration, as described in "Automate the Oracle Streams Replication Configuration", then each Oracle Streams client is configured with its own queue automatically.









Automate the Oracle Streams Replication Configuration


Use the following procedures in the DBMS_STREAMS_ADM package to create your Oracle Streams replication environment whenever possible:


  • 

    MAINTAIN_GLOBAL configures an Oracle Streams environment that replicates changes at the database level between two databases.
    

  • 

    MAINTAIN_SCHEMAS configures an Oracle Streams environment that replicates changes to specified schemas between two databases.
    

  • 

    MAINTAIN_SIMPLE_TTS clones a simple tablespace from a source database at a destination database and uses Oracle Streams to maintain this tablespace at both databases.
    

  • 

    MAINTAIN_TABLES configures an Oracle Streams environment that replicates changes to specified tables between two databases.
    

  • 

    MAINTAIN_TTS clones a set of tablespaces from a source database at a destination database and uses Oracle Streams to maintain these tablespaces at both databases.
    

  • 

    PRE_INSTANTIATION_SETUP and POST_INSTANTIATION_SETUP configure an Oracle Streams environment that replicates changes either at the database level or to specified tablespaces between two databases. These procedures must be used together, and instantiation actions must be performed manually, to complete the Oracle Streams replication configuration.
    



These procedures automate the entire configuration of the Oracle Streams clients at multiple databases. Further, the configuration follows Oracle Streams best practices. For example, these procedures create queue-to-queue propagations whenever possible.


If these procedures are not suitable for your environment, then use the following procedures in the DBMS_STREAMS_ADM package to create Oracle Streams clients, rules sets, and rules:



These procedures minimize the number of steps required to configure Oracle Streams clients. It is also possible to create rules for nonexistent objects, so ensure that you check the spelling of each object specified in a rule carefully.


Although it is typically not recommended, a propagation or apply process can be used without rule sets or rules if you always want to propagate or apply all of the messages in a queue. However, a capture process requires one or more rule sets with rules, and a synchronous capture requires a positive rule set. You can use the ADD_GLOBAL_RULES procedure to capture data manipulation language (DML) changes to an entire database with a capture process if a negative rule set is configured for the capture process to filter out changes to unsupported objects. You can also use the ADD_GLOBAL_RULES procedure to capture all data definition language (DDL) changes to the database with a capture process.


The rules in the rule set for a propagation can differ from the rules specified for a capture process or a synchronous capture. For example, to configure that all captured changes be propagated to a destination database, you can run the ADD_GLOBAL_PROPAGATION_RULES procedure for the propagation even though multiple rules might have been configured using ADD_TABLE_RULES for the capture process or synchronous capture. Similarly, the rules in the rule set for an apply process can differ from the rules specified for the capture process, synchronous capture, and propagation(s) that capture and propagate messages to the apply process.


An Oracle Streams client can process changes for multiple tables or schemas. For the best performance, ensure that the rules for these multiple tables or schemas are simple. Complex rules will impact the performance of Oracle Streams. For example, rules with conditions that include LIKE clauses are complex. When you use a procedure in the DBMS_STREAMS_ADM package to create rules, the rules are always simple.


When you configure multiple source databases in an Oracle Streams replication environment, change cycling should be avoided. Change cycling means sending a change back to the database where it originated. You can use Oracle Streams tags to prevent change cycling.









See Also:

















Best Practices for Oracle Streams Database Operation


After the Oracle Streams replication environment is configured, follow the best practices in this section to keep it running properly and efficiently. This section contains these topics:






Follow the Best Practices for the Global Name of an Oracle Streams Database


Oracle Streams uses the global name of a database to identify changes from or to a particular database. For example, the system-generated rules for capture, propagation, and apply typically specify the global name of the source database. In addition, changes captured by an Oracle Streams capture process or synchronous capture automatically include the current global name of the source database. If possible, do not modify the global name of a database that is participating in an Oracle Streams replication environment after the environment has been configured. The GLOBAL_NAMES initialization parameter must also be set to TRUE to guarantee that database link names match the global name of each destination database.


If the global name of an Oracle Streams database must be modified, then do so at a time when no user changes are possible on the database, the queues are empty, and no outstanding changes must be applied by any apply process. When these requirements are met, you can modify the global name of a database and re-create the parts of the Oracle Streams configuration that reference the modified database. All queue subscribers, including propagations and apply processes, must be re-created if the source database global name is changed.









Monitor Performance and Make Adjustments When Necessary


For Oracle Database 11g Release 1 (11.1) and later databases, the Oracle Streams Performance Advisor provides information about how Oracle Streams components are performing. You can use this advisor to monitor the performance of multiple Oracle Streams components in your environment and make adjustments to improve performance when necessary.


The UTL_SPADV package also provides performance statistics for an Oracle Streams environment. This package uses the Oracle Streams Performance Advisor to gather performance statistics. The package enables you to format the statistics in output that can be imported into a spreadsheet for analysis.


For databases before Oracle Database 11g Release 1 (11.1), you can use STRMMON to monitor the performance of an Oracle Streams environment. You can use this tool to obtain a quick overview of the Oracle Streams activity in a database. STRMMON reports information in a single line display. You can configure the reporting interval and the number of iterations to display. STRMMON is available in the rdbms/demo directory in your Oracle home.









See Also:















Monitor Capture Process's and Synchronous Capture's Queues for Size


You should monitor the queues used by a capture process to check for queue size. The number of messages in a queue used by a capture process or synchronous capture increases if the messages in the queue cannot be propagated to one or more destination queues. When a source queue becomes large, it often indicates that there is a problem with the Oracle Streams replication environment. Common reasons why messages cannot be propagated include the following:


  • 

    One of the destination databases is down for an extended period.
    

  • 

    An apply process at a destination database is disabled for an extended period.
    

  • 

    The queue is the source queue for a propagation that cannot deliver the messages to a particular destination queue for an extended period due to network problems or propagation job problems.
    



When a capture process's queue becomes large, the capture process pauses for flow control to minimize the number of messages that are spilled to disk. You can monitor the number of messages in a capture process's queue by querying the V$BUFFERED_QUEUES dynamic performance view. This view shows the number of messages in memory and the number of messages spilled to disk.


You can monitor the number of messages in a synchronous capture's queue by querying the V$PERSISTENT_QUEUES or V$AQ dynamic performance view. This view shows the number of messages in different message states in the persistent queue.


Propagation is implemented using Oracle Scheduler. If a job cannot execute 16 successive times, the job is marked as "broken" and is aborted. Check propagation jobs periodically to ensure that they are running successfully to minimize the size of the source queue.









Follow the Oracle Streams Best Practices for Backups


The following sections contain information about best practices for backing up source databases and destination databases in an Oracle Streams replication environment. A single database can be both a source database and a destination database.





Best Practices for Backups of an Oracle Streams Source Database


A source database is a database where changes captured by a capture process are generated in a redo log or a database where an Oracle Streams synchronous capture is configured. Follow these best practices for backups of an Oracle Streams source database:


  • 

    Use an Oracle Streams tag in the session that runs the online backup SQL statements to ensure that the capture process which captures changes to the source database will not capture the backup statements. An online backup statement uses the BEGIN BACKUP and END BACKUP clauses in an ALTER TABLESPACE or ALTER DATABASE statement. To set an Oracle Streams session tag, use the DBMS_STREAMS.SET_TAG procedure.
    

    


    

    

    Note:
    
Backups performed using Recovery Manager (RMAN) do not need to set an Oracle Streams session tag.
    

    

    


  • 

    Do not allow any automated backup of the archived logs that might remove archive logs required by a capture process. It is especially important in an Oracle Streams environment that all required archive log files remain available online and in the expected location until the capture process has finished processing them. If a log required by a capture process is unavailable, then the capture process will abort.
    

    To list each required archive redo log file in a database, run the following query:
    

    COLUMN CONSUMER_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A10
COLUMN SEQUENCE# HEADING 'Sequence|Number' FORMAT 99999
COLUMN NAME HEADING 'Required|Archived Redo Log|File Name' FORMAT A40
 
SELECT r.CONSUMER_NAME,
       r.SOURCE_DATABASE,
       r.SEQUENCE#, 
       r.NAME 
  FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c
  WHERE r.CONSUMER_NAME =  c.CAPTURE_NAME AND
        r.NEXT_SCN      >= c.REQUIRED_CHECKPOINT_SCN;

  • 

    Ensure that all archive log files from all threads are available. Database recovery depends on the availability of these logs, and a missing log will result in incomplete recovery.
    

  • 

    In situations that result in incomplete recovery (point-in-time recovery) at a source database, follow the instructions in "Performing Point-in-Time Recovery on the Source in a Single-Source Environment" or "Performing Point-in-Time Recovery in a Multiple-Source Environment".
    









Best Practices for Backups of an Oracle Streams Destination Database


In an Oracle Streams replication environment, a destination database is a database where an apply process applies changes. Follow these best practices for backups of an Oracle Streams destination database:











Adjust the Automatic Collection of Optimizer Statistics


Every night by default, the optimizer automatically collects statistics on tables whose statistics have become stale. For volatile tables, such as Oracle Streams queue tables, it is likely that the statistics collection job runs when these tables might not have data that is representative of their full load period.


You create these volatile queue tables using the DBMS_AQADM.CREATE_QUEUE_TABLE or DBMS_STREAMS_ADM.SETUP_QUEUE procedure. You specify the queue table name when you run these procedures. In addition to the queue table, the following tables are created when the queue table is created and are also volatile:


  • 

    AQ$_queue_table_name_I
    

  • 

    AQ$_queue_table_name_H
    

  • 

    AQ$_queue_table_name_T
    

  • 

    AQ$_queue_table_name_P
    

  • 

    AQ$_queue_table_name_D
    

  • 

    AQ$_queue_table_name_C
    



Replace queue_table_name with the name of the queue table.


Oracle recommends that you collect statistics on volatile tables by completing the following steps:


  1. 

    Run the DBMS_STATS.GATHER_TABLE_STATS procedure manually on volatile tables when these tables are at their fullest.
    

  2. 

    Immediately after the statistics are collected on volatile tables, run the DBMS_STATS.LOCK_TABLE_STATS procedure on these tables.
    



Locking the statistics on volatile tables ensures that the automatic statistics collection job skips these tables, and the tables are not analyzed.









See Also:

Oracle Database Performance Tuning Guide for more information about managing optimizer statistics












Check the Alert Log for Oracle Streams Information


By default, the alert log contains information about why Oracle Streams capture and apply processes stopped. Also, Oracle Streams capture and apply processes report long-running and large transactions in the alert log.


Long-running transactions are open transactions with no activity (that is, no new change records, rollbacks, or commits) for an extended period (20 minutes). Large transactions are open transactions with a large number of change records. The alert log reports whether a long-running or large transaction has been seen every 20 minutes. Not all such transactions are reported, because only one transaction is reported for each 20 minute period. When the commit or rollback is received, this information is reported in the alert log as well.


You can use the following views for information about long-running transactions:


  • 

    The V$STREAMS_TRANSACTION dynamic performance view enables monitoring of long running transactions that are currently being processed by Oracle Streams capture processes and apply processes.
    

  • 

    The DBA_APPLY_SPILL_TXN and V$STREAMS_APPLY_READER views enable you to monitor the number of transactions and messages spilled by an apply process.
    










Note:

The V$STREAMS_TRANSACTION view does not pertain to synchronous captures.













See Also:

Oracle Streams Concepts and Administration for more information about Oracle Streams information in the alert log












Follow the Best Practices for Removing an Oracle Streams Configuration at a Database


To completely remove the Oracle Streams configuration at a database, complete the following steps:


  1. 

    In SQL*Plus, connect to the database as an administrative user.
    

    See Oracle Database Administrator's Guide for instructions about connecting to a database in SQL*Plus.
    

  2. 

    Run the DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION procedure.
    

  3. 

    Drop the Oracle Streams administrator, if possible.
    











Best Practices for Oracle Real Application Clusters and Oracle Streams


The following best practices are for Oracle Real Application Clusters (Oracle RAC) databases in Orax$cle Streams replication environments:










See Also:

Oracle Streams Concepts and Administration for more information about how Oracle Streams works with Oracle RAC









Make Archive Log Files of All Threads Available to Capture Processes


The archive log files of all threads from all instances must be available to any instance running a capture process. This requirement pertains to both local and downstream capture processes.








Follow the Best Practices for the Global Name of an Oracle RAC Database


The general best practices described in "Follow the Best Practices for the Global Name of an Oracle Streams Database" also apply to Oracle Real Application Clusters (Oracle RAC) databases in an Oracle Streams environment. In addition, if the global name of an Oracle RAC destination database does not match the DB_NAME.DB_DOMAIN of the database, then include the global name for the database in the list of services for the database specified by the SERVICE_NAMES initialization parameter.


In the tnsnames.ora file, ensure that the CONNECT_DATA clause in the connect descriptor specifies the global name of the destination database for the SERVICE_NAME. Also, ensure that the CONNECT_DATA clause does not include the INSTANCE_NAME parameter.


If the global name of an Oracle RAC database that contains Oracle Streams propagations is changed, then drop and re-create all propagations. Ensure that the new propagations are queue-to-queue propagations by setting the queue_to_queue parameter set to TRUE during creation.


If the global name of an Oracle RAC destination database must be changed, then ensure that the queue used by each apply process is empty and that there are no unapplied transactions before changing the global name. After the global name is changed, drop and re-create each apply process's queue and each apply process.









See Also:

"Follow the Best Practices for Queue Ownership" for more information about the SERVICE_NAME parameter in the tnsnames.ora file












Follow the Best Practices for Configuring and Managing Propagations


The general best practices described in "Restart Broken Propagations" also apply to Oracle Real Application Clusters (Oracle RAC) databases in an Oracle Streams environment. Use the procedures START_PROPAGATION and STOP_PROPAGATION in the DBMS_PROPAGATION_ADM package to start and stop propagations. These procedures automatically handle queue-to-queue propagation.


Also, on an Oracle RAC database, a service is created for each buffered queue. This service always runs on the owner instance of the destination queue and follows the ownership of this queue upon queue ownership switches, which include instance startup, instance shutdown, and so on. This service is used by queue-to-queue propagations. You can query NETWORK_NAME column of the DBA_SERVICES data dictionary view to determine the service name for a queue-to-queue propagation. If you are running Oracle RAC instances, and you have queues that were created before Oracle Database 10g Release 2, then drop and re-create these queues to take advantage of the automatic service generation and queue-to-queue propagation. Ensure that you re-create these queues when they are empty and no new messages are being enqueued into them.









Follow the Best Practices for Queue Ownership


All Oracle Streams processing is done at the owning instance of the queue used by the Oracle Streams client. To determine the owning instance of each ANYDATA queue in a database, run the following query:


SELECT q.OWNER, q.NAME, t.QUEUE_TABLE, t.OWNER_INSTANCE
   FROM DBA_QUEUES q, DBA_QUEUE_TABLES t
   WHERE t.OBJECT_TYPE = 'SYS.ANYDATA' AND
         q.QUEUE_TABLE = t.QUEUE_TABLE AND
         q.OWNER = t.OWNER;



When Oracle Streams is configured in an Oracle Real Application Clusters (Oracle RAC) environment, each queue table has an owning instance. Also, all queues within an individual queue table are owned by the same instance. The following Oracle Streams clients use the owning instance of the relevant queue to perform their work:


  • 

    Each capture process is run at the owning instance of its queue.
    

  • 

    Each propagation is run at the owning instance of the propagation's source queue.
    

  • 

    Each propagation must connect to the owning instance of the propagation's destination queue.
    

  • 

    Each apply process is run at the owning instance of its queue.
    



You can configure ownership of a queue to remain on a specific instance, if that instance is available, by running the DBMS_AQADM.ALTER_QUEUE_TABLE procedure and setting the primary_instance and secondary_instance parameters. When the primary instance of a queue table is set to a specific instance, the queue ownership will return to the specified instance whenever the instance is running.


Capture processes and apply processes automatically follow the ownership of the queue. If the ownership changes while process is running, then the process stops on the current instance and restarts on the new owner instance.


Queue-to-queue propagations send messages only to the specific queue identified as the destination queue. Also, the source database link for the destination database connect descriptor must specify the correct service to connect to the destination database. The CONNECT_DATA clause in the connect descriptor should specify the global name of the destination database for the SERVICE_NAME.


For example, consider the tnsnames.ora file for a database with the global name db.mycompany.com. Assume that the alias name for the first instance is db1 and that the alias for the second instance is db2. The tnsnames.ora file for this database might include the following entries:


db.mycompany.com= 
 (description= 
  (load_balance=on)
   (address=(protocol=tcp)(host=node1-vip)(port=1521))
   (address=(protocol=tcp)(host=node2-vip)(port=1521))
  (connect_data=
     (service_name=db.mycompany.com)))
 
db1.mycompany.com=
 (description=
  (address=(protocol=tcp)(host=node1-vip)(port=1521))
  (connect_data= 
    (service_name=db.mycompany.com)
    (instance_name=db1)))
 
db2.mycompany.com= 
 (description= 
  (address=(protocol=tcp)(host=node2-vip)(port=1521))
  (connect_data= 
    (service_name=db.mycompany.com)
    (instance_name=db2)))









PKN;xPK+AOEBPS/config_add.htm

Adding to an Oracle Streams Replication Environment



4 Adding to an Oracle Streams Replication Environment


This chapter contains instructions for adding database objects and databases to an existing Oracle Streams replication environment.


This chapter contains these topics:










Note:

Certain types of database objects are not supported by Oracle Streams. When you extend an Oracle Streams environment, ensure that no capture process attempts to capture changes to an unsupported database object. Also, ensure that no synchronous capture or apply process attempts to process changes to unsupported columns. To list unsupported database objects and unsupported columns, query the DBA_STREAMS_UNSUPPORTED and DBA_STREAMS_COLUMNS data dictionary views.










About Adding to an Oracle Streams Replication Environment


Sometimes it is necessary to extend an Oracle Streams replication environment when the needs of your organization change. You can extend an Oracle Streams replication environment by adding database objects or databases.


There are three ways to extend an Oracle Streams replication environment:






About Using the Setup Streams Replication Wizard or a Single Configuration Procedure


There are two easy ways to extend an Oracle Streams replication environment:


  • 

    Run the Setup Streams Replication Wizard in Oracle Enterprise Manager
    

  • 

    Run one of the following procedures in the DBMS_STREAMS_ADM package:
    

    • 

      The MAINTAIN_GLOBAL procedure can add a new database to an environment that replicates changes to all of the database objects in the databases.
      

    • 

      The MAINTAIN_SCHEMAS procedure can add one or more new schemas to the existing databases in the replication environment, or it can add a new database that replicates schemas that are currently being replicated.
      

    • 

      The MAINTAIN_SIMPLE_TTS procedure can add a new simple tablespace to an existing replication environment, or it can add a new database that replicates a simple tablespace that is currently being replicated.
      

    • 

      The MAINTAIN_TABLES procedure can add one or more new tables to the existing databases in the replication environment, or it can add a new database that replicates tables that are currently being replicated.
      

    • 

      The MAINTAIN_TTS procedure can add a new set of tablespaces to an existing replication environment, or it can add a new database that replicates a set of tablespaces that are currently being replicated.
      

    



To use either of these methods to extend an Oracle Streams replication environment, the environment must meet the following conditions:


  • 

    It must be a two-database or hub-and-spoke replication environment that was configured by the Setup Streams Replication Wizard or by one of the configuration procedures in the DBMS_STREAMS_ADM package. See Oracle Database 2 Day + Data Replication and Integration Guide for information about these types of replication environments.
    

  • 

    It cannot use a synchronous capture at any database in the Oracle Streams replication environment. See Oracle Streams Concepts and Administration for more information about synchronous capture.
    

  • 

    If you are adding a database to the environment, then each database that captures changes must use a local capture process. No database can use a downstream capture process. If you are adding one or more database objects to the environment, then the databases can use either local or downstream capture processes. See "Decide Whether to Configure Local or Downstream Capture for the Source Database" for more information about downstream capture.
    

  • 

    If you are adding database objects to the replication environment, then the database objects must exist at the database specified in the source_database parameter of the configuration procedure.
    



If your environment meets these conditions, then you can use the Setup Streams Replication Wizard or a single procedure to extend the environment.


The following are additional requirements for cases in which the replicated database objects already exist at an intended destination database before you run the wizard or procedure:


  • 

    If you are adding database objects to the replication environment, and one or more of these database objects exist at a database other than the source database, then meet the following requirements:
    


  • 

    If you are adding a database to the replication environment, then any of the database objects that are replicated in the current environment exist at the added database, then meet the following requirements:
    




For instructions about adding to a replication environment using the wizard or a single procedure, see the following documentation:










See Also:

Oracle Database PL/SQL Packages and Types Reference for information about the procedures in the DBMS_STREAMS_ADM chapter












About Adding the Oracle Streams Components Individually in Multiple Steps


If you cannot extend the Oracle Streams replication environment by using the Setup Streams Replication Wizard or a configuration procedure in the DBMS_STREAMS_ADM package, then you must complete the configuration steps manually. These steps include adding the necessary rules and Oracle Streams components to the environment, and other configuration steps.


If you must extend the Oracle Streams replication environment manually, then see the instructions in "Adding Components Individually in Multiple Steps".










Adding Multiple Components Using a Single Procedure


This section describes adding Oracle Streams components a single PL/SQL procedure in the DBMS_STREAMS_ADM package. Oracle Streams components include queues, rules, rule sets, capture processes, synchronous captures, propagations, and apply processes.


This section contains these topics:






Adding Database Objects to a Replication Environment Using a Single Procedure


This topic includes an example that uses the MAINTAIN_TABLES procedure in the DBMS_STREAMS_ADM package to add tables to an existing hub-and-spoke replication environment. When the example is complete, the Oracle Streams replication environment replicates the changes made to the added tables at the databases in the environment.


Specifically, the example in this topic extends the replication environment configured in "Example That Configures Hub-and-Spoke Replication". That configuration has the following characteristics:


  • 

    The hr schema is replicated at the hub.example.com, spoke1.example.com, and spoke2.example.com databases.
    

  • 

    The hub.example.com database is the hub database in the hub-and-spoke environment, while the other databases are the spoke databases.
    

  • 

    The spoke databases allow changes to the replicated schema, and each database has a local capture process to capture these changes.
    

  • 

    Update conflict handlers are configured for each replicated table at each database to resolve conflicts
    



This example adds the following tables to the environment:


  • 

    oe.orders
    

  • 

    oe.order_items
    



This example uses the tables in the oe sample schema. The oe sample schema is installed by default with Oracle Database.









Note:

Before you use a configuration procedure in the DBMS_STREAMS_ADM package to extend an Oracle Streams replication environment, ensure that the environment meets the conditions described in "About Using the Setup Streams Replication Wizard or a Single Configuration Procedure".






Complete the following steps:


  1. 

    Ensure that the following directory objects exist, and remove any files related to the previous configuration from them, including Data Pump export dump files and export log files:
    

    • 

      The hub_dir directory object at the hub.example.com database.
      

    • 

      The spoke1_dir directory object at the spoke1.example.com database.
      

    • 

      The spoke2_dir directory object at the spoke2.example.com database.
      

    

  2. 

    Stop the capture process at the hub database in the hub-and-spoke environment.
    

    Use the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package to stop a capture process, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about stopping a capture process using Oracle Enterprise Manager.
    

    In this example, stop the capture process at the hub.example.com database. The replicated database objects can remain open to changes while the capture process is stopped. These changes will be captured when the capture process is restarted.
    

  3. 

    In SQL*Plus, run the appropriate configuration procedure in the DBMS_STREAMS_ADM package at the hub database to add each new database object for each spoke database.
    

    You might need to run the procedure several times if the environment has multiple spoke databases. In this example, complete the following steps:
    

    1. 

      Open SQL*Plus and connect to the hub.example.com database as the Oracle Streams administrator.
      

      See Oracle Database 2 Day DBA for more information about starting SQL*Plus.
      

    2. 

      Run the MAINTAIN_TABLES procedure to add the oe.orders and oe.order_items tables for replication between hub.example.com and spoke1.example.com:
      

      DECLARE
  tables DBMS_UTILITY.UNCL_ARRAY;
  BEGIN
    tables(1) := 'oe.orders';
    tables(2) := 'oe.order_items';
    DBMS_STREAMS_ADM.MAINTAIN_TABLES(
      table_names                  => tables,
      source_directory_object      => 'hub_dir',
      destination_directory_object => 'spoke1_dir',
      source_database              => 'hub.example.com',
      destination_database         => 'spoke1.example.com',
      capture_name                 => 'capture_hns',
      capture_queue_table          => 'source_hns_qt',
      capture_queue_name           => 'source_hns',
      propagation_name             => 'propagation_spoke1',
      apply_name                   => 'apply_spoke1',
      apply_queue_table            => 'destination_spoke1_qt',
      apply_queue_name             => 'destination_spoke1',
      bi_directional               => TRUE);
END;
/

      

      The MAINTAIN_TABLES procedure can take some time to run because it is performing many configuration tasks. Do not allow data manipulation language (DML) or data definition language (DDL) changes to the specified tables at the destination database while the procedure is running. When the procedure completes, the new database objects are added to the environment, and the capture process that was stopped in Step 2 is restarted.
      

      When a configuration procedure is run, information about its progress is recorded in the following data dictionary views: DBA_RECOVERABLE_SCRIPT, DBA_RECOVERABLE_SCRIPT_PARAMS, DBA_RECOVERABLE_SCRIPT_BLOCKS, and DBA_RECOVERABLE_SCRIPT_ERRORS. If the procedure stops because it encounters an error, then see Oracle Streams Replication Administrator's Guide for instructions about using the RECOVER_OPERATION procedure in the DBMS_STREAMS_ADM package to recover from these errors.
      

      The parameter values that specify Oracle Streams component names must be the same as the values specified in the configuration procedure in the DBMS_STREAMS_ADM package that configured the replication environment. The Oracle Streams component names specified include the capture process name, queue names, queue table names, the propagation name, and the apply process name. In this example, the Oracle Streams component names match the ones specified in "Example That Configures Hub-and-Spoke Replication".
      

    3. 

      Run the MAINTAIN_TABLES procedure to add the oe.orders and oe.order_items tables for replication between hub.example.com and spoke2.example.com:
      

      DECLARE
  tables DBMS_UTILITY.UNCL_ARRAY;
  BEGIN
    tables(1) := 'oe.orders';
    tables(2) := 'oe.order_items';
    DBMS_STREAMS_ADM.MAINTAIN_TABLES(
      table_names                  => tables,
      source_directory_object      => 'hub_dir',
      destination_directory_object => 'spoke2_dir',
      source_database              => 'hub.example.com',
      destination_database         => 'spoke2.example.com',
      capture_name                 => 'capture_hns',
      capture_queue_table          => 'source_hns_qt',
      capture_queue_name           => 'source_hns',
      propagation_name             => 'propagation_spoke2',
      apply_name                   => 'apply_spoke2',
      apply_queue_table            => 'destination_spoke2_qt',
      apply_queue_name             => 'destination_spoke2',
      bi_directional               => TRUE);
END;
/

    

  4. 

    Set the instantiation SCN for the replicated tables at the spoke databases:
    

    


    

    

    Note:
    
This step is required in this example because the replicated tables existed at the spoke databases before the MAINTAIN_TABLES procedure was run. If the replicated tables did not exist at the spoke databases before the MAINTAIN_TABLES procedure was run, then the procedure sets the instantiation SCN for the replicated tables and this step is not required. Ensure that the data in the shared table is consistent at the source and destination databases when the instantiation SCN is set and that no changes are made to the table at the source database until after the SCN that is used for the instantiation SCN.
    

    

    

    1. 

      In SQL*Plus, connect to the hub.example.com database as the Oracle Streams administrator.
      

      See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
      

    2. 

      Set the instantiation SCN for the oe.orders table at the spoke1.example.com database:
      

      DECLARE
  iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke1.example.com(
    source_object_name    => 'oe.orders',
    source_database_name  => 'hub.example.com',
    instantiation_scn     => iscn);
END;
/

    3. 

      Set the instantiation SCN for the oe.order_items table at the spoke1.example.com database:
      

      DECLARE
  iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke1.example.com(
    source_object_name    => 'oe.order_items',
    source_database_name  => 'hub.example.com',
    instantiation_scn     => iscn);
END;
/

    4. 

      Set the instantiation SCN for the oe.orders table at the spoke2.example.com database:
      

      DECLARE
  iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke2.example.com(
    source_object_name    => 'oe.orders',
    source_database_name  => 'hub.example.com',
    instantiation_scn     => iscn);
END;
/

    5. 

      Set the instantiation SCN for the oe.order_items table at the spoke2.example.com database:
      

      DECLARE
  iscn  NUMBER;    -- Variable to hold instantiation SCN value
BEGIN
  iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER();
  DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@spoke2.example.com(
    source_object_name    => 'oe.order_items',
    source_database_name  => 'hub.example.com',
    instantiation_scn     => iscn);
END;
/

    

  5. 

    Configure latest time conflict resolution for the orders and order_items tables in the oe schema at the hub.example.com, spoke1.example.com, and spoke2.example.com databases. See Oracle Database 2 Day + Data Replication and Integration Guide for instructions.
    









Adding a Database to a Replication Environment Using a Single Procedure


This topic includes an example that uses the MAINTAIN_SCHEMAS procedure in the DBMS_STREAMS_ADM package to add a new spoke database to an existing hub-and-spoke replication environment. When the example is complete, the Oracle Streams replication environment replicates the changes made to the schema with the new database.


Specifically, the example in this topic extends the replication environment configured in "Example That Configures Hub-and-Spoke Replication". That configuration has the following characteristics:


  • 

    The hr schema is replicated at the hub.example.com, spoke1.example.com, and spoke2.example.com databases.
    

  • 

    The hub.example.com database is the hub database in the hub-and-spoke environment, while the other databases are the spoke databases.
    

  • 

    The spoke databases allow changes to the replicated schema, and each database has a local capture process to capture these changes.
    



This example adds the spoke3.example.com database to the environment.









Note:

Before you use a configuration procedure in the DBMS_STREAMS_ADM package to extend an Oracle Streams replication environment, ensure that the environment meets the conditions described in "About Using the Setup Streams Replication Wizard or a Single Configuration Procedure".






Complete the following steps:


  1. 

    Complete the following tasks to prepare the environment for the new database:
    

    1. 

      Configure network connectivity so that the hub database can communicate with the new spoke database. In this example, configure network connectivity so that the hub.example.com database and the spoke3.example.com databases can communicate with each other.
      

      See Oracle Database 2 Day DBA for information about configuring network connectivity between databases.
      

    2. 

      Configure an Oracle Streams administrator at the new spoke database. In this example, configure an Oracle Streams administrator at the spoke3.example.com database. See "Configuring an Oracle Streams Administrator on All Databases" for instructions. This example assumes that the Oracle Streams administrator is strmadmin.
      

    3. 

      Create a database link from the hub database to new spoke database and from new spoke database to the hub database. In this example, create the following database links:
      

      • 

        From the hub.example.com database to the spoke3.example.com database. Both the name and the service name of the database link must be spoke3.example.com.
        

      • 

        From the spoke3.example.com database to the hub.example.com database. Both the name and the service name of the database link must be hub.example.com.
        

      

      Each database link should be created in the Oracle Streams administrator's schema. Also, each database link should connect to the Oracle Streams administrator at the destination database. See "Configuring Network Connectivity and Database Links" for instructions.
      

    4. 

      Set initialization parameters properly at the new spoke database. In this example, set initialization parameters properly at the spoke3.example.com database. See "Setting Initialization Parameters Relevant to Oracle Streams" for instructions.
      

    5. 

      Configure the new spoke database to run in ARCHIVELOG mode. For a capture process to capture changes generated at a source database, the source database must be running in ARCHIVELOG mode. In this example, configure the spoke3.example.com database to run in ARCHIVELOG mode. See Oracle Database Administrator's Guide for information about configuring a database to run in ARCHIVELOG mode.
      

    6. 

      Ensure that the hub_dir directory objects exist at the hub.example.com database, and remove any files related to the previous configuration from it, including Data Pump export dump files and export log files.
      

    

  2. 

    Open SQL*Plus and connect to the spoke3.example.com database as the Oracle Streams administrator.
    

    See Oracle Database 2 Day DBA for more information about starting SQL*Plus.
    

  3. 

    Create a directory object to hold files that will be generated by the MAINTAIN_SCHEMAS procedure, including the Data Pump export dump file used for instantiation. The directory object can point to any accessible directory on the computer system. For example, the following statement creates a directory object named spoke3_dir that points to the /usr/spoke3_log_files directory:
    

    CREATE DIRECTORY spoke3_dir AS '/usr/spoke3_log_files';

  4. 

    Stop the capture process at the hub database in the hub-and-spoke environment.
    

    Use the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM package to stop a capture process, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about stopping a capture process using Oracle Enterprise Manager.
    

    In this example, stop the capture process at the hub.example.com database. The replicated database objects can remain open to changes while the capture process is stopped. These changes will be captured when the capture process is restarted.
    

  5. 

    In SQL*Plus, run the appropriate configuration procedure in the DBMS_STREAMS_ADM package at the hub database to add the new spoke database.
    

    In this example, complete the following steps:
    

    1. 

      Open SQL*Plus and connect to the hub.example.com database as the Oracle Streams administrator.
      

    2. 

      Run the MAINTAIN_SCHEMAS procedure to add the spoke3.example.com database to the Oracle Streams replication environment:
      

      BEGIN
  DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
    schema_names                 => 'hr',
    source_directory_object      => 'hub_dir',
    destination_directory_object => 'spoke3_dir',
    source_database              => 'hub.example.com',
    destination_database         => 'spoke3.example.com',
    capture_name                 => 'capture_hns',
    capture_queue_table          => 'source_hns_qt',
    capture_queue_name           => 'source_hns',
    propagation_name             => 'propagation_spoke3',
    apply_name                   => 'apply_spoke3',
    apply_queue_table            => 'destination_spoke3_qt',
    apply_queue_name             => 'destination_spoke3',
    bi_directional               => TRUE);
END;
/

      

      The MAINTAIN_SCHEMAS procedure can take some time to run because it is performing many configuration tasks. Do not allow data manipulation language (DML) or data definition language (DDL) changes to the database objects in the specified schema at the destination database while the procedure is running. When the procedure completes, the new database objects are added to the environment, and the capture process that was stopped in Step 4 is restarted.
      

      The parameter values specified in capture_name, capture_queue_table, and capture_queue_name must be the same as the values specified in the configuration procedure in the DBMS_STREAMS_ADM package that configured the replication environment. In this example, these parameter values match the ones specified in "Example That Configures Hub-and-Spoke Replication".
      

      When a configuration procedure is run, information about its progress is recorded in the following data dictionary views: DBA_RECOVERABLE_SCRIPT, DBA_RECOVERABLE_SCRIPT_PARAMS, DBA_RECOVERABLE_SCRIPT_BLOCKS, and DBA_RECOVERABLE_SCRIPT_ERRORS. If the procedure stops because it encounters an error, then see Oracle Streams Replication Administrator's Guide for instructions about using the RECOVER_OPERATION procedure in the DBMS_STREAMS_ADM package to recover from these errors.
      

    

  6. 

    Configure latest time conflict resolution for all of the tables in the hr schema at the spoke3.example.com database. This schema includes the countries, departments, employees, jobs, job_history, locations, and regions tables. See Oracle Database 2 Day + Data Replication and Integration Guide for instructions.
    











Adding Components Individually in Multiple Steps


This section describes adding Oracle Streams components separately to extend a replication environment. Oracle Streams components include queues, rules, rule sets, capture processes, synchronous captures, propagations, and apply processes.


This section contains these topics:










Note:


  • 

    When possible, it is usually easier to extend an Oracle Streams replication environment using either a single procedure or the Setup Streams Replication Wizard in Oracle Enterprise Manager. See "Adding Multiple Components Using a Single Procedure" for instructions about using a single procedure and Oracle Database 2 Day + Data Replication and Integration Guide for instructions about using the wizard.
    

  • 

    The instructions in the following sections assume you will use the DBMS_STREAMS_ADM package to configure your Oracle Streams environment. If you use other packages, then extra steps might be necessary for each task.
    












Adding Replicated Objects to an Existing Single-Source Environment


You can add existing database objects to an existing single-source environment by adding the necessary rules to the appropriate capture processes, synchronous captures, propagations, and apply processes. Before creating or altering capture or propagation rules in a running Oracle Streams environment, ensure that any propagations or apply processes that will receive logical change records (LCRs) because of the new or altered rules are configured to handle these LCRs. That is, the propagations or apply processes should exist, and each one should be associated with rule sets that handle the LCRs appropriately. If these propagations and apply processes are not configured properly to handle these LCRs, then LCRs might be lost.


For example, suppose you want to add a table to an Oracle Streams replication environment that already captures, propagates, and applies changes to other tables. Assume that only one capture process or synchronous captures will capture changes to this table, and only one apply process will apply changes to this table. In this case, you must add one or more table rules to the following rule sets:


  • 

    The positive rule set for the apply process that will apply changes to the table
    

  • 

    The positive rule set for each propagation that will propagate changes to the table
    

  • 

    The positive rule set for the capture process or synchronous capture that will capture changes to the table
    



If you perform administrative steps in the wrong order, you can lose LCRs. For example, if you add the rule to a capture process rule set first, without stopping the capture process, then the propagation will not propagate the changes if it does not have a rule that instructs it to do so, and the changes can be lost.


This example assumes that the replicated database objects are read-only at the destination databases. If the replicated database objects are read/write at the destination databases, then the replication environment will not stay synchronized because Oracle Streams is not configured to replicate the changes made to the replicated database objects at the destination databases.


Figure 4-1 shows the additional configuration steps that must be completed to add replicated database objects to a single-source Oracle Streams environment.




Figure 4-1 Example of Adding Replicated Objects to a Single-Source Environment

Description of Figure 4-1 follows

Description of "Figure 4-1 Example of Adding Replicated Objects to a Single-Source Environment"





To avoid losing LCRs, complete the configuration in the following order:


  1. 

    At each source database where replicated database objects are being added, specify supplemental logging for the added replicated database objects. See "Specifying Supplemental Logging" for instructions.
    

  2. 

    Either stop the capture process, one of the propagations, or the apply processes:
    


    In general, it is best to stop the capture process so that messages do not accumulate in queues during the operation.
    

    


    

    

    Note:
    
Synchronous captures cannot be stopped.
    

    

    

    


    

    

    See Also:
    
Oracle Streams Concepts and Administration for more information about completing these tasks with PL/SQL procedures
    

    

    

  3. 

    Add the relevant rules to the rule sets for the apply processes. To add rules to the rule set for an apply process, you can run one of the following procedures:
    


    Excluding the ADD_SUBSET_RULES procedure, these procedures can add rules to the positive or negative rule set for an apply process. The ADD_SUBSET_RULES procedure can add rules only to the positive rule set for an apply process.
    

  4. 

    Add the relevant rules to the rule sets for the propagations. To add rules to the rule set for a propagation, you can run one of the following procedures:
    


    Excluding the ADD_SUBSET_PROPAGATION_RULES procedure, these procedures can add rules to the positive or negative rule set for a propagation. The ADD_SUBSET_PROPAGATION_RULES procedure can add rules only to the positive rule set for a propagation.
    

  5. 

    Add the relevant rules to the rule sets used by the capture process or synchronous capture. To add rules to a rule set for an existing capture process, you can run one of the following procedures and specify the existing capture process:
    


    Excluding the ADD_SUBSET_RULES procedure, these procedures can add rules to the positive or negative rule set for a capture process. The ADD_SUBSET_RULES procedure can add rules only to the positive rule set for a capture process.
    

    To add rules to a rule set for an existing synchronous capture, you can run one of the following procedures and specify the existing synchronous capture:
    


    When you use a procedure in the DBMS_STREAMS_ADM package to add the capture process rules, it automatically runs the PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively, if the capture process is a local capture process or a downstream capture process with a database link to the source database.
    

    You must run the appropriate procedure to prepare for instantiation manually if any of the following conditions is true:
    

    • 

      You use DBMS_RULE_ADM to create or modify rules in a capture process rule set.
      

    • 

      You do not add rules for the added objects to a capture process rule set, because the capture process already captures changes to these objects. In this case, rules for the objects can be added to propagations and apply processes in the environment, but not to the capture process.
      

    • 

      You use a downstream capture process with no database link to the source database.
      

    

    If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
    

    When you use a procedure in the DBMS_STREAMS_ADM package to add the synchronous capture rules, it automatically runs the PREPARE_SYNC_INSTANTIATION function in the DBMS_CAPTURE_ADM package for the specified table.
    

  6. 

    At each destination database, either instantiate, or set the instantiation SCN for, each database object you are adding to the Oracle Streams environment. If the database objects do not exist at a destination database, then instantiate them using export/import, transportable tablespaces, or RMAN. If the database objects already exist at a destination database, then set the instantiation SCNs for them manually.
    

    • 

      To instantiate database objects using export/import, first export them at the source database. Next, import them at the destination database. See Chapter 8, "Instantiation and Oracle Streams Replication".
      

      Do not allow any changes to the database objects being exported while exporting these database objects at the source database. Do not allow changes to the database objects being imported while importing these database objects at the destination database.
      

      You can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.
      

    • 

      To set the instantiation SCN for a table, schema, or database manually, run the appropriate procedure or procedures in the DBMS_APPLY_ADM package at a destination database:
      

      • 

        SET_TABLE_INSTANTIATION_SCN
        

      • 

        SET_SCHEMA_INSTANTIATION_SCN
        

      • 

        SET_GLOBAL_INSTANTIATION_SCN
        

      

      When you run one of these procedures at a destination database, you must ensure that every added object at the destination database is consistent with the source database as of the instantiation SCN.
      

      If you run SET_GLOBAL_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to TRUE so that the instantiation SCN also is set for each schema at the destination database and for the tables owned by these schemas.
      

      If you run SET_SCHEMA_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to TRUE so that the instantiation SCN also is set for each table in the schema.
      

      If you set the recursive parameter to TRUE in the SET_GLOBAL_INSTANTIATION_SCN procedure or the SET_SCHEMA_INSTANTIATION_SCN procedure, then a database link from the destination database to the source database is required. This database link must have the same name as the global name of the source database and must be accessible to the user who executes the procedure. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
      

      Alternatively, you can perform a metadata export/import to set the instantiation SCNs for existing database objects. If you choose this option, then ensure that no rows are imported. Also, ensure that every added object at the importing destination database is consistent with the source database that performed the export at the time of the export. If you are sharing DML changes only, then table level export/import is sufficient. If you are sharing DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.
      

    

  7. 

    Start any Oracle Streams client you stopped in Step 2:
    


    


    

    

    See Also:
    
Oracle Streams Concepts and Administration for more information about completing these tasks using PL/SQL procedures
    

    

    



You must stop the capture process, disable one of the propagation jobs, or stop the apply process in Step 2 to ensure that the table or schema is instantiated before the first LCR resulting from the added rule(s) reaches the apply process. Otherwise, LCRs could be lost or could result in apply errors, depending on whether the apply process rule(s) have been added.


If you are certain that the added table is not being modified at the source database during this procedure, and that there are no LCRs for the table already in the stream or waiting to be captured, then you can perform Step 7 before Step 6 to reduce the amount of time that an Oracle Streams process or propagation job is stopped.









See Also:

Oracle Streams Extended Examples for a detailed example that adds objects to an existing single-source environment












Adding a New Destination Database to a Single-Source Environment


You can add a destination database to an existing single-source environment by creating one or more new apply processes at the new destination database and, if necessary, configuring one or more propagations to send changes to the new destination database. You might also need to add rules to existing propagations in the stream that send changes to the new destination database.


As in the example that describes "Adding Replicated Objects to an Existing Single-Source Environment", before creating or altering propagation rules in a running Oracle Streams replication environment, ensure that any propagations or apply processes that will receive logical change records (LCRs) because of the new or altered rules are configured to handle these LCRs. Otherwise, LCRs might be lost.


This example assumes that the replicated database objects are read-only at the destination databases. If the replicated database objects are read/write at the destination databases, then the replication environment will not stay synchronized because Oracle Streams is not configured to replicate the changes made to the replicated database objects at the destination databases.


Figure 4-2 shows the additional configuration steps that must be completed to add a destination database to a single-source Oracle Streams environment.




Figure 4-2 Example of Adding a Destination to a Single-Source Environment

Description of Figure 4-2 follows

Description of "Figure 4-2 Example of Adding a Destination to a Single-Source Environment"





To avoid losing LCRs, you should complete the configuration in the following order:


  1. 

    Complete the necessary tasks to prepare each database in your environment for Oracle Streams. See "Tasks to Complete Before Configuring Oracle Streams Replication".
    

    Some of these tasks might not be required at certain databases.
    

  2. 

    Create any necessary ANYDATA queues that do not already exist at the destination database. When you create an apply process, you associate the apply process with a specific ANYDATA queue. See "Creating an ANYDATA Queue" for instructions.
    

  3. 

    Create one or more apply processes at the new destination database to apply the changes from its source database. Ensure that each apply process uses rule sets that are appropriate for applying changes. Do not start any of the apply processes at the new database. See Chapter 7, "Configuring Implicit Apply" for instructions.
    

    Keeping the apply processes stopped prevents changes made at the source databases from being applied before the instantiation of the new database is completed. Starting the apply processes might lead to incorrect data and errors.
    

  4. 

    Configure any necessary propagations to send changes from the source databases to the new destination database. Ensure that each propagation uses rule sets that are appropriate for propagating changes. See "Creating Oracle Streams Propagations Between ANYDATA Queues".
    

  5. 

    At the source database, prepare for instantiation each database object for which changes will be applied by an apply process at the new destination database.
    

    If you are using one or more capture processes, then run either the PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively.
    

    If you are using one or more synchronous captures, then run the PREPARE_SYNC_INSTANTIATION function in the DBMS_CAPTURE_ADM package for the specified table.
    

    See "Preparing Database Objects for Instantiation at a Source Database".
    

  6. 

    At the new destination database, either instantiate, or set the instantiation SCNs for, each database object for which changes will be applied by an apply process. If the database objects do not already exist at the new destination database, then instantiate them using export/import, transportable tablespaces, or RMAN. If the database objects exist at the new destination database, then set the instantiation SCNs for them.
    

    • 

      To instantiate database objects using export/import, first export them at the source database. Next, import them at the destination database. See Chapter 8, "Instantiation and Oracle Streams Replication".
      

      Do not allow any changes to the database objects being exported while exporting these database objects at the source database. Do not allow changes to the database objects being imported while importing these database objects at the destination database.
      

      You can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.
      

    • 

      To set the instantiation SCN for a table, schema, or database manually, run the appropriate procedure or procedures in the DBMS_APPLY_ADM package at the new destination database:
      

      • 

        SET_TABLE_INSTANTIATION_SCN
        

      • 

        SET_SCHEMA_INSTANTIATION_SCN
        

      • 

        SET_GLOBAL_INSTANTIATION_SCN
        

      

      When you run one of these procedures, you must ensure that the replicated database objects at the new destination database are consistent with the source database as of the instantiation SCN.
      

      If you run SET_GLOBAL_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to TRUE so that the instantiation SCN also is set for each schema at the destination database and for the tables owned by these schemas.
      

      If you run SET_SCHEMA_INSTANTIATION_SCN at a destination database, then set the recursive parameter for this procedure to TRUE so that the instantiation SCN also is set for each table in the schema.
      

      If you set the recursive parameter to TRUE in the SET_GLOBAL_INSTANTIATION_SCN procedure or the SET_SCHEMA_INSTANTIATION_SCN procedure, then a database link from the destination database to the source database is required. This database link must have the same name as the global name of the source database and must be accessible to the user who executes the procedure. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
      

      Alternatively, you can perform a metadata export/import to set the instantiation SCNs for existing database objects. If you choose this option, then ensure that no rows are imported. Also, ensure that the replicated database objects at the importing destination database are consistent with the source database that performed the export at the time of the export. If you are sharing DML changes only, then table level export/import is sufficient. If you are sharing DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.
      

    

  7. 

    Start the apply processes you created in Step 3 using the START_APPLY procedure in the DBMS_APPLY_ADM package, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about starting an apply process using Oracle Enterprise Manager.
    










See Also:

Oracle Streams Extended Examples for detailed example that adds a database to an existing single-source environment












Adding Replicated Objects to an Existing Multiple-Source Environment


You can add existing database objects to an existing multiple-source environment by adding the necessary rules to the appropriate capture processes, synchronous captures, propagations, and apply processes.


This example uses the following terms:


  • 

    Populated database: A database that already contains the replicated database objects being added to the multiple-source environment. You must have at least one populated database to add the objects to the environment.
    

  • 

    Export database: A populated database on which you perform an export of the database objects you are adding to the environment. This export is used to instantiate the added database objects at the import databases. You might not have an export database if all of the databases in the environment are populated databases.
    

  • 

    Import database: A database that does not contain the replicated database objects before they are added to the multiple-source environment. You instantiate the replicated database objects at an import database by performing an import of these database objects. You might not have any import databases if all of the databases in the environment are populated databases.
    



Before creating or altering capture or propagation rules in a running Oracle Streams replication environment, ensure that any propagations or apply processes that will receive logical change records (LCRs) because of the new or altered rules are configured to handle these LCRs. That is, the propagations or apply processes should exist, and each one should be associated with rule sets that handle the LCRs appropriately. If these propagations and apply processes are not configured properly to handle these LCRs, then LCRs can be lost.


For example, suppose you want to add a new table to an Oracle Streams replication environment that already captures, propagates, and applies changes to other tables. Assume multiple capture processes or synchronous captures in the environment will capture changes to this table, and multiple apply processes will apply changes to this table. In this case, you must add one or more table rules to the following rule sets:


  • 

    The positive rule set for each apply process that will apply changes to the table
    

  • 

    The positive rule set for each propagation that will propagate changes to the table
    

  • 

    The positive rule set for each capture process or synchronous capture that will capture changes to the table
    



If you perform administrative steps in the wrong order, then you can lose LCRs. For example, if you add the rule to a capture process rule set first, without stopping the capture process, then the propagation will not propagate the changes if it does not have a rule that instructs it to do so, and the changes can be lost.


Figure 4-3 shows the additional configuration steps that must be completed to add replicated database objects to a multiple-source Oracle Streams environment.




Figure 4-3 Example of Adding Replicated Objects to a Multiple-Source Environment

Description of Figure 4-3 follows

Description of "Figure 4-3 Example of Adding Replicated Objects to a Multiple-Source Environment"





When there are multiple source databases in an Oracle Streams replication environment, change cycling is possible. Change cycling happens when a change is sent back to the database where it originated. Typically, you should avoid change cycling. Before you configure your replication environment, see Chapter 10, "Oracle Streams Tags", and ensure that you configure the replication environment to avoid change cycling.


To avoid losing LCRs, complete the configuration in the following order:


  1. 

    At each populated database, specify any necessary supplemental logging for the objects being added to the environment. See "Specifying Supplemental Logging" for instructions.
    

  2. 

    Either stop all of the capture processes that will capture changes to the added objects, stop all of the propagations that will propagate changes to the added objects, or stop all of the apply process that will apply changes to the added objects:
    


    In general, it is best to stop the capture process so that messages do not accumulate in queues during the operation.
    

    


    

    

    Note:
    
Synchronous captures cannot be stopped.
    

    

    

    


    

    

    See Also:
    
Oracle Streams Concepts and Administration for more information about completing these tasks using PL/SQL procedures
    

    

    

  3. 

    Add the relevant rules to the rule sets for the apply processes that will apply changes to the added objects. To add rules to the rule set for an apply process, you can run one of the following procedures:
    


    Excluding the ADD_SUBSET_RULES procedure, these procedures can add rules to the positive or negative rule set for an apply process. The ADD_SUBSET_RULES procedure can add rules only to the positive rule set for an apply process.
    

  4. 

    Add the relevant rules to the rule sets for the propagations that will propagate changes to the added objects. To add rules to the rule set for a propagation, you can run one of the following procedures:
    


    Excluding the ADD_SUBSET_PROPAGATION_RULES procedure, these procedures can add rules to the positive or negative rule set for a propagation. The ADD_SUBSET_PROPAGATION_RULES procedure can add rules only to the positive rule set for a propagation.
    

  5. 

    Add the relevant rules to the rule sets used by each capture process or synchronous capture that will capture changes to the added objects. To add rules to a rule set for an existing capture process, you can run one of the following procedures and specify the existing capture process:
    


    Excluding the ADD_SUBSET_RULES procedure, these procedures can add rules to the positive or negative rule set for a capture process. The ADD_SUBSET_RULES procedure can add rules only to the positive rule set for a capture process.
    

    To add rules to a rule set for an existing synchronous capture, you can run one of the following procedures and specify the existing synchronous capture:
    


    When you use a procedure in the DBMS_STREAMS_ADM package to add the capture process rules, it automatically runs the PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively, if the capture process is a local capture process or a downstream capture process with a database link to the source database.
    

    You must run the appropriate procedure to prepare for instantiation manually if any of the following conditions is true:
    

    • 

      You use DBMS_RULE_ADM to create or modify rules in a capture process rule set.
      

    • 

      You do not add rules for the added objects to a capture process rule set, because the capture process already captures changes to these objects. In this case, rules for the objects can be added to propagations and apply processes in the environment, but not to the capture process.
      

    • 

      You use a downstream capture process with no database link to the source database.
      

    

    If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
    

    When you use a procedure in the DBMS_STREAMS_ADM package to add the synchronous capture rules, it automatically runs the PREPARE_SYNC_INSTANTIATION function in the DBMS_CAPTURE_ADM package for the specified table.
    



After completing these steps, complete the steps in each of the following sections that apply to your environment. You might need to complete the steps in only one of these sections or in both of these sections:






Configuring Populated Databases When Adding Replicated Objects


After completing the steps in "Adding Replicated Objects to an Existing Multiple-Source Environment", complete the following steps for each populated database if your environment has multiple populated databases:


  1. 

    For each populated database, set the instantiation SCN for each added object at the other populated databases in the environment. These instantiation SCNs must be set, and only the changes made at a particular populated database that are committed after the corresponding SCN for that database will be applied at another populated database.
    

    For each populated database, you can set these instantiation SCNs for each added database object in one of the following ways:
    

    • 

      Perform a metadata only export of the added database objects at the populated database and import the metadata at each of the other populated databases. Such an import sets the required instantiation SCNs for the database at the other databases. Ensure that no rows are imported. Also, ensure that the replicated database objects at each of the other populated databases are consistent with the populated database that performed the export at the time of the export.
      

      If you are replicating DML changes only, then table level export/import is sufficient. If you are replicating DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.
      

    • 

      Set the instantiation SCNs manually for the added objects at each of the other populated databases. Ensure that every added database object at each populated database is consistent with the instantiation SCNs you set at that database. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
      

    









Adding Replicated Objects to Import Databases in an Existing Environment


After completing the steps in "Adding Replicated Objects to an Existing Multiple-Source Environment", complete the following steps for the import databases:



  1. 

    Pick the populated database that you will use as the export database. Do not perform the instantiations yet.
    

  2. 

    For each import database, set the instantiation SCNs for the added database objects at all of the other databases in the environment that will be a destination database of the import database. In this case, the import database will be the source database for these destination databases. The databases where you set the instantiation SCNs might be populated databases and other import databases.
    

    1. 

      If one or more schemas will be created at an import database during instantiation or by a subsequent replicated DDL change, then run the SET_GLOBAL_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for this import database at all of the other databases in the environment.
      

    2. 

      If a schema exists at an import database, and one or more tables will be created in the schema during instantiation or by a subsequent replicated DDL change, then run the SET_SCHEMA_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for the schema for this import database at each of the other databases in the environment. Do this for each such schema.
      

    

    See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
    

    Because you run these procedures before any tables are instantiated at the import databases, and because the local capture processes or synchronous captures are configured already for these import databases, you will not need to run the SET_TABLE_INSTANTIATION_SCN procedure for each table created during instantiation. Instantiation SCNs will be set automatically for these tables at all of the other databases in the environment that will be destination databases of the import database.
    

  3. 

    At the export database you chose in Step 1, perform an export of the replicated database objects. Next, perform an import of the replicated database objects at each import database. See Chapter 8, "Instantiation and Oracle Streams Replication" and Oracle Database Utilities for information about using export/import.
    

    Do not allow any changes to the database objects being exported while exporting these database objects at the source database. Do not allow changes to the database objects being imported while importing these database objects at the destination database.
    

    You can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.
    

  4. 

    For each populated database, except for the export database, set the instantiation SCNs for the added database objects at each import database that will be a destination database of the populated source database. These instantiation SCNs must be set, and only the changes made at a populated database that are committed after the corresponding SCN for that database will be applied at an import database.
    

    For each populated database, you can set these instantiation SCNs for the added objects in one of the following ways:
    

    • 

      Perform a metadata only export of the added database objects at the populated database and import the metadata at each import database. Each import sets the required instantiation SCNs for the populated database at the import database. In this case, ensure that every added database object at the import database is consistent with the populated database at the time of the export.
      

      If you are replicating DML changes only, then table level export/import is sufficient. If you are replicating DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.
      

    • 

      Set the instantiation SCNs manually for the added objects at each import database. Ensure that every added object at each import database is consistent with the populated database as of the corresponding instantiation SCN. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
      

    









Finish Adding Objects to a Multiple-Source Environment Configuration


Before completing the configuration, you should have completed the following tasks:



When all of the previous configuration steps are finished, complete the following steps:


  1. 

    At each database, configure conflict resolution for the added database objects if conflicts are possible. See Chapter 9, "Oracle Streams Conflict Resolution" for instructions.
    

  2. 

    Start each Oracle Streams client you stopped in Step 2 in "Adding Replicated Objects to an Existing Multiple-Source Environment":
    


    


    

    

    See Also:
    
Oracle Streams Concepts and Administration for more information about completing these tasks using the PL/SQL procedures
    

    

    











Adding a New Database to an Existing Multiple-Source Environment


Figure 4-4 shows the additional configuration steps that must be completed to add a source/destination database to a multiple-source Oracle Streams environment.




Figure 4-4 Example of Adding a Database to a Multiple-Source Environment

Description of Figure 4-4 follows

Description of "Figure 4-4 Example of Adding a Database to a Multiple-Source Environment"





When there are multiple source databases in an Oracle Streams replication environment, change cycling is possible. Change cycling happens when a change is sent back to the database where it originated. Typically, you should avoid change cycling. Before you configure your replication environment, see Chapter 10, "Oracle Streams Tags", and ensure that you configure the replication environment to avoid change cycling.


Complete the following steps to add a new source/destination database to an existing multiple-source Oracle Streams replication environment:









Note:

Ensure that no changes are made to the database objects being replicated at the database you are adding to the Oracle Streams replication environment until the instantiation at the database is complete.






  1. 

    Complete the necessary tasks to prepare each database in your environment for Oracle Streams. See "Tasks to Complete Before Configuring Oracle Streams Replication".
    

    Some of these tasks might not be required at certain databases.
    

  2. 

    Create any necessary ANYDATA queues that do not already exist. When you create a capture process, synchronous capture, or apply process, you associate the process with a specific ANYDATA queue. When you create a propagation, you associate it with a specific source queue and destination queue. See "Creating an ANYDATA Queue" for instructions.
    

  3. 

    Create one or more apply processes at the new database to apply the changes from its source databases. Ensure that each apply process uses rule sets that are appropriate for applying changes. Do not start any apply process at the new database. See Chapter 7, "Configuring Implicit Apply" for instructions.
    

    Keeping the apply processes stopped prevents changes made at the source databases from being applied before the instantiation of the new database is completed. Starting the apply processes might lead to incorrect data and errors.
    

  4. 

    If the new database will be a source database, then, at all databases that will be destination databases for the changes made at the new database, create one or more apply processes to apply changes from the new database. Ensure that each apply process uses rule sets that are appropriate for applying changes. Do not start any of these new apply processes. See Chapter 7, "Configuring Implicit Apply" for instructions.
    

  5. 

    Configure propagations at the databases that will be source databases of the new database to send changes to the new database. Ensure that each propagation uses rule sets that are appropriate for propagating changes. See "Creating Oracle Streams Propagations Between ANYDATA Queues".
    

  6. 

    If the new database will be a source database, then configure propagations at the new database to send changes from the new database to each of its destination databases. Ensure that each propagation uses rule sets that are appropriate for propagating changes. See "Creating Oracle Streams Propagations Between ANYDATA Queues".
    

  7. 

    If the new database will be a source database, and the replicated database objects already exist at the new database, then specify any necessary supplemental logging for the replicated database objects at the new database. See "Specifying Supplemental Logging" for instructions.
    

  8. 

    At each source database for the new database, prepare for instantiation each database object for which changes will be applied by an apply process at the new database.
    

    If you are using one or more capture processes, then run either the PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively.
    

    If you are using one or more synchronous captures, then run the PREPARE_TABLE_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table.
    

    See "Preparing Database Objects for Instantiation at a Source Database" for instructions.
    

  9. 

    If the new database will be a source database, then create one or more capture processes or synchronous captures to capture the relevant changes. See Chapter 5, "Configuring Implicit Capture" for instructions. If you plan to use capture processes, then Oracle recommends that you use only one capture process for each source database.
    

    When you use a procedure in the DBMS_STREAMS_ADM package to add the capture process rules, it automatically runs the PREPARE_TABLE_INSTANTIATION, PREPARE_SCHEMA_INSTANTIATION, or PREPARE_GLOBAL_INSTANTIATION procedure in the DBMS_CAPTURE_ADM package for the specified table, specified schema, or entire database, respectively, if the capture process is a local capture process or a downstream capture process with a database link to the source database.
    

    You must run the appropriate procedure to prepare for instantiation manually if any of the following conditions is true:
    

    • 

      You use the DBMS_RULE_ADM package to add or modify rules.
      

    • 

      You use an existing capture process and do not add capture process rules for any replicated database object.
      

    • 

      You use a downstream capture process with no database link to the source database.
      

    

    If you must prepare for instantiation manually, then see "Preparing Database Objects for Instantiation at a Source Database" for instructions.
    

    When you use a procedure in the DBMS_STREAMS_ADM package to add the synchronous capture rules, it automatically runs the PREPARE_SYNC_INSTANTIATION function in the DBMS_CAPTURE_ADM package for the specified table.
    

  10. 

    If the new database will be a source database, then start any capture process you created in Step 9 using the START_CAPTURE procedure in the DBMS_CAPTURE_ADM package, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about starting a capture process using Oracle Enterprise Manager.
    



After completing these steps, complete the steps in the appropriate section:






Configuring Databases If the Replicated Objects Already Exist at the New Database


After completing the steps in "Adding a New Database to an Existing Multiple-Source Environment", complete the following steps if the objects that are to be replicated with the new database already exist at the new database:


  1. 

    For each source database of the new database, set the instantiation SCNs at the new database. These instantiation SCNs must be set, and only the changes made at a source database that are committed after the corresponding SCN for that database will be applied at the new database.
    

    For each source database of the new database, you can set these instantiation SCNs in one of the following ways:
    

    • 

      Perform a metadata only export of the replicated database objects at the source database, and import the metadata at the new database. The import sets the required instantiation SCNs for the source database at the new database. Ensure that no rows are imported. In this case, ensure that the replicated database objects at the new database are consistent with the source database at the time of the export.
      

      If you are replicating DML changes only, then table level export/import is sufficient. If you are replicating DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.
      

    • 

      Set the instantiation SCNs manually at the new database for the replicated database objects. Ensure that the replicated database objects at the new database are consistent with the source database as of the corresponding instantiation SCN. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
      

    

  2. 

    For the new database, set the ins%tantiation SCNs at each destination database of the new database. These instantiation SCNs must be set, and only the changes made at the new source database that are committed after the corresponding SCN will be applied at a destination database. If the new database is not a source database, then do not complete this step.
    

    You can set these instantiation SCNs for the new database in one of the following ways:
    

    • 

      Perform a metadata only export at the new database and import the metadata at each destination database. Ensure that no rows are imported. The import sets the required instantiation SCNs for the new database at each destination database. In this case, ensure that the replicated database objects at each destination database are consistent with the new database at the time of the export.
      

      If you are replicating DML changes only, then table level export/import is sufficient. If you are replicating DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.
      

    • 

      Set the instantiation SCNs manually at each destination database for the replicated database objects. Ensure that the replicated database objects at each destination database are consistent with the new database as of the corresponding instantiation SCN. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
      

    

  3. 

    At the new database, configure conflict resolution if conflicts are possible. See Chapter 9, "Oracle Streams Conflict Resolution" for instructions.
    

  4. 

    Start the apply processes that you created at the new database in Step 3 using the START_APPLY procedure in the DBMS_APPLY_ADM package, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about starting an apply process using Oracle Enterprise Manager.
    

  5. 

    Start the apply processes that you created at each of the other destination databases in Step 4. If the new database is not a source database, then do not complete this step.
    









Adding Replicated Objects to a New Database


After completing the steps in "Adding a New Database to an Existing Multiple-Source Environment", complete the following steps if the database objects that are to be shared with the new database do not already exist at the new database:


  1. 

    If the new database is a source database for other databases, then, at each destination database of the new source database, set the instantiation SCNs for the new database.
    

    1. 

      If one or more schemas will be created at the new database during instantiation or by a subsequent replicated DDL change, then run the SET_GLOBAL_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for the new database at each destination database of the new database.
      

    2. 

      If a schema exists at the new database, and one or more tables will be created in the schema during instantiation or by a subsequent replicated DDL change, then run the SET_SCHEMA_INSTANTIATION_SCN procedure in the DBMS_APPLY_ADM package for the schema at each destination database of the new database. Do this for each such schema.
      

    

    See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
    

    Because you run these procedures before any tables are instantiated at the new database, and because the local capture process or synchronous capture is configured already at the new database, you will not need to run the SET_TABLE_INSTANTIATION_SCN procedure for each table created during instantiation. Instantiation SCNs will be set automatically for these tables at all of the other databases in the environment that will be destination databases of the new database.
    

    If the new database will not be a source database, then do not complete this step, and continue with the next step.
    

  2. 

    Pick one source database from which to instantiate the replicated database objects at the new database using export/import. First, perform an export of the replicated database objects. Next, perform an import of the replicated database objects at the new database. See Chapter 8, "Instantiation and Oracle Streams Replication" and Oracle Database Utilities for information about using export/import.
    

    Do not allow any changes to the database objects being exported while exporting these database objects at the source database. Do not allow changes to the database objects being imported while importing these database objects at the destination database.
    

    You can specify a more stringent degree of consistency by using an export parameter such as FLASHBACK_SCN or FLASHBACK_TIME.
    

  3. 

    For each source database of the new database, except for the source database that performed the export for instantiation in Step 2, set the instantiation SCNs at the new database. These instantiation SCNs must be set, and only the changes made at a source database that are committed after the corresponding SCN for that database will be applied at the new database.
    

    For each source database, you can set these instantiation SCNs in one of the following ways:
    

    • 

      Perform a metadata only export at the source database and import the metadata at the new database. The import sets the required instantiation SCNs for the source database at the new database. In this case, ensure that the replicated database objects at the new database are consistent with the source database at the time of the export.
      

      If you are replicating DML changes only, then table level export/import is sufficient. If you are replicating DDL changes also, then additional considerations apply. See "Setting Instantiation SCNs Using Export/Import" for more information about performing a metadata export/import.
      

    • 

      Set the instantiation SCNs manually at the new database for the replicated database objects. Ensure that the replicated database objects at the new database are consistent with the source database as of the corresponding instantiation SCN. See "Setting Instantiation SCNs Using the DBMS_APPLY_ADM Package" for instructions.
      

    

  4. 

    At the new database, configure conflict resolution if conflicts are possible. See Chapter 9, "Oracle Streams Conflict Resolution" for instructions.
    

  5. 

    Start the apply processes that you created in Step 3 at the new database using the START_APPLY procedure in the DBMS_APPLY_ADM package, or see Oracle Database 2 Day + Data Replication and Integration Guide for instructions about starting an apply process using Oracle Enterprise Manager.
    

  6. 

    Start the apply processes that you created in Step 4 at each of the other destination databases. If the new database is not a source database, then do not complete this step.
    













PKB\ڟPK

+Aoa,mimetypePK+Ai[V:iTunesMetadata.plistPK+AYuMETA-INF/container.xmlPK+A6R>OEBPS/rep2strm.htmPK+A=OEBPS/rep_tags.htmPK+AKo,vOEBPS/config_flex.htmPK+A[pTOrOEBPS/cover.htmPK+A96<
7
OEBPS/ptrep_best.htmPK+Az&OEBPS/title.htmPK+A32(<OEBPS/hetero.htmPK+AGA{AOEBPS/best_apply.htmPK+A*JM s1n1OEBPS/best_prop.htmPK+AjeC>KOEBPS/preface.htmPK+AʩUƏ..
iOEBPS/ccap.htmPK+A9]՗OEBPS/index.htmPK+Aa8z[u[OEBPS/capply.htmPK+A&7OEBPS/conflict.htmPK+AOEBPS/img/strep504.gifPK+A00OEBPS/img/strep014.gifPK+Ai\hhOEBPS/img/strep042.gifPK+A즘\	OEBPS/img/strep024.gifPK+AR$M$$
OEBPS/img/strep064.gifPK+A	7ʨB8I
OEBPS/img/strep065.gifPK+AvOEE
OEBPS/img/strep041.gifPK+A՟0``DOEBPS/img/strep062.gifPK+A
?D:DۤOEBPS/img/strep038.gifPK+ABLpf^OEBPS/img/strep050.gifPK+AO0FZZOEBPS/img/strep506.gifPK+AGj%eeOEBPS/img/strep059.gifPK+A:2D-DK
OEBPS/img/strep051.gifPK+A5N?8:8W
OEBPS/img/strep063.gifPK+Aĝlpgp
OEBPS/img/strep060.gifPK+AZ9OEBPS/img/strep_setup.gifPK+AaTuOEBPS/img/strep066.gifPK+AzZv5q5}OEBPS/img/strep009.gifPK+A[W7OEBPS/img/strep022.gifPK+A&JrrCOEBPS/img/strep067.gifPK+A	bTTpOOEBPS/img/strep049.gifPK+A+TLaGazOEBPS/img/strep028.gifPK+A\ybtb
OEBPS/img/strep048.gifPK+ANKkahOEBPS/img/strep509.gifPK+Aww܂M}MvOEBPS/img/strep_wizard.gifPK+AA5?0?@6OEBPS/img/strep101.gifPK+A0,"uOEBPS/img/strep040.gifPK+A
rpp)OEBPS/img/strep043.gifPK+AItZTUT_OEBPS/img/strep030.gifPK+Ah.ggOEBPS/img/strep052.gifPK+AڵxlslAOEBPS/img/strep061.gifPK+AC'yyOEBPS/img/strep039.gifPK+A["

t(OEBPS/ptrep_config.htmPK+A2OEBPS/img_text/strep050.htmPK+AG4OEBPS/img_text/strep101.htmPK+Ab:[7OEBPS/img_text/strep014.htmPK+ASQJE;:OEBPS/img_text/strep061.htmPK+A0,@OEBPS/img_text/strep509.htmPK+ApXLOEBPS/img_text/strep009.htmPK+AlJGB	POEBPS/img_text/strep038.htmPK+AejUOEBPS/img_text/strep066.htmPK+AjNlg[OEBPS/img_text/strep059.htmPK+A`+&bOEBPS/img_text/strep040.htmPK+A>%hOEBPS/img_text/strep504.htmPK+AcixOEBPS/img_text/strep067.htmPK+A5|q~OEBPS/img_text/strep048.htmPK+AAiOEBPS/img_text/strep043.htmPK+A~WXSʈOEBPS/img_text/strep022.htmPK+Aq8kOEBPS/img_text/strep052.htmPK+ACe OEBPS/img_text/strep506.htmPK+A28"OEBPS/img_text/strep024.htmPK+A&OEBPS/img_text/strep064.htmPK+As+)OEBPS/img_text/strep051.htmPK+AhZupBOEBPS/img_text/strep_setup.htmPK+AYOEBPS/img_text/strep039.htmPK+ALPOEBPS/img_text/strep042.htmPK+Ar@2GBIOEBPS/img_text/strep_wizard.htmPK+A0ݿOEBPS/img_text/strep049.htmPK+A`s94OEBPS/img_text/strep065.htmPK+AHtxOEBPS/img_text/strep063.htmPK+A%%OEBPS/img_text/strep030.htmPK+A#OEBPS/img_text/strep060.htmPK+Aup_OEBPS/img_text/strep028.htmPK+A3'e83OEBPS/img_text/strep041.htmPK+A 6OEBPS/img_text/strep062.htmPK+A2*"OEBPS/ptrep_ap.htmPK+A;۔44OEBPS/man_lcrs.htmPK+Add!OEBPS/prep_rep.htmPK+AȆOEBPS/config_simple.htmPK+A>{{qOEBPS/instant.htmPK+AЃ
OEBPS/toc.ncxPK+ABTOEBPS/man_gen_rep.htmPK+A]yVAAD!OEBPS/content.opfPK+A_	U!OEBPS/dcommon/prodbig.gifPK+AY@
[!OEBPS/dcommon/doclib.gifPK+Aڔqq8]!OEBPS/dcommon/oracle-logo.jpgPK+A!OEBPS/dcommon/contbig.gifPK+A!OEBPS/dcommon/darbbook.cssPK+AMά""!O!OEBPS/dcommon/O_signature_clr.JPGPK+APzz!OEBPS/dcommon/feedbck2.gifPK+A-!OEBPS/dcommon/feedback.gifPK+Aː5"OEBPS/dcommon/booklist.gifPK+AN61J"OEBPS/dcommon/cpyr.htmPK+A!:3."OEBPS/dcommon/masterix.gifPK+AeӺ1,?"OEBPS/dcommon/doccd.cssPK+A7	"OEBPS/dcommon/larrow.gifPK+A#"OEBPS/dcommon/indxicon.gifPK+AS'"G"OEBPS/dcommon/leftnav.gifPK+Ahu,"OEBPS/dcommon/uarrow.gifPK+Al-OJ!"OEBPS/dcommon/oracle.gifPK+A(e*"OEBPS/dcommon/index.gifPK+AGC		+"OEBPS/dcommon/bookbig.gifPK+AJV^5"OEBPS/dcommon/rarrow.gifPK+A枰pk7"OEBPS/dcommon/mix.gifPK+Ao"nR
M
:"OEBPS/dcommon/doccd_epub.jsPK+Av
I
4E"OEBPS/dcommon/toc.gifPK+A
r~$F"OEBPS/dcommon/topnav.gifPK+A1FAG"OEBPS/dcommon/prodicon.gifPK+A3(
#
yK"OEBPS/dcommon/bp_layout.cssPK+Ax[?:X"OEBPS/dcommon/bookicon.gifPK+Ap*c^q^"OEBPS/dcommon/conticon.gifPK+Aʍb"OEBPS/dcommon/blafdoc.cssPK+A+&y"OEBPS/dcommon/rightnav.gifPK+Aje88z"OEBPS/dcommon/oracle-small.JPGPK+Aއ{&!ϳ"OEBPS/dcommon/help.gifPK+Af6o
9"OEBPS/toc.htmPK+AcKEEU#OEBPS/best_capture.htmPK+A}u#OEBPS/ptrep_admin.htmPK+AG\\#OEBPS/cprop.htmPK+AhZA:#OEBPS/man_comp.htmPK+AN;x&OEBPS/best_gen.htmPK+AB\ڟ&OEBPS/config_add.htmPK"H(