- Performing updates in a replicated environment:
=================================================

Based on prior tests from Ellen and after some more thinking,
I don't believe that there is a way to update a replicated table
without losing transactions; there will always be a small time
window where that table is not available.

In a CISN-type installation where we can assume that we have
two real-time databases replicating to one or more data center
databases, there is a possibility to update a replicated
table without losing any "authoritative" transactions.
However this scenario requires a master/slave switch.

The following steps outline the proposed method:

0.- We assume that the real time databases RT1 & RT2 replicate
    to the data center DC via snapshot replication. We also
    assume that RT1 is the current master system and RT2 the
    slave one.

1.- We stop the oracle listener on RT2 so that no more transactions
    are being executed on this database.

2.- We suspend the propagation from RT2 to DC.

3.- We update the table (snapshot) on RT2.

4.- We restart the oracle listener on RT2. New transactions coming in
    are now using the new version of the table.

5.- We perform a master/slave switch. RT2 is now master.

6.- We stop the oracle listener on RT1 so that no more transactions
    are being executed on this database.

7.- We suspend the propagation from RT1 to DC.

8.- We suspend replication on DC.

9.- We update the table on DC.

10.- We resume replication on DC.

11.- We resume the propagation from RT2 to DC.

12.- We update the table (snapshot) on RT1.

13.- We resume the propagation from RT1 to DC.

14.- We restart the oracle listener on RT1. New transactions coming in
     are now using the new version of the table.

15.- All the databases are now using the new version of the table and at
     no point in time were any transactions lost on a master system.


- Proposed COSMOS tables:
=========================

1.- After comparing the COSMOS documentation with Allan's proposed tables,
    I found only two attributes that are missing from the proposed schema:

- R43 (COSMOS Real Header 43): Full scale output of sensor (volts).
- R44 (COSMOS Real Header 44): Full scale sensing capability of sensor (in g).

Those two attributes are currently stored as a comment in the sensor description
and instead of R43, we are currently storing the sensor v/g value. We then
derive R43 by multiplying this value by R44.

I propose that we add those two attributes to the C_SensorData table.

2.- Allan's schema adequately maps all of the tables defined in the
    COSMOS documentation:

DB Table <----> COSMOS Table
----------------------------
C_PhysType      Table 1
C_Units         Table 2
C_RecTyp        Table 3
C_Net           Table 4
C_Datum         Table 5
C_Site          Table 6
C_Auth          Table 7
C_TimeClk       Table 8
C_LgrTyp        Table 9
C_SnsTyp        Table 10
C_Ornt          Table 11
C_OrntAbbrv     Table 11
C_FltrTyp       Table 12
 
However I don't see any difference between the C_Ornt & C_OrntAbbrv tables.
One of those might be redundant.

3.- There seems to be some normalization issues with the following sets of tables:
    - C_ChannelData, C_LoggerData & C_LgrTyp.
    - C_ChannelData, C_SensorData & C_SnsTyp.

Also, should the attributes lgrName & snsName in the C_ChannelData table
be replaced by lgrId & snsId? Ellen & I probably need to ponder
some more about this.