Kategorie: ASE: Konfiguration

Locking Schema, locking scheme

Der ASE stellt drei verschiedene Locking Schemata bzw. locking schemes bereit. allpages locking scheme, datapages locking scheme und datarows locking scheme.

Um herauszufenden welches Locking Schema eine oder alle Tabellen einer bestimmten Datenbank haben, kann die Systemtabelle sysobjects der jeweiligen Datenbank abgefragt werden. Das Locking Schema ist mit einer bitmap in der Spalte sysstat2 hinterlegt.

Locking Scheme - sysobject - sysstat2 bitmap

8192 - 0x2000 - Table uses allpages locking scheme.
16384 - 0x4000 - Table uses datapages locking scheme.
32768 - 0x8000 - Table uses datarows locking scheme.

Query zur Abfrage der Locking Schemata aller Tabellen einer Datenbank

Eine Querry auf die sysobjects könnte dann so aussehen. Zum Ausführen bitte vorher ein use database machen.

    select 
          name
        , 'table uses...' = case (sysstat2 & 57344)
            when 8192 then 'allpages locking scheme'
            when 16384  then 'datapages locking scheme'
            when 32768 then 'datarows locking scheme'
          end
    from sysobjects where type = "U"

Locking Schema ändern

Im Allgemeinen kann der dbo seine Objekte selbst verwalten. Eine serverweite Einstellung kann mit der sso_role über

    sp_configure "lock scheme"

ermittelt und geändert werden. Geändert wird das beispielsweise mit:

    sp_configure "lock scheme", 0, datarows

um alle Objekte per default mit dem Locking Schema datarows anzulegen. Zusätzlich kann beim Erstellen einer Tabelle das Locking Schema mit create table festgelegt werden:

    create table table_name (column_name_list) 
      [lock {datarows | datapages | allpages}]

Tabellen können auch nachträglich entsprechend geändert werden. Hierzu haben gibt es das Kommando alter table.

    alter table table_name 
      lock {allpages | datapages | datarows}

Worauf man beim Ändern des Locking Schemas achten sollte

Beim Ändern des Lockíng Schemas gibt es allerdings einiges zu beachten: Wenn von allpages locking zu data-only locking gewechselt werden soll, wird eine komplette Kopie der Tabelle angelegt und dabei jeder Index neu erstellt. Das kann je nach Größe der Tabelle einige Zeit in Anspruch nehmen und erfordert ausreichend freien Platz in der Datenbank. Die Applikation sollte dann möglichst nicht auf die Tabelle zugreifen.

Zudem gibt es noch ein paar Besonderheiten, die beim Wechsel von allpages locking zu data-only locking beachtet werden müssen.

Der Wechsel ist nur bei Tabellen möglich, deren maximum lenght von 1962 (inklusive der 2 Bytes der offset table) noch nicht erreicht ist. Eine Row darf hierzu nicht ganz mit Benutzerdaten gefüllt sein. Also voll noch sehr nahe am maximalen Füllstand von 1962 Bytes sein. Bei Tabellen mit data-only-locked Schema und einer fix-length-column (feste Spaltenlänge) ist die maximale Größer einer data row 1960 Bytes (inklusive der 2 Bytes der offset Tabelle)
Tabellen mit einer variablen column-length, also eienr variablen Spaltenlänge benötigen 2 zusätzliche Bytes für jede variable-length column, das beinhaltet auch Spalten, die NULL Werte erlauben.

Zudem ist der Wechsel mit alter table ... lock zu oder von allpage locking ein stark I/O-lastiger Prozess, der vornehmlich durch das Kopieren der Tabelle und dem Neuanlegen der Indizes verursacht wird. Während des alter-Kommandos durchläuft der Prozess folgende Schritte:

Zunächst werden alle Rows der Tabelle in neue data pages umkopiert und mit dem neuen Locking Schema formatiert. Beim Wechsel auf das data-only locking Schema wird jede row die kleiner als 10 Bytes groß ist auf 10 Bytes erweitert. Das gleiche gilt auch für den Wechsel auf allpage locking von data-only-locking.
Danach werden die Indizes gedroped und neu angelegt.
Als nächstes wird die alte Tabelle gelöscht.
Anschließend gibt es ein Update mit den neuen Informationen auf die Systemtabellen.
Schielßlich wir der Zähler der Tabelle upgedated, so dass der Query plan recompiliert (recompile) wird.

Beim Ändern des Locking Schemas: Besonderehieten bei einem clustered Index

Bei einem Wechsel von allpage-locking nach data-only locking wird ein clustered Index einer Tabelle in der Key-Reihenfolge des clustered Index auf die neuen data pages kopiert. Bei nicht geclusterten Indizes werden die Rows gemäß der page chain-Reihenfolge kopiert.

Um ein Rollback zu gewährleisten, wird beim Ausführen des Kommandos alter table ... lock die Änderung des Locking Schemas in einer einzigen Transaktion durchgeführt. Dabei wird ein so genanntes exclusive table lock auf der Tabelle gehalten.

Wenn von datepages locking zu datarows locking oder umgekehrt gewechselt werden soll, werden nur Systemtabellen geändert, so dass die Umstellung nach ein paar Minutenfertig sein sollte und auch im laufenden Betrieb gemacht werden kann. Die Datenbankoptionen select into/bulkcopy/pllsort wird dabei nicht benötigt.

Vor einer Änderung des Locking Schemas ist ein Dump der Benutzerdatenbank und der master zu empfehlen! Danach solle

    dbcc checktable

auf der geänderten Tabelle und

    dbcc checkalloc

auf der Benutzerdatenbank durchgeführt werden, um die Konsistenz der Daten zu prüfen. Um nach dem Wechsel von allpages locking zu data-only locking oder umgekehrt das Transactionlog sichern zu können, muss zunächst ein Dump der ganzen Datenbank durchgeführt werden.