Introduction
Il existe plusieurs méthodes pour garantir l’intégrité des données d’une base Sybase Adaptive Server Enterprise (ASE).
Les devices d’une base de données Sybase ASE peuvent être sécurisés avec la mise en place de miroir. L’avantage est de limiter l’impact d’une panne liée au support de stockage, l’inconvénient est qu’il n’est alors pas possible de revenir dans un état antérieur ni même de procéder à une copie de base.
Une deuxième approche possible consiste à sauvegarder ces mêmes devices par
copie physique des devices en mode 'quiesce database' (Montage et
démontage de bases de données avec ASE 12.5.1). On a alors une image
complète et cohérente de la base, au détriment d’une dégradation du service, la
base n’étant alors disponible qu’en lecture seule lors de la copie.
La sauvegarde avec la commande dump permet une sécurisation des
données à chaud sans interruption de service. Ce document présente la
sauvegarde et la restauration d’une base Sybase ASE, explique les concepts,
l’implémentation technique, ainsi que quelques fonctionnalités spécifiques.
Présentation
La base de données
L’unité de sauvegarde des données hébergées dans une instance Sybase ASE est la base de données. Toute implémentation d’une stratégie de sécurisation de l’information doit donc traiter chacune d’entre-elle unitairement.
La commande dump est exécutée sur une instance en activité et
construit, sans interruption de service, une image complète et cohérente d’une
base. Ce sont les pages de données qui sont sauvegardées. Il n’y a donc, dans
l’image générée, aucune notion logique (donnée, structure, index, procédure,
…), ni même physique (la notion de 'device' n’est pas
enregistrée).
Le journal de transactions
Une base, au sens Sybase ASE, est organisée en deux espaces distincts : les
données (data) et le journal (log). Le premier stocke les données proprement
dites, le second représente, toutes les modifications (transactions) de ces
données. Le contenu du log est périodiquement appliqué dans
l’espace data puis vidé.
Dans le log, la purge des transactions terminées et validées
(commit) peut être automatique grâce à l’option trunc log on
checkpoint, ou implicite via une sauvegarde du journal qui peut être
régulière ou déclenchée sur seuil de remplissage (threshold).
Une sauvegarde régulière du journal permet donc de pouvoir journaliser toute l’activité transactionnelle d’une base et ainsi potentiellement retrouver un état antérieur à une date et heure précise précise.
Le support de sauvegarde
La commande dump prend en charge la sauvegarde sur fichier(s)
et/ou sur bande(s) de façon transparente pour l’utilisateur. Une grande
majorité de paramètres de cette commande est d’ailleurs liée à la gestion des
bandes (rewind, erase, mount, retaindays, blocksize…).
La présente note va simplement évoquer la sauvegarde sur systèmes de fichiers (File Systems).
Implémentation technique
La sauvegarde / restauration Hello world
La représentation suivante montre une procédure de sauvegarde-restauration d’une base.
Il est difficile de faire plus simple : l’instruction dump est
exécutée dans une session sql, n’utilisant comme paramètre qu’un nom de base et
un nom de fichier. Durant l’opération de sauvegarde (dump), la
base est totalement disponible en lecture/écriture.
L’instruction de restauration est tout aussi aisée. À noter dans ce dernier
cas une instruction supplémentaire online qui indique la fin de
l’opération de restauration. Durant l’opération de chargement
(load), et tant que l’instruction online n’est pas
exécutée, la base n’est pas accessible.
Implémentation technique
Les opérations d’interaction entre l’instance Sybase ASE (devices) et le système (fichiers, bandes, OS…) sont délégués à un service externe appelé backupserver. Ce service est identifié au sein de l’instance Sybase ASE par le nom logique SYB_BACKUP dans la table système sysservers et ses caractéristiques (adresse IP, port…) décrites dans le fichier interfaces (Unix) ou sql.ini (Windows).
| sysservers | Fichier Interfaces |
|---|---|
|
$SYBASE/interfaces |
Pour ajouter le serveur logique SYB_BACKUP si il est inexistant, utiliser la procédure système sp_addserver :
exec sp_addserver SYB_BACKUP, ASEnterprise, BOR_U1_BCKCe processus backupserver doit être actif au moment de la sauvegarde et son activation n’est pas gérée par le serveur Sybase ASE. Le service backupserver est démarré de la façon suivante :
# Démarrage du service Backup Server BOR_U1_BCK
DSQUERY=BOR_U1_BCK
SYBASE=/Software/sybase/sybase-15.0
. $SYBASE/SYBASE.sh
exec $SYBASE/$SYBASE_ASE/bin/backupserver \
-S$DSQUERY \
-e/log/$DSQUERY.log \
-M$SYBASE/$SYBASE_ASE/bin/sybmultbuf \
-N25 -C20 &Cas particulier sur Unix, au moment de la sauvegarde, le process backupserver va 'forker' 2 autres programmes (par stripe) nommés sybmultbuf, un pour la gestion de l’archive, au autre pour la lecture de la base.
Comment ça marche ?
La sauvegarde est réalisée en 3 étapes :
- Étape 1 (
DBPages) : copie des pages de données allouées (data), plus les pages de log si les segments data et log sont mixés dans un ou plusieurs devices. - Étape 2 (
Flushpages) : copies des pages modifiées pendant l’étape 1 pour les transactions non journalisées ou non loguées dans le jargon courant (truncate table, select into, fast bcp…). - Étape 3 (
ScanlogPages) : copie des pages du journal allouées au démarrage de la commandedumpet ajoutées durant l’opération de sauvegarde. La sauvegarde est donc bien réalisée à chaud et reste cohérente.
Taille des bases et segments
Les informations de configuration physiques - la nature des devices (Raw device, FS), leur nombre et leur localisation - ne sont pas transportées durant le dump. Pour une raison toute simple : ces informations sont dans la base master.
Cela apporte une grande souplesse pour la restauration, l’environnement cible peut ainsi avoir différentes caractéristiques physiques que sa source ( Raw=>FS, localisation des devices…), mais suppose quelques contraintes.
La première est que la base à restaurer doit exister, avec une taille - au moins - égale à la base source.
La seconde est que l’allocation d’espace - en particulier la déclaration data/log, doit être réalisée de manière cohérente dans les deux environnements. En effet, lors du chargement, ASE va manipuler les segments, les allouer et/ou les fusionner, de manière automatique. Voici quelques cas:
Comme toute la logique ASE consiste lors d’un rechargement à manipuler des allocations de segments, la requête suivante est exécutée sur chacune des deux bases, avant et après le rechargement, pour illustrer l’interprétation réalisée :
-- select sysusages ...
select segmap,
size/512,phyname
from sysusages u
join sysdevices d on d.vdevno=u.vdevno
where dbid=db_id('dst')Le contenu de la colonne segmap s’interprète comme suit :
- 3 : Data
- 4 : Log
- 7 : Data+Log
Nom de base et devices différents
| Source | Cible |
|---|---|
|
|
Bien que le nom de la base et des devices soient différents, aucun souci ici, la base est montée en respectant l’allocation.
Structure différente
| Source | Cible |
|---|---|
|
|
L’allocation initiale a été conservée, et les segments contigus fusionnés.
Taille différente
| Source | Cible |
|---|---|
|
|
Rien ne va plus, ou plutôt, le résultat n’est pas celui espéré. Certes, la base est chargée et avec la taille souhaitée. Cependant, la séparation physique data/log n’est plus respectée, on retrouve une partie du journal dans un segment de données (data) et une partie des données dans un segment de journal (log).
La structure logique de la base source se retrouve dans la structure
physique de la base cible, ce que montre syssegments.
À noter l’alerte levée par le serveur ASE sur la situation nouvelle.
Plan de sauvegarde avancé : les journaux de transaction
La commande dump génère une image exacte mais figée d’une base.
Il est possible de mettre en place une stratégie de sauvegarde permettant de sécuriser l’ensemble de l’activité transactionnelle de la base, tant pour des raisons pratiques, comme revenir à un état antérieur et précis, quel qu’il soit, mais aussi pour des raisons de performance : réaliser une sauvegarde différentielle est bien moins contraignant qu’une sauvegarde complète.
Sybase ASE permet donc de réaliser une sauvegarde du journal de transaction,
via une syntaxe proche de celle d’un 'dump' de base.
dump transaction src to '/tmp/src.tran'
goNotons qu’il est possible de recharger une sauvegarde de journal totalement bien sûr, mais aussi partiellement, en spécifiant une date par exemple
Voici un cas d’usage simplifié illustrant l’usage. On y réalise une sauvegarde complète, une sauvegarde de journal tout en simulant une activité transactionnelle.
Dans l’exemple ci-dessus, des données sont insérées à 12:00, 14:00, 15:00 et 16:00.
L’option trunc log on checkpoint n’est pas activée pour la base dba !
Cette option vide en effet le journal à intervalles réguliers avec le process interne CHECKPOINT SLEEPER d’un serveur Sybase ASE.
La commande 'dump tran dbname with truncate_only' ne doit pas être exécutée également, celle-ci vide le journal.
Voici quelques cas de restauration possibles :
Cas 1 : restauration complète
On se retrouve alors à la situation correspondant au moment de sauvegarde
Cas 2 : restauration complète de la base, puis complète du journal
On se retrouve alors à la situation correspondant à la dernière sauvegarde du journal.
Cette exemple illustre également l’intérêt de la commande
'online'. Celle-ci n’est exécutée qu’une fois les bases et
journaux chargés.
À noter qu’il n’est pas possible de charger un journal seul. Celui-ci doit toujours être précédé d’une restauration de base complète et éventuellement d’une restauration du ou des journaux de transactions qui le précèdent temporellement.
Cas 3 : restauration complète de la base, puis partielle du journal
On veut revenir à une heure précise, alors on le spécifie au moment du rechargement.
On se retrouve alors à la situation souhaitée, soit 14:00.
Fonctions étendues
Permissions
La sauvegarde peut être protégée par mot de passe.
| Source | Cible |
|---|---|
|
|
Compression
Plus intéressant, la sauvegarde peut être compressée.
Moyennant un surcoût CPU, un taux de compression peut être appliqué lors de la sauvegarde. L’échelle, de 1 à 9, indique le degré de compression , le plus grand taux étant le plus efficace… mais aussi le plus consommateur de ressources CPU. Quelques tests interne ont montré que le taux par défaut (1) était largement satisfaisant sans impact majeur sur les performances:
| Source | Cible |
|---|---|
|
|
À noter que le caractère compressé de la sauvegarde ni même le taux ne sont nécessaires lors de l’opération de restauration.
La version ASE 15.7 ajoute deux nouveaux taux, 100 et 101, moins consommateurs de ressources cpu.
Stripe
Il est possible d’optimiser l’écriture du fichier de sauvegarde en le scindant sur plusieurs fichiers (striping). On peut ainsi solliciter en écriture plusieurs lecteurs de bandes, ou disques.
Dans les anciennes versions unix, le 'striping' était obligatoire pour contourner la limite de taille de fichier de 2 Go .
| Source | Cible |
|---|---|
|
|
Lire l’entête des sauvegardes
Sybase ASE fournit les commandes pour lire l’entête des fichiers de
sauvegarde avec les options with headeronly, with
listonly et with listonly=full de la commande load
database
load database dst from '/tmp/src.dmp' with headeronly
goL’option with headeronly permet de retrouver le nom de la base
source, la date de sauvegarde, le nombre de 'stripes', le chemin de sauvegarde
original de chacun des stripes, la taille de page de l’instance, le nombre de
pages de la base, la répartition des segments.
load database dst from '/tmp/src.dmp' with listonly
goL’option with listonly permet de retrouver le nom de la base
source, la date de sauvegarde, la date d’expiration.
load database dst from '/tmp/src.dmp' with listonly=full
goL’option with listonly=full permet de retrouver le nom de la
base source, la date de sauvegarde, la date d’expiration, le niveau de
compression, le nombre de stripes.
Archive database
Il est possible de consulter le contenu d’une sauvegarde dans une structure créée à cet effet. Intérêt majeur, la structure ( base ) d’accueil ne doit pas être dimensionnée en fonction de la taille de la base mais de celle du journal.
Autrement dit, la sauvegarde d’une base de plusieurs To peut être consultée en ligne, sans écrasement, par l’intermédiaire d’une base de quelques dizaines ou centaines de Mo .
create database scratchdb on dev1='100M'
go
create archive database archivedb on dev1='50M' with scratch_database = scratchdb
go
load database archivedb from '/tmp/src.dmp'
load transaction archivedb from '/tmp/src.tran' with until_time='20111107 14:00:00'
go
online database archivedb
go