1.

Introduction

A set of rough notes taken from Phil Trautmans Database knowledge-sharing session, DB Architecture and Environment.

2.

Agenda

3.

Background Information

You need to have a basic understanding of Oracle and the following concepts: 1. Tablespaces 2. Schema (collection of database objects ; owned by and has the same name as a single database user) 3. Database Server (consists of an Oracle Database and an Oracle Instance) 4. Difference between Oracle Database and Oracle Instances (multiple Oracle Instances, each accessing its own Schema in the database, can be started; combination of the background processes and memory buffers is called an Oracle instance see http://www.dbi-services.com/index.php/blog/entry/oracle-basics-1-oracle-database-vsoracle-instance for more information) 5. Redo logs (Every Oracle database has a set of two or more redo log files. The set of redo log files is collectively known as the redo log for the database. A redo log is made up of redo entries (also called redo records). The primary function of the redo log is to record all changes made to data.) 6. DB Link: http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm: The central concept in distributed database systems is a database link. A database link is a connection between two physical database servers that allows a client to access them as one logical database. A database link is a pointer that defines a one-way communication path from an Oracle Database server to another database server. The link pointer is actually defined as an entry in a data dictionary table. To access the link, you must be connected to the local database that contains the data dictionary entry. A database link connection is one-way in the sense that a client connected to local database A can use a link stored in database A to access information in remote database B, but users connected to database B cannot use the same link to access data in database A. If local users on database B want to access data on database A, then they must define a link that is stored in the data dictionary of database B.

4.
1. 2.

Information
http://hsdz0089.hydc.sbc.com/mswiki/Wiki.jsp?page=2012WorkflowKnowledgeSharing Phil recommends (see wiki) the oracle documentation (e.g. http://www.oracle.com/pls/db102/homepage)

5.
1. 2.

List of all our Database Instances

In 2010, they moved the database servers from the old environment to the AT&T-supported ITO environment. Phil keeps spreadsheets showing the Database Instances and which Host they are on. Heres an example showing 4 Database Instances on the same server (spreadsheet is on Wiki):

Issue Date: Effective Date:

Page 1 of 8

3. 4. 5. 6.

Most databases were upgraded (and patches applied) from 10.2.0.3 10.2.0.5 (last release of Oracle 10). Portal database is Oracle 11.2.0.2 The rsdev servers are not big not much memory,etc. used to mainly test new software Can reference by LDAP name or host name Staging databases are set up to be identical to production

5.1

Servers that Database Instances Are Installed On

In the same spreadsheet (wiki), a separate tab exists to show information (memory, CPUs) of the different servers. E.g.

6.

Database Instance Versions and Patch Level

Phils spreadsheet showing patches applied (on Wiki):

7.

Disaster Recovery

For Disaster Recovery, we use a product called Data Guard. It keeps production (located in Alpharetta) and Disaster Recovery (located in Kansas City) databases in sync; if production fails, theres a fail-over to DR databases. It usually takes about an hour for the fail over. Data Guard is running constantly to keep things in sync. Following shows production and DR databases from Phils spreadsheet (on Wiki):

Issue Date: Effective Date:

Page 2 of 8

Following is a slide (on Wiki) showing the failover mapping between production and DR recovery databases (IOL does not currently have a DR db):

8.

Golden Gate

Golden Gate is a real-time replication tool for replicating data from one database to another. Its a newer tool thats meant as a better replication mechanism than Oracles Materialized Views (its less overhead because it accesses the Redo logs more as opposed to the actual database tables which is what Materialized Views do).

Issue Date: Effective Date:

Page 3 of 8

9.

Materialized Views

1. http://docs.oracle.com/cd/B10501_01/server.920/a96567/repmview.htm : Oracle uses materialized views (also known as snapshots in prior releases) to replicate data to non-master sites in a replication environment and to cache expensive queries in a data warehouse environment. 2. In the following, we see Phils spreadsheet (on Wiki) showing the replication information associated with the replication provided by Materialized Views. MASTER is the source table and TARGET_TB is the database that this table data will be replicated to. FREQUENCY shows how often the data is replicated.

3.

Following shows that MS (workflow) database tables are replicated every 30 seconds.

4. Question: why do we replicate using Master Views from our database tables to the other databases as opposed to giving the target a view/link to our database so that they can access our data that way? Answer: reduce access to our databases 5. MV (Materialized View) logs are created (by reading the table thats being replicated) to keep track of changes to a table to make replication faster 6. Any changes made to database tables means that the Materialized View has to be rebuilt 7. Example of Database Configuration Report showing Materialized View logs:

Issue Date: Effective Date:

Page 4 of 8

10.

Discussion on DB Link, Data Guard, Materialized Views, and Golden Gate

1. Data Guard is independent of Materialized Views, Golden Gate, and DB Link. Data Guard is a tool that provides disaster recovery, including on-going replication of the data from the primary database to the DR database. This replication has nothing to do with the replication provided by Materialized Views and Golden Gate. 2. Materialized Views and Golden Gate are two tools for replicating data from one database to another . The replication is NOT the same intent as the replication for DR provided by Data Guard; its replication for various reasons backup, other users want the data located in their table for faster access, etc. Golden Gate and Materialized Views do the same thing; Golden Gate is newer and had less overhead because it primarily accesses the Redo tables (whereas Materialized Views primarily access the actual database tables). 3. DB Link is just a one-way access from one database to a remote one. While it has nothing to do with replication, its important to keep in mind that when one considers access to another databases data, we would consider options such as: a) use DB Link to access data; b) use Materialized Views or Golden Gate to replicate the data; c) Use a web service to have the other application provide the data from its database. 4. Reason we are still using Materialized Views vs Golden Gate: labor/time needed to switch over 5. Keep in mind the following:

Issue Date: Effective Date:

Page 5 of 8

6. Heres a picture from Phils slides (wiki) showing different replication using Materialized Views and Golden Gate:

7. From Phils spreadsheet for Materialized Views, we see in the comments that some tables are also replicated by Golden Gate (shouldnt be this is duplicate replication / duplicate overhead):

Issue Date: Effective Date:

Page 6 of 8

11.

Database Configuration Report

Issue Date: Effective Date:

Page 7 of 8

MSDBO is the schema for some of our user tables:

Table spaces for MS database:

Issue Date: Effective Date:

Page 8 of 8