suivant: Php et odbc monter: maxdb précédent: Peupler l'instance
Rappelons que par défaut le loader attend un saut de ligne entre deux enregistrements, des champs séparés par une virgule et délimités par des guillemets doubles.
loadercli -d base -u user,passwd -b commandfile
Fichier de commande:
// commentaire: on aurait pu lancer la création de table ici // fichier: /home/jm/sapdb/etc/load_courriel.loader // commencer par definir le format de l'input // separateur tabulation (on tape une vraie tabulation, pas de delimiteur // une ligne vide separe deux commandes SET COMPRESSED '/ //' // DATALOAD TABLE JM.COURRIEL msgid 1 fils_de 2 maildate 3 mailfrom 4 subject 5 body 6 INFILE '/home/jm/sapdb/data/courriel.txt'Ce qui donnera en réalité la ligne de commande suivante:
loadercli -d mails -u jm,jm_passwd -b /home/jm/sapdb/etc/load_courriel.loader
Attention:il ne faut pas être connecté sous dbmcli sur la base au lancement de loadercli car ça le bloque.
J'ai eu un souci avec l'enregistrement 48. Je l'ai supprimé, détruit les entrées
de la table et
relancé loadercli. Voici la fin du log de loadercli:
(/usr/local/sapdb/indep_data/wrk/loader.prt)
DATA LOAD TABLE "JM"."COURRIEL" successfully executed // * // M Last transaction committed at input record 237 // * // M Sum of inserted records 237, sum of rejected records 0 // * // M Releasing user connection (USER: 'JM').
En fin de compte on aurait pu tout faire dans le même fichier, en plusieurs parties distinctes:
// courriel.ini.loader
// lodercli script de creation & chargement de table
CREATE TABLE courriel
(
msgid VARCHAR(80) NOT NULL PRIMARY KEY CONSTRAINT ct_msgid CHECK msgid LIKE '<%>',
fils_de VARCHAR(80) NOT NULL DEFAULT '<head>' CONSTRAINT ct_fils_de CHECK fils_de LIKE '<%>',
maildate VARCHAR(40) NOT NULL,
mailfrom VARCHAR(80) NOT NULL,
subject VARCHAR(128) NOT NULL,
body VARCHAR(7000) NOT NULL
)
//
SET COMPRESSED '/ //'
//
DATALOAD TABLE JM.COURRIEL
msgid 1
fils_de 2
maildate 3
mailfrom 4
subject 5
body 6
INFILE '/home/jm/sapdb/data/courriel.txt'
//
ALTER TABLE courriel FOREIGN KEY ct_fk_fils_de (fils_de) REFERENCES courriel (msgid)
ON DELETE SET DEFAULT
Ça aurait pu ce faire au moment de l'installation dans le script appelé par dbmcli. On va le faire maintenant.2
dbmcli -d mails dbmcli> user_logon dbm,dbm_passwd dbmcli>medium_put data /home/databases/mails/datasave FILE DATA 0 8 YES dbmcli>medium_put logauto /home/databases/mails/logautosave FILE AUTO dbmcli>util_connect dbmcli>backup_start data DATA dbmcli>autolog_on
On a créé un support de nom data dans le fichier cité sous le protocole DATA, donc pas automatique.
D'ailleurs il ne peut y avoir qu'un backup AUTO par instance. Ici c'est le support auto pour les logs qui fait l'objet d'un backup auto. Puis on a lancé le backup et le backup automatique des logs.
En effet la log area ne peut être réécrite que si les logs ont été archivés: si elle est pleine et qu'il faut écrire des logs dedans la base s'arrête. D'où la nécessité d'archiver des logs, manuellement ou en mode auto, ou bien encore d'activer le mode overwrite de la Log Area (ce qui n'est pas la meilleure manière de faire pour une base en production).
Voilà des commandes pour faire des vérifications sur les backups. C'est pas lisible-lisible au point où j'en suis mais il faut se former.
dbmcli -d mails dbmcli> user_logon dbm,dbm_passwd dbmcli> service_connect dbmcli> recover_check data DATA dbmcli> service_release dbmcli> util_connect dbmcli> medium_label data dbmcli> util_release dbmcli> medium_get data # infos sur le medium data dbmcli> medium_getall # infos sur tous les media
Et des commandes d'informations générales sur l'instance. D'après la doc ça devrait se lancer d'une session sql mais on y arrive tout simplement avec la commande info:
dbmcli -d mails -u dbm,dbm_passwd dbmcli> info identifiant
Où identifiant peut-être ce qui est rendu par l'identifiant infos (avec un s).
Une différence entre SapDB et MaxDB: la sequence util_execute INIT CONFIG suivie de
recover_start nomMedium DATA est remplacée par db_activate RECOVER. Bien sur le nom du
medium doit avoir été paramétré auparavant avec un medium_put adéquat.
db_create DATABASE dbm,dbm medium_put nomMediumExistant pathMediumExistant FILE DATA 0 8 YES recover_config nomMediumExistant service_release db_admin util_connect dbm,dbm util_execute INIT CONFIG recover_start nomMediumExistant DATA util_release db_online
Sinon il faut recréer l'instance, la paramétrer jusqu'au INIT CONFIG et lancer la restauration comme vu précédemment.
Il ne faut pas oublier le medium_put avant toute séquence de récupération, que ce soit pour
la récupération de configuration ou pour la recréation d'instance.
On commence par détruire l'instance:
dbmcli on mails>db_offline OK dbmcli on mails>db_drop OK
Et on la récupère:
dbmcli> db_admin dbmcli> util_connect dbm,dbm dbmcli> recover_start nomMediumData DATAVérifier que l'instance est prête à redémarrer (les informations sont consistantes) avec
db_restartinfo. Si oui, il n'y a rien à récupérer dans les logs. Si non il faut récupérer les
infos dans les logs, à partir du fichier dbm.knl de l'instance: le numéro de séquence du data backup
(champ n^ 8) doit être compris entre les numéro de séquence (champs 8 et 9) du log backup qui
correspond. Alors il sera possible de faire un:
recover_start logMediumName LOG 00N avec 00N étant le numéro du log qui va bien.
recover_replace si il reste des logs après le 00N:
recover_replace logMediumName /path/vers/fichierDeLog 00Ni avec 00Ni étant les numéros de log
qui suivent le log utilisé pour la restauration. fichierDeLog est le nom du fichier qui a été donné
lorsqu'on a fait le medium_put du medium de log (chez moi, par exemple:
/home/databases/troupeau/logautosave)
recover_ignore
Il est possible de récupérer des logs jusqu'à une certaine date avec:
recover_start logMediumName LOG UNTIL <date> <time>
Et normalement tout est bon.
Le tout est d'avoir un backup des données (medium data) à jour...Car
les logs enregistrent les transactions et opérations et permettent de remonter mais toute donnée non
sauvegardée est perdue. Pour avoir des sauvegardes des logs plus souvent il faut définir le
paramètre LOG_SEGMENT_SIZE, car lorsqu'un segment est plein il est sauvegardé, en mode auto. Par
défaut, c'est à dire si le paramètre n'a pas été défini à la création, il est d'un tiers de la
log area, donc chez moi 341 pages (des pages sapdb de 8096 octets, pas des pages linux) ce qui fera
un backup des logs tous les 2.7 Mo environ.
Attention: La restauration supprime l'autolog. Il faut refaire le backup et relancer
l'autolog (autolog_on). Vous le vérifierez avec un autolog_show en console
dbmcli.
Un lien pour de la doc sur les backups-restore
Pour une table, en une seule passe, obtenir les données et le catalogue de création:
USE USER JM JMPASSWD // DATAEXTRACT FOR DATALOAD TABLE JM.ADRESSES OUTFILE '/home/databases/backups/CONTACTS.ADRESSES.command' OUTFILE '/home/databases/backups/CONTACTS.ADRESSES.data'
Pour toute la base, on va obtenir un fichier de définitions de la structure de la base: tables, users, droits, procédures...avec les commandes suivantes:
Le fichier de description est ascii, le fichier de données est binaire.
USE USER DBA DBAPASSWD // DBEXTRACT CATALOG OUTSTREAM FILE '/home/jm/sapdb/data/CONTACTS/dbextract.command' DATA OUTSTREAM FILE '/home/jm/sapdb/data/CONTACTS/dbextract.data' PAGES
On lance le script avec, comme d'habitude, loadercli -d nomBase -b script.
dbmcli> sql_execute SELECT * from domain.connectparametersPar défaut on est en Isolation Level 1. Lors d'un INSERT un verrou exclusif est posé sur le rang d'insertion.
Les requêtes peuvent être paramétrées en modifiant le niveau d'isolation par un "lock option" Le parametre TIMEOUT sert à préciser la durée maximale d'inctivité entre deux instructions SQL de la session. Par défaut 900 secondes. Si il est mis à 0, l'activité de la session n'est pas surveilée, et c'est mauvais pour les autres transactions en cours.
Le verrouillage peut être modifié par un "lock statement"...
dbmcli> sql_execute LOCK TABLE courriel IN EXCLUSIVE MODE dbmcli> sql_execute SELECT lockmode, lockstate from domain.locks WHERE tablename = 'COURRIEL'
ou bien par une "lock option" dans le select:
dbmcli> sql_execute SELECT subject, body FROM courriel WHERE subject like '%Masq%' / WITH LOCK (NOWAIT) ISOLATION LEVEL 15
Étant donné que la probabilité de deadlock évolue avec la puissance de 4 du nombre d'objets verrouillés, on peut dire que verrouiller une table n'est pas forcément une bonne option.
paramètre REQUEST_TIMEOUT: par défaut 5000 secondes: C'est la durée maximale en attente d'un verrou déjà pris.
Bref, pour vérifier le transactionnel, faite une insertion et terminez par COMMIT WORK. Un
petit SELECT ensuite pour vérifier l'insertion.
Puis faites en une autre en terminant par un ROLLBACK WORK et même vérification, et une
autre en terminant avec un ROLLBACK WORK RELEASE suivi d'une opération quelconque en
SQLMODE et vous verrez les différences entre ces différentes manips.
Ça n'est pas compliqué: comme pour l'installation on détarre l'archive et on va dans le dossier créé. Là j'ai essayé ./SDBUPD sans succès, donc je me suis replié vers ./SDBINST en mettant à jour d'abord le serveur (profile 0), puis une nouvelle fois pour mettre à jour le pilote ODBC. Il n'y avait pas grand enjeu à cette mise à jour, mais un backup complet serait recommandé avant d'opérer.
La seule chose c'est qu'il m'a fallu relancer un:
load_systab -u dba,dba_passwd -ud domain_passwd
pour que les tables systèmes soient accessibles (ce ne fut pas nécessaire pour la mise à jour de la
7.4.3.25 vers la 7.4.3.27).
Procéder comme au point précédent: détarrage de l'archive (archive de binaires) et lancement de
SDBINST
L'installation est découpée en profils: j'ai commencé par Runtime, puis Scripts Interface, puis Server, puis Web Tools.
Tout va bien, enfin si l'installation se déroule bien, sauf que....j'ai eu des soucis de reconnexion à mes instances (ERR_USRFAIL). Donc j'ai du modifier quelques droits, car, sous MaxDB, les administrateur et groupe administrateur sont maintenant sdb et sdba.
J'ai modifié les droits et propriétaires des volumes (data et log), ainsi que des backups.
J'ai surtout du modifier les propriétaires et droits des fichiers <indep_data>/config/nomBase*, comme un strace -f me l'a démontré. Mais il faut également modifier les droits sur <indep_data>/wrk/nomBase/*
chown sdb,sdba /usr/local/indep_data/config/TROUPEAU* chmod 660 /usr/local/indep_data/config/TROUPEAU*
Après avoir créé une table, je n'ai pas pu faire un DROP TABLE. Une analyse de knldiag et
knldiag.err montrait un problème sur le fichier <indep_data>/config/Registry1.dcom. Il a fallu
modifier les droits d'accès sur ce fichier puis lancer un LOAD_SYSTAB pour que tout rentre
dans l'ordre.
remarque:Il faut le load_systab après toute mise à jour:
dbmcli -d database -u dbm,dbmpasswd dbmcli on database> load_systab -u dba,dbapasswd -ud domainpasswd