Data Replication with SQL Remote
PART 3. SQL Remote Administration
CHAPTER 11. Administering SQL Remote for Adaptive Server Anywhere
The publisher of the consolidated database can directly intervene at remote sites using a passthrough mode, which enables standard SQL statements to be passed through to a remote site. By default, passthrough mode statements are executed at the local (consolidated) database as well, but an optional keyword prevents the statements from being executed locally.
Caution
Always test your passthrough operations on a test database with a remote database subscribed. Never run untested passthrough scripts against a production database.
Passthrough mode is started and stopped using the PASSTHROUGH statement. Any statement entered between the starting PASSTHROUGH statement and the PASSTHROUGH STOP statement which terminates passthrough mode is checked for syntax errors, executed at the current database, and also passed to the identified subscriber and executed at the subscriber database. We can call the statements between a starting and stopping passthrough statement a passthrough session.
The following statement starts a passthrough session which passes the statements to a list of two named subscribers, without being executed at the local database:
PASSTHROUGH ONLY FOR userid_1, userid_2;
The following statement starts a passthrough session which passes the statements to all subscribers to the specified publication:
PASSTHROUGH ONLY FOR SUBSCRIPTION TO [owner].pubname [ ( string ) ] ;
Passthrough mode is additive. In the following example, statement_1 is sent to user_1, and statement_2 is sent to both user_1 and user_2.
PASSTHROUGH ONLY FOR user_1 ; statement_1 ; PASSTHROUGH ONLY FOR user_2 ; statement_2 ;
The following statement terminates a passthrough session:
PASSTHROUGH STOP ;
PASSTHROUGH STOP terminates passthrough mode for all remote users.
Passthrough statements are replicated in sequence with normal replication messages, in the order in which the statements are recorded in the log.
Passthrough is commonly used to send data definition language statements. In this case, replicated DML statements use the before schema before the passthrough and the after schema following the passthrough.
You should always test your passthrough operations on a test database with a remote database subscribed. You should never run untested passthrough scripts against a production database.
You should always qualify object names with the owner name. PASSTHROUGH statements are not executed at remote databases from the same user ID. Consequently, object names without the owner name qualifier may not be resolved correctly.
Passthrough mode is a powerful tool, and should be used with care. Some statements, especially data definition statements, could cause a running SQL Remote setup to come tumbling down. SQL Remote relies on each database in a setup having the same objects: if a table is altered at some sites but not at others, attempts to replicate data changes will fail.
Also, it is important to remember that in the default setting passthrough mode also executes statements at the local database. To send statements to a remote database without executing them locally you must supply the ONLY keyword. The following set of statements drops a table not only at a remote database, but also at the consolidated database.
-- Drop a table at the remote database -- and at the local database PASSTHROUGH TO Joe_Remote ; DROP TABLE CrucialData ; PASSTHROUGH STOP ;
The syntax to drop a table at the remote database only is as follows:
-- Drop a table at the remote database only PASSTHROUGH ONLY TO Joe_Remote ; DROP TABLE CrucialData ; PASSTHROUGH STOP ;
The following are tasks that can be carried out on a running SQL Remote setup:
Add new users.
Resynchronize users.
Drop users from the setup.
Change the address, message type, or frequency for a remote user.
Add a column to a table.
Many other schema changes are likely to cause serious problems if executed on a running SQL Remote setup.
In a multi-tier SQL Remote installation, it becomes important that passthrough statements work on the level of databases immediately beneath the current level. In a multi-tier installation, passthrough statements must be entered at each consolidated database, for the level beneath it.
There are special considerations for some statements in passthrough mode.
When a stored procedure is called in passthrough mode using a CALL or EXEC statement, the CALL statement itself is replicated and none of the statements inside the procedure are replicated. It is assumed that the procedure on the replicate side has the correct effect.
Control-flow statements such as IF and LOOP, as well as any cursor operations, are not replicated in passthrough mode. Any statements within the loop or control structure are replicated.
Operations on cursors are not replicated. Inserting rows through a cursor, updating rows in a cursor, or deleting rows through a cursor are not replicated in passthrough mode.
Static embedded SQL SET OPTION statements are not replicated. The following statement is not replicated in passthrough mode:
EXEC SQL SET OPTION . . .
However, the following dynamic SQL statement is replicated:
EXEC SQL EXECUTE IMMEDIATE "SET OPTION . . . "
Batch statements ( a group of statements surrounded with a BEGIN and END) are not replicated in passthrough mode. You receive an error message if you try to use batch statements in passthrough mode.