SelectEtoile : Base de connaissance SGBD

Posts Tagged 'recovery'

Syslogs full et not recovery yet

Problèlme:

Pour différentes raisons, il peut arriver que le journal de transaction d'une base Sybase soit totalement rempli et qu'il ne soit plus possible de le purger. Dans la plus part des situations, il faut agrandir la base en ajoutant un peu de place pour le segment de log. Mais certain (Je pense même que c'est arrivé à tout le monde), sous l'emprise de la panique ou d'un optimise frôlant la reconversion en admin windows, choisissent de procéder à un arrêt/relance du serveur Sybase et là c'est catastrophe. La serveur tente de faire un recovery de base qui s'arrête avec le message traditionnel:

erver Can't allocate space for object
'syslogs' in database.

et comme un malheur n'arrive jamais seul, Le status de la base passe "not rovery yet". A ce moment là on peut se poser plein de question et maudire la reine des bases: Mais non. Il existe des moyens de s'en sortir sans forcément recharger la base ou bien suicider le log de la base en jetant ainsi tous ses espoirs de revenir à une situation saine avant la prochain ebf ASE.

 Dans l'application de la solution, être rigoureux tu dois

 Le principe est simple. On va mettre un fragment de donnée de la base en data et log mélangés, faire le recovery de la base et remettre le fragment en data only.

 

  1. Avant tout, il faut redémarrer votre serveur avec le trace flag 3608 pour redémarrer sans faire le recovery des bases user (-T3608 dans le fichier de démarrage du dataserver). 
  2. Permettre de modifier les tables systèmes: sp_configure 'allow update', 1
  3. Mettre de côté une sortie du mapping de votre base de donnée: select * from sysusages where dbid=db_id('My_db')
  4. Quand vous avez choisi le fragment sur lequel vous allez faire le recovery:
    begin tran
    update sysusages set segmap=7 where dbid=db_id('My_db') and lstart= <lstart du fragment de la base choisi>
    <Vérifier le résultat>
    commit or rollback
  5. Il faut modifier le status de la base pour pouvoir utiliser un segment en data et log mélangés pour un base ayant les data et le log séparés:
    select status - 320
    from sysdatabases
    where dbid = db_id("My_db")

    Sauvegardez le résulta.

    update sysdatabases set status2 = -32768 where dbid = db_id("my_db")
    go -- Si tout est bon:...
    commit transaction
    go
    shutdown
    go

  6. Redémarrer le serveur sans le traceflag. Si vous avez assez d'espace dans le fragment modifier le recovery se fera
  7. Une fois la base online, purger le journal de transaction: dump tran My_db with truncate_only
  8. Remettre les valeurs initiales de la ligne modifiée dans sysusages avec les données sauvegarder à l'étape 3
  9. Arrêt/relance du serveur (Vérifier bien que le trace flag soit désactivé à l'étape 6 n'est plus actif.

Temps de recouvrement d'une base

 

Il faut d’abord bien comprendre que lorsqu’un utilisateur, insert, modifie ou supprime des données, seul le journal de transaction est écrit immédiatement sur le disque. Les données modifiées sont écrites dans le cache d’ASE. Pour des raisons de performance, leurs écritures sur disque sont différées. C’est le processus checkpoint ou la commande checkpoint qui provoque l’écriture des données modifiés en cache sur disque. C’est ce même processus qui déplace le point de troncature pour permettre la purge du journal de transactions.

 

Si le serveur est arrêté avec « un arrêt immédiat » (On fige le journal de transaction en l’état, il n’y a pas de checkpoint ni de purge) ou alors suite à un arrêt brutal, les données modifiées en cache qui ne sont pas écrites sur disque sont flashées. Lorsque le serveur redémarre, il va rechercher ces données en se basant sur le journal de transaction.

 

Pour réaliser cette tache le serveur se lance dans un processus de  recovery de la base qui se décompose en trois étapes :

  • Analyse : C’est la lecture du journal de transaction afin de construire les taches à effectuer dans le REDO PASS et le UNDO PASS.
  • Redo Pass : C’est l’écriture des données, des transactions validées, sur disque
  • Undo Pass : C’est l’annulation des transactions qui n’ont pas abouties ou bien qui étaient marquées comme à défaire.

 

 

Donc selon la périodicité des checkpoints et le taille du journal de transaction, l’étape de REDO peut-être très longue.

Error 3475 during recovery

Quand on détecte l'erreur 3475 dans l'errorlog durant le recovery d'une base, le serveur marquera cette base à 'not recovered' et la gardera offline (La base peut avoir le status 64 ou 68 dans sysdatabases)


Il est nécessaire de bypasser le recovery et d'augmenter le journal de transaction


Pour cela, suivre la procédure suivante :

- faire un update de la table sysdatabases et positionner le status de la base à -32768 (garder en mémoire la valeur de la colonne status avant modification)
- faire un 'checkpoint' sur la base master
- Lancer un 'shutdown with nowait'
- redémarrer le server (il ne va pas faire de recovery sur la base en question)
- Ajouter le ou les devices de logs
- Faire un update sur sysdatabases en remettant la valeur sauvegardée au début.
- Faire checkpoint in master
- Rebooter un derniere fois le serveur SYBASE.

Maintenant, le recovery devrait se faire sans problème.


Installation Mirroring SQL Server

Définition du Miroring

 

Le Miroring est un outil disponible à partir de la version SQL SERVER 2005 SP1. Cet outil permet de maintenir à jours une base de données distante (par exemple sur un serveur de secours).

Sa granularité est la base de données (impossible de ne maintenir que certains objets), et son fonctionnement est basé sur le transfert des blocs du journal de transaction.

·         PRINCIPES DE FONCTIONNEMENT / restriction

Nous appellerons ‘base primaire’ la base de données source et ‘base secondaire’ la base de données cible du miroring.

La base primaire est obligatoirement en mode de recovery full, il sera donc nécessaire de mettre en place des jobs de backup pour le journal de transaction (cf Jobs DBA). L’instance sql serveur va donc gérer un second point de troncature pour ce journal de transaction. Lors d’une modification de données la partie du journal de transaction relative à ce changement va être envoyée et écrite dans le journal de transaction de la base secondaire. Cette dernière est quand à elle en recovery mode.

Le transfert des blocs de journaux de transactions ce fait par un ‘endpoint miroring’. Ce dernier définit la connexion entre l’instance primaire et l’instance secondaire.  La création d’un endpoint miroring est donc nécessaire sur les 2 instances cible est source. Le même ‘endpoint’ peut être utilisé pour plusieurs bases.

La base primaire ne peut avoir qu’une seule base secondaire (contrairement au log shipping)

La base secondaire ne peut pas être accédée (même en lecture). Il est possible de mettre en place en fonction des besoins un snapshot de la base secondaire qui lui sera dispo en lecture uniquement mais avec certaines contraintes (nous ne traiterons pas des snapshot dans ce document)

 

·         MODE de miroring

Il existe plusieurs modes de miroring en fonction des besoins.

                Le mode synchrone avec bascule automatique

                               Ce mode permet de ne perdre aucune transaction et de pouvoir basculer sur la base secondaire sans aucune intervention manuelle. En contrepartie de la sécurité les performances peuvent être considérablement diminuées (50%) car les modifications ne seront appliquées sur la bases primaire qu’une fois commitées sur la base secondaire. (des tests applicatifs sont impératifs pour définir l’acceptabilité des pertes du à ce mode synchrone). La bascule automatique Elle nous coutera un serveur/instance supplémentaire pour y installer le ‘witness server ‘ ce dernier va contrôler en permanence la présence de la base primaire, en cas de défaillance il activera automatiquement la base secondaire. 

 

                Le mode synchrone avec bascule manuelle

Idem que si dessus mais sans la partie ‘witness serveur’ la bascule sera donc manuelle (très rapide quand même)

                Le mode asynchrone

Ce mode de miroring pas la perte  de transaction est possible, mais les performances accrues. La base primaire va vivre indépendamment de la base secondaire, à fréquence définis les block de journaux de transaction seront envoyés et exécutés sur la base secondaire. La bascule sera obligatoirement manuelle.

 

Mise en place du Mirroring entre 2 serveurs SQL-Server (SQLServer1 --> SQLServer2)

Prérequis

  • La version de SQLServer doit être au minimum 2005 SP1
  • La base doit exister sur les 2 environnements.
  • La base primaire doit être en mode de recovery full
  • Les logins / users doivent être synchronisés entre primaire et secondaire via un script de transfert login par exemple.

Verrouillage des logins

Use master ;

ALTER LOGIN [mon login] DISABLE ;

Passage de la base Primaire en mode full sur le SQLServer 1

ALTER DATABASE [ma base] SET RECOVERY FULL;

Lancement d'un dump database et dump transaction de la base primaire SQLServer 1

BACKUP DATABASE [ma base] TO DISK = 'chemin\fichier.bck' WITH FORMAT; 

BACKUP LOG [ma base] TO DISK = 'chemin\fichier.trn' with format;

 

Read more: Installation Mirroring SQL Server