Sybase 12.5.3 - Dump/load cross plateforme

Introduction

Sybase Adaptive Server Enterprise 12.5.2 supporte les opérations de dump/load sur des plateformes avec une architecture identique de poids (endian).

Depuis Sybase Adaptive Server Enterprise 12.5.3, les opérations de dump/load cross plateformes sont désormais supportées sur des architectures de poids différentes (endian).

Dans le tableau ci-dessous sont regroupés les différents OS supportés et leurs poids correspondant :

Poids	OS
Big Endian	Sun Solaris IBM AIX Silicon Graphics HP-UX AIX
Little Endian	Linux IA Windows HP True 64 Sun Solaris X86

Cet article revient sur les poids dans les systèmes d’exploitation et donne un exemple de dump/load cross-plateforme en chargeant un dump Sybase fait sous Sun Solaris Sparc ASE 12.5.3 32 bits dans un serveur Sybase ASE 12.5.4 32 bits sous Windows.

Aucune nouveauté n’est introduite dans les commandes dump et load pour du cross plateforme, ASE détecte automatiquement le type d’architecture du système d’exploitation d’origine du fichier de dump et la commande load effectue les conversions nécessaires.

Les chargements cross-plateformes provenant de versions antérieures sont supportés ( ASE 12.0, 11.9)
Les chargements cross-plateformes d’architectures 32 bits vers des plateformes 64 bits et vice-versa sont supportés.

Poids (little Endian, big Endian) et ordres de traitement des octets

Le terme "endian" se rapporte à l’ordre de numérotation des octets d’un type de données (entier, caractères…). Les architectures d’ordinateur divergent dans la façon dont elles numérotent les octets d’un type de données de gauche à droite ou de droite à gauche (un peu comme l’écriture).

Dans le schéma ci-dessous, les architectures 32 bits « Big Endian » et « Little Endian » sont illustrées pour le stockage d’un entier 0XA0B70708 en notation héxadécimale.

Chaque octet équivaut à 8 bits :

dans une architecture Big endian, la numérotation des octets se fait de gauche à droite (ex. : HP, Sun Solaris SPARC). On parle aussi dans ce cas de gros-boutiste (poids fort en tête)
dans une architecture Little endian, la numérotation des octets se fait de droite à gauche (ex. : Intel x86, Pentium). On parle aussi dans ce cas de petit-boutiste (poids faible en tête).

Dump/Loads cross-plateformes avec le même poids (iso-endian)

Lorsque l’on réalise des commandes dump database et load database pour des plateformes ayant la même architecture de poids (little-endian ou big-endian), les données utilisateur et systèmes ne requièrent pas de conversion et il n’y a aucune limitation spécifique.

Les procédures stockées et autres objets compilés sont recompilés à partir du texte SQL dans la table syscomments à la première exécution après la commande load database pour certaines combinaisons de dump/load cross-plateformes iso endian.

Dump/Loads cross-plateformes avec des poids différents (big-endian < > little-endian)

Restrictions sur le l’opération de dump (mode quiesce)

Pour un dump/load cross-plateforme, quelques précautions majeures doivent être observées car il est impératif que la base de données au moment du dump soit dans un niveau d’activité transactionnel nul (quiesce).

Ce point est complètement logique dans le sens où le dump/load cross plateforme avec poids différents pour les journaux de transactions n’est pas supporté, aussi il faut que le dump ne contienne pas les dernières phases de synchronisation avec le journal des transactions.

Voici les actions recommandées lors du dump d’une base de données pour la charger vers une plateforme de poids différent, actions visant essentiellement à atteindre le niveau transactionnel 0.

dbcc checkdb et dbcc checkalloc : cette étape est optionnelle, mais il est recommandé de vérifier le degré 0 de corruption avec les commandes dbcc checkdb et dbcc checkalloc.
Mise en mode 'single user' avec sp_dboption de la base de données à "dumper" : ce point est problématique car il suppose que l’on rende indisponible potentiellement une base de données de production, ce qui n’est pas toujours négociable, ou bien un batch peut empêcher la mise en mode 'single user':
```
use master
go
exec sp_dboption '<dbname>','single user',true
go
use <dbname>
go
checkpoint
go
```
Une fois en mode 'single user' dans la base de données, flush des statistiques dans systabstats avec sp_flushstats.
Flush des pages mises à jour avec la commande checkpoint dans la base de données en question :
```
checkpoint
go
```
La commande dump database peut être lancée (Ne pas oublier d’enlever le mode 'single user' à l’issue de la commande dump).

Chargement (load) et processus de conversion

LOAD DATABASE

Au moment de la commande LOAD database, Adaptive Server détecte automatiquement le type de poids dans le fichier de dump et réalise presque toutes les opérations nécessaires durant les commandes LOAD DATABASE et ONLINE DATABASE.

Voici un exemple de chargement d’un dump effectué sur Sun Solaris SPARC (big-endian) vers Windows x86 (little-endian) :

load database KGB from 'compress::1::C:\dba\sybase\DBA_T1_ASE\export\KGB_20061220_1of1_v1.z.dmp'
go
                Backup Server session id is: 5. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.
      Backup Server: 4.132.1.1: Attempting to open byte stream device:
      'compress::1::C:\dba\sybase\DBA_T1_ASE\export\KGB_20061220_1of1_v1.z.dmp::00'
      Backup Server: 6.28.1.1: Dumpfile name 'KGB06354135F7 ' section number 1 mounted on byte stream 'compress::1::C:\dba\sybase\DBA_T1_ASE\export\KGB_20061220_1of1_v1.z.dmp::00'
      Backup Server: 4.58.1.1: Database KGB: 2358 kilobytes LOADED.
      Backup Server: 4.58.1.1: Database KGB: 42502 kilobytes LOADED.
      Backup Server: 4.58.1.1: Database KGB: 85514 kilobytes LOADED.
      Backup Server: 4.58.1.1: Database KGB: 122890 kilobytes LOADED.
      Backup Server: 4.58.1.1: Database KGB: 122898 kilobytes LOADED.
      Backup Server: 3.42.1.1: LOAD is complete (database KGB).
      Started cross-platform conversion for database KGB.
      Started cross-platform conversion for system objects.
      Cross-platform conversion for database KGB: 306 pages completed.
      Completed cross-platform conversion for system objects.
      Started cross-platform conversion for user objects.
      Cross-platform conversion for database KGB: 10129 pages completed.
      Cross-platform conversion for database KGB: 20329 pages completed.
      Cross-platform conversion for database KGB: 30529 pages completed.
      Cross-platform conversion for database KGB: 40729 pages completed.
      Cross-platform conversion for database KGB: 50929 pages completed.
      Cross-platform conversion for database KGB: 61129 pages completed.
      Completed cross-platform conversion for user objects.
      Started cross-platform conversion for log records.
      Cross-platform conversion for database KGB: 1 pages completed.
      Completed cross-platform conversion for log records.
      Completed cross-platform conversion for database KGB.
      All dumped pages have been loaded. SQL Server is now clearing pages above page 61440, which were not present in the database just loaded.
      SQL Server has finished clearing database pages.
      Started estimating recovery log boundaries for database 'KGB'.
      Database 'KGB', checkpoint=(51356, 12), first=(51356, 12), last=(51356, 12).
      Completed estimating recovery log boundaries for database 'KGB'.
      Started ANALYSIS pass for database 'KGB'.
      Completed ANALYSIS pass for database 'KGB'.
      Started REDO pass for database 'KGB'. The total number of log records to process is 1.
      Completed REDO pass for database 'KGB'.
      Use the ONLINE DATABASE command to bring this database online; SQL Server will
      not bring it online automatically.

La commande LOAD DATABASE affiche très clairement le processus de conversion qui est opéré sur toutes les pages chargées et montre également l’ordonnancement du processus de conversion :

conversion des objets systèmes.
conversion des objets utilisateurs.
conversion des enregistrements de transactions (syslogs).

ONLINE DATABASE

La commande ONLINE DATABASE va quant à elle se charger des indexes sur les objets systèmes de la base de données pour convertir les lignes d’indexes, l’ordre de tri et le jeu de caractères des lignes d’indexes, voici un extrait :


      ...
      Checking sysreferences: Logical pagesize is 2048 bytes
      The sortorder and character set ID's for index 1 on this table were 50:1 in sysindexes. They have been corrected to 50:2.
      The sortorder and character set ID's for index 2 on this table were 50:1 in sysindexes. They have been corrected to 50:2.
      The sortorder and character set ID's for index 3 on this table were 50:1 in sysindexes. They have been corrected to 50:2.
      The indexes for 'sysreferences' are already correct. They will not be rebuilt.
      ...
      Checking sysconstraints: Logical pagesize is 2048 bytes
      The indexes for 'sysconstraints' are already correct. They will not be rebuilt.
      Checking sysqueryplans: Logical pagesize is 2048 bytes
      The indexes for 'sysqueryplans' are already correct. They will not be rebuilt.
      (4 rows affected)
      WARNING: One or more indexes on user tables may have been marked as 'suspect'
      making these indexes unusable. Use the sp_post_xpload stored procedure to check
      and rebuild these indexes.
      Database 'KGB' is now online.

À l’issue de la commande ONLINE DATABASE, Adaptive Server marque les types d’indexes ci-dessous pour les tables utilisateur comme des indexes suspects, le caractère suspect rendant ces indexes inutilisables !

Indexes non-clustered sur les tables APL (mode de verrouillage AllPages, DataPages)
Indexes clustered sur les tables DOL (mode de verrouillage datarows ou lignes)
Indexes non-clustered sur les tables DOL (mode de verrouillage datarows ou lignes)

Opérations Post-Load : sp_indsuspect et sp_post_xpload (dbcc reindex)

Une fois la base de données chargée et en ligne, les indexes utilisateurs rendus suspects peuvent être retrouvés avec la commande sp_indsuspect :

exec sp_indsuspect
go
                Suspect indexes in database KGB:
      Own.Tab.Ind (Obj_ID, Ind_ID)

      -------------------------------------------------------------------------------
      ------------------------------------------------------------------------------
      dbo.KPI.KPI_KPI_id (32000114, 2)

      dbo.ENV.ENV_ENV_id (64000228, 2)

      dbo.PRODUIT.PROD_PROD_id (160000570, 2)

      dbo.CALENDRIER.CAL_DATE (192000684, 2)

      (return status = 0)

Les indexes suspects peuvent être recréés par deux méthodes :

suppression et recréation classique des indexes.
sp_post_xpload

sp_post_xpload valide les indexes, supprime les indexes invalides et recréée les indexes supprimés en une seule commande :

exec sp_post_xpload
go
          sp_post_xpload: Processing table KPI (1/5)
      Checking KPI: Logical pagesize is 2048 bytes
      The indexes for 'KPI' are already correct. They will not be rebuilt.
      sp_post_xpload: Processing table ENV (2/5)
      Checking ENV: Logical pagesize is 2048 bytes
      The indexes for 'ENV' are already correct. They will not be rebuilt.
      sp_post_xpload: Processing table REPORT (3/5)
      sp_post_xpload: Processing table PRODUIT (4/5)
      Checking PRODUIT: Logical pagesize is 2048 bytes
      The indexes for 'PRODUIT' are already correct. They will not be rebuilt.
      sp_post_xpload: Processing table CALENDRIER (5/5)
      Checking CALENDRIER: Logical pagesize is 2048 bytes
      The indexes for 'CALENDRIER' are already correct. They will not be rebuilt.
      (return status = 0)

sp_post_xpload peut apparaître très intéressante car elle prend en charge tous les indexes de la base de données en une seule ligne de commandes, toutefois cette procédure système sollicite dbcc reindex (voici l’extrait de sp_post_xpload) :


      begin
      /*
      ** We don't need to check a APL table which has
      ** only clustered index.

      ** Need to check and rebuild non-clustered index on APL or
      ** clusterd/non-cluster index on DOL.
      */
      dbcc reindex(@objid,14)
      end

dbcc reindex effectue un "fast" dbcc checktable avant la recréation éventuelle d’indexes suspects, les opérations sont donc plus longues avec dbcc reindex que lors d’une recréation classique des indexes. Ce point doit être pris en compte sur les tables très volumineuses en terme de performances.

Restrictions

Les commandes dump transaction et load transaction ne sont pas autorisées.
Les commandes dump database et load database pour du cross-plateforme avec différence d’endian ne sont pas autorisées à travers un backupserver distant.
Les fichiers de dump protégés par mot de passe ne peuvent pas être chargés.
Les versions ASE inférieures à la version 11.9 ne sont pas supportées dans le cross-plateforme.
ASE ne peut pas traduire les données structurées embarquées stockées dans les colonnes binary, varbinary et image.
La commande LOAD DATABASE en cross plateforme n’est pas autorisée pour la base master.
Pour toutes les combinaisons cross-plateformes autres que Solaris / Linux, les mots de passe de syslogins sont incompatibles si on utilise les commandes bcp, il demeure malheureusement nécessaire de recréer les logins par la voie classique (sp_addlogin).

Conclusion

L’opération doit se révéler particulièrement longue en temps d’upgrade (conversion des pages lors du chargement, recréation des indexes) pour un dump/load cross plateforme avec des poids différents sur des bases de données très volumineuses. À méditer en fonction de ce qu’on envisage (est ce qu’un week-end suffira ?).

Sybase 12.5.3 - Dump/Load cross plateforme