Today's lesson completes the three-day section on maximizing uptime and securing your data. On Day 16, "Understanding Effective Backup Techniques," you learned how to back up your database; on Day 17, "Recovering the Database," you learned how to restore that data in the event of a system failure. Today you will learn how to use other techniques to maximize uptime and minimize recovery time.
Not all replication is used for maximizing uptime. It is convenient, however, to include all the benefits and uses of replication in this lesson. Replication can be used for many different purposes, such as read-only copies in satellite locations and multiple access points.
Today you will learn about replication and other methods for reducing downtime, such as the backup database and Oracle failover.
New Term: Replication is the facility that allows you to copy database data to multiple local and remote systems. This data can be accessed and modified in certain instances. In many cases, systems are designed so that the remote data is read-only and updates are processed on the master system. There are various options available.
A replicated database might consist of the entire database or of certain tables or tablespaces. This is completely up to you. With Oracle replication, you can configure a number of options to provide whatever features you want.
Oracle provides several replication options; the most basic of these is the read-only table snapshot. This basic method of replication allows you to copy a table to a remote site as a read-only table. Any updates to the table must be made on the master database. This method is described as a "snapshot" because it is a picture of the database at a certain point in time. Unlike other replication options, the read-only table snapshot refreshes the remote copy only on a periodic basis, which you control.
Another option for replication is Oracle advanced replication. With advanced replication it is possible for all replicated objects to be updated. Advanced replication is much more complex than the read-only table snapshot because conflict resolution must be programmed. The advanced replication option can be quite powerful, but it is more difficult to maintain.
Read-only table snapshots are used when a read-only copy is all that is needed. You might think this method is quite limiting, but in reality it is very useful. Indeed, there are quite a few applications where the read-only table snapshot is sufficient, and even desirable:
Telemarketing--A list of clients should be maintained at a central location and downloaded periodically to each sales office. It is desirable for all offices to have the same client list.
These are just a few examples of places where a read-only replicated table is quite sufficient for the satellite location. With this type of replication, the data on the local or master database is periodically updated to the replicated sites, as shown in Figure 18.1.
This snapshot can be an entire table or a selected view of that table. In this manner you can keep information in the master table that is not propagated to the replicated sites, such as item costs or sales figures. With replication you have many options for what data you want to replicate and when you want to replicate it.
In some cases you must update the data on each replicated site. This is where the advanced replication option is necessary.
New Term: The Oracle advanced replication option, sometimes known as symmetric replication or updateable snapshots, allows each of the replicated databases to be updated. The updates are typically batched and periodically sent to the other replicated objects. You can, however, configure Oracle to propagate updates immediately. This is known as synchronous data propagation or realtime data replication.
The updateable snapshot method is usually sufficient, but with certain applications it is necessary to use realtime data replication.
With the advanced replication option, the system is sometimes described as having multiple masters. These masters can each have read-only table snapshots if desired. An advanced replication system is shown in Figure 18.2.
An advanced replication system.
With the advanced replication option, you can have multiple sites throughout the country, and each can be used as an independent database. Each of these databases can be updated independently and on a regular basis--and can even be deferred to off hours.
Replication is quite straightforward. The data to be replicated is defined by a defining query, which determines the data that is to be replicated. After the query is defined, the data is selected from the master and copied to the replicated site.
The defining query is set up so that each row in the replicated table corresponds to one row or part of one row in the master table. The defining query cannot contain an aggregate function or GROUP BY clause.
New Term: After the defining query is set up, it will be executed on a regular basis and its result will be propagated to the replicate systems. This propagation of fresh replicated data is called the snapshot refresh. The snapshot refresh can operate in a couple different modes:
New Term: If multiple tables are involved in the snapshot, you can use a snapshot group. When you define a snapshot group, several different tables can be linked together so that there is transaction consistency within the snapshot (that is, the tables are in sync).
The snapshot refresh can occur manually or automatically, depending on how you configure the master and the replicated site. With an automatic refresh, no operator intervention is required. The snapshots are automatically refreshed on a regular time interval. With manual refresh, the operator determines when the refresh should occur and manually initiates the refresh. If changes to the tables are rare, manual refresh might work for you.
Replication can be configured through Replication Manager or manually via SQL commands. What method you use is up to you.
To configure replication using Replication Manager, you should first make sure the database was created with the advanced replication option. This option is available through the Oracle Database Assistant installation process.
NOTE: If your database was not built with the advanced replication option, you must run the administrative SQL script \orant\rdbms80\admin\ catrep.sql to install the replication packages.
Replication Manager can be invoked from the Enterprise Manager toolbar or from the Oracle Replication Manager program group. After you invoke Replication Manager, you will see the main screen (shown in Figure 18.3).
Oracle Replication Manager.
If you have never run Replication Manager, you might find yourself in the Setup wizard. From here you can create the master and snapshot sites. If you click the Cancel button, you will see that no database connections are set up, so no information can be displayed.
If you had specified advanced replication when you were building the database from the Database Assistant, this would already be set up for you. To invoke the Setup wizard, click Create (see Figure 18.4).
Create the database connection.
After you click Create, the Create DB Connection dialog (shown in Figure 18.5) prompts you to supply information to connect to a database.
The Create DB Connection dialog.
You will also be prompted to set up a propagator. To do so, highlight the database connection from the Replication Manager main screen (system@dogs in this case) and pull down the Edit menu to select properties. To select a propagator, click the Propagator tab (see Figure 18.6). You can choose any of the users you have defined; DBSNMP is a good choice.
The Edit DB Connection dialog.
The next step is to invoke the Setup wizard. Do so by selecting File | Setup Wizard. From here you will be led through a series of screens that will help you configure a replicated system. The first is the Master or Snapshot Site Setup screen, shown in Figure 18.7.
The Master or Snapshot Site Setup screen of the Setup wizard.
Here you can specify whether you are setting up a database as a master site or as a snapshot site. Both require initial setup.
Configuring the Master Site
Configuring the master site involves setting up a replication account and privileges as well as setting up scheduling for the snapshots. To do so, perform these steps:
The Select Master Sites screen of the Setup wizard.
The New Master Site screen of the Setup wizard.
The Default Admin/Propagator/Receiver screen of the Setup wizard.
The Existing Propagator's Password screen of the Setup wizard.
6. The next screen schedules the time for replication and a replication interval. You can leave the default to replicate once per day or change it, as shown in Figure 18.13.
NOTE: The values entered here represent the username and password of the account that does the replication. This account will be created by the Setup wizard.
The Defaults for Scheduled Links screen of the Setup wizard.
8. The Master Site Customizations screen, shown in Figure 18.14, allows you to customize the master site as desired. Select a site and click the Customize button to modify users, the using clause, and so on.
The Master Site Customizations screen of the Setup wizard.
The Finish screen of the Setup wizard.
The Setup Wizard Finish screen of the Setup wizard.
Configuring the Snapshot Site
Configuring the snapshot site is similar to configuring the master site. The Setup wizard leads you through a series of screens to help you set up the snapshot site correctly:
2. After you have selected the master site, the Setup wizard connects to
it to obtain information it needs for the configuration and to validate the connection.
3. Select the snapshot site via the Select Snapshot Sites screen, which
resembles the Select Master Sites screen shown in Figure 18.8. From here you select
one or more snapshot sites.
4. Clicking the New button invokes the New Snapshot Site screen, where you enter the site name and the SYSTEM password (see Figure 18.17).
The New Snapshot Site screen of the Setup wizard.
The Snapshot Site Defaults screen of the Setup wizard.
7. As with the master setup, you must also set the default purge schedule.
This is done in the Default Purge Scheduling screen, which enables you to select
an interval expression and rollback segment.
8. As with the master setup, you are given the opportunity to customize
the snapshot site with the Snapshot Site Customizations screen, shown in Figure 18.19.
Select a snapshot site and click the Customize button to modify users, the using
clause, link scheduling, and the schema.
9. In the Finish screen, you have the option of running the setup or writing
the steps to a script. If you write them to a script, you can get an idea of what
steps are performed and you have a record of the operation.
10. After you finish the Setup wizard, you are presented with the Setup Wizard Finish screen (see Figure 18.20), which summarizes all the actions to be taken. When you are satisfied with the steps, click OK and the setup will begin.
The Snapshot Site Customizations screen of the Setup wizard.
The Setup Wizard Finish screen of the Setup wizard.
Both the master and snapshot setups offer a variety of different options. If you don't know which options to use, click the Help button for an explanation of the option. The online help is fairly complete and can be quite useful.
Creating the Snapshots Using Replication Manager
Now that you have set up the replication master (replicated from) and replication slave (replicated to), the final step is to set up the replication objects. To do so, follow these steps:
The Basic Type screen of the Snapshot wizard.
NOTE: Before you can create the snapshot, you must create a database link from the menu where you chose the Create Snapshot option. This link is scheduled between the master and the slave. It is also necessary to create a snapshot log on the database object on the master if you intend to do fast updates. This can be done through Replication Manager.
The Master Link screen of the Snapshot wizard.
The Master Table screen of the Snapshot wizard.
The Where Clause screen of the Snapshot wizard.
The Refresh Group screen of the Snapshot wizard.
The Create Refresh Group screen of the Snapshot wizard.
The Tablespace and Extent Characteristics screen of the Snapshot wizard.
9. The Finish Snapshot Wizard screen (see Figure 18.28) summarizes all the operations to be performed. At this point you should review the snapshot-creation operation to determine whether all the options have been set up correctly. If you are satisfied, click OK.
The Finish Snapshot Wizard screen of the Snapshot wizard.
After the snapshot is configured, the database link refreshes the snapshot on a regular basis. You can set many small details and options; I have not gone into all of them here. Consult the Oracle documentation or the online help to better use all the options.
Configuring Using the CREATE SNAPSHOT Command
You can define a snapshot via the CREATE SNAPSHOT SQL statement, which is sometimes more useful if the query is complex. Use the CREATE SNAPSHOT command in conjunction with a query to create the snapshot-defining query. An example of a defining query is shown in Listing 18.1.
CREATE SNAPSHOT etw.dogs AS SELECT name, owner_name FROM dogs, dog_owners WHERE dogs.owner_id = dog_owner.id;
This creates a snapshot using a join between the dogs table and the dog_owners table. This snapshot can then be used to set up replicated sites.
Advanced replication can be used for a variety of different uses: for remote disconnected sites (portable computers), for distributing application loads, and to create failover sites in the event of system failure. Oracle's advanced replication option does not work in quite the same way as the snapshot-replication method. Because multiple sites might be modifying data, it would not work to simply copy the database on a regular basis. Instead, changes are saved and queued to be run on other replication sites.
New Term: Oracle replicates changes on a row basis; this is known as row-level replication. These row changes are saved and queued to run at a later time on the replicated systems. I suggest that you read the Oracle documentation if you want a detailed description of the steps taken to perform advanced replication.
Advanced replication can be used in a disconnected environment where some of the replicated systems are periodically disconnected and reconnected. For example, these systems can be used with portable computers where they are used on the road (disconnected) and reconnected to the network nightly via modem.
In this manner, the snapshot can be refreshed each night, causing the database to be resynced with other masters. The portable data and the data on the home system can be synced every night, providing the traveling user with regular updated access to corporate data.
When your database's workload is spread across different areas of the country, it might be beneficial to use advanced replication to allow local access to your corporate data. If the replicated databases are local, access times will be reduced and the data will be available regardless of the state of the wide area network.
If you use advanced replication, each site can perform its own updates and the changes can be propagated nightly to the other systems. There are a few problems, however, if the same records are updated at multiple sites. You must address this when you configure the conflict-resolution setup for advanced replication.
If your database handles a large number of updates that typically involve the same records, replication might not be suitable for your configuration. But if you have only a few updates, and if they do not typically involve the same data, replication might be suitable.
Advanced replication can serve a variety of different purposes, one of which is quick recovery in the event of a catastrophic system failure. If you use the advanced replication option, an entire database can be replicated. Not only can the database be used during normal operations, but if one of the systems should happen to fail, the users can use one of the available replicated sites.
New Term: Another method sometimes used for quick recovery is the Oracle standby database. A standby database is a complete copy of your primary database, but it is constantly in recovery mode. Each time a log switch occurs on your primary database, the archived log file is applied to the standby database, bringing it up to date.
In the event of a catastrophic system failure, the standby database can be used as the primary database. In the event of a failure on the primary system, you can archive the current log files using the ALTER SYSTEM ARCHIVE LOG CURRENT command. This creates an archive log file of the current redo log file. In this manner, the standby database can be made current with the primary database.
The standby database is designed to be used only as a recovery mechanism. After the standby database has been activated, it becomes the primary database. The original database can later be re-created as the standby database, but you cannot switch back to the original. More details on the standby database can be found in Oracle8 Server Backup and Recovery Guide.
By using read-only tablespaces in areas where updates are not necessary, you can reduce downtime spent in recovery. Because the RDBMS knows that a tablespace marked as read-only cannot be updated, the normal recovery process will be skipped. In the event of media failure on the volume containing the read-only tablespace, you must restore the damaged datafiles, but no instance recovery is necessary.
All tablespaces are created read-write and must be populated with data to be considered useful. After the data and indexes have been created to your specifications, the tablespace can be made read-only. This can happen in several ways. For example, Enterprise Manager or Storage Manager can be used to modify a tablespace to be read-only, as described in the previous section. Simply go to the Tablespace Modification screen, shown in Figure 18.29, and click the Read Only box. Invoke this screen by selecting the desired tablespace from the Storage Manager.
Making a tablespace read-only.
The tablespace can also be made read-only via the ALTER TABLESPACE command. The syntax will look something like this:
ALTER TABLESPACE DOGS READONLY;
There are several uses for the read-only tablespace, but they are fairly specific. Whether you can take advantage of it depends on your applications. If you have a large amount of static data that can be put on slower media, the read-only tablespace might be advantageous. Also, if you want to guarantee that archival data is not modified, a read-only tablespace might work.
Today you learned how Oracle replication works and how to configure it via Replication Manager. You also learned a few ways to reduce downtime by using replication and by using the standby database feature. You learned how using read-only tablespaces can reduce the amount of time it takes to recover a tablespace, because Oracle knows that no changes have been made to it.
Replication is a very specific option and is useful only in very specific cases. If you can take advantage of replication with your system, you will see very good results.
In tomorrow's lesson, "Advanced Oracle Options," you will learn about some of the advanced options available to Oracle, including the Oracle Parallel Server (OPS) and Oracle Parallel Query options.
The Oracle Parallel Server option, an add-on feature, allows more than one instance of Oracle to share the same database. This allows two or more systems to simultaneously access the same data, providing a performance boost and failover capabilities. This linking of systems to form one larger system has traditionally been called a cluster.
The Parallel Query option can provide a good-to-outstanding performance improvement over traditional query operations by splitting some operations into multiple processes or threads. Tomorrow you will learn how the Parallel Query option works and how to use it.
A Replication is a feature that allows a database or schema object(s) to be copied to another system.
Q What types of replication does Oracle offer?
A Oracle offers several types of replication: read-only table snapshots, updateable snapshots, and realtime data replication.
Q What is a standby database?
A The standby database is a database that is constantly in recovery mode, recovering archived log files from the primary database. In the event of a failure, the standby database can immediately substitute for the primary database.
Q How does a read-only tablespace help speed up recovery?
A Because a tablespace is marked read-only, Oracle knows that no instance recovery is necessary. That tablespace can then be skipped.
The workshop provides quiz questions to help you solidify your understanding of the material covered and exercises to provide you with experience in using what you've learned. Find answers to the quiz questions in Appendix A, "Answers."
2. What is an updateable snapshot?
3. What is realtime data replication?
4. What is a master site?
5. What is a snapshot site?
6. What are some uses of read-only table snapshots?
7. What are some uses of advanced replication?
8. What is the difference between a complete refresh and a fast refresh?
9. What is a standby database used for?
10. Why would you use a read-only tablespace?
2. Use Replication Manager to set up a snapshot site.
3. Use Storage Manager to make a tablespace read-only.
4. Set that tablespace back to read-write.
© Copyright, Macmillan Computer Publishing. All rights reserved.