Créer la base

S'outiller

L'outil en ligne de commande natif de sapdb ne fait pas de complétion, pas d'historique ni de navigation: la grosse galère...

Mais il existe des parades: voici ce que j'ai obtenu sur la ML: uniread, un petit programme qui émule la libreadline et qui permet de naviguer dans un prompt mais également de garder un historique des commandes.
J'ai mis ça en place, c'est fabuleux, il n'y a plus qu'à définir un alias:
alias dbmcli='uniread dbmcli'

Et on fait pareil pour loadercli et autres clients (voir 4 pour une description des clients que j'ai pu utiliser) qui agissent de la même manière.

Bien sur, j'utilise ireport (voir 4), et il est possible d'y activer une historisation, donc rendez-vous section 4 sur mes infos relatives à ireport.py

Remarque:Le module Python est dans le profil Interfaces de l'installeur.

Préparation et création

L'installation a créé un user sdb et un groupe sdba pour les fichiers de MaxDB.

Le mieux est donc d'avoir un user (soi même ?) qui se trouve dans le groupe sdba pour posséder des droits sur les opérations d'administration physiques:

adduser jm sdba

jm c'est mon login.

On a mis /usr/local/sapdb/indep_prog/bin dans le PATH de l'user affilié au groupe sdba. Celui-ci va démarrer le serveur:

x_server -Y start

Le -Y est là pour empêcher le démarrage de niserver, qui ne sert qu'aux communications pour les services SAP et leurs clients. Pas la peine d'ouvrir un port pour rien.

D'abord il faut créer la base (l'instance de base) avec dbmcli:
On crée ainsi le premier dbm qui possède "all user authorizations"
Voir la doc:

• The SAP DB Database System
  • User Concept
    • SAP DB User Class
      • Database Manager Operator

On peut utiliser des outils graphiques (le DBM GUI mais pas sous Linux, uniquement avec W$) ainsi qu'un outil qui fonctionne à partir d'un serveur Web Apache ou bien un serveur fourni par Sapdb (le Webdbm, voir 4 Web Tools). Mais vu que ce n'est pas mon truc, on va s'en tenir à dbmcli...

Puis:

dbmcli -s db_create mails nom_dbm,passwd_dbm

La syntaxe est pour un accès local. Le nom de l'instance est donc "mails" (pas plus de 8 caractères, je me suis fait avoir). Il est important de ne pas mettre d'espace entre virgule et mot de passe, sinon ça donne une erreur (authorization failed).

MaxDB convertit tous les noms en majuscules. Donc, pour le serveur, mail, Mails et MAILS c'est du pareil au même.

Créer ensuite le dossier qui contient la base:

mkdir -p /home/databases/mails

Quelques commandes

On peut d'ores et déjà essayer:

• dbmcli -d archi -u dbm,dbm_passwd db_drop pour détruire une création d'instance;
• dbmcli -d mails -u dbm,dbm_passwd db_state pour connaître le statut de la base;
• dbmcli db_enum pour connaître les instances disponibles.

Création physique et paramétrage

On va maintenant créer la base physiquement. Il est possible de mettre les commandes dans un fichier qu'on appelle ensuite avec:

dbmcli -d nom_base -u nom_dbm,passwd_dbm -i fichier

Voir 4 pour la syntaxe de dbmcli.

Un autre exemple de script de création d'instance, qui fait appel à des appels un peu différents de dbmcli se trouve dans <depend>/misc: create_demo_db.sh

La suite de ce document constitue le fichier lui-même.

L'user qui lance la création physique de la base doit avoir les droits en écriture dans le dossier physique. Donc j'ai mis /home/databases en sdb:sdba avec les permissions 770

# dbmcli n'aime pas les accents
# supprimer un ancien parametrage, utile si plantage de l'instanciation
param_rmfile
# D'abord ouvrir une session de paramétrage:
param_startsession
# puis donner a l'instance les parametres par défaut
# on ouvre une instance de type OLTP
param_init OLTP
# puis donner ses propres parametres:
param_put MAXUSERTASKS 5
param_put MAXDATAVOLUMES 1
param_put MAXLOGVOLUMES 1
param_put CACHE_SIZE 4000
# verification de ce qu'on a demande
param_checkall
# envoyer les parametres
param_commitsession
# definir les volumes (F pour File) en nb de pages
# syntaxe: commande n°_volume type_volume path type_volume taille_pages
# type_volume peut-etre MLOG pour mirrored volume
param_addvolume 1 DATA /home/databases/mails/data_001 F 2560
param_addvolume 1 LOG /home/databases/mails/log_001 F 1024
# definir une valeur personnalisee de LOG_SEGMENT_SIZE
# on le fait apres la definition du log volume, sinon le serveur n'est pas content...
param_startsession
param_put LOG_SEGMENT_SIZE 150
param_checkall
param_commitsession
# demarrer la base, elle passe en mode admin
db_start
# lancer une session de service
util_connect nom_dbm,passwd_dbm
# on cree le premier dba
db_activate nom_dba,passwd_dba
# quitter la session de service
util_release
# puis on charge les tables systemes. Il faut donner le passwd de l'user DOMAIN
# si il est inconnu, donc on le cree
load_systab -u dba,dba_passwd -ud domain_passwd

Normalement à ce stade la base est créée, avec les fichiers là où on les a demandés, ainsi qu'un dossier dans /usr/local/indep_data/wrk/nom_base avec nom_base en majuscules. La base est dans un état online. La commande s'est terminée avec un:

0,OK: everything works fine
Installation successfully finished

Remarque: Je n'ai pas expérimenté moi-même (par chance), mais, sur certaines distributions, il est nécessaire que l'utilisateur qui démarre le serveur aie positionné la variable d'environnement LD_ASSUME_KERNEL=2.2.5, dans son .bashrc par exemple, ou dans le script de lancement. L'erreur pourrait alors se manifester par un:

24994 runtime environment error [db_online -s] check knldiag,
kernel died before reaching admin state

Récupérer et Modifier les paramètres

dbmcli -d mails -u dbm,passwd_dbm
dbmcli>param_getvalue PARAMETRE
dbmcli>param_startsession # débuter une session de paramétrage
dbmcli>param_put PARAMETRE valeur
dbmcli>param_checkall # vérification
dbmcli>param_commitsession # valider

Utilisateurs

On crée un user avec la commande CREATE USER:

dbmcli -d base -u dba,dba_passwd
dbmcli> sql_connect dba,dba_passwd
dbmcli> sql_execute CREATE USER jm password jm_passwd NOT EXCLUSIVE

not exclusive signifie qu'il est possible d'ouvrir plusieurs instances de base à la fois. Et tant qu'on est connecté on peut vérifier qu'on est bien là:

dbmcli> sql_connect jm,jm_passwd
dbmcli> quit

Sinon, on se déloge avec quit, on se reloge en tant que dbm, et on se connecte en tant que user avec sql_connect

On donne des droits à un nouvel utilisateur (ATTENTION: Il devra exister, donc il devra avoir été créé par le dba. La procédure n'est pas identique à celle de MySQL) avec l'instruction GRANT. Dans l'exemple suivant on va donner des droits de SELECT à l'user INVITE qui vient d'être créé, sur la table COURRIEL.

dbmcli> sql_connect jm,jm_passwd
dbmcli> sql_execute GRANT SELECT ON COURRIEL TO INVITE
dbmcli> quit

Ce sont là les premiers exemples d'utilisation de dbmcli pour des requêtes SQL. En fait cet outil n'est pas vraiment fait pour ça, plutôt pour de l'administration. Pour des requêtes SQL importantes on préfèrera loadercli qui est l'outil de chargement et d'extraction de masse. Pour des requêtes sql il y a sqlcli ou ireport.py

Informations sur l'instance

Voici quelques commandes dbmcli qui peuvent servir. On va supposer qu'on s'est logé sous dbmcli, mais la commande peut-être envoyée par dbmcli commande

help cmd                   # pour obtenir la syntaxe et options de cmd
info infos                 # toutes les sections d'info possible et, à partir de là, par exemple...
info LOG
info DATA
db_online                  # instance opérationnelle
db_admin                   # passage en admin mode, donc pas de requêtes sql possibles
db_offline                 # arrêt de l'instance
param_getvalue parametre   # obtenir la valeur d'un parametre