FR/Documentation/HSQLDB Guide/ch04

From Apache OpenOffice Wiki
Jump to: navigation, search

Chapitre 4. Considérations avancées

Fred Toussi

HSQLDB Development Group

<ft@cluedup.com>


Copyright 2002-2005 Fred Toussi. Permission is granted to distribute this document without any alteration under the terms of the HSQLDB license. Additional permission is granted to the HSQLDB Development Group to distribute this document with or without alterations under the terms of the HSQLDB license.

$Date: 2007/03/24 11:39:08 $

But de ce document

Beaucoup de questions fréquemment posées dans les forums et mailing-lists trouvent leurs réponses dans ce guide. Si vous voulez utiliser HSQLDB avec votre application, vous devez lire ce guide. Ce document couvre les problèmes relatifs au système. Pour les problèmes relatifs au SQL voyez le chapitre : Problèmes liés au SQL.

Connexions

La méthode normale d'accès à une base de données HSQLDB est par une interface de connexion JDBC. Un point de départ aux différentes méthodes pour fournir les services des bases de données et y accéder se situe au chapitre Problèmes liés au SQL. Des détails et exemples sur la connexion JDBC sont fournis dans JavaDoc for jdbcConnection.

La version 1.7.2 a introduit une méthode uniforme de distinction entre différents types de connexions, abordant de nouvelles possibilités pour fournir l'accès à de multiples bases de données. L'identifiant de pilote commun est jdbc:hsqldb: suivi par un identifiant de protocole (mem: file: res: hsql: http: hsqls: https:) puis suivi par l'hôte et les identifiants de port dans le cas de serveurs, et enfin suivi de l'identifiant de la base de données.

Tableau 4.1. Composants des URL Hsqldb

Pilote et Protocole Machine hôte et Port Base de données
jdbc:hsqldb:mem: non disponible accounts
En minuscule, un identifiant d'un simple mot créé la base de données en mémoire lors de la première connexion. Par la suite, l'usage de la même URL de connexion se connecte à la base de données existante.

L'ancienne forme de l'URL, jdbc:hsqldb:. créé ou se connecte à la même base de données que la nouvelle forme de l'URL, jdbc:hsqldb:mem:.
jdbc:hsqldb:file: non disponible MaBase
/opt/db/accounts
C:/data/MaBase
Le chemin spécifie le fichier de la base de données. Dans les exemples ci-dessus le premier fait référence à un jeu de fichier MaBase.* dans le dossier d'où la commande Java pour lancer l'application a été initié. Le second et le troisième exemple font référence aux chemins absolus sur la machine hôte.
jdbc:hsqldb:res: non disponible /UnDossier/NomDeLaBase
Les fichiers de base de données peuvent être chargés depuis un des jars spécifiés comme une partie de la commande Java de la même manière qu'on accède aux fichiers de ressources dans les programmes Java. Le dossier /UnDossier positionne dans un dossier dans l'un des jars.
jdbc:hsqldb:hsql:
jdbc:hsqldb:hsqls:
jdbc:hsqldb:http:
jdbc:hsqldb:https:
//localhost
//192.0.0.10:9500
//dbserver.somedomain.com
/an_alias
/enrollments
/quickdb
L'hôte et le port spécifient l'adresse IP ou le nom de l'hôte du serveur et un numéro de port optionnel. La base de données à laquelle se connecter est spécifiée par un alias. Cet alias est une chaîne de caractères en minuscule définie dans le fichier des propriétés du serveur pour pointer sur une base de données existante sur le système de fichiers d'un serveur, ou une base de données en mémoire, éphémère, sur le serveur. Les lignes de l'exemple suivant dans server.properties ou webserver.properties définissent les alias de base de données définis ci-dessus et accessibles aux clients pour faire référence aux différents fichiers et base de données en mémoire.
   database.0=file:/opt/db/accounts
dbname.0=an_alias

database.1=file:/opt/db/mydb
dbname.1=enrollments

database.2=mem:adatabase
dbname.2=quickdb

L'ancienne forme pour l'URL de serveur, par ex. jdbc:hsqldb:hsql//localhost se connecte à la même base de données que la nouvelle forme d'URL jdbc:hsqldb:hsql//localhost/ ou l'alias est une chaîne de caractères de longueur zéro. Dans l'exemple ci-dessous, les fichiers de base de données lists.* dans le répertoire /home/dbmaster/ sont associés avec un alias vide :

   database.3=/home/dbmaster/lists
dbname.3=

Propriétés de Connexion

Chaque nouvelle connexion JDBC à une base de données peut spécifier des propriétés de connexion. Les propriétés Utilisateur et Mot de passe sont toujours requises. Dans la version 1.8.0 on peut également utiliser les propriétés optionnelles suivantes.

Les propriétés de connexion peuvent être spécifiées soit en établissant la connexion par l'appel de la commande :

   DriverManager.getConnection (String url, Properties info);

Soit la propriété peut être ajoutée à l'URL complet de connexion.

Tableau 4.2. Propriétés de connexion

get_column_name true Nom de colonne dans le ResultSet
Cette propriété est utilisée pour la compatibilité avec l'implémentation d'autres pilotes JDBC. Si vrai (la valeur par défaut), ResultSet.getColumnName(int c) renvoie le nom de la colonne sous-jacente.

Quand la valeur est fausse, la méthode ci-dessus renvoie la même valeur que ResultSet.getColumnLabel(int column). Exemple ci-dessous :
   jdbc:hsqldb:hsql://localhost/enrollments;get_column_name=false

Quand on utilise une procédure stockée définie par l'utilisateur à l'intérieur d'un ResultSet, la valeur par défaut, vrai, est la seule utilisée pour cette propriété.

ifexists false Etablit la connexion seulement si la base de données existe déjà.
A un effet seulement avec les bases de données mem: et file:. Quand la valeur est vrai, ne créera pas de nouvelle base de données s'il n'en existe pas déjà une pour l'URL donnée.

Quand la valeur est faux (par défaut), une nouvelle base de données mem: ou file: sera créée si elle n'existe pas déjà.

Régler la propriété à vrai est pratique en cas de dépannage comme aucune base de données n'est créée si l'URL est mal formée. Exemple ci-dessous :
   jdbc:hsqldb:file:enrollments;ifexists=true
shutdown false Ferme la base de données quand la dernière connexion est fermée.
Ceci imite le comportement des versions 1.7.1 et plus anciennes. Quand la dernière connexion à une base de données est close, la base de données est automatiquement fermée. La propriété prend effet seulement lors de la première connexion à la base de données. C'est à dire la connexion qui ouvre la base de données. Elle n'a pas d'effet utilisée par la suite, ou dans le cas de connexions simultanées.

Cette commande a deux usages. L'un est pour tester les suites, ou les connexions à une base de données sont réalisées à partir d'un contexte d'une machine virtuelle Java, et immédiatement suivies par un autre contexte. L'autre utilisation est pour les applications ou il n'est pas facile de configurer l'environnement de fermeture de la base de données. Les exemples rapportés par les utilisateurs incluent des serveurs d'applications web, ou la fermeture de la dernière connexion coïncide avec la fermeture de l'application web.

De plus, quand la connexion à une base de données "in-process" crée une nouvelle base de données, ou en ouvre une existante (par exemple si c'est la première connexion à la base de données faite par l'application), toutes les propriétés de la base de donnée définies par l'utilisateur peuvent être spécifiées comme des propriétés URL. On peut l'utiliser pour spécifier des propriétés qui forcent un langage SQL plus strict, ou pour changer cache_scale ou des propriétés similaires avant que les fichiers de la base de données ne soient créés. Toutefois, dans le cas des nouvelles bases de données, il est recommandé d'utiliser la commande SET PROPERTY pour de tels réglages.

Fichiers de propriétés

HSQLDB s'en remet à un jeu de fichiers de propriétés pour différents réglages. Depuis la version 1.7.0 la nomenclature des propriétés a été rationalisée et nombre de nouvelles propriétés ont été introduites.

Dans tous les fichiers de propriétés, les valeurs sont sensibles à la casse. Toutes les valeurs en dehors des noms de fichiers ou de pages sont requises en minuscule (c.a.d. server.silent=FALSE n'aura pas d'effet, mais server.silent=false fonctionnera).

Les fichiers de propriétés et les réglages stockés en eux sont les suivants :

Tableau 4.3. Fichiers de propriétés Hsqldb Server

Nom du fichier Adresse Fonction
server.properties Le répertoire d'ou vient la commande pour exécuter la classe Server Les réglages pour exécuter HSQLDB comme un serveur de base de données communicant par le protocole HSQL
webserver.properties Le répertoire d'ou vient la commande pour exécuter la classe WebServer Les réglages pour exécuter HSQLDB comme un serveur de base de données communicant par le protocole HTTP
<dbname>.properties Le répertoire ou sont situés tous les fichiers pour une base de données Réglages pour chaque base de données individuelle

Les fichiers de propriétés pour exécuter les serveurs ne sont pas créés automatiquement. Vous devez créer vos propres fichiers contenant les paires server.property=value pour chaque propriété.

Le fichier des propriétés de chaque base de données est généré par le moteur de base de données. Ce fichier peut être édité après fermeture de la base de données. Dans la version 1.8.0, la plupart de ces propriétés peuvent être changés via les commandes SQL.

Les propriétés de Serveur et de Serveur Web

Dans les deux fichiers server.properties et webserver.properties, les valeurs prises en charge et leur valeur par défaut sont comme suit :

Tableau 4.4. Propriétés d'un fichier de propriétés

Valeur Par défaut Description
server.database.0 test Chemin et nom de fichier du premier fichier de base de données à utiliser
server.dbname.0 "" Alias du serveur en minuscule pour le premier fichier de base de données
server.urlid.0 NONE L'urlid de SqlTool utilisée par le script d'initialisation UNIX. (Cette propriété n'est pas utilisée si vous exécutez le mode Server/Webserver sur une plate-forme autre qu'UNIX, ou si vous n'utilisez pas notre script d'initialisation UNIX).
server.silent true Pas de messages explicites affichés sur la console.
server.trace false Messages de "trace" JDBC affichés sur la console.

Dans la version 1.8.0, chaque serveur peut servir jusqu'à dix bases de données différentes simultanément. La propriété server.database.0 définit le nom de fichier / chemin alors que server.dbname.0 définit l'alias en minuscule utilisé par les clients pour se connecter à cette base de données. Le chiffre 0 est incrémenté pour la deuxième base de données, et ainsi de suite. Les valeurs pour la propriété server.database.{0-9} peuvent utiliser les préfixes mem:, file: ou res: et les propriétés sont décrites plus haut dans la section Connexions. Par exemple,

   database.0=mem:temp;sql.enforce_strict_size=true;

Les valeurs spécifiques à server.properties sont :

Tableau 4.5. Propriétés du fichier Propriété Serveur

Valeur Par défaut Description
server.port 9001 (normal) or 554 (if TLS encrypted) Port TCP/IP utilisé pour échanger avec les clients. Toutes les base de données sont servies sur le même port.
server.no_system_exit true Pas d'appel System.exit() lors de la fermeture de la base de données.

Les valeurs spécifiques à webserver.properties sont :

Tableau 4.6. Propriétés du fichier Propriété WebServeur

Valeur Par défaut Description
server.port 80 Port TCP/IP utilisé pour échanger avec les clients.
server.default_page index.html La page web par défaut pour le serveur.
server.root ./ Les adresses des pages fournies.
.<extension> ? Les entrées multiples telles que .html=text/html définissent les types mime des fichiers statiques fournis par le serveur web. Voyez la source de WebServer.java pour une liste.

Toutes les valeurs ci dessus peuvent être spécifiées en ligne de commande de démarrage du serveur en omettant le préfixe server.

Démarrer un serveur depuis votre application

Si vous voulez démarrer le serveur depuis votre application, sans ligne de commande ni fichier batch, vous devez créer une instance du serveur ou du serveur web, puis assigner les propriétés sous forme d'une chaîne de caractères et enfin démarrer le serveur. Vous en avez un exemple dans org.hsqldb.test.TestBase source.

  • Note

Mise à jour : Si vous avez déjà des fichiers de propriétés personnalisés, accordez les valeurs à la nouvelle convention de dénomination. Notez l'usage des chiffres à la fin des propriétés de server.database.n et server.dbname.n.

Propriétés d'une base de données individuelle

Chaque base de données a son propre fichier <NomDeLaBase>.properties, faisant lui-même partie d'un petit groupe de fichiers comprenant aussi <NomDeLaBase>.script et <NomDeLaBase>.data. Les fichiers de propriétés contiennent des paires Clé/Valeur pour quelques réglages importants.

Dans la version 1.8.0 une nouvelle commande SQL permet à la plupart des propriétés de base de données d'être modifiés comme suit :

   SET PROPERTY "property_name" property_value

Les propriétés qui peuvent être modifiés par la commande SET PROPERTY sont indiquées dans le tableau ci-dessous. D'autres propriétés sont indiquées comme PROPERTIES FILE ONLY et peuvent être modifiés seulement par édition du fichier .properties après une fermeture et avant un redémarrage. Seulement les valeurs définies par l'utilisateur listées ci-dessous pourront jamais être modifiées. Le changement de toute autre valeur pourrait résulter en des dysfonctionnements inattendus dans les opérations de la base de données. La plupart de ces valeurs ont été introduites en vue de nouvelles fonctionnalités depuis la version 1.7.0 :

Tableau 4.7. Database-specific Property File Properties ???

Valeur Par défaut Description
readonly false Toute la base de données est en lecture seule.
Si la propriété est Vrai, la base de données ne peut pas être modifiée pendant l'utilisation. Ce réglage peut être changé en true si la base de données doit être ouverte depuis un CD. Avant de changer ce réglage, la base de données doit être fermée avec la commande SHUTDOWN COMPACT pour assurer la consistance et la compacité des données. (PROPERTIES FILE ONLY) mais peut être utilisé comme une propriété de connexion pour ouvrir une base de données normale en lecture seule.
hsqldb.files_readonly false Les fichiers de la base de données ne seront pas écrits.
Si la propriété est Vrai, les données dans les tables MEMORY peuvent être modifiées et de nouvelles tables MEMORY peuvent être ajoutées. Toutefois ces changements ne sont pas sauvegardés quand la base de données est close. Les tables CACHED et TEXT sont toujours en lecture seule quand ce réglage est Vrai. (PROPERTIES FILE ONLY)
hsqldb.cache_file_scale 1 Etablit la taille limite du fichier de données. Une fois réglée, cette limite peut être repoussée jusquà 8 Go.
Cette propriété peut-être réglée à 8 pour augmenter la taille limite du fichier .data de 2 à 8 Go. Pour appliquer le changement à une base de données existante, il faut d'abord exécuter la commande SHUTDOWN SCRIPT, puis la ligne Propriété=Valeur ci dessous doit être ajoutée au fichier .properties avant de rouvrir la base de données.
hsqldb.cache_file_scale=8

La propriété peut-être réglée avec la commande SQL (contrairement au changement de la valeur dans le fichier des propriétés) quand la base de données n'a pas de tables en cache (CACHED) (par ex. une nouvelle base de données). (SET PROPERTY) The property can be set with the SQL command (as opposed to changing the value in the properties file) when the database has no CACHED tables (e.g. a new database). (SET PROPERTY)

sql.enforce_size false Taille et remplissage (trimming and padding) des colonnes de texte
Cette propriété n'est plus prise en charge. Utilisez sql.enforce_sctrict_size
sql.enforce_strict_size false Renforcement de la taille et remplissage des colonnes de texte
Se conforme aux standards SQL pour la taille et la précision du type des données. Quand la propriété est Vrai, toutes les valeurs CHARACTER, VARCHAR, NUMERIC et DECIMAL contenues dans une ligne affectée par une déclaration INSERT INTO ou UPDATE sont confrontées avec la taille spécifiée dans la définition SQL de la table. Il se produit une exception si la valeur est trop grande. De plus toutes les valeurs CHARACTER qui sont plus courtes que la taille spécifiée sont remplies avec des espaces. Les valeurs TIMESTAMP(0) et TIMESTAMP(6) sont également permises de façon à spécifier la résolution des fractions de seconde des valeurs. Quand la propriété est fausse (par défaut), stocke la chaîne exactement comme elle est insérée. (SET PROPERTY)
sql.tx_no_multi_rewrite false Gestion d'une transaction
Dans le mode par défaut READ_UNCOMMITED, une transaction peut ré-écrire des lignes insérées ou mises à jour par une autre transaction non commise. Régler cette propriété à Vrai générera une exception quand une telle écriture sera tentée. (SET PROPERTY)
hsqldb.cache_scale 14 Exposant du cache mémoire
Indique le nombre maximum de lignes des tables en cache contenues en mémoire, calculé comme 3*(2^Valeur) (trois multiplié par (deux puissance Valeur)). La valeur par défaut résulte en 3*16384 lignes de toutes les tables en cache contenues en mémoire à chaque instant.

La plage de valeurs est comprise entre 8 et 18. (SET PROPERTY). Si la valeur est réglée via SET PROPERTY elle devient effective après la prochaine commande de base de données SHUTDOWN ou CHECKPOINT. (SET PROPERTY)
hsqldb.cache_size_scale 10 Exposant du cache mémoire
Indique la taille moyenne de chaque ligne dans le cache mémoire utilisé avec les tables en cache, calculé comme 2^Valeur (deux à la puissance Valeur). Ce résultat est multiplié par le nombre maximum de lignes définit par hsqldb.cache_scale pour former le nombre maximum d'octets pour toute les lignes dans le cache mémoire. La valeur par défaut donne un résultat de 1024 octets par ligne. Cette valeur, combinée avec le nombre de lignes par défaut, aboutit au fait qu'approximativement 50 Mo du fichier .data est stocké dans le cache mémoire.

La plage de valeurs est comprise entre 6 et 20. (SET PROPERTY). Si la valeur est réglée via SET PROPERTY elle devient effective après la prochaine commande de base de données SHUTDOWN ou CHECKPOINT. (SET PROPERTY)
hsqldb.log_size 200 Taille de l'historique (log) quand un checkpoint est exécuté.
La valeur est la taille en mégaoctets que le fichier .log peut atteindre avant qu'un checkpoint automatique n'intervienne. Un checkpoint ré-écrit le fichier .script et vide le fichier .log. La valeur peut être changée via la commande SQL SET LOGSIZE nnn.
runtime.gc_interval 0 forced garbage collection
This setting forces garbage collection each time a set number of result set row or cache row objects are created. The default, "0" means no garbage collection is forced by the program.

This should not be set when the database engine is acting as a server inside an exclusive JVM. The setting can be useful when the database is used in-process with the application with some Java Runtime Environments (JRE's). Some JRE's increase the size of the memory heap before doing any automatic garbage collection. This setting would prevent any unnecessary enlargement of the heap. Typical values for this setting would probably be between 10,000 to 100,000.
(PROPERTIES FILE ONLY)
hsqldb.nio_data_file true Utilisation des méthodes d'accès de nio pour le fichier .data
Quand HSQLDB est compilé et exécuté depuis Java 1.4 ou ultérieur, régler cette propriété à false évitera l'usage des méthodes d'accès nio


When HSQLDB is compiled and run in Java 1.4 or higher, setting this property to false will avoid the use of nio access methods, resulting in somewhat reduced speed. If the data file is larger than 256MB when it is first opened, nio access methods are not used. Also, if the file gets larger than the amount of available computer memory that needs to be allocated for nio access, non-nio access methods are used.

(SET PROPERTY). If used before defining any CACHED table, it applies to the current session, otherwise it comes to effect after a SHUTDOWN and restart or CHECKPOINT. hsqldb.default_table_type memory type of table created with unqualified CREATE TABLE

The CREATE TABLE command results in a MEMORY table by default. Setting the value "cached" for this property will result in a cached table by default. The qualified forms such as CREATE MEMORY TABLE or CREATE CACHED TABLE are not affected at all by this property. (SET PROPERTY) hsqldb.applog 0 application logging level

The default level 0 indicates no logging. Level 1 results in events related to persistence to be logged, including any failures. The events are logged in a file ending with .app.log textdb.* 0 default properties for new text tables

Properties that override the database engine defaults for newly created text tables. Settings in the text table SET <tablename> SOURCE

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, arm, asm, asp, asymptote, autoconf, autohotkey, autoit, avisynth, awk, bascomavr, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_loadrunner, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, coffeescript, cpp, cpp-qt, csharp, css, cuesheet, d, dcl, dcpu16, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, epc, erlang, euphoria, f1, falcon, fo, fortran, freebasic, freeswitch, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, haxe, hicest, hq9plus, html4strict, html5, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, ldif, lisp, llvm, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, nagios, netrexx, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, octave, oobas, oorexx, oracle11, oracle8, oxygene, oz, parasail, parigp, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, pli, plsql, postgresql, povray, powerbuilder, powershell, proftpd, progress, prolog, properties, providex, purebasic, pycon, pys60, python, q, qbasic, rails, rebol, reg, rexx, robots, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, spark, sparql, sql, stonescript, systemverilog, tcl, teraterm, text, thinbasic, tsql, typoscript, unicon, upc, urbi, uscript, vala, vb, vbnet, vedit, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, yaml, z80, zxbasic


 command override both the engine defaults and the database properties defaults. Individual textdb.* properties are listed in the Text Tables chapter. (SET PROPERTY)

When connecting to an in-process database creates a new database, or opens an existing database (i.e. it is the first connection made to the database by the application), all the user-defined database properties listed in this section can be specified as URL properties.
Note

Upgrading: From 1.7.0, the location of the database files can no longer be overridden by paths defined in the properties file. All files belonging to a database should reside in the same directory.

The property sql.compare_in_locale=true is no longer supported. If the line exists in a .properties file, it will switch the database to the collation for the current default. See the SET DATABASE COLLATION[2] command.

When HSQLDB is used in OpenOffice.org, some property values will have a different default. The properties and values are:

hsqldb.default_table_type=cached hsqldb.cache_scale=13 hsqldb.log_size=10; hsqldb.nio_data_file=false sql.enforce_strict_size=true

== SQL Commands for Database Properties ==
There are some database properties that are set with dedicated SQL commands beginning with SET.

Table 4.8. SQL command properties
SET WRITE_DELAY {{TRUE | FALSE} | <seconds> | <milliseconds> MILLIS

The default is TRUE and indicates that the changes to the database that have been logged are synched to the file system once every 20 seconds. FALSE indicates there is no delay and at each commit a file synch operation is performed. Numeric values from 0 can also be specified for the synch delay.

The purpose of this command is to control the amount of data loss in case of a total system crash. A delay of 1 second means at most the data written to disk during the last second before the crash is lost. All data written prior to this has been synced and should be recoverable

This setting should be specified on the basis of the reliability of the hardware used for running the database engine, the type of disk system used, the possibility of power failure etc. Also the nature of the data stored should be considered.

In general, when the system is very reliable, the setting can be left to the default. If it is not very reliable, or the data is critical a setting of 1 or 2 seconds would suffice. Only in the worst case scenario or with the most critical data should a setting of 0 or FALSE be specified as this will slow the engine down to the speed at which the file synch operation can be performed by the disk subsystem.

Values down to 10 millisconds can be specified by adding MILLIS to the command, but in practice a delay of 100 milliseconds provides 99.99999% reliability with an average one system crash per 6 days.
SET LOG_SIZE <numeric value>

The engine writes out a log of all the changes to the database as they occur. This log is synched to the disk based on the WRITE_DELAY property above. The log is never reused unless there is an abnormal termination, i.e. the database process is terminated without SHUTDOWN, or it was terminated using SHUTDOWN IMMEDIATELY.

The default maximum size of the .log file is 200 MB. When the maximum size is reached, a CHECKPOINT operation is performed. This operation will save the other database files in a consistent state and delete the old log. A value of 0 indicates no limit for the .log file.
SET CHECKPOINT DEFRAG <numeric value>

When rows in CACHED tables are updated or deleted, the spaces are mostly reused. However, in time, some unused spaces are left in the .data file, especially when large tables are dropped or their structure is modified.

A CHECKPOINT operation does not normally reclaim the empty spaces, whereas CHECKPOINT DEFRAG always does.

This property determines when a normal CHECKPOINT, whether initiated by an administrator or when the size of the log exceeds its limit.

The numeric value is the number of megabytes of recorded empty spaces in the .data file that would force a DEFRAG operation. Low values result in more frequent DEFRAG operations. A value of 0 indicates no automatic DEFRAG is performed. The default is 200 megabytes of lost space.
SET REFERENTIAL INTEGRITY {TRUE | FALSE}

This is TRUE by default. If bulk data needs to be loaded into the database, this property can be set FALSE for the duration of bulk load operation. This allows loading data for related tables in any order. The property should be set TRUE after bulk load. If the loaded data is not guaranteed to conform to the referential integrity constraints, SQL queries should be run after loading to identify and modify any non-conforming rows.
Personal tools