The examples below assume, that the data base server is running on a system called server and is listening on port number 8800. If the server is running on the local system, you could simply omit the host name. If the server is listening on the port mapped to the eloqdb service, you can omit the port number as well. Of course, you could also use a service name instead of the port number.
# eloqdb6.cfg [Server] Service=8800 UID = eloq GID = eloq LogFile = /tmp/eloqdb6.log [Volumes]Short description of the configuration settings:
dbvolcreate -v -c eloqdb6.cfg /path/volume01.volThis creates the root volume /path/volume01.vol with the default size (~2.5 MB) and adds the volume path to the volume section of the config file. The config file could even be empty during volume creation, but it must exist.
Additional dbvolcreate options.
-s sz initial volume size in MB -e sz chunks the volume is extended by (MB) -m sz max volume size (MB)
dbvolextend -v -c eloqdb6.cfg -t log /path/volume02.volThis will create the log volume and append it in the volume section of the config file. Additional dbvolextend options.
-s sz initial volume size in MB -e sz chunks the volume is extended by (MB) -m sz max volume size (MB)The log volume will need at least enough space to hold all commited transactions between two check points. So starting a huge dbimport with CheckpointFreq=60 may cause the log volume to grow and use a huge amount of disk space.
eloqdb6 -d"*1" -c eloqdb6.cfg
You could also start the data base server from the commandline by specifying the -standalone option. However this is only considered a debug tracking option and should not be used regulary.
eloqdb6 -standalone -d"*1" -c eloqdb6.cfg
If you kill the server (please no -9 or you will have stuck IPC resources) or if the server did crash due to a problem, the all committed but not yet completed transactions are recovered automatically.
The new data base server does no longer use ROOT files. Instead it includes a special data base (the system catalog) which is used to hold the data base structure. Actually, there are several catalogs: One which is used to hold server global information and a seperate one for each data base. You can use the dbdumpcat utility to have a look into the server catalogs.
The new data base provides its own authorization scheme and list of users. By default there are two different users "dba" and "public".
The server has two predefined users, "dba" and "public" which are created when the data base environment is generated. By default the user dba has administrative capabilities (for example it can create a new data base) but is not allowed to access any data. The user public by default has no administrative capabilities but is allowed to access the data base contents. The user public is also used as a default user whenever a data base is opened without providing authorization information to the server (please refer to the new DBLOGON statement from more information).
The dbutil utility can be used to create additional users and to maintain the access rights.
schema -u dba -h server -s 8800 db.txtThis will create the data base catalog on the specified server. The server name can be omitted if the server is running on the local system. Specifying a service name or port number can be omitted if the server is using the default eloqdb service.
The -u dba is required. It will identify you as user dba to the server. All commandline tools use $LOGNAME as the default user.
After the schema succeeded, you should be on known grounds. dbcreate and dbimport should work as expected.
dbcreate -u dba server:8800/db dbimport -vs db.exp -u public server:8800/dbPlease note, that the -u public argument is required. It will identify you as user public to the server. All commandline tools use $LOGNAME as the default user.
dbdumpcat -u public -h server -s 8800This will dump the global server catalog.
dbumpcat -u public -h server -s 8800 dbnameThis will dump the catalog specic to dbname.
Please be aware that you can have any number of data bases in a db environment. Dumping the catalogs might give a better understanding how structural information is handled internally - it's completely different than the old ROOT file aproach.