HP 3000 Manuals HP 3000 Manuals
Partitions Because you can use the ALLBASE/Replicate functionality in so many different ways, there is great flexibility for specifying which tables on the master DBEnvironment will be replicated and where they will be replicated. You can group the tables in the master DBEnvironment into subsets called partitions. Each table in the master DBEnvironment is associated with a specific partition that controls whether or not the table will be replicated, and to which slave DBEnvironment it will be replicated. A partition may contain one table, several tables, or every table in the DBEnvironment. Various configurations for partitioning a DBEnvironment are discussed later in this chapter. Each partition is a unit of replication. If a master partition is specified for replication when the slave application is started, all tables in that master partition will be replicated from the master to the slave. If a partition is not specified for replication when the slave application is started, tables associated with that partition will not be replicated. One or more master partitions can be replicated to a single slave. In this case, you can either use one application instance to replicate each partition, or you can use one application to replicate all partitions at once. One master partition may also be replicated to several different slaves. In this case, there must be one instance of the ALLBASE/Replicate application running on the master for each slave where partitions are being replicated. It is the responsibility of the slave to tell the master which master partitions the slave is to receive for replication. When the slave application is started, you are prompted to enter the ID number of each master partition to be replicated. Direct and Indirect Updates in Partition Design The table receives a direct update if it is updated through: * a user application. * the ISQL interface. * a third-party application. The table receives an indirect update if it is updated through: * the use of ALLBASE/Replicate. Tables used in the master role must receive only direct updates, not indirect updates, for ALLBASE/Replicate to function properly. Tables used in the slave role must receive only indirect updates, not direct updates. Any environment allowing a table to receive both direct and indirect updates can generate unpredictable results that can make it impossible for the master and slave DBEnvironments to become identical copies of each other. Therefore, partition design must insure that this constraint is not violated.
NOTE [REV BEG] Under carefully controlled circumstances, it is permissible to update the same table both directly and indirectly. However, do not update the same row both directly and indirectly. Any one row must be "owned" by one, and only one, master. Only the owning master is allowed to directly update the row. Consult with Hewlett-Packard before implementing a design that updates the same table both directly and indirectly.[REV END]
Partition Types Note: This manual frequently refers to various ALLBASE/SQL statements that support the operation of ALLBASE/Replicate. You may find it useful to make copies of the annotated syntax diagrams found later in this chapter in the section, "ALLBASE/SQL Statements that Support ALLBASE/Replicate," prior to reading this introductory material. ALLBASE/Replicate provides the following types of partitions: NONE partition, DEFAULT partition, user-defined partitions, and COMMENT partition. NONE Partition. If you have a subset of tables you do not want replicated, associate those tables with the NONE partition using the CREATE TABLE statement or the ALTER TABLE statement. Master tables are not replicated in the NONE partition when audit logging is enabled. To reenable replication for a table in the NONE partition, associate it with another partition that is currently being replicated by using the ALTER TABLE statement. Previous changes made to the data in the table while it was in the NONE partition will not be replicated when it is placed in a partition that is generating audit log records. If you want to replicate those changes, you must do a hard resynchronization that includes the newly added table in order to properly synchronize the master and slave partitions. The resynchronization must be from the master to the slave, and must include the table's partition. DEFAULT Partition. If you do not explicitly associate a table with a partition, using the CREATE TABLE statement or the ALTER TABLE statement, the table will automatically be associated with the DEFAULT partition. (You can also explicitly associate a table with the DEFAULT partition with these statements if you do not want to create user-defined partitions.) Audit log records will be generated for tables in the DEFAULT partition when audit logging is enabled. If you plan to enable audit logging, you must assign the DEFAULT partition a DefaultPartitionNumber when creating the DBEnvironment using the START DBE NEW statement. You can also specify or change a DefaultPartitionNumber after DBEnvironment creation using the START DBE NEWLOG statement. If you do not want tables associated with the default partition to be replicated, you can specify NONE instead of a DefaultPartitionNumber in the above START DBE statements. User-Defined Partitions. You may have several groups of tables in a master DBEnvironment, where some groups are replicated to a different slave DBEnvironment, and where some groups are not to be replicated at all. In this case, you may create several user-defined partitions in order to explicitly specify how each group of tables will be handled. Several examples of different partitioning configurations are discussed later in this chapter. User-defined partitions are created using the CREATE PARTITION statement. Tables are associated with them using the CREATE TABLE statement or the ALTER TABLE statement as stated above. User-defined partitions are removed using the DROP PARTITION statement. COMMENT Partition. To place user-generated comments in the audit log using the LOG COMMENT statement, you must activate the COMMENT partition. To do this you must specify a CommentPartitionNumber in the START DBE NEW or START DBE NEWLOG statements. You may also specify DEFAULT instead of a CommentPartitionNumber, in which case comments will be placed in the DEFAULT partition. To disable audit logging from the COMMENT partition, you can specify NONE instead of a CommentPartitionNumber in either of the START DBE statements. Audit Log Records. Changes to data in tables associated with user-defined partitions and the DEFAULT partition, and comments entered with the LOG COMMENT statement, generate special log records called audit log records. These are produced in addition to regular log records when ALLBASE/Replicate audit logging is enabled. Four Typical Partition Configurations There are four basic partition configurations common to ALLBASE/Replicate scenarios in general usage. From these basic configurations, you can design other variations and more complex configurations. Figure 2-1 , "ALLBASE/Replicate Partition Configuration Examples," diagrams the basic configurations and their characteristics. In the diagram, MADBEn is the master DBEnvironment, SLDBEn is the slave DBEnvironment, Pn is a partition, and Tn is a table. Details for each configuration are on subsequent pages.Figure 2-1. ALLBASE/Replicate Partition Configuration Examples Configuration 1 - Entire DBEnvironment to a Dedicated Slave. This configuration depicts replicating an entire master DBEnvironment to a dedicated slave DBEnvironment. * This could be a typical configuration when the slave is being used as a standby DBEnvironment for use if the master DBEnvironment fails. * The entire master DBEnvironment, MADBE1, is replicated to the slave, SLDBE1. The slave is replicating transactions from only one master. [REV BEG] * All tables to be replicated are in one user-defined partition. Only one master and one slave application are needed to carry out replication. * You could put all tables in the DEFAULT partition, instead of a user-defined partition, and replicate the DEFAULT partition.[REV END] * There are COMMENT, DEFAULT, and NONE partitions in every DBEnvironment, but they are shown only for MADBE1 to save space. Tables associated with the DEFAULT partition would be replicated to SLDBE1. Comments entered with the LOG COMMENT statement would be replicated through the COMMENT partition to the slave. For tables in either the DEFAULT or COMMENT partitions to be replicated, those partitions have to be specified, by partition number, when the slave resynchronization application is started. Configuration 2 - Subset of a DBEnvironment to a Dedicated Slave. This configuration depicts replicating a subset of a master DBEnvironment to a dedicated slave DBEnvironment. [REV BEG] * This could be a typical configuration when you replicate some data in the DBEnvironment that is critical, but you do not replicate other data. Such a case is when you are offloading a read-only application that only accesses some tables.[REV END] * A subset of the master DBEnvironment, MADBE2, is being replicated to the slave, SLDBE2. * All tables to be replicated are in one partition. Only one master and one slave application are needed to carry out replication. * Tables T3 and T4 could be in another partition P2 being replicated to a second slave, SLDBE2B (not shown here). In that case you would need a minimum of two master/slave application pairs. One application pair replicating tables in P1 to SLDBE2. The other application pair replicating tables in P2 to SLDBE2B. Configuration 3 - Multiple Master DBEnvironments to One Slave. This configuration depicts several master DBEnvironments (MADBE3A, MADBE3B, and MADBE3C) all being replicated to the same slave, SLDBE3. * This could be a typical configuration when several remote business locations each have information that the home office wants to be able to view as a collected whole. * A minimum of three master/slave application pairs are needed. One is needed to replicate partitions 1 and 2 from MADBE3A to the slave, another is needed for partitions 3 and 4 on MADBE3B, and the third is needed for partitions 5 and 6 on MADBE3C. A master/slave application pair could be assigned to replicate each individual partition, in which case six such pairs would be needed. * Tables T1 on MADBE3A, T2 on MADBE3B, and T3 on MADBE3C are each unique, and are being replicated to unique tables T1, T2, and T3 on the slave, SLDBE3. * Table T4 is identical on each master, and each master T4 is being replicated to one single T4 on the slave. T4 on each master might be an employees table showing only the employees at each branch location. A column in the table indicates the branch where the employees belong. T4 on the slave holds the total set of employee records for the entire enterprise. Therefore, the T4 at each branch is a horizontal partition of table T4 on the slave. Configuration 4 - Two-Way Replication. This configuration depicts two-way replication between two DBEnvironments where each has a partition that is a master replicating information to the other DBEnvironment and each has another partition that is a slave receiving records to be replicated from the other DBEnvironment. * This could be a typical configuration when each location has information to be shared with the other location. * A minimum of two master/slave application pairs is needed for replication. One pair replicates information from table T1 on MASLDBE4A to table T1 on MASLDBE4B. The other replicates information from table T2 on MASLDBE4B to table T2 on MASLDBE4A. * In MASLDBE4A, only table T1 may receive direct updates from user applications. Table T1 must not receive indirect updates from T1 on MASLDBE4B. Table T2 cannot have direct updates, and must only be indirectly updated by table T2 on MASLDBE4B. * In MASLDBE4B, only table T2 may receive direct updates from user applications. Table T2 must not receive indirect updates from table T2 on MASLDBE4A. Table T1 cannot have direct updates and must only be indirectly updated by table T1 on MASLDBE4A. Configuration Design Issues. From these basic configurations, you can build much more complex configurations to meet your needs. Every complex configuration can be broken down into simpler parts, each of which represents one set of master partitions being replicated to one set of slave partitions.
NOTE Never configure ALLBASE/Replicate such that a loop is developed between a table in one DBEnvironment and its counterpart in another DBEnvironment.
For example, partition P1 on MASLDBE4A sends replicated transactions to table T1 on MASLDBE4B. Do not at the same time, place table T1 on MASLDBE4B in a partition (e.g. partition P1) and then send replicated transactions back to table T1 on MASLDBE4A. If you replicate P1 both ways, this creates an infinite loop that soon fills both tables with large amounts of duplicate data. You are allowed to place table T1 on MASLDBE4B in a partition, for example partition 3, and replicate that table to a third DBEnvironment, MASLDBE4C (not shown here). Specific issues related to setting up ALLBASE/Replicate in each of these four basic configurations are discussed in later chapters.
![[]](../../pic3k/M013580/FFN43c50.gif)