SelectEtoile : Base de connaissance SGBD

Posts Tagged 'syslogs'

Count free space

Pour corriger les problèmes de calcul d'espace libre.

7408 - Force the server to scan *log segment* allocation pages; to recalculate free log space rather than use saved counts.

7409 - Force the server to scan *data* segment allocation pages; to recalculate free data page space rather than use saved counts.

 

Ou

 

>dbcc usedextents(db_name, 0, 1, 1)

 

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.

Comment corriger un mauvais calcul de l'espace libre du journal de transaction

Comment corriger un mauvais calcul de l'espace libre du journal de transaction  ?

 

Symptomes :

1> sp_spaceused syslogs
2> go
 name            total_pages     free_pages      used_pages      reserved_pages
 --------------- --------------- --------------- --------------- ---------------
 syslogs         17920000        23365587        -5447337        1750

 Apparition de valeur négative dans used_pages. Cela correspond à un bug SYBASE

Pour info, voici la requête qui permet de calculer l'espace alloué,libre, occuppé du journale de transaction :

 select distinct convert(int,lct_admin('logsegment_freepages',db_id('msbdb_sumotc'))-lct_admin('reserved_for_rollbacks',db_id('msbdb_sumotc')))*(@@maxpagesize/1024.0/1024.0)

 

Methode 1

  • use master
  • go
  • sp_dboption dbname, 'single user', true
  • go
  • use dbname
  • go
  • dbcc tablealloc(syslogs, full, fix)
  • go
  • use master
  • go
  • sp_dboption dbname, 'single user', false
  • go

Methode 2

  • use master
  • go
  • sp_dboption dbname, 'single user', true
  • go
  • dbcc dbrepair(dbname, fixlogfreespace)
  • go
  • sp_dboption dbname, 'single user', false
  • go

 

 

La méthode 1 est préférable car supportée.

Arrêt d'un processus en log full

Arrêter une session en log full sans kill


  1. Find the spid of the transaction process:

    1> select spid from master..syslogshold
    2> where dbid = ID /* is id of database with LOG SUSPENDed users */
    3> go

  2. Abort the transaction process. Only a System Administrator can use lct_admin abort.
    1> select lct_admin("abort", spid, dbid)
    2> go
    This terminates and closes the suspended transaction.
  3. Perform dump transaction for the database with LOG SUSPENDed users.

Articles tagged

Suicide de Log SYBASE ASE

1.  use master
        begin tran
        update sysdatabases set status=-32768 where name='suspect_database'
        if only one row changed (verify)
        commit tran
2. issue "checkpoint" in master db
3. shutdown with nowait
4. restart dataserver in single user mode (-m)
5. use suspect_database
        checkpoint
6. use master
        begin tran
        update sysdatabases set status=(whatever it was before) where name='suspect_database'
        if only one row changed (verify)
        commit tran
7. restart dataserver in multuser mode (no -m)