Tag: "locking _ blocking"

Conferences 2013: Frankfurter Datenbanktage und einige “Oracle-Momente”

Normalerweise versuche ich ja, meine Konferenz-Teilnahmen vorab bekanntzugeben, um dem Leser auch eine Chance zu geben, diese eventuell einzuplanen.

Aufgrund akutem Zeitmangel, und auch dem Umstand gewidmet, das ich erst eine Woche vor der Konferenz spontan für einen ausgefallenen Sprecher eingesprungen bin, ist mir das diesmal nicht gelungen.

Ich hatte das Vergnügen, einen Vortrag über “Hochverfügbarkeitstechniken mit SQL Server 2012” zu halten, und auch in einem Interview zu diesem Thema befragt zu werden.

Ich möchte über die diesjährigen (ersten) Frankfurter Datenbanktage (der Termin für das nächste Jahr steht bereits fest: 26. - 28. März 2014) gerne noch im Nachhinein schreiben, da mir das Konzept mit gleichzeitigen Tracks & Sessions zu Oracle, DB2, MySQL, NoSQL und SQL Server sehr gefällt.

Es ist z.B. immer wieder interessant - aber auch bedauerlich, festzustellen, wie unbekannt Snapshot Isolation & RCSI in SQL Server eigentlich ist.
Das geht soweit, das in einer Session, in der es um die Fähigkeiten der verschiedenen Datenbanksysteme, während des Schreibens von Datensätzen, dennoch gleichzeitig einen konsistenten Zustand lesen zu können zu der Aussage kam, das nur Oracle dies beherrscht.
Das ist sehr schade.
Denn abgesehen davon, das diese Aussage so nicht richtig ist - SQL Server bietet 2 Varianten (eben Snapshot Isolation und Read Committed Snapshot Isolation), auf die das ebenso zutrifft; das Hintergrundwissen, das Microsoft den Entwicklern die Wahl zwischen vielen verschiedenen Isolationsstufen gibt, und warum dieses Konzept auch besser ist, als keine Wahl zu haben (oder zumindest so sehr auf nur eine festgelegt zu sein, das selbst Oracle-Admins meinen, es gäbe keine), scheint nicht so weit verbreitet zu sein, wie man es sich erhoffen würde.

Eine andere Session, die ich nur lesenderweise mir ansah, hat mich als Security Spezialist für SQL Server schon fast geschockt: Es ist zwar kein Geheimnis (auch wenn es interessanterweise gerade im Bankenbereich gern ignoriert wird), wie umfangreich die Anzahl der Sicherheitslücken in ORACLE ist (Beim "NIST" kann man sich darüber informieren: nvd.nist.gov), aber in welchem Ausmaß man selbst ohne spezieller Betrachtung derer eine sogenanntes Sicherheits-“Härtung” durchführen muss, um einigermaßen sicher vor den gröbsten Einfallstoren zu sein, hat mich als seit SQL Server 2005 “secure by default” gewohnter doch sehr überrascht. - Möglichst “sanft" (Session-Untertitel "Sanftes Härten"), damit danach auch noch alles funktioniert - und wir wollen die Angreifer ja auch nicht völlig vergraulen, oder? :) (Nachtrag: natürlich ist es nachvollziehbar, das man nicht einfach so alles "dicht" macht, und danach auch die validen Anwendungen nicht mehr funtionieren. Die Essenz ist: es muss ein Mittelweg gefunden werden, welcher die Angreifbarkeit und Verletzbarkeit zumindest mindert. Und das ist natürlich schon viel Wert!)
Welche meiner Daten so "geschützt" in Oracle-DBs liegen, wäre vielleicht gut zu wissen... ganz ohne Häme, denn der einzelne Kunde kann dafür meistens gar Nichts. - Nur wenn er informiert ist und gar nicht handelt (Und nicht einmal mildernd eingreift).

Um es aber auch klar zu sagen: auch einen SQL Server kann man angreifen, wenn Applikationen oder andere Verbindungen mit zu viel Rechten laufen, Service Accounts geshared werden, etc.. Deswegen hier noch einmal die beiden wichtigsten Sicherheitsprinzipien: "Separation of duties/roles" und "Principle of least privilege". Also Aufgaben/Rollen (Dienstkonten!) trennen und immer mit den geringstmöglichen Rechten arbeiten. Und oben drauf ein Auditing, damit man mitbekommt, wenn man einen Weg übersehen hat.

Und nicht zuletzt wegen der Möglichkeit solche Missverständnisse oder Vergleiche einmal live zu erfahren, oder auch einfach ganz andere Möglichkeiten, die es bei anderen DBMS ja auch gibt, kennenzulernen, empfinde ich die Frankfurter Datenbanktage als Bereicherung in der Konferenz-Landschaft.

Tatsächlich versucht die PASS Deutschland e.V. eine kleine Variante solcher Mixtur auch für den geplanten SQLSaturday #230 in Rheinland, auf welchem ich sicherlich auch anzutreffen sein werde, mit einzubringen. Ich bin gespannt, was daraus wird, und wie es aufgenommen wird.

 

vielleicht sieht man sich auf der nächsten Konferenz,

 

Andreas

Locking & READONLY Filegroups vs READONLY Databases // Sperren & READONLY Dateigruppen vs READONLY Datenbanken

(en)
The Topic Locking and Read-Only for filegroups and databases is one of the ongoing myths around SQL Server in forums – and at least half of the information unfortunately wrong.
Since I recently fell into the trap myself, I want to write down, how it really is.

To have a definite picture, I made 3 test series under 3 different isolation levels:
  • Read Commited (the default)
  • Read Uncommitted (equal to the often misunderstood “NOLOCK”)
  • Repeatable Read

     

    The Setup:


    Tested under:
    Microsoft SQL Server 2012 - 11.0.2376
    A Test using SQL Server 2008 R2 produced identical results

    The base is a simple table, which has a Clustered Index. Altogether it consists of 36 pages
    (In case you wonder about the name – I had also tested with a single-Page table)

(de)
Das Thema Sperren im Zusammenhang mit Readonly Filegroups und Datenbanken geistert immer wieder durch die Foren - und mindestens zur Hälfte leider mit Falschinformationen angereichert. Da ich kürzlich selber in die Falle tappte, möchte ich hiermit schwarz auf weiß festhalten, wie es sich wirklich verhält.

Um ein eindeutiges Bild zu erhalten, habe ich Testreihen unter 3 verschiedenen Isolation Levels durchgeführt:

  • Read Commited (also dem Standard)
  • Read Uncommitted (gleichbedeuted mit dem ebenfalls gerne missinterpretierten “NOLOCK”)
  • Repeatable Read

    Das Setup:

    Getestet unter:
    Microsoft SQL Server 2012 - 11.0.2376
    Ein Test unter SQL Server 2008 R2 ergab identische Ergebnisse

    Basis ist eine simple Tabelle, welche mit einem Clustered Index versehen ist. Insgesamt besteht sie aus 36 Pages.
    (Falls ihr Euch über den Namen wundert: ich hatte auch Test mit einer single-Page Tabelle gemacht)

 

Databases

 

Read-Only Filegroup


USE
LockingDemo_RW
go
exec sp_help'BigTable'

Data_located_on_filegroup
PRIMARY

index_name    index_description
PK__BigTable__3213E83FFF01B718    clustered, unique, primary key located on PRIMARY

USELockingDemo_RO

Data_located_on_filegroup
PRIMARY

index_name    index_description
PK__BigTable__3213E83FFF01B718    clustered, unique, primary key located on PRIMARY

Identical structure so far except the database LockingDemo_RW_FG_RO – here the Table resides on filegroup FG_RO Also ein identischer Aufbau, bis auf die Datenbank LockingDemo_RW_FG_RO – hier ist die Tabelle auf der Filegroup FG_RO

USELockingDemo_RW_FG_RO

Data_located_on_filegroup
FG_RO

index_name    index_description
PK__BigTable__3213E83FC5587D01    clustered, unique, primary key located on FG_RO

The first/upper query shows the total amount of data, the lower is used as the test query: Die die erste/obere Abfrage zeigt die Gesamtdatenmenge, die untere wird als Testabfrage verwendet:

1)
SELECT * FROM BigTable

(1000 row(s) affected)

Table 'BigTable'. Scan count 1, logical reads 36, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 

2) – The Testquery / die Testabfrage

SELECT
* FROM BigTable

    WHERE id BETWEEN 100 AND 200

(101 row(s) affected)

Table 'BigTable'. Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 

This is what the test looked like (abbreviated): So sah der Testlauf aus (abgekürzt):

--====================

--  1

--====================

 SET TRANSACTION ISOLATION LEVEL READ COMMITTED

 

USELockingDemo_RW

go

 BEGINTRAN

 SELECT * FROM BigTable

    WHERE id BETWEEN 100 AND 200

 COMMITTRAN

 

USELockingDemo_RO

go

 BEGINTRAN

 

SELECT * FROM BigTable

    WHERE id BETWEEN 100 AND 200

 

COMMITTRAN

 

USELockingDemo_RW_FG_RO

go

 BEGINTRAN

 SELECT * FROM BigTable

    WHERE id BETWEEN 100 AND 200

 COMMITTRAN

 

USEmaster

 --====================

-- 2

--====================

 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

 ...

 --====================

-- 3

--====================

 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

 ...

 

Parallel to that, an extended events session was running (Lock-escalation isn’t happening in this scenario) Parallel dazu lief eine Extended Events session
(Lock-Escalation tritt in diesem Szenario nicht auf)

 CREATE EVENT SESSION [Locking] ON SERVER

ADD EVENT sqlserver.lock_acquired(

    ACTION(package0.event_sequence,sqlserver.database_id,sqlserver.is_system,sqlserver.session_id)

    WHERE ([sqlserver].[database_id]>=(23) AND [sqlserver].[database_id]<=(25)))

ADD TARGET package0.event_file(SET filename=N'D:\SQLData\SQLData1\Locking.xel')

WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=1 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)

GO 

 

Results

(Locks with granularity / resource_type = DATABASE left out)

1. Read Committed

Resultate

(Sperren mit Granularität / resource_type = DATABASE ausgelassen)

1. Read Committed

  Locks under Read Committed

2. Read Uncommitted

(for obvious reason I left out the sub-totals :-)

2. Read Uncommitted

(aus offensichtlichem Grund habe ich die Zwischensummen weggelassen :-)

 Locks under Read Uncommitted

3. Repeatable Read

3. Repeatable Read

 Locks under Repeatable Read

A note about Statistics und eXclusive Locks on ReadOnly-Databases:

Yes, one can indeed watch X-Locks on Read-Only databases. And this happens when auto-created stats jump in.
This works only starting with SQL Server 2012. The statistics themselves are stored in Tempdb.
In order to create those, SQL Server generates SCH_S and METADATA locks on several system objects (here: sysallocunits, sysschobjs, sysobjvalues, syssingleobjrefs, sysobjkeycrypts):

Eine Bemerkung zu Statistiken und eXklusive-Sperren auf schreibgeschützten Datenbanken:

Ja, tatsächlich kann man auch auf Read-Only Datenbanken hin und wieder X-Locks beobachten. Und zwar wenn auto-created Statistics einspringen.
Das funktioniert erst seit SQL Server 2012. Dabei werden die Statistiken selber in der Tempdb hinterlegt.
Um sie zu erzeugen, generiert SQL Server SCH_S und METADATA Locks auf diverse Systemobjekte (hier: sysallocunits, sysschobjs, sysobjvalues, syssingleobjrefs, sysobjkeycrypts):

image

This is of course not the most common scenario, but it does happen (especially in AlwaysOn scenarios with read-only secondaries involved) and belongs to a complete picture.

-

Besides that one can see on first sight, that there is no diffference in the Locking behaviour beetween the table on a ReadWrite Filegroup (here Primary) and the table on the ReadOnly filegroup.

Only if the whole database is ReadOnly, SQL Server  saves himself the Page- and Key- locks.
Even there an Intent shared Lock is placed on the table.

Conclusion:

Putting Tables onto a ReadOnly-Filegroup does not save Locks.
But it often does make a lot of sense, to break up databases in this manner.
Just thinking of: less backup, faster restore, NTFS-compression etc.
Das ist sicherlich nicht das am meisten übliche Szenario, aber es tritt auf (insbesondere in AlwaysOn Szenarien mit read-only Secondaries) und gehört zu einem vollständigen Bild.

-

Abgesehen davon erkennt man auf den ersten Blick, das kein Unterschied im Sperrverhalten zwischen der Tabelle auf einer ReadWrite Filegroup (hier Primary) und der Tabelle auf der ReadOnly Filegroup besteht.

Nur wenn die gesamte Datenbank ReadOnly ist, spart sich SQL Server die Page- und Key- Locks. Selbst dort jedoch wird ein Intent-Share-Lock auf die Tabelle gesetzt.

Fazit:

Tabellen auf eine ReadOnly-Dateigruppe zu verlegen spart keine Sperren.
Aber es macht natürlich trotzdem oft sehr viel Sinn, Datenbanken so aufzuteilen.
Ich denke da nur an: Weniger Backup, schnellere Wiederherstellung, NTFS-Komprimmierung  etc.

Andreas

Sarpedon Quality Lab