CODESET values for import and export procedures
Derby Server and Administration Guide
78
The import procedures work the same way; an empty field is imported as a NULL value.
CODESET values for import and export procedures
Import and export procedures accept arguments to specify codeset values. You can
specify the codeset (character encoding) for import and export procedures to override the
system default.
For a table that shows a sample of the character encodings supported by the Java
Development Kit, see "derby.ui.codeset property" in the Derby Tools and Utilities Guide.
To review the complete list of character encodings, refer to your Java documentation.
Examples: Specifying the codeset in import and export procedures
The following example shows how to specify UTF-8 encoding to export to the
staff.dat
table:
CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE(
NULL,'STAFF','staff.dat',NULL,NULL,'UTF-8')
The following example shows how to specify UTF-8 encoding to import from the
staff.dat
table:
CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE(
NULL,'STAFF','staff.dat',NULL,NULL,'UTF-8',0)
Replicating databases
Replication is an important feature of a robust database management system. In Derby,
you start database replication by using connection URL attributes.
The replication capability of Derby has the following features:
· One master, one slave: A replicated database resides in two locations and is
managed by two different Derby instances. One of these Derby instances has the
master role for this database, and the other has the slave role. Typically, the master
and slave run on different nodes, but this is not a requirement. Together, the master
and its associated slave represent a replication pair.
· Roll-forward shipped log: Replication is based on shipping the Derby transaction
log from the master to the slave, and then rolling forward the operations described
in the log to the slave database.
· Asymmetry: Only the master processes transactions. The slave processes no
transactions, not even read operations.
· Asynchronicity: Transactions are committed on the master without waiting for the
slave. The shipping of the transaction log to the slave is performed regularly, and is
completely decoupled from the transaction execution at the master. This may lead
to a few lost transactions if the master crashes.
· Shared nothing: Apart from the network line, no hardware is assumed to be
shared.
· Replication granularity: The granularity for replication is exactly one database.
However, one Derby instance may have different roles for different databases. For
example, one Derby instance may have the following roles, all at the same time:
· The master role for one database D1 replicated to one node
· The slave role for a database D2 replicated from another node
· The normal, non-replicated, role for a database D3
Replication builds on Derby's ability to recover from a crash by starting with a backup and
rolling forward Derby's transaction log files. The master sends log records to the slave
