 |
| 7 Database administration with cgadm |
|---|
| Back to TOC |
While the client program cgclt is be used to perform any database oriented queries, the admin program cgadm is more useful for any database administration tasks. Either retrieving information status but also performing standard admin tasks like managing tablesets or threads, the admin program cgadm is used for this admin tasks. cgadm is a command based utility which supports GNU readline library editing and history features.
Please note: For fully distributed tableset environments as provided with version Cego 2.0 and higher, it is highly recommended to use the cgadm admin program to manage tableset, since the program synchronizes the corresponding tableset information for all affected nodes ( mediator, primary and secondary ).
All supported features of cgadm are explained in the following section.
7.1 Connecting to the database
To invoke cgadm, a running cego database daemon is required. See section Daemon mode how to start up the cego database daemon.After the cego daemon has been started successful, the cgadm can be invoked to connect to it. For example, this may be
$ cgadm --server=localhost --port=2000 --user=cgadm/cgadm CGADM > |
This connects the admin program the the database host localhost to port 2000 with the admin user cgadm.
7.2 Retrieving database informtion
After establishing a connection to the cego database server, several commands are available to get information about the corresponding database system or about managed tablesets.
7.2.1 Database parameter information
Information about the configured database parameters can be retrieved with the following command.
CGADM > show parameter; +---------------------+---------------------+ | PARAMETERINFO | PARAMETERINFO | | PARAMETER | VALUE | +---------------------+---------------------+ | DBNAME | cgdb | | PAGESIZE | 16384 | | NUMRECSEMA | 1021 | | NUMRBRECSEMA | 1021 | | NUMSYSRECSEMA | 1021 | | NUMSYSPAGESEMA | 1021 | | NUMDATAPAGESEMA | 1021 | | NUMIDXPAGESEMA | 1021 | | NUMRBPAGESEMA | 1021 | | NUMDATAFILESEMA | 1021 | | NUMBUFFERPOOLSEMA | 1021 | | MAXFIXTRIES | 30 | | PAGELOCKTIMEOUT | 10000 | | RECLOCKTIMEOUT | 10000 | | POOLLOCKTIMEOUT | 60000 | | FILELOCKTIMEOUT | 10000 | | NUMLOCKTRIES | 3 | | MAXSENDLEN | 8192 | | DATETIMEFORMAT | %d.%m.%Y %H:%M:%S | | LOGMNGPROG |/usr/local/cgdb/c... | | LOGMNGTIMEOUT | 10 | | BACKUPMNGPROG | null | | CSMODE | ON | | QESCMODE | ON | | DUPLICATENULL | ON | | CURRENCYSYMBOL | null | | DECIMALPOINT | . | +---------------------+---------------------+ ParameterInfo ok ( 0.004 s ) |
7.2.2 Pool information
Information about the current buffer pool state can be retrieved using the show pool command
CGADM > show pool; +---------------------+----------------+ | POOLINFO | POOLINFO | | PARAMETER | VALUE | +---------------------+----------------+ | Page Size | 16384 | | Total Pages | 3000 | | Used Pages | 61 | | Free Pages | 2939 | | Dirty Pages | 102 | | Fixed Pages | 0 | | Persistent Pages | 30 | | No Sync Pages | 0 | |-------------------- |--------------- | | Stat Start | 18:21:40 | | Cur Fix Count | 67057 | | Max Fix Count | 100000 | | Disk Reads | 27 | | Disk Writes | 0 | | Read Delay | 0.026 msec | | Write Delay | 0.000 msec | +---------------------+----------------+ PoolInfo ok ( 0.002 s ) |
The database page size, indicated in the first row, is defined at database creation time and cannot be changed. The total number of pages gives information about the size of the bufferpool. The bufferpool size can be specified with an option for the daemon start command. Used an free pages indicate how much the bufferpool is in use. Pages which have been modified but have still not be written back to disk are shown as dirty pages. Fixed pages are actually in use by any database thread. Normally this number should be zero and only get a higher value for a short period. For performance reasons, a number of persistent pages are hold in the bufferpool, which are never released. No sync pages are index pages, for which it is allowed to be released asynchronously to disk.
Below the page information, some statistical information is mentioned. From the beginning of the current statistics period, the number of page fixes is indicated, the number of disk reads and write in addition with the corresponding read and write delay.
All these information may help the administrator to check the health state of the database system and if required measures to improve can be carried out.
In rare cases, it can be useful to get a more detailed view about the bufferpool. Information about each page in the bufferpool can be listed uding the list pool command
CGADM > list pool; +-----------+----------------+----------------+----------------+----------------+----------------+----------------+----------------+ | PEL | PEL | PEL | PEL | PEL | PEL | PEL | PEL | | POS | OCCSTATE | ISDIRTY | NUMFIXES | TABSETID | FILEID | PAGEID | FIXSTAT | +-----------+----------------+----------------+----------------+----------------+----------------+----------------+----------------+ | 0 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 1 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 2 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 3 | PERSISTENT | n | 0 | 2 | 2 | 0 | 25 | | 4 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 5 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 6 | PERSISTENT | n | 0 | 2 | 2 | 1 | 25 | | 7 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 8 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 9 | PERSISTENT | n | 0 | 2 | 2 | 2 | 25 | | 10 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 11 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 12 | PERSISTENT | n | 0 | 2 | 2 | 3 | 25 | | 13 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 14 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 15 | PERSISTENT | n | 0 | 2 | 2 | 4 | 25 | | 16 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 17 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 18 | PERSISTENT | n | 0 | 2 | 2 | 5 | 25 | | 19 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 20 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 21 | PERSISTENT | n | 0 | 2 | 2 | 6 | 25 | | 22 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 23 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 24 | PERSISTENT | n | 0 | 2 | 2 | 7 | 25 | | 25 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 26 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 27 | PERSISTENT | n | 0 | 2 | 2 | 8 | 25 | | 28 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 29 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | | 30 | PERSISTENT | n | 0 | 2 | 2 | 9 | 25 | | 31 | NOTOCCUPIED | n | 0 | 0 | 0 | 0 | 0 | ... |
7.2.3 Lock information
There are several types of locks, which can be monitored.
- Record locks ( rec )
- Order Record locks ( orec )
- RB Record locks ( rbrec )
- System Record locks ( sysrec )
- Bufferpool locks ( bp )
- Datapage locks ( dp )
- Index page locks ( ix )
- System page locks ( sp )
- RB page locks ( rb )
- Datafile locks ( df )
- Threadpool locks ( tp )
- Logmanager locks ( lm )
As a sample, we list the current state of the threadpool and bufferpool locks.
CGADM > list tp lock; +---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+ | LOCKINFO | LOCKINFO | LOCKINFO | LOCKINFO | LOCKINFO | LOCKINFO | | LOCKID | LOCKCOUNT | RD HITS | RD DELAY | WR HITS | WR DELAY | +---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+ | ADMQUEUE | 4 | 0 | 0 | 40512 | 0 | | DBQUEUE | 10 | 0 | 0 | 90703 | 0 | | LOGQUEUE | 3 | 0 | 0 | 1420 | 0 | | DBM | 0 | 7 | 0 | 80393 | 0 | | XML | 0 | 1900 | 0 | 1641 | 0 | +---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+ LockInfo ok ( 0.003 s ) CGADM > list bp lock; +---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+ | LOCKINFO | LOCKINFO | LOCKINFO | LOCKINFO | LOCKINFO | LOCKINFO | | LOCKID | LOCKCOUNT | RD HITS | RD DELAY | WR HITS | WR DELAY | +---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+ | POOLLOCK-0 | 0 | 0 | 0 | 132 | 46 | | POOLLOCK-1 | 0 | 0 | 0 | 179 | 62 | | POOLLOCK-2 | 0 | 0 | 0 | 130 | 45 | | POOLLOCK-3 | 0 | 0 | 0 | 177 | 62 | | POOLLOCK-4 | 0 | 0 | 0 | 137 | 47 | | POOLLOCK-5 | 0 | 0 | 0 | 144 | 49 | | POOLLOCK-6 | 0 | 0 | 0 | 193 | 66 | | POOLLOCK-7 | 0 | 0 | 0 | 137 | 47 | | POOLLOCK-8 | 0 | 0 | 0 | 137 | 47 | | POOLLOCK-9 | 0 | 0 | 0 | 185 | 63 | | POOLLOCK-10 | 0 | 0 | 0 | 137 | 47 | +---------------------+---------------------+---------------------+---------------------+---------------------+---------------------+ LockInfo ok ( 0.004 s ) |
An aggregated view for the described lock groups can be retrieved using the lockstat command
CGADM > lockstat; +---------------------+-----------+---------------------+---------------------+---------------------+---------------------+---------------------+ | LOCKSTAT | LOCKSTAT | LOCKSTAT | LOCKSTAT | LOCKSTAT | LOCKSTAT | LOCKSTAT | | LOCKID | NUMLOCK | LOCKCOUNT | RD HITS | RD DELAY | WR HITS | WR DELAY | +---------------------+-----------+---------------------+---------------------+---------------------+---------------------+---------------------+ | ADMQUEUE | 1 | 4 | 0 | 0 | 29526 | 1079842958 | | DBQUEUE | 1 | 10 | 0 | 0 | 86099 | 2602100737 | | LOGQUEUE | 1 | 3 | 0 | 0 | 466 | 809861541 | | DBM | 1 | 0 | 1 | 0 | 73649 | 9019546 | | XML | 1 | 0 | 0 | 0 | 30641 | 21600 | | RECLOCK | 1000 | 0 | 7400 | 1834 | 0 | 0 | | ORDERRECLOCK | 31 | 0 | 1 | 0 | 0 | 0 | | RBRECLOCK | 31 | 0 | 0 | 0 | 0 | 0 | | SYSRECLOCK | 31 | 0 | 0 | 0 | 14800 | 3800 | | SYSPAGELOCK | 41 | 0 | 126188 | 32082 | 41 | 19 | | DATAPAGELOCK | 41 | 0 | 30 | 0 | 14678 | 3670 | | IDXPAGELOCKGROUP | 41 | 0 | 0 | 0 | 0 | 0 | | RBPAGELOCK | 41 | 0 | 5 | 2 | 0 | 0 | | DATAFILELOCK | 11 | 0 | 6 | 9 | 454 | 127 | | POOLLOCK | 11 | 0 | 0 | 0 | 538258 | 131530 | +---------------------+-----------+---------------------+---------------------+---------------------+---------------------+---------------------+ LockStat ok ( 0.025 s ) |
7.2.4 Thread administration
The cego daemon manages three thread pools for database, administration and log requests. The size of each thread pool can be configured at daemon startup.
An overall overwiew about the pools can be retrieved with
CGADM > threadinfo; +---------------------+------------+------------+ | THREADINFO | THREADINFO | THREADINFO | | TYPE | TOTAL | ACTIVE | +---------------------+------------+------------+ | DB Thread | 10 | 0 | | Admin Thread | 5 | 1 | | Log Thread | 3 | 0 | +---------------------+------------+------------+ ThreadInfo |
For each of the three thread pools ( db, adm and log ), the current state of the pool can be retrieved.
To list the database pool, type the following command
CGADM > threadinfo db; +------------+---------------------+---------------------+---------------------+------------+ | THREADINFO | THREADINFO | THREADINFO | THREADINFO | THREADINFO | | THREADID | NUMREQUEST | NUMQUERYREQ | THREADLOAD | STATUS | +------------+---------------------+---------------------+---------------------+------------+ | 0 | 2 | 142 | 1 | READY | | 1 | 2 | 6 | 1 | READY | | 2 | 3 | 6 | 0 | READY | | 3 | 1 | 66 | 21 | CONNECTED | | 4 | 1 | 224 | 21 | CONNECTED | | 5 | 4 | 32 | 0 | READY | | 6 | 2 | 155 | 21 | CONNECTED | | 7 | 1 | 219 | 0 | CONNECTED | | 8 | 3 | 16 | 0 | READY | | 9 | 2 | 47 | 21 | CONNECTED | | 10 | 2 | 4 | 0 | READY | | 11 | 1 | 245 | 0 | CONNECTED | | 12 | 2 | 4 | 0 | READY | | 13 | 1 | 261 | 21 | CONNECTED | | 14 | 2 | 163 | 0 | READY | | 15 | 3 | 104 | 1 | READY | | 16 | 1 | 2 | 0 | READY | | 17 | 1 | 184 | 0 | READY | | 18 | 2 | 171 | 21 | CONNECTED | | 19 | 4 | 8 | 1 | READY | | 20 | 2 | 149 | 21 | CONNECTED | | 21 | 6 | 12 | 0 | READY | | 22 | 3 | 32 | 1 | READY | | 23 | 1 | 38 | 1 | READY | | 24 | 5 | 10 | 1 | READY | | 25 | 0 | 0 | 0 | READY | | 26 | 1 | 2 | 0 | READY | | 27 | 3 | 6 | 0 | READY | | 28 | 3 | 29 | 21 | CONNECTED | | 29 | 2 | 7 | 1 | READY | +------------+---------------------+---------------------+---------------------+------------+ DBThreadinfo ok ( 0.112 s ) |
The number of connection requests and query requests is listed, but also information about load and status of the thread.
A high thread load is indicated by a higher load value ( up to 100 ). Since each thread has an amount of internal management tasks, a thread load between 0 and 20 is normal. The thread status indicates, if the thread actually is idle ( READY ), if a client is connected to ( CONNECTED ) or if any query is currently processes ( BUSY ).
To get information about the last action of a database thread, add the corresponding task id to the threadinfo command
CGADM > threadinfo db 1; +----------------------+ | THREADINFO | | LASTACTION | +----------------------+ | select * from mytab; | +----------------------+ DBThreadinfo ok ( 0.002 s ) |
The view for the admin thread pool looks pretty similar.
CGADM > threadinfo adm; +---------------------+---------------------+---------------------+------------+---------------------------------------------------+ | THREADINFO | THREADINFO | THREADINFO | THREADINFO | THREADINFO | | THREADID | NUMREQUEST | THREADLOAD | STATUS | LASTACTION | +---------------------+---------------------+---------------------+------------+---------------------------------------------------+ | 0 | 8 | 21 | BUSY | AdminThreadInfo | | 1 | 0 | 0 | READY | null | | 2 | 5 | 20 | READY | showUser | | 3 | 4 | 0 | READY | null | | 4 | 9 | 0 | READY | PoolInfo | +---------------------+---------------------+---------------------+------------+---------------------------------------------------+ AdminThreadinfo ok ( 0.037 s ) |
Since the admin commands are not as long as database queries, they are added to the threadlist directly.
Active long-running database queries can be aborted using the abort command
CGADM > abort db thread 1; Thread aborted ok ( 0.002 s ) |
7.3 User administration
For any database or adminstration task, a user has to log on to the database using an account with appropriate permissions. To enable the user to work with the database, a specific role has to assigned to the user. Before this, appropriate user roles have to be created and managed. The administration of roles and users is described in the following.
7.3.1 Role management
Roles are created using the create role statement. Any identifier can be used for the role name. There are reserverd two dedicated names for special purposes.
- admin
- jdbc
If role admin is assigned to a user, the user can connect as administrator to the database ( via cgadm ) to perform any kind of administration requests. To retrieve database information requested by several JDBC drivers, the jdbc role should be assigned to the user.
For all other purposes, special roles should be created, configured and assigned to the user as described in the following.
CGADM > list role; +----------------+ | ROLELIST | | ROLE | +----------------+ | thisrole | | thatrole | +----------------+ Role List ok ( 0.001 s ) |
CGADM > create role myrole; Role myrole created ok ( 0.001 s ) |
Now a permission entry can be set to the new created role.
CGADM > set permission myperm with tableset=TS1, filter='ALL', right=READ for myrole; Permission myperm set ok ( 0.002 s ) |
This entry adds read permission for all objects located in tableset TS1.
Please note :If a permission with the corresponding id already exists, it is overwritten.
CGADM > show role myrole; +----------------+----------------+----------------+----------------+ | ROLEINFO | ROLEINFO | ROLEINFO | ROLEINFO | | PERMID | TABLESET | FILTER | PERM | +----------------+----------------+----------------+----------------+ | myperm | TS1 | ALL | READ | +----------------+----------------+----------------+----------------+ ok ( 0.001 s ) |
CGADM > remove permission myperm from myrole; Permission myperm removed ok ( 0.001 s ) |
If a role is no more used, it can be dropped.
CGADM > drop role myrole; Role myrole dropped |
7.3.2 User management
Users are created using the add user statement.
CGADM > add user erwin identified by 'erwin'; User erwin added ok ( 0.042 s ) |
If the user has been created, an appropriate role can be assigned.
CGADM > assign role myrole to erwin; Role set for user erwin ok ( 0.036 s ) |
An overview of all users can be listed using the list user command
CGADM > list user; +-----------+-----------+-----------+-----------+-----------+ | USERINFO | USERINFO | USERINFO | USERINFO | USERINFO | | NAME | ROLE | TRACE | NUMREQ | NUMQUERY | +-----------+-----------+-----------+-----------+-----------+ | cgadm | admin | | | | | lemke | ALL | | | | | erwin | myrole | | | | +-----------+-----------+-----------+-----------+-----------+ User Info ok ( 0.001 s ) |
To change the users password, the passwd command is used.
CGADM > passwd user erwin identified by 'hubert'; +-----------+---------------------+---------------------------------------------------+ | ADM | ADM | ADM | | ROLE | HOSTNAME | MSG | +-----------+---------------------+---------------------------------------------------+ | mediator | dude.local | Passwd changed | +-----------+---------------------+---------------------------------------------------+ Admin action finished ok ( 0.001 s ) |
7.4 Retrieving tableset informtion
An overview of all known tablesets can be retrieved using the list tableset command.
CGADM > list tableset; +-----------+----------+-------------+-------------+-----------+-----------+ | TSL | TSL | TSL | TSL | TSL | TSL | | NAME | RUNSTATE | SYNCSTATE | MEDIATOR | PRIMARY | SECONDARY | +-----------+----------+-------------+-------------+-----------+-----------+ | TS1 | ONLINE | SYNCHED | dude.local |dude.local |dude.local | +-----------+----------+-------------+-------------+-----------+-----------+ Tableset list ok ( 0.001 s ) |
In the sample above, one tableset is registered for the corresponding node and it is currently in offline status. A more detailed view for a specific tableset can be retrieved, by using the info tableset command.
CGADM > show tableset TS1; +---------------------+---------------------+ | TABLESETINFO | TABLESETINFO | | PARAMETER | VALUE | +---------------------+---------------------+ | Tableset | TS1 | | RunState | ONLINE | | SyncState | SYNCHED | | Primary | dude.local | | Secondary | dude.local | | Mediator | dude.local | | RootPath | ./db | | Ticket | ./db/TS1ticket.xml | | InitFile | null | | Checkpoint | 0 | | SystemPageTotal | 100 | | SystemPageUsed | 15 | | TempPageTotal | 300 | | TempPageUsed | 15 | | AppPageTotal | 1000 | | AppPageUsed | 0 | | SortAreaSize | 10000000 | | Tid | 0 | | CLSN | 2 | | NLSN | 3 | | ArchMode | OFF | | AutoCorrect | OFF | | TableCache | OFF | | TC MaxEntryNum | 0 | | TC MaxEntrySize | 0 | | TC UsedSize | 0 | | QueryCache | ON | | QC MaxEntryNum | 500 | | QC MaxEntrySize | 30000000 | | QC UsedSize | 1194769 | | LogSize | 1000000 | | LogFile | ./db/TS1redo0.log | | LogFile | ./db/TS1redo1.log | | LogFile | ./db/TS1redo2.log | +---------------------+---------------------+ Admin action finished ok ( 0.001 s ) |
The contained objects of a tableset can be listed with the list object command
CGADM > list object for TS1; +-----------+---------------------+ | OBJINFO | OBJINFO | | Type | Name | +-----------+---------------------+ | TABOBJ | t1 | | TABOBJ | t2 | +-----------+---------------------+ Admin action finished ok ( 0.001 s ) |
7.4.1 Datafile information
Information about registered datafiles can be retrieved using the list datafile command.
CGADM > list datafile for TS1; +---------------------+--------------+--------------+--------------+ | DATAFILEINFO | DATAFILEINFO | DATAFILEINFO | DATAFILEINFO | | FILENAME | FILETYPE | SIZE | USED | +---------------------+--------------+--------------+--------------+ | ./db/chkdb_TS1.sys | SYSFILE | 100 | 15 | | ./db/chkdb_TS1.temp | TEMPFILE | 3000 | 17 | | ./db/data01.dbf | APP | 1000 | 29 | | ./db/data02.dbf | APP | 500 | 0 | | ./db/sys02.dbf | SYS | 500 | 0 | | ./db/temp02.dbf | TEMP | 500 | 0 | +---------------------+--------------+--------------+--------------+ Admin action finished ok ( 0.003 s ) |
Please note : The size information for any data-, system- or tempfile is available, just if the tableset has been started up.
7.4.2 Redo Log information
Redo log information can be retrieved with the following command
CGADM > list logfile for TS1; +-------------------+-----------+---------------------+---------------------+---------------------+ | LOGFILE | LOGFILE | LOGFILE | LOGFILE | LOGFILE | | NAME | STATUS | SIZE | OFFSET | USAGE | +-------------------+-----------+---------------------+---------------------+---------------------+ | ./db/TS1redo0.log | ACTIVE | 1000000 | 4 | 0% | | ./db/TS1redo1.log | FREE | 1000000 | 0 | 0% | | ./db/TS1redo2.log | FREE | 1000000 | 0 | 0% | +-------------------+-----------+---------------------+---------------------+---------------------+ Admin action finished ok ( 0.004 s ) |
7.4.3 Archive Log information
Archive log information can be retrieved with the following command
CGADM > list archlog for TS1; +-------------+-------------+ | ARCHLOGINFO | ARCHLOGINFO | | ARCHID | ARCHPATH | +-------------+-------------+ | AL1 | ./arch | +-------------+-------------+ Admin action finished ok ( 0.004 s ) |
7.4.4 Transaction information
If there are any open user transaction in a tableset, the corresponding transaction objects can be retrieved with cgadm For each transaction a dedicated rollback table is created called rbcatlog<tid>. The transaction file stores the modified tuple information to perform either a commit or rollback for the transaction. To view the open transaction for a tableset, the list transaction command is used
CGADM > list transaction for TS1; +----------------+-----------+ | TAINFO | TAINFO | | RBO | NUMOP | +----------------+-----------+ | rbcatlog4711 | 28332 | +----------------+-----------+ Admin action finished |
The NUMOP attributes indicates the number of operations, which have been performed for the transaction. Please note: Since an update operation is reduced to a delete and an insert operation, there are two operations for each tuple in the rollback table.
If during an update operation an appropriate index is used, the index is updated at the end of the update operations. During the update, another object occurs for the transaction.
As an example, we take a look at the folling update operation.
A table exists with an index on attribute a and the following update operation is performed
CGCLT > update t1 set b = 'hugo' where a = 4000; 9 tuples updated ok ( 0.138 s ) |
Since a is not modified during this operations and a can be used to retrieve the corresponding tuples, the index on a is used as a virgin index. All update operations are stored in the rollback table updtab4712
CGADM > list transaction for TS1; +----------------+-----------+ | TAINFO | TAINFO | | RBO | NUMOP | +----------------+-----------+ | updtab4712 | 24905 | | rbcatlog4712 | 49810 | +----------------+-----------+ Admin action finished |
If all tuples are retrieved an updated, now the virgin index is treated.
This means, all updated tuples are added to the virgin index.
During the commit ( or rollback ), the cleanup of the transaction is performed.
Either the old entries are deleted and the new entries are made visible ( commit ) or the new entries are deleted and the old entries are reactivated ( rollback ).
7.5 Realtime Monitor
A realtime overview of a running cego database system is show with the included real time monitor. To invoke the monitor, you have to call cgadm with the --mon option.
$ cgadm --server=localhost --port=2000 --user=cgadm/cgadm --mon |
7.6 Basic tableset administration
With the commands described in this section, the most important administration tasks from the cego database administration can be done. This includes definition and creation of new tableset, starting and stopping but also dropping and removing tablesets.
7.6.1 Definition
To create a default tableset, just type
CGADM > define tableset TSX; Tableset TSX defined ok ( 0.001 s ) |
This defines tableset TSX using the default parameters as listed in the following table.
| Parameter | Meaning | Default |
|---|---|---|
| tsroot | Root directory for the tableset | Current directory |
| syssize | Size of the system space in number of pages | 100 |
| tmpsize | Size of the temporary space in number of pages | 100 |
| appsize | Size of the application space in number of pages | 3000 |
| logsize | Size of a redolog file in bytes | 1000000 |
| lognum | Number of configured redolog files | 3 |
| sortareasize | Max order and grouping buffer size | 1000000 |
| mediator | Name of the mediator host | local hostname |
| primary | Name of the primary host | local hostname |
| secondary | Name of the secondary host | local hostname |
For more special tableset definitions, you may set any of the listed attributes to appropriate values. The attribute values for syssize, tmpsize and logsize are specified as integer values. The attribute values for logfilename, meiator, primary and secondary are specified as string values.
CGADM >define tableset TSX tsroot='./db' syssize=100 tmpsize=100 logsize=100000 lognum=3 sortareasize=1000000 mediator='game' primary='geek' secondary='sam'; Tableset TSX defined ok ( 0.001 s ) |
You can check the tableset configuration by typing
CGADM > show tableset TSX; +---------------------+----------------------+ | TABLESETINFO | TABLESETINFO | | PARAMETER | VALUE | +---------------------+----------------------+ | Tableset | TSX | | RunState | DEFINED | | SyncState | SYNCHED | | Primary | dude.local | | Secondary | dude.local | | Mediator | dude.local | | RootPath | ./dbx | | Ticket | tsticket.xml | | InitFile | null | | Checkpoint | 0 | | SystemPageTotal | 100 | | SystemPageUsed | 0 | | TempPageTotal | 100 | | TempPageUsed | 0 | | AppPageTotal | 0 | | AppPageUsed | 0 | | SortAreaSize | 10000000 | | Tid | 0 | | CLSN | 0 | | NLSN | 0 | | ArchMode | OFF | | AutoCorrect | OFF | | TableCache | OFF | | TC MaxEntryNum | 0 | | TC MaxEntrySize | 0 | | TC UsedSize | 0 | | QueryCache | ON | | QC MaxEntryNum | 500 | | QC MaxEntrySize | 30000000 | | QC UsedSize | 954344 | | LogSize | 1000000 | | LogFile | ./dbx/TSXredo0.log | | LogFile | ./dbx/TSXredo1.log | | LogFile | ./dbx/TSXredo2.log | +---------------------+----------------------+ Admin action finished ok ( 0.002 s ) |
If you want to change some of the parameters, you can do this using the set command
CGADM > set sortareasize 2000000 for TSX; Sort area size set ok ( 0.000 s ) CGADM > set syssize 2000 for TSX; System size set ok ( 0.000 s ) CGADM > set tmpsize 2000 for TSX; Temp size set ok ( 0.000 s ) CGADM > set appsize 12000 for TSX; App size set ok ( 0.000 s ) |
Please note: Most of the parameters just can be changed, if the tableset is in defined state. If the tableset is created, it is not possible to change parameters like root path, syssize, tmpsize or appsize.
7.6.2 Creation
After a tableset has been defined, it can be created. This process creates all required system, temp, datafiles and redo log files for the corresponding tableset. Since all information is availale after the tableset defintion, the creation command is quite easy.
CGADM > create tableset TS1; Tableset created ok ( 0.081 s ) |
7.6.3 Start and stop
To use a previous created tableset, it must be started up to be online. The start command is used to bring a tableset online.
CGADM > start tableset TS1; Table set started ok ( 0.002 s ) |
With the start command, the cleanup and forceload option can be used.
The cleanup option performs a cleanup of datafiles. This means, datafiles are analysed for allocated but unused pages.
For this, all tableset objects are traced. So for larger tableset configurations, the cleanup may take a while.
Allocation leaks may happen in case of a system crash, if pages have already been allocated but have not been commited via checkpointing.
The forceload option can be used, if all view and procedure objects should be compiled and load at tableset startup.
These options can also be used in combination
CGADM > start tableset TS1 cleanup forceload; Table set started ok ( 0.002 s ) |
The following startup options are available
- cleanup - cleanup garbage pages
- forceload - enforce object load during startup
- cpdump - active spdump mode
- noinit - do not execute tableset init file, this can be usedful after recreation of a tableset
CGADM > list tableset; +-----------+----------+-----------+-----------+-----------+-----------+ | TSL | TSL | TSL | TSL | TSL | TSL | | NAME | RUNSTATE | SYNCSTATE | MEDIATOR | PRIMARY | SECONDARY | +-----------+----------+-----------+-----------+-----------+-----------+ | TS1 | ONLINE | SYNCHED | game | game | game | +-----------+----------+-----------+-----------+-----------+-----------+ Tableset list ok ( 0.016 s ) |
To set the tableset offline it can be stopped using the stop command.
CGADM > stop tableset TS1; Table set stopped ok ( 0.002 s ) |
CGADM > list tableset; +-----------+----------+-----------+-----------+-----------+-----------+ | TSL | TSL | TSL | TSL | TSL | TSL | | NAME | RUNSTATE | SYNCSTATE | MEDIATOR | PRIMARY | SECONDARY | +-----------+----------+-----------+-----------+-----------+-----------+ | TS1 | OFFLINE | SYNCHED | game | game | game | +-----------+----------+-----------+-----------+-----------+-----------+ Tableset list ok ( 0.016 s ) |
7.6.4 Drop
If a tableset is not need any more or should be destroyed for any reasons, it can be removed with the drop command.
CGADM > drop tableset TS1; Table set dropped ok ( 0.027 s ) |
This deletes all corresponding system , data and redo logfiles for the corresponding tableset. After the tableset has been dropped, the tableset defintion is still available in the database configuration file.
7.6.5 Remove
To remove the tableset definition from the database configuration file, it can be deleted using the remove command.
CGADM > remove tableset TS1; Tableset removed ok ( 0.001 s ) |
Before a tableset can be removed, it must be dropped using the drop command.
7.6.6 Datafile expansion
Datafiles are appended with the following command
CGADM > add app datafile './newdata.dbf' size 1000 to tableset TS1; Data file added ok ( 0.846 s ) |
CGADM > add sys datafile './sysdata.dbf' size 1000 to tableset TS1; Data file added ok ( 0.846 s ) |
CGADM > add temp datafile './tempdata.dbf' size 1000 to tableset TS1; Data file added ok ( 0.846 s ) |
7.6.7 Tableset verification
A tableset consitency check can be done with
CGADM > verify tableset TS1; +----------------+-----------------------------------------+---------------------------------------------------+ | TSVERIFY | TSVERIFY | TSVERIFY | | TYPE | NAME | STATUS | +----------------+-----------------------------------------+---------------------------------------------------+ | Table | t1 | ok | | Table | t2 | ok | | Table | t3 | ok | | View | myView1 | ok | | View | myView2 | ok | | Procedure | myProc1 | ok | | Procedure | myProc2 | ok | +----------------+-----------------------------------------+---------------------------------------------------+ Tableset TS1 verified ok ( 4.418 s ) |
7.6.8 Tableset correction
For performance reasons, index entries are not modified in a transactional way. After system crash, it may happen, that index objects are invalidated. This is because index tables are not synchronized with the checkpoint and so they are not written consistently. If indexes are modified after the last checkpoint, they are invalidated after crash recovery. To validate index objects for a tableset, this can be done with the following command
CGADM > correct tableset TS1; +----------------+-----------------------------------------+---------------------------------------------------+ | TSVERIFY | TSVERIFY | TSVERIFY | | TYPE | NAME | STATUS | +----------------+-----------------------------------------+---------------------------------------------------+ | Table | t1 | Index i1 corrected | | Table | t2 | ok | | Table | t3 | ok | +----------------+-----------------------------------------+---------------------------------------------------+ Tableset TS1 corrected ok ( 4.418 s ) |
7.6.9 Checkpoint setting
To enforce periodic tableset checkpoints ( memory sync with the filesystem ), checkpoints have to be set up. This is done with the checkpoint command.
CGADM > set checkpoint interval 3600 for TS1; Checkpoint interval set ok ( 0.000 s ) |
The checkpoint interval is specified in seconds, so the command above sets the checkpoint interval to one hour.
7.6.10 Auto correction
After a system crash, it could be required to perform a correction for the affected tableset. The correction procedure checks for invalidated index objects and rebuilds them. This can be done either in a manual way after the tableset has been started, or it could be triggered automatically using the auto correct feature.
To enable autocorrection, just execute the following admin command
CGADM > enable autocorrect for TS1; Auto correction enabled ok ( 0.000 s ) |
Auto correction also could be disabled with
CGADM > disable autocorrect for TS1; Auto correction disabled ok ( 0.000 s ) |
7.6.11 Checkpoint Dump
From cego version 2.43.x and up, a checkpoint dump option is provided with can be enabled at tableset startup time ( either from command line or via admin shell ). By enabling this option, modified page data in the buffer pool is first written to a temporary dump file instead of directly to the data files. If completed, the dump is renamed and so the modifications are commited. The modified page data recorded in the dumpfile then are written with to the datafiles. This operation is idempotent and can be repeated if required. In case of a system crash before the dump file is completed, the data files keep the consistent state before the checkpoint. If the system crashes while the recorded pages are written to the data files, the dump file is still available and the write procedure is repeated by the recovery procedure during the next tableset startup.
In this sense, the checkpoint dump eliminates the risk of a data file corruption caused by a system crash during the critical checkpoint procedure. Please note, that the checkpoint dump file reaches a maximum size of all pages managed by the buffer pool, so it must be ensured, that the corresponding file system provides enough disk space. The location of the checkpoint dump file is the tableset root path
To enable the checkpoint dump option, you have to start the corresponding tableset with the cpdump option
CGADM > start tableset TS1 cpdump; Table set started ok ( 0.002 s ) |
The cpdump option can also be specified on command line level by starting the cego process in batch or daemon mode. Please note, that this enables the checkpoint dump option for all given startup tablesets.
7.6.12 Loguser setting
In distributed mode ( cego mode ) the primary database node has to establish a connection to the secondary. For this, a user with admin rights is required. This user can be set up with the following command
CGADM > set loguser cgadm for lit; Loguser set ok ( 0.034 s ) |
The user should be a valid user, which can be configured with the user administration commands.
7.7 Caching
The cego caching feature enables the database, to fetch any query or table data in a second level memory cache. This might be useful especially for OLAP applications ( Analytical Processing ), but also for applications, which access unmodified data via frequent queries. The activation and configuration of the cache feature should be made individually based on the specific database requirements. In the following, some hints are given, when the usage might be makes sense and how to configure the caches.
Both cache types can be customized on tableset level.This is done via the cgadm admin console program. At default, the cache features are disabled. To enable either query or table caching, this must be done via cache enabling commands provided by cgadm. For each cache, the initial maximum number of cache entries could be configured and the initial maximum number of allocated bytes per cache entry. Depending on the available amount of memory and the cache requirements, these parameters should be configured.
7.7.1 Query Cache
To speed up execution time of frequent executed (sub)queries, the query cache could be enabled. In this case, the result set of the query is stored in a dedicated memory and can be accessed for subsequent execution calls of the same query much faster, than accessing the data via the database buffer cache. The query cache can be configured in terms of maximum number of entries, maximum size for each cache entry ( in byte ) and a hash range value. The hash range value should be less than maxentry, since it is used to search an appropriate slot in the hash array. Small hash ranges max lead to a better performance but also increases the probability of a query result replacement. Larger values lead to a better usage of the query cache but max slow down the cache lookup speed.
CGADM > set querycache maxentry = 100, maxsize = 100000, hashrange = 20 for TS1; QueryCache params set ok ( 0.000 s ) |
After setting up appropriate cache parameters, the cache could be enabled using the following command
CGADM > enable querycache for TS1; Query cache enabled ok ( 0.045 s ) |
The current status for the caches is indicated by retrieving detailed tableset information
CGADM > show tableset TS1; +---------------------+---------------------+ | TABLESETINFO | TABLESETINFO | | PARAMETER | VALUE | +---------------------+---------------------+ | Tableset | TS1 | | RunState | ONLINE | | SyncState | SYNCHED | | Primary | bigmac.local | | Secondary | bigmac.local | | Mediator | bigmac.local | | RootPath | ./db | | LogUser | null | | Ticket | ./db/TS1_ticket.xml | | InitFile | null | | Checkpoint | 3600 | | SystemPageTotal | 300 | | SystemPageUsed | 16 | | TempPageTotal | 2000 | | TempPageUsed | 15 | | AppPageTotal | 3000 | | AppPageUsed | 1 | | SortAreaSize | 10000000 | | Tid | 0 | | CLSN | 6 | | WLSN | 6 | | ArchMode | OFF | | AutoCorrect | ON | | CP Dump | OFF | | TableCache | OFF | | TC MaxEntryNum | 0 | | TC MaxEntrySize | 0 | | TC UsedSize | 0 | | QueryCache | ON | | QC MaxEntryNum | 100 | | QC MaxEntrySize | 100000 | | QC HashRange | 20 | | QC UsedSize | 0 | | LogSize | 1000000 | | LogFile | ./db/TS1_redo0.log | | LogFile | ./db/TS1_redo1.log | | LogFile | ./db/TS1_redo2.log | +---------------------+---------------------+ Tableset information ok ( 0.001 s ) |
All query cache entries can be removed with
CGADM > clean querycache for TS1; Query Cache cleaned ok ( 0.047 s ) |
The query cache could be disabled with the following command
CGADM > disable querycache for TS1; Query cache disabled ok ( 0.045 s ) |
Please note, that for enabling and disabling the query cache, the tableset must NOT be online, since the hash array is allocated with the appropriate size at tableset startup.
The cached entries for the query cache can be listed with
CGADM > list querycache for TS1; +-----------+-------------------+-----------+-----------+-----------+ | CACHE | CACHE | CACHE | CACHE | CACHE | | POS | ID | NUMROWS | NUMHITS | SIZE | +-----------+-------------------+-----------+-----------+-----------+ | 2 | *t1@TS1@t1# | 1 | 1 | 221 | | 68 | t1.a#a#t1@TS1@t1# | 1 | 1 | 128 | | 72 | t1.b#b#t1@TS1@t1# | 1 | 1 | 128 | +-----------+-------------------+-----------+-----------+-----------+ QueryCache List ok ( 0.000 s ) |
The first column indicates the position in the hash array. Furthermore, the unique query id for the cache entry is indicated, the number of corresponding rows in the result set, the number of cache hits and the size of the result set in bytes.
The query cache might be useful for applications with expensive queries, where the result set is moderate and updates on the involved tables are rare. Also the performance of applications with complex nested queries could be improved, if the involved tables of the nested queries are not modifed very often.
7.7.2 Table Cache
On a lower level, the table cache stores tuples on table level. This might improve performance of queries, which often access tables via specific full table scans, where the low level table cursor is not able to make first attribute evaluation via index. Normally, the happens for the following predicate forms
- ( not ) like predicate
- ( not ) in subselect
- ( not ) exists subselect
- or condition
Samples for such queries are
- select a from t1 where b like '%X%'
- select a from t1 where a in ( select a from t2 )
- select a from t1 where exists ( select a from t2 where t2.b = t1.b )
If table t1 fits into the specified maxtablecachesize, the table is cached and subsequent calls for the select statement should be executed faster.
Cache administration for the tablecache is done with the following commands
To configure the tablecache, both parameters can be modified
CGADM > set tablecache entry 100 for TS1; TableCache entries set ok ( 0.045 s ) CGADM > set tablecache size 100000 for TS1; TableCache size set ok ( 0.044 s ) |
All table cache entries can be removed with
CGADM > clean tablecache for TS1; Table Cache cleaned ok ( 0.047 s ) |
The cached entries for the table cache can be listed with
CGADM > list tablecache for TS1; +--------+-----------+-----------+-----------+ | CACHE | CACHE | CACHE | CACHE | | ID | NUMROWS | NUMHITS | SIZE | +--------+-----------+-----------+-----------+ | t2@TS1 | 2 | 2 | 156 | | t1@TS1 | 5865 | 8 | 442787 | +--------+-----------+-----------+-----------+ TableCache List ok ( 0.000 s ) |
As we have discussed at the beginning, the activation of query cache or table cache might be useful for a specific database applications. In any case, this must be analysed and tested for the specific application. For this, a detailed understanding of the datamodel and the implemented queries is an important prerequsiste.
7.8 Backup administration
The cgadm program provides several commands for managing backups of a cego database. In the following section these commands are described. For a more detailed description of the overall backup procedure, please refer to section Backup and recovery.
7.8.1 Import and export
For several reasons, it can be necessary to export any data of a database to a file and import the file again to any other or the same database.
Normally, database exports are used to create a new copy of the existing tableset or just to save the data for backup reasons.
Cego provides three modes of doing data import and export.
- XML mode
- Binary mode
- Plain mode
XML exports are used to generate a readable file in XML format. The format is appropriate for heterogenous system copies or system migrations. It also can be used for editing, since the exported files can be modified using any standard text editor. From the cgadm command line console, XML export is generated with
CGADM > export tableset TS1 to 'ts1.exp'; Exporting table t1 ... Exporting table t2 ... Exporting btree i1... Exporting table data for t1 ... 77010 rows exported Exporting table data for t2 ... 49949 rows exported Tableset TS1 exported ok ( 2.174 s ) |
During the export of any table data, the number of rows, which have been actually exported, are indicated. This informs the administrator about the current status of the export. The resulting file contains all objects which are stored in the tableset TS1. This also includes any indexes, key, checks and counters. It can be imported with the following import command
CGADM > import tableset TS1 from 'ts1.exp'; Importing table data for t1 ... Importing table data for t2 ... Importing index i1... Tableset TS1 imported ok ( 3.241 s ) |
If the nologging option is added to the import command, redo logging is disabled during the import process. The option speeds up the import and can be used, if no recovery is needed for the import.
A more faster way to export and import data is provided with the binary mode. The resulting file is machine dependent and can be just used for target systems with the same architecture. Binary is much faster than XML and should be used, if performance is an important issue.
The corresponding commands are
CGADM > export binary tableset TS1 to 'ts1.bin'; Exporting table t1... Exporting table data for t1 ... 77010 rows exported Exporting table t2... Exporting table data for t2 ... 49949 rows exported Tableset TS1 exported ok ( 0.904 s ) |
For huge table data and restricted export requirements, the plain mode can be used. Plain mode reads any rows of a table without any column structure analysis and directly writes this data to the dump file. As a result, huge amount of data can be exported and imported pretty fast. Using a 2.7 GHz CPU with a modern fast IO subsystem, throughput of more then 100000 rows per second can be achieved. The method is restricted to tables without blob columns and no reorganisation of the data on column level in done.
CGADM > export plain tableset TS1 to 'ts1.dmp'; Exporting table t1... Exporting table data for t1 ... 77010 rows exported Exporting table t2... Exporting table data for t2 ... 49949 rows exported Tableset TS1 exported ok ( 0.565 s ) |
Import of binary and plain data is done in a similar way as done by xml import. Instead of xml import mode, binary or plain import mode should be specified.
CGADM > import plain tableset TS1 from 'ts1.dmp'; Importing table t1... Importing table data for t1 ... 77010 rows imported Importing table t2... Importing table data for t2 ... 49949 rows imported Importing index i1... Tableset TS1 imported ok ( 1.082 s ) |
7.8.2 Archive log mode
The configured online redo log files are written in a round robin manner. As a consequence, online log files are overwritten and log information of the past gets lost. To avoid the loss of log information, the online logs have to saved to an archive log destination.
For this, archive log mode must be configured and enabled.
The log location must have enough space to save all written logfiles ( until they are saved to any other third level storage ). For redundancy reaosons, several log location can be configured for a tableset. An archive log location is added to a tableset with the following command
CGADM > add archlog AL1 path './arch' to TS1; Arch log added ok ( 0.000 s ) CGADM > |
The archive log destionation is identified by an unique id AL1 so it can be referenced. If the log location should be not written any more, the location entry can be removed with
CGADM > remove archlog AL1 from TS1; Arch log removed ok ( 0.000 s ) |
To active the configured archive logs, archive log mode must be enabled.
CGADM > enable archlog for TS1; Arch mode enabled ok ( 0.000 s ) |
This enables the archive logging for tableset TS1.
To disable the archive log mode for a tableset, use the command
CGADM > disable archlog for TS1; Arch mode disabled ok ( 0.000 s ) |
7.8.3 Online backup mode
To make a backup of a tableset while the tableset is online and in use can be done using the online backup mode. To switch a tableset to the online backup mode, use the command
CGADM > begin backup for TS1; Backup mode started ok ( 0.002 s ) |
To add any appropriate log information for the backup statistics, the backup mode can be set with any log message.
CGADM > begin backup for TS1 message 'This is a sample backup'; Begin backup mode ok ( 0.002 s ) |
Now a backup of the tableset can be done. After the backup has been finished, the backup mode of the tableset should be ended. This is done with
CGADM > end backup for TS1 message 'Sample backup finished'; Backup mode finished ok ( 0.002 s ) |
The backup log statistics can be listed with the following command
CGADM > list bustat for TS1; +---------------------+---------------------+---------------------------------------------------+ | BUSTAT | BUSTAT | BUSTAT | | TS | BUINFO | BUMSG | +---------------------+---------------------+---------------------------------------------------+ | 18.12.2012 11:07:26 | BEGIN BACKUP | No message | | 18.12.2012 11:07:30 | END BACKUP | No message | | 18.12.2012 11:12:34 | BEGIN BACKUP | This is a sample backup | | 18.12.2012 11:12:47 | END BACKUP | Sample backup finished | +---------------------+---------------------+---------------------------------------------------+ BUStat info ok ( 0.001 s ) |
The backup log statistics can be cleared with
CGADM > reset bustat for TS1; BUStat reseted ok ( 0.002 s ) |
For a detailed description how to create and restore an online backup of a tableset, please refer to section Backup and recovery
7.8.4 Tableset recovery
If a recovery of a tableset is required, this can be done using cgadm. For this, all required archive log files must be provided in any configured archive log destination.
First make sure, an appropriate external log manager is configured. If all archive logs are already provided in any larchive log destination, the log manager could set be to NONE
CGADM > set logmng 'NONE'; Log Manager set ok ( 0.000 s ) |
This disables the external logmanager. Check the configuration with
CGADM > show logmng; +-------------------------------+------------+ | LOGMNGINFO | LOGMNGINFO | | LOGMANAGER | TIMEOUT | +-------------------------------+------------+ | NONE | 10 | +-------------------------------+------------+ Log Manager Info ok ( 0.000 s ) |
To perform a tableset recovery, the tableset must be in status OFFLINE. After all required datafiles and logfiles have been provided, the recovery is started with
CGADM > recover tableset TS1; Tableset recovered to lsn 15789 Recover completed ok ( 8.008 s ) CGADM > list tableset; +-----------+----------+-------------+ | TSL | TSL | TSL | | NAME | RUNSTATE | SYNCSTATE | +-----------+----------+-------------+ | TS1 | ONLINE | SYNCHED | +-----------+----------+-------------+ Tableset list ok ( 0.000 s ) |
This recovers all redo logs in the known archive log locations until the recent available log entry ( up-to-crash recovery ). If you rather would like to perform a recovery to an earlier point in time, this can be done using the point-in-time recovery. To do this, you have to provide a valid timestamp with the recover command
CGADM > recover tableset TS1 to '2007-08-12 10:47:39 CEST'; Tableset recovered to lsn 14789 ok ( 0.338 s ) |
Depending on the amount of log data, which has to be recovered, the recovery process can take a while. You can follow the process, by tracing the database protocol file.