All Packages Class Hierarchy This Package Previous Next Index
java.lang.Object | +----interbase.interclient.Server
InterClient Extension
for future release
This class is used for administrating an InterBase server.
In addition to the InterBase service which operates on InterBase databases, a guardian process known as the InterBase administration service exists for administrating the server as a whole.
The InterBase administration service can be used for starting and stopping the InterBase service, or for operating on database files directly.
Only sysdba can obtain a Server object, thereby administering an InterBase server; other users access database information thru a Connection or DatabaseMetaData and are not allowed Server access.
activateIndices(String, boolean)
InterClient Extension.
addUser(String, String)
InterClient Extension.
backup(boolean, boolean, boolean, boolean, boolean, String, String)
InterClient Extension.
backup(boolean, String, String)
InterClient Extension.
changePassword(String, String)
InterClient Extension.
commitLimboTransaction(String, int)
InterClient Extension.
createDatabase(String)
InterClient Extension.
createDatabase(String, int, int, String[], int[])
InterClient Extension.
createShadow(String, String)
InterClient Extension.
createShadow(String, String, int)
InterClient Extension.
createShadow(String, String, int, String[], int[])
InterClient Extension.
deregister(String)
InterClient Extension.
dropDatabase(String)
InterClient Extension.
dropShadow(String)
InterClient Extension.
dropUser(String)
InterClient Extension.
enableAutomaticSweeping(String, boolean)
InterClient Extension.
getCacheBuffers(String)
InterClient Extension.
getDefaultCacheBuffers()
InterClient Extension.
getDefaultPageSize(int)
InterClient Extension.
getLengths(String)
InterClient Extension.
getLimboTransactionIds(String)
InterClient Extension.
getLockActivity(String)
InterClient Extension.
getRegisteredDatabases()
InterClient Extension.
getSecondaryFiles(String)
InterClient Extension.
getStatistics()
InterClient Extension.
getUsers()
InterClient Extension.
getUsersConnected()
InterClient Extension.
getUsersConnected(String)
InterClient Extension.
limitNumberOfConnections(String, int)
InterClient Extension.
markAsDamaged(String)
InterClient Extension.
move(String, String)
InterClient Extension.
register(String)
InterClient Extension.
repair(String)
InterClient Extension.
restore(String, String)
InterClient Extension.
restore(String, String, int, String[], int[])
InterClient Extension.
restore(String, String, int, String[], int[], boolean, boolean, boolean, boolean, String[])
InterClient Extension.
rollbackLimboTransaction(String, int)
InterClient Extension.
setCacheBuffers(String, int)
InterClient Extension.
setSweepInterval(String, int)
InterClient Extension.
shutdown()
InterClient Extension.
shutdown(String, boolean, boolean, boolean, int)
InterClient Extension.
startup(ServerProperties)
InterClient Extension.
sweep(String)
InterClient Extension.
twoPhaseCommitLimboTransactions(String)
InterClient Extension.
verify(String)
InterClient Extension.
startup
public synchronized void startup(ServerProperties properties) throws SQLException
InterClient Extension
for future release
shutdown
public synchronized void shutdown() throws SQLException
InterClient Extension
for future release
shutdown
public synchronized void shutdown(String database,
boolean force,
boolean blockNewConnections,
boolean blockNewTransactions,
int timeout) throws SQLException
InterClient Extension
for future release
Periodically you will want to shut down a database for backups and restores. Backup saves only the current committed version of each record while also putting all the data for each relation on contiguous pages in the database. Restore will rebuild all the indices and reset the statistics for each. This usually will increase performance significantly.
createDatabase
public synchronized void createDatabase(String database) throws SQLException
InterClient Extension
for future release
Registers the database automatically.
createDatabase
public synchronized void createDatabase(String database,
int pageSize,
int cacheBuffers,
String secondaryFiles[],
int lengths[]) throws SQLException
InterClient Extension
for future release
dropDatabase
public synchronized void dropDatabase(String database) throws SQLException
InterClient Extension
for future release
getRegisteredDatabases
public synchronized String[] getRegisteredDatabases() throws SQLException
InterClient Extension
for future release
register
public synchronized void register(String database) throws SQLException
InterClient Extension
for future release
deregister
public synchronized void deregister(String database) throws SQLException
InterClient Extension
for future release
addUser
public synchronized void addUser(String user,
String password) throws SQLException
InterClient Extension
for future release
dropUser
public synchronized void dropUser(String user) throws SQLException
InterClient Extension
for future release
changePassword
public synchronized void changePassword(String user,
String newPassword) throws SQLException
InterClient Extension
for future release
getUsers
public synchronized String[] getUsers() throws SQLException
InterClient Extension
for future release
getUsersConnected
public synchronized String[] getUsersConnected() throws SQLException
InterClient Extension
for future release
getUsersConnected
public synchronized String[] getUsersConnected(String database) throws SQLException
InterClient Extension
for future release
backup
public synchronized void backup(boolean transportable,
String database,
String backupFile) throws SQLException
InterClient Extension
for future release
Backup always stores the database backup to a single gbak file. Garbage collection of old record versions is performed by default.
backup
public synchronized void backup(boolean transportable,
boolean ignoreLimboTransactions,
boolean ignoreChecksums,
boolean metaDataOnly,
boolean inhibitGarbageCollection,
String database,
String backupFile) throws SQLException
InterClient Extension
for future release
Issues a SQLWarning for checksum errors and limbo transactions
restore
public synchronized void restore(String backupFile,
String database) throws SQLException
InterClient Extension
for future release
restore
public synchronized void restore(String backupFile,
String database,
int pageSize,
String secondaryFiles[],
int lengths[]) throws SQLException
InterClient Extension
for future release
secondaryFiles argument may be null if you're only changing pageSize.
restore
public synchronized void restore(String backupFile,
String database,
int pageSize,
String secondaryFiles[],
int lengths[],
boolean inactivateIndices,
boolean dropValidityConstraints,
boolean dropShadow,
boolean incremental,
String tables[]) throws SQLException
InterClient Extension
for future release
If the tables argument is non-null then restore only those tables.
The database page size decides how much data will be retrieved with one logical access from the database. The default is 1K (1024 bytes) with 2K, 4K, and 8K the other allowed values. A single logical access from the database may involve multiple physical accesses. For example, on most UNIX systems, the default number of bytes retrieved in a single physical access is 512. For a 1K page size, two physical accesses occur for every logical access. There is a tradeoff then between reading/writing the most data versus physical I/O. The proper page size will be determined by your database requirements, i.e., is the database mostly for reading, update intensive, or a combination? Is accessing BLOBS or ARRAYS a priority? What is the record size of your main table, the table that will be accessed most often?
Database page size will also influence the tuning of indices. The section on performance monitoring will review the tool called gstat that can analyze the layout of an index. If there are too many levels in the index then increasing the page size will flatten the index structures and usually improve performance. Another rule of thumb is to try to keep the indices on the main table to three or fewer levels.
The only way to change the database's page size after creation is to backup and then restore the database with a different page size. Page 110 in the Windows Client User's Guide details how to do this. Note that databases on Windows 3.1 and Windows NT can only have a page size of 1024.
The database can also be made up of many different files. This allows you to effectively use the available disk space on multiple volumes. The user always refers to the first file, the database name, and never has to know about the secondary files. This also allows a database to be larger than the operating system limit for a single file. This does not allow the DBA to specify in which file individual objects in the database may be placed. In other words, you cannot assign Relation A to the first file, Relation B to the second file and the indices for both to the third file. The files are used and filled in sequential order and can contain data from any table or index in the database.
The only way to change the number of database files after creation is to backup and then restore the database specifying the secondary files and the attributes. Page 109 in the Windows Client User's Guide details how to do this.
activateIndices
public synchronized void activateIndices(String database,
boolean activate) throws SQLException
InterClient Extension
for future release
move
public synchronized void move(String database,
String newDatabase) throws SQLException
InterClient Extension
for future release
Note: Move cannot be used to split a database or change its page size; Backup and restore must be used to split a database into multiple files or change its page size.
enableAutomaticSweeping
public synchronized void enableAutomaticSweeping(String database,
boolean on) throws SQLException
InterClient Extension
for future release
Sweeping can be performed manually or automatically. By default, when the OIT is 20,001 transactions less then the Next Transaction number, which is also kept on the database header page, the process that tried to start the transaction will sweep the entire database and remove as many BDRs as possible. While this is happening, other users can continue to use the database.
If you are going to start the sweep manually then it is advised that you first make sure there is no one connected to the database. This will not only clean out the BDRs and clean out the erased records, but also update the OIT number on the header page to be one less than the Next Transaction number. It can do this because there are no other active transactions that might need to see any of the BDRs.
sweep
public synchronized void sweep(String database) throws SQLException
InterClient Extension
for future release
Even with our efficiencies in keeping the BDRs small, the database can still accumulate a great deal of unnecessary generations, i.e. garbage. There are two ways to clean out all the garbage from the database. The first is called Cooperative Garbage Collection. It happens automatically every time a record is touched, on a select, update, or delete operation. When the record is touched, the InterBase kernel follows the pointers to each BDR and compares it's transaction number with what's called the Oldest Interesting Transaction (OIT). This number is kept in the header page for the database. If the BDR's transaction number is less than the OIT, then the BDR can be purged from the database and the space reclaimed for new data. This will not clean up deleted records and their BDRs.
setSweepInterval
public synchronized void setSweepInterval(String database,
int num) throws SQLException
InterClient Extension
for future release
createShadow
public synchronized void createShadow(String database,
String shadowURL) throws SQLException
InterClient Extension
for future release
Another physical property is the ability to create shadows of the database. Shadows are carbon copies of the database, an exact duplicate. The main reason for shadows is to protect yourself from hardware failure. First you have to set up one or more shadows on other disk partitions or better still, other machines. The if your primary disk or server fails the users can reconnect to the shadow after the DBA has enabled it. This is much quicker than restoring from a backup.
Shadows can also be composed of multiple files just like normal databases.
The major drawback to shadows is that they increase the number of writes the database server does. If you have only one shadow then every write is duplicated. Two shadows and every write is tripled. This can cause performance problems.
createShadow
public synchronized void createShadow(String database,
String shadowURL,
int pageSize) throws SQLException
InterClient Extension
for future release
createShadow
public synchronized void createShadow(String database,
String shadowURL,
int pageSize,
String secondaryFiles[],
int lengths[]) throws SQLException
InterClient Extension
for future release
dropShadow
public synchronized void dropShadow(String shadowURL) throws SQLException
InterClient Extension
for future release
verify
public synchronized void verify(String database) throws SQLException
InterClient Extension
for future release
markAsDamaged
public void markAsDamaged(String database) throws SQLException
InterClient Extension
for future release
Connection requests should throw a SQLException for damaged databases.
limitNumberOfConnections
public synchronized void limitNumberOfConnections(String database,
int maxUsers) throws SQLException
InterClient Extension
for future release
repair
public synchronized void repair(String database) throws SQLException
InterClient Extension
for future release
Note: Clearly this cannot repair corrupt databases in general.
getLimboTransactionIds
public synchronized int[] getLimboTransactionIds(String database) throws SQLException
InterClient Extension
for future release
rollbackLimboTransaction
public synchronized void rollbackLimboTransaction(String database,
int transactionId) throws SQLException
InterClient Extension
for future release
commitLimboTransaction
public synchronized void commitLimboTransaction(String database,
int transactionId) throws SQLException
InterClient Extension
for future release
twoPhaseCommitLimboTransactions
public synchronized void twoPhaseCommitLimboTransactions(String database) throws SQLException
InterClient Extension
for future release
getSecondaryFiles
public synchronized String[] getSecondaryFiles(String database) throws SQLException
InterClient Extension
for future release
getLengths
public synchronized int[] getLengths(String database) throws SQLException
InterClient Extension
for future release
setCacheBuffers
public synchronized void setCacheBuffers(String database,
int buffers) throws SQLException
InterClient Extension
for future release
By default, Server.createDatabase() stamps a zero onto the database header page. If this value is non-zero, it takes precedence over both the server-wide and connection-wide settings (ServerProperties.setDefaultCacheBuffers(), and ConnectionProperties.setCacheBuffers()).
Superserver allocates a separate page buffer cache per database.
getCacheBuffers
public synchronized int getCacheBuffers(String database) throws SQLException
InterClient Extension
for future release
getDefaultPageSize
public int getDefaultPageSize(int pageSize) throws SQLException
InterClient Extension
for future release
getDefaultCacheBuffers
public int getDefaultCacheBuffers() throws SQLException
InterClient Extension
for future release
getStatistics
public synchronized ServerStatistics getStatistics() throws SQLException
InterClient Extension
for future release
getLockActivity
public synchronized InputStream getLockActivity(String database) throws SQLException
InterClient Extension
for future release
All Packages Class Hierarchy This Package Previous Next Index