Sybase ASE, sauvegardes et restaurations (dump / load)

Logo

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.

Procédure de sauvegarde restauration d’une base Sybase ASE

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
use master
go
select srvname, srvnetname 
from sysservers
where srvname='SYB_BACKUP'
go

srvname     srvnetname
----------  -------------
SYB_BACKUP  BOR_U1_BCK
$SYBASE/interfaces
...
BOR_U1_BCK
        master tli tcp FRDBOR302 30020
        query tli tcp FRDBOR302 30020
...

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_BCK

Ce 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.

Service externe Sybase backupserver

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 commande dump et ajoutées durant l’opération de sauvegarde. La sauvegarde est donc bien réalisée à chaud et reste cohérente.
Étapes dans la sauvegarde d’une base ASE

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
create database src 
on     d_src_1=10 
log on l_src_1=5
go
-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3       10 /tmp/d_src_1.dat 
4        5 /tmp/l_src_1.dat 
dump database src ...
create database dst 
on     d_dst_1=10 
log on l_dst_1=5
go
-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3       10 /tmp/d_dst_1.dat 
4        5 /tmp/l_dst_1.dat 
load database dst ...
-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3       10 /tmp/d_dst_1.dat 
4        5 /tmp/l_dst_1.dat 

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
create database src 
on     d_src_1=7, 
       d_src_2=3
log on l_src_1=5
go
-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3        7 /tmp/d_src_1.dat 
3        3 /tmp/d_src_2.dat 
4        5 /tmp/l_src_1.dat 

dump database src ...
create database dst 
on     d_dst_1=10 
log on l_dst_1=5
go

-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3       10 /tmp/d_dst_1.dat 
4        5 /tmp/l_dst_1.dat 


load database dst ...
-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3       10 /tmp/d_dst_1.dat 
4        5 /tmp/l_dst_1.dat 

L’allocation initiale a été conservée, et les segments contigus fusionnés.

Taille différente

Source Cible
create database src 
on     d_src_1=7, 
       d_src_2=3
log on l_src_1=5
go
-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3        7 /tmp/d_src_1.dat 
3        3 /tmp/d_src_2.dat 
4        5 /tmp/l_src_1.dat 

dump database src ...
create database dst 
on     d_dst_1=7 
log on l_dst_1=5
go

-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3       7 /tmp/d_dst_1.dat 
4       5 /tmp/l_dst_1.dat 


load database dst ...
Msg 3105, Level 16, State 1
Server 'DAS_U1_ASE', Line 1
Data on dump will not fit into current database. 
Need 15 Mbyte database.
alter database dst on d_dst_1=3
-- select sysusages ...
segmap  Mb phyname
------- -- -----------------
3        7 /tmp/d_dst_1.dat 
4        5 /tmp/l_dst_1.dat 
3        3 /tmp/d_dst_1.dat 
load database dst ...
Caution:  You have set up this database to 
 include space on disk 14 
 for both data and the transaction log
 This can make recovery impossible 
 if that disk fails.
Caution:  You have set up this database to 
 include space on disk 15 
 for both data and the transaction log.
 This can make recovery impossible 
 if that disk fails.
-- select sysusages ...
segmap  Mb phyname   
------- -- -----------------
3       7 /tmp/d_dst_1.dat  
3       3 /tmp/l_dst_1.dat  
4       2 /tmp/l_dst_1.dat  
4       3 /tmp/d_dst_1.dat 

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.

Structures cible et source Sybase ASE pour une sauvegarde/restauration

À 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'
go

Notons 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.

Sauvegarde avancée d’une base Sybase ASE avec les journaux

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

Restauration complète d’une base Sybase ASE

On se retrouve alors à la situation correspondant au moment de sauvegarde

Cas 2 : restauration complète de la base, puis complète du journal

Restauration complète d’une base Sybase ASE avec les journaux de transactions

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.

Restauration partielle d’une base Sybase ASE avec les journaux de transactions

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
dump database src 
to '/tmp/src.dmp'
with passwd='Mot!dePasse'
go.
load database dst 
from '/tmp/src.dmp'
go
Msg 3025, Level 16, State 4
Server 'DAS_U1_ASE', Line 1
Dump is password-protected,
 a valid password is required.
load database dst 
from '/tmp/src.dmp'
with passwd='Mot!dePasse'
go

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
dump database src 
to '/tmp/src.dmp'
with compression=1
go
load database dst 
from '/tmp/src.dmp'
go

online database dst
go

À 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
dump database src 
to '/tmp/src.dmp.1'
stripe on '/tmp/src.dmp.2'
stripe on '/tmp/src.dmp.3'
stripe on '/tmp/src.dmp.4'
go
load database src 
from '/tmp/src.dmp.1'
stripe on '/tmp/src.dmp.2'
stripe on '/tmp/src.dmp.3'
stripe on '/tmp/src.dmp.4'
go

online database dst
go

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
go

L’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
go

L’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
go

L’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