| > 1. What kind of performance hit will we be taking from the
> reading/writing/locking of the relation RDB$CHANGES?
I'll leave the answer to this question to customers who actually have the
product in production and live with it everyday.
> 2. The RDB$CHANGES relation will get really big as we take one
> database offline to make changes. Typically we could be off
> line as long as a day or two. How fast/large does RDB$CHANGES
> relation grow and what do you see as the "critical time period"
> of being offline?
If you're replicating the entire database, it will grow at a rate approximately
equal to the rate of growth of the main data tables. I can't comment on what
the critical time period might be.
> 3. How long does the initial replication take to create the system
> system tables and record portions of the transfer definition?
> Is this the part it needs the exclusive lock for?
This is the part. I've added an option in version 7.0 (aka version 6.1,
which is being renumbered) to allow you to separate this part from the
data transfer part. It typically takes a few seconds to perhaps a minute
when there are lots of tables being named.
> 4. In the user document section 5.5.2, it talks about creating the
> system tables for non-RDB databases. Can we create the system
> tables ahead of time and decrease the amount of time that DD needs
> the exclusive lock for?
I don't the have the book in front of me. It must be talking about "system:
tables for the "target" database, not the "source" database. An exclusive
lock is not needed in that case.
> 5. If the data is already there and "up-to-date", and the system
> tables exists, can we bypass the initial replication and just start
> the update replications with an empty RDB$CHANGES table?
By "there" I presume you mean the target database. How will you get the data
there? Do you know about the additional DDAL$DBKEY columns in the target
tables and the database keys stored there?
> 6. How big is the transfer database?
It's a small database, on the order of 4000 blocks.
> 7. In the documentation section 5.2.1.1, it mentions that we may see
> a noticeable decrease in throughput. How noticeable is it?
Again, I don't have the manual handy, so I'm not sure in what context that
statement is being made.
> 8. Are statistics saved somewhere about the activity on the database,
> such as number of inserts per table? if so, where is it and in what
> format?
"the database" = which database? There's the source, the target and the
transfer database. What are you looking for? If you want to know after the
initial transfer has been executed how many rows have been inserted into each
target table, that information appears in the transfer log. On subsequent
transfers, the log shows the aggregate number of inserts, updates and deletes
for all tables, not for each individual table.
> 9. Can you reinitialize a transfer that will only affect the data and
> not recreate the database?
Yes, if you use the TO EXISTING FILENAME clause in the CREATE TRANSFER state-
ment.
> 10. Should we index RDB$CHANGES or not and why?
Indexing is a two-edged sword. It helps data retrieval and penalizes data
insertion. In this case, data retrieval is done by our copy process, not
by your applications. My guess is that few customers use indexing on the
RDB$CHANGES table because it slows down the production applications that
update the production data. Indexing was added as an option as a way for
some customers to improve transfer performance by reducing the amount of
time it takes a copy process to read the RDB$CHANGES table. This is most
noticeable when the table has a lot of empty space in it.
Although I've not had a chance to try it yet, I believe that Oracle Rdb 7.0
makes it easier for you to recover space in the RDB$CHANGES table thereby
improving performance.
> 11. Can you explain why the source tables cannot be changed after the
> initial replication?
It is because we've not implemented any logic to record changes in data
definitions for propagation to the target databases. We only record
changes to the data. It would be possible to relax this restriction in some
cases. For example, adding a column to a replicated table should be possible
to support. However, dropping a column or change the definition of a column
can make things quite complex to figure out how that affects the rows already
stored in the target tables. Anyway, given that we do not replciate table
definition changes, Rdb prevents you from making such changes so long as the
tables are marked for replication.
> 12. Can you shorten/lengthen a field in the target database and still
> do replication? What will happen?
I'm not sure what will happen during the transfer of changes. I've never
tried that. I do know that if the transfer has to be reinitialized, we'll
change the target table definition to match the source definition.
> 13. Can you change datatypes from integer to real (or similar changes)
> and still do replication? What will happen?
Same comment as above.
|