Commandes mount et unmount - ASE 12.5.1

1- Introduction
2- Généralités
3- Cas pratique 1 : déplacement de devices d’une base de données par démontage
- 3-1- Contexte du cas pratique
- 3-2- Etapes
4- Cas pratique 2 : copie de bases de données vers un nouveau serveur
- 4-1- Contexte du cas pratique
- 4-2- Étapes
Annexe
- Historique
- Liens

1- Introduction

Les nouvelles commandes mount et umount avec Sybase 12.5.1 facilitent le déplacement ou la copie de bases de données. Il est désormais possible de déplacer ou copier une ou plusieurs bases de données d’un serveur ASE vers un autre serveur ASE sans avoir à redémarrer chacun des deux serveurs.

Ces commandes s’avérent très intéressantes pour déplacer physiquement des devices d’une base de données ou encore copier une ou des bases de données vers un nouveau serveur ASE sans utiliser les commandes dump/load.

Cette note technique s’attarde sur deux cas pratiques :

le déplacement de devices pour une base de données appelée testmountdb avec démontage, remontage
la copie de deux bases de données pubs2 et victimdb vers un nouveau serveur ASE

2- Généralités

2-1- Démontage d’une base de données : commande unmount

La commande unmount permet de démonter une ou plusieurs bases de données. Avec la commande unmount la base de données et ses devices sont supprimés du serveur ASE, ce qui revient à dire que les devices et la base de données démontée sont supprimés des tables systèmes sysdevices et sysdatabases du serveur ASE.

unmount database <dbname list> to <manifest_file>

La base de données et ses pages de données ne sont pas altérées au cours du démontage.

Un fichier manifest lors du démontage d’une base de données est créé, ce dernier est un fichier binaire qui décrit les devices servant de support aux bases de données démontées. Le fichier manifest ne peut être créé que si les bases de données qui occupent les devices sont isolées : en d’autres termes, les devices doivent être exclusivement occupés par la ou les bases de données démontées.

! Le fichier manifest peut être corrompu si ce dernier est transféré en mode non binaire par ftp.

2-2- Copie d’une base de données : quiesce database

En vue de copier une base de données, il faut mettre la base de données en sommeil pour stopper les transactions en cours et générer le fichier manifest. La commande quiesce database permet de réaliser ces opérations :

quiesce database < tag_name > hold < dbname list > [for external dump] [ to <manifest_file> [with override]]

Ainsi les transactions dans la base de données à copier sont stoppées et le fichier manifest est créé.

La commande quiesce database ne peut être réalisée si le mirroring est actif sur le serveur ASE (sp_configure 'disable disk mirroring',1), ce paramètre est statique et ASE doit être redémarré.

La commande mount avec l’option listonly permet de lire explicitement le contenu du fichier manifest créé ainsi que la liste des devices qui devront être copiés :

mount database all from ″manifest_file″ with listonly

Dès lors la copie des devices et du fichier manifest peut être réalisée vers le serveur de destination en vue du montage (mode binaire impératif si l’utilitaire ftp est utilisé pour le déplacement des devices)

Une fois la copie réalisée, la base de données sur le serveur source est rendue disponible pour les transactions avec la commande quiesce database et l’option release :

quiesce database < tag_name > release

2-3- Montage d’une base de données : command mount

La commande mount est utilisée pour monter une ou plusieurs bases de données sur un serveur ASE :

mount database all from <manifest_file>

Le fichier manifest est donné à la commande mount database pour prendre en compte les devices et les bases de données à créer sur le serveur de destination.

Pour connaître la liste des devices contenus dans le fichier manifest (noms logique et chemin) :

mount database all from <manifest_file> with listonly

La liste retournée par la commande mount with listonly a la forme suivante :

'<path_device1>' = '<device_name1>'
'<path_device2>' = '<device_name2>'
...

Exemple :

'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_01.dat'='testmountdb_data_01'
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_02.dat'='testmountdb_data_02'
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_log_01.dat'='testmountdb_log_01'

Il est possible de spécifier des chemins différents pour les devices lors du montage d’une base de données avec la commande mount en utilisant l’option using :

mount database all from <manifest_file> 
[ using
″<new_device_path1>″=″<device_name1>″ [, ″<new_device_path2>″=″<device_name2>″ ]]

A l’issue d’une commande mount, la base de données est mise offline comme lors de la fin d’une commande load database : utiliser alors la commande online database

online database <db_name>

Restrictions :

Il est impossible de monter une partie des bases de données décrites dans un fichier manifest. Toutes les bases de données décrites dans un fichier manifest doivent être montées en même temps ;
La taille des pages de données doit être la même entre le serveur ASE source et le serveur ASE de destination ;
Il doit y avoir assez de devices configuré sur le serveur ASE de destination (sp_configure ‘number of devices’) lors du montage ;
Les bases de données et devices ne doivent pas déjà exister sur le serveur ASE de destination ;
La version des serveurs ASE source et de destination doit être la même ;
La plateforme des serveurs ASE doit être la même ;

2-4- Considérations générales

2-4-1- Restrictions

Les bases de données système ne peuvent être démontées, toutefois le démontage de la base sybsystemprocs est autorisée ;
Les bases de données proxy ne peuvent être démontées ;
Les commandes mount et umount ne peuvent être utilisées au sein d’une transaction ;
la commande mount n’est pas autorisée dans un serveur configuré avec du HA (High Availability).

2-4-2- Performances

Un changement de la valeur dbid lors du montage d’une base de données a des conséquences sur les procédures stockées qui sont alors marquées comme devant être recompilées. Ceci affecte le temps de recovery de la base de données sur la destination et la première exécution des procédures stockées.

! il est impératif de s’assurer que les applications n’utilisent pas la fonction db_id et ne stockent pas cette information dans des tables applicatives car il n’est pas certain qu’une base nouvelle montée sur un serveur ASE ait le même identifiant de base de données.

3- Cas pratique 1 : déplacement de devices d’une base de données par démontage

3-1- Contexte du cas pratique

La base de données testmountdb repose sur trois devices : 2 pour les données et 1 pour le journal de transactions.

sp_helpdb testmountdb
-----------------------------------------
testmountdb_data_01 50.0 MB data only 
testmountdb_log_01 10.0 MB log only 
testmountdb_data_02 10.0 MB data onl

Tous les devices sur lesquels repose la base de données testmountdb sont localisés dans le répertoire /sdata/sybase/v12.5.1/CGC_T1_ASE/devices.

sp_helpdevice testmountdb_data_01
------------------------------------------------------------------
/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_01.dat
special, dsync on, physical disk, 50.00 MB 


sp_helpdevice testmountdb_data_02
-----------------------------------------------------------------
/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_02.dat
special, dsync on, physical disk, 10.00 MB 


sp_helpdevice testmountdb_log_01
-----------------------------------------------------------------
/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_log_01.dat
special, dsync on, physical disk, 10.00 MB

L’utilisation des commandes unmount et mount va consister à déplacer et renommer physiquement les devices testmount_data_01, testmount_data_02 et testmount_log_01 dans le répertoire /sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user.


testmount_data_01 .../devices/ testmount_data_01.dat	=>	testmount_data_01 .../devices/user/testdb_data_01.dat
testmount_data_02 .../devices/ testmount_data_02.dat	=>	testmount_data_02 .../devices/user/testdb_data_02.dat
testmount_log_01 .../devices/ testmount_log_01.dat	=>	testmount_log_01 .../devices/user/testdb_log_01.dat

3-2- Etapes

1- Démontage de la base de données testmountdb

La base de données testmountdb est tout d’abord démontée avec la commande unmount :

unmount database testmountdb to
"/sdata/sybase/v12.5.1/CGC_T1_ASE/manifest.testmountdb" 
go

Le fichier de log du serveur CGC_T1_ASE indique clairement la suppression des devices supportant la base de données testmountdb :

00:00000:00015:2004/05/28 17:09:00.65 kernel Deactivating virtual
device 12, '/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_01.dat'.

00:00000:00015:2004/05/28 17:09:00.65 kernel Deactivating virtual
device 13,'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_02.dat'.

00:00000:00015:2004/05/28 17:09:00.65 kernel Deactivating virtual
device 14,'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_log_01.dat'.

2- Déplacement et renommage des devices

Les devices peuvent être alors déplacés et renommés :


testmount_data_01 .../devices/testmount_data_01.dat	=>	testmount_data_01 .../devices/user/testdb_data_01.dat
testmount_data_02 .../devices/testmount_data_02.dat	=>	testmount_data_02 .../devices/user/testdb_data_02.dat
testmount_log_01 .../devices/testmount_log_01.dat	=>	testmount_log_01 .../devices/user/testdb_log_01.dat

3- Montage de la base de données testmountdb

La commande ‘’mount with listonly’’ est utilisée pour lire et vérifier les informations dans le fichier manifest manifest.testmountdb créé lors du démontage de la base de données testmountdb :

mount database all from
"/sdata/sybase/v12.5.1/CGC_T1_ASE/manifest.testmountdb" with listonly
go

'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_01.dat'='testmountdb_data_01'
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_data_02.dat'='testmountdb_data_02'
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/testmountdb_log_01.dat'='testmountdb_log_01'

Compte tenu du déplacement et du renommage des devices physiques, la base de données testmountdb est remontée avec la commande mount en spécifiant les nouveaux chemins pour les devices

mount database all from
"/sdata/sybase/v12.5.1/CGC_T1_ASE/manifest.testmountdb"
using
"/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/testdb_data_01.dat"="testmountdb_data_01",
"/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/testdb_data_02.dat"="testmountdb_data_02",
"/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/testdb_log_01.dat"="testmountdb_log_01"

Started estimating recovery log boundaries for database 'testmountdb'. 
Completed estimating recovery log boundaries for database 'testmountdb'. 
Started ANALYSIS pass for database 'testmountdb'. 
Completed ANALYSIS pass for database 'testmountdb'. 
Started REDO pass for database 'testmountdb'. The total number of log records to process is 1. 
Completed REDO pass for database 'testmountdb'. 
Recovery of database 'testmountdb' will undo incomplete nested top actions.
Started recovery checkpoint for database 'testmountdb'. 
Completed recovery checkpoint for database 'testmountdb'. 
Started filling free space info for database 'testmountdb'. 
Completed filling free space info for database 'testmountdb'. 
Started cleaning up the default data cache for database 'testmountdb'. 
Completed cleaning up the default data cache for database 'testmountdb'. 
MOUNT DATABASE: Completed recovery of mounted database 'testmountdb'.

Le fichier de log montre l’activation des trois devices :

00:00000:00019:2004/05/28 18:52:56.36 kernel Initializing virtual device 12, 
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/testdb_data_01.dat' with dsync 'on'.
00:00000:00019:2004/05/28 18:52:56.36 kernel Virtual device 12 started using asynchronous i/o.
00:00000:00019:2004/05/28 18:52:56.36 kernel Initializing virtualdevice 13,
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/testdb_data_02.dat' with dsync 'on'.
00:00000:00019:2004/05/28 18:52:56.36 kernel Virtual device 13 started using asynchronous i/o.
00:00000:00019:2004/05/28 18:52:56.36 kernel Initializing virtual device 14,
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/testdb_log_01.dat' with dsync 'on'.
00:00000:00019:2004/05/28 18:52:56.36 kernel Virtual device 14 started using asynchronous i/o.

La base testmountdb est ensuite mise en ligne :

online database testmountdb

4- Cas pratique 2 : copie de bases de données vers un nouveau serveur

4-1- Contexte du cas pratique

Dans ce cas pratique, on se propose de copier les bases de données utilisateurs pubs2 et victimdb du serveur CGC_T1_ASE vers le serveur CGC_T2_ASE.

La base de données pubs2 repose sur deux devices : 1 pour les données et 1 pour le journal de transactions.

sp_helpdb pubs2
------------------------------------
pubs2_data_01 50.0 MB data only 
pubs2_log_01 10.0 MB log only

La base de données victimdb repose sur deux devices : 1 pour les données et 1 pour le journal de transactions.

sp_helpdb victimdb
-----------------------------------
victimdb_data_01 50.0 MB data only 
victimdb_log_01 10.0 MB log only

Tous les devices sur lesquels reposent les bases de données pubs2 et victimdb sont localisés dans le répertoire /sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user.

sp_helpdevice pubs2_data_01 
-----------------------------------------------------------------------
/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/pubs2_data_01.dat
special, dsync on, physical disk, 50.00 MB 

sp_helpdevice pubs2_log_01
----------------------------------------------------------------------
/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/pubs2_log_01.dat
special, dsync on, physical disk, 50.00 MB

sp_helpdevice victimdb_data_01 
---------------------------------------------------------------------
/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/victimdb_data_01.dat
special, dsync on, physical disk, 10.00 MB

sp_helpdevice victimdb_log_01 
--------------------------------------------------------------------
/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/victimdb_log_01.dat
special, dsync on, physical disk, 10.00 MB

L’utilisation des commandes quiesce et mount va permettre de copier en toute sureté les devices pubs2_data_01, pubs2_log_01, victimdb_data_01 et victimdb_log_01 dans le répertoire /sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user en vue de monter les bases de données pubs2 et victimdb sur le serveur CGC_T2_ASE.


pubs2_data_01 .../CGC_T1_MYS/devices/user/pubs2_data_01.dat	=>	pubs2_data_01 .../CGC_T2_MYS/devices/user/pubs2_data_01.dat
pubs2_log_01 .../CGC_T1_MYS/devices/user/pubs2_log_01.dat	=>	pubs2_log_01 .../CGC_T2_MYS/devices/user/pubs2_log_01.dat
victimdb_data_01 .../CGC_T1_MYS/devices/user/victimdb_data_01.dat	=>	victimdb_data_01 .../CGC_T2_MYS/devices/user/victimdb_data_01.dat
victimdb_log_01 .../CGC_T1_MYS/devices/user/victimdb_log_01.dat	=>	victimdb_log_01 .../CGC_T2_MYS/devices/user/victimdb_log_01.dat

4-2- Étapes

1- Mise en mode silencieux des bases pubs2 et victimdb et génération du fichier manifest

Afin de copier en toute sécurité les devices des bases de données pubs2 et victimdb, il est nécessaire de mettre en mode silencieux les bases de données pubs2 et victimdb sur le serveur source CGC_T1_ASE afin de garantir aucune activité transactionnelle sur ces bases pendant la copie. Par ailleurs, en même temps que les bases pubs2 et victimdb sont mises en mode silencieux, un fichier manifest sera créé en vue du montage de ces devices sur le serveur CGC_T2_ASE.

La commande quiesce database est mise en œuvre pour ces deux opérations (mise en mode silencieux, génération du fichier manifest) :

quiesce database pubs2victimdb_tag hold pubs2,victimdb for external
dump to ″/sdata/sybase/v12.5.1/pubs2victimdb.manifest″

Le fichier de log du serveur CGC_T1_ASE montre la mise en mode silencieux et la création du fichier manifest :

00:00000:00016:2004/05/28 18:23:35.33 server QUIESCE DATABASE command with
tag pubs2victimdb_tag is being executed by process 16.
00:00000:00015:2004/05/28 18:23:35.45 server QUIESCE DATABASE HOLD for tagname 'pubs2victimdb_tag' 
has suspended processes trying to issue writes in the affected databases, and is creating the manifest file.
00:00000:00015:2004/05/28 18:23:35.58 server QUIESCE DATABASE HOLD for tagname 'pubs2victimdb_tag' 
has suspended writes and created the manifestfile. 
Writes will remain suspended until user executes QUIESCE DATABASERELEASE.

La commande "mount with listonly" permet de vérifier le contenu du fichier manifest créé :

mount database all from
″/sdata/sybase/v12.5.1/manifest.pubs2victimdb″ with listonly

'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/victimdb_data_01.dat' = 'victimdb_data_01'
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/victimdb_log_01.dat' = 'victimdb_log_01' 
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/pubs2_data_01.dat' = 'pubs2_data_01'
'/sdata/sybase/v12.5.1/CGC_T1_ASE/devices/user/pubs2_log_01.dat' = 'pubs2_log_01'

2- Copie des devices et suppression du mode silencieux

Les devices concernés sont alors copiés dans l’architecture du serveur CGC_T2_ASE (mode binaire dans le contexte d’un transfert ftp) et à l’issue de la copie le mode silencieux est supprimé pour les bases pubs2 et victimdb sur le serveur source CGC_T1_ASE avec la commande quiesce database.

quiesce database pubs2victimdb_tag release

00:00000:00016:2004/05/28 20:38:57.23 server Process 16 successfully
executed QUIESCE DATABASE with RELEASE option for tag pubs2victimdb_tag.

3- Montage des bases de données pubs2 et victimdb sur le serveur CGC_T2_ASE

La commande mount est alors utilisée pour monter les bases de données pubs2 et victimdb sur le serveur source CGC_T2_ASE. Les options using sont utilisées avec la commande mount pour spécifier la nouvelle localisation des devices lors du montage des bases de données puisqu’une modification survient sur les chemins :

mount database all from "/sdata/sybase/v12.5.1/pubs2victimdb.manifest"
using 
"/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/pubs2_data_01.dat"="pubs2_data_01",
"/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/pubs2_log_01.dat"="pubs2_log_01",
"/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/victimdb_data_01.dat"="victimdb_data_01",
"/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/victimdb_log_01.dat"="victimdb_log_01"

Started estimating recovery log boundaries for database 'pubs2'. 
Completed estimating recovery log boundaries for database 'pubs2'. 
Database 'pubs2' is in QUIESCE DATABASE state. It will recovered as for
LOAD DATABASE and left off line. 
Started ANALYSIS pass for database 'pubs2'. 
Completed ANALYSIS pass for database 'pubs2'. 
Started REDO pass for database 'pubs2'. The total number of log records
to process is 1. 
Completed REDO pass for database 'pubs2'. 
MOUNT DATABASE: Completed recovery of mounted database 'pubs2'. 
Started estimating recovery log boundaries for database 'victimdb'. 
Completed estimating recovery log boundaries for database 'victimdb'. 
Database 'victimdb' is in QUIESCE DATABASE state. It will recovered as
for LOAD DATABASE and left off line. 
Started ANALYSIS pass for database 'victimdb'. 
Completed ANALYSIS pass for database 'victimdb'. 
Started REDO pass for database 'victimdb'. The total number of log
records to process is 1. 
Completed REDO pass for database 'victimdb'. 
MOUNT DATABASE: Completed recovery of mounted database 'victimdb'.

Le fichier de log montre l’activation des quatres devices sur le serveur CGC_T2_ASE :

00:00000:00017:2004/05/28 18:49:56.60 kernel Initializing virtual device 4,
'/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/victimdb_data_01.dat' with dsync 'on'.
00:00000:00017:2004/05/28 18:49:56.75 kernel Virtual device 4 started using asynchronous i/o.
00:00000:00017:2004/05/28 18:49:56.78 kernel Initializing virtual device 5,
'/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/victimdb_log_01.dat' with dsync 'on'.
00:00000:00017:2004/05/28 18:49:56.78 kernel Virtual device 5 started using asynchronous i/o.
00:00000:00017:2004/05/28 18:49:56.79 kernel Initializing virtual device 6,
'/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/pubs2_data_01.dat' with dsync 'on'.
00:00000:00017:2004/05/28 18:49:56.79 kernel Virtual device 6 started using asynchronous i/o.
00:00000:00017:2004/05/28 18:49:56.80 kernel Initializing virtual device 7,
'/sdata/sybase/v12.5.1/CGC_T2_ASE/devices/user/pubs2_log_01.dat' with dsync 'on'.
00:00000:00017:2004/05/28 18:49:56.80 kernel Virtual device 7 started using asynchronous i/o.

Les bases de données pubs2 et victimdb sont ensuite mises en ligne sur le serveur CGC_T2_ASE :

online database pubs2
online database victimdb

Annexe

Historique

Version	Date	Commentaires
1.0	05/2004	Version initiale

Liens

Sybase Adaptive Server Enterprise 12.5.1 Books OnLine - New Functionality in Adaptive Server 12.5.1, Database mount and unmount
Sybase Adaptive Server Enterprise 12.5.1 Books OnLine - System Administration Guide, Database mount and unmount