Sample Work for Information Engineering - Technical Report Editing. Business and technical editing, writing, Web content development, and Web site maintenance in Boulder/Longmont, Colorado. High-quality, freelance editorial services tailored to your budget and schedule. Find out why you should hire a professional technical editor.

IEC Editing Sample:
Technical Report

The "before" version of this technical report (first portion only shown below) contained valuable information, but it was difficult for the reader to quickly understand the purpose of the paper and its scope. Also, it lacked two critical sections: an overview and a conclusion (technical staff often forget to include these sections). Major edits done by IEC included giving the paper a clear title, adding a table of contents (after chunking the information into sections with headings), adding a troubleshooting section, and providing both an introductory overview and a conclusions section. Even if there aren't dramatic conclusions to report, it's important to have a bottom-line section readers can easily reference.

Before

After

Symmetric Replication Paper

Configuring Oracle Symmetric Replication is challenging because we are dealing with a complex technology and a diverse audience. This paper will attempt to provide an outline and a "how to" approach to Symmetric Replication as apposed to a document stating the virtues of Symmetric Replication and features of a particular release of Oracle. This paper will attempt to explain in sufficient detail the following:

- Replication across multiple master sites: This entails updating, inserting and deleting data on one site, and showing how the changes get propagated to the other replicated site.

- Application availability: Here we want to show that if network failure occurs between the two replicated sites, that work can continue, and that users are not effected by the network failure. We would like to show that when the network is broken, transactions get logged in a queue, and upon the return of the network, the transactions get propagated to the other replicated sites.

- The ability to resolve conflicts: Here we will show that if simultaneous updates are made to the same record in the different replicated sites, the Symmetric Replication functionality allows for specific ways of resolving the conflict. For our purposes, we will use Latest Timestamp conflict resolution. That means that any time a conflict is detected the transaction with the latest timestamp is kept, and the others are discarded.

The setup phase is as follows:

We begin with some basic parameter file entries recommended for our discussion. The 'compatible' parameter is set to 7.1.0 but could be set to a higher release depending on your environment. The important fact is that 'global_names' be set to true.

Databases' Initialization Parameters:

COMPATIBLE = 7.1.0
JOB_QUEUE_PROCESSES = 1
JOB_QUEUE_INTERVAL = 1
SHARED_POOL_SIZE = 10000000
GLOBAL_NAMES = TRUE

Next are some database assumption:

Create two instances of Oracle7 v7.1.6(or higher). Make sure that the user tablespace is named 'USERS', and the temporary tablespace is named 'TEMP'.

Next consider the following SQL*NET parameters:

Configure SQL*NET v2.1 on the server and client. Make sure that the names for the two instances in the tnsnames.ora are set to 'v716' and 'v716_2' for example.

.... [rest of body of paper]

Here are the replication SQL scripts that we used:

.... [appendixes for paper]

Symmetric Replication Implementation Guidelines

by Ron Jones
March 1997

Introduction
  - What is Symmetric Replication
  - Document Purpose
Usage Guidelines
  - Basic Database Setup
  - Replication Administration Setup
  - Date Replication and Manipulation
Troubleshooting
Conclusions
Appendix A: Replication SQL Scripts

Introduction

What is Symmetric Replication

The Symmetric Replication facility in Oracle version 7.3 supports the replication of tables, views, indexes, synonyms, triggers, and packages at master sites. All master sites participating in a replicated environments must have the same replicated objects. If you want to replicate only a subset of the objects to a given site, you should consider making that site a snapshot site.

The Symmetric Replication facility supports both DML and DDL changes to replicated tables. Changes to any table in a replicated environment are reflected at the other sites in the replicated environment. Procedures provided in the package DBMS_REPCAT are used to make changes to non-table objects. These procedures are described in detail in Chapter 12 of Oracle7 Server Distributed Systems, Volume II: Replicated Data, Release 7.3, February 1996, Oracle Corporation, Part No. A32545-2.

Document Purpose

This document describes the guidelines for using the Oracle7 Symmetric Replication feature that were developed by the XXX group as a result of its testing in this area.

Configuring Oracle Symmetric Replication is challenging, not only because the technology behind it is complex, but also because users have diverse needs that necessitate configurations that are tailored to their specific needs.

This paper will show, by way of a detailed example, how several key aspects of Symmetric Replication operate. If you work through the steps outlined in the example, you should gain an understanding of:

Replication across multiple master sites. The example updates, inserts, and deletes data on one site, and then shows how the changes get propagated to the other replicated site.
Application availability. The example shows that if a network failure occurs between the two replicated sites, users can continue working unaffected. When the network is broken, transactions get logged in a queue; when the network operations resume, the transactions get propagated to the other replicated sites.
The ability to resolve conflicts. The example shows that if simultaneous updates are made to the same record in different replicated sites, the Symmetric Replication functionality allows for different ways of resolving the conflict. For our example, we used the latest Timestamp conflict resolution method. This means that any time a conflict is detected, the transaction with the latest timestamp is kept, while others are discarded.

Usage Guidelines

Basic Database Setup

Our example begins with making certain recommended parameter file entries. The most important is that GLOBAL_NAMES be set to TRUE. The COMPATIBLE parameter is set to 7.1.0 in our example, but could be set to a higher release, depending on your environment. The initialization parameters for both the master and master definition sites are as follows:

COMPATIBLE = 7.1.0
JOB_QUEUE_PROCESSES = 1
JOB_QUEUE_INTERVAL = 1
SHARED_POOL_SIZE = 10000000
GLOBAL_NAMES = TRUE

Our example assumes that:

there are two instances of Oracle7 v7.1.6 (or higher)
the user tablespace is named USERS
the temporary tablespace is named TEMP
SQL*NET version 2.1 is configured on the server and client
the names for the two instances in the tnsnames.ora are set to v716 and v716_2 (v716 is the Master Definition site and v716_2 is the Master site)

.... [rest of body of paper]

Conclusions

Testing by the XXX group showed that Oracle's Symmetric Replication feature worked as documented. However, you must be very careful when building the environment to ensure that correct database links from client to server and from server to client are set up properly at each step along the way. Note that any mistake in formulating the statements here can result in unsuccessful replication. This setup process can be a source of error and frustration.

Before implementing advanced replication, be sure you thoroughly read and understand the DBMS_* procedures described in the manual Oracle7 Server Distributed Systems, Volume II: Replicated Data, Release 7.3. These procedures allow creation of, deletion of, and inquiry into all aspects of the replicated environment. Understanding these procedures is essential to creating a replicated environment.

Appendix A: Replication SQL Scripts

The replication SQL scripts that were used are listed below.