Ich habe vor kurzem bei XING eine kleine Umfrage durchführen lassen, um einmal zu erfahren, warum es weltweit, aber auch insbesondere im Deutschen Raum so wenige MCMs gibt. - Speziell außerhalb von Microsoft-Angestellten selber schwankt die Anzahl je nach Produkt zwischen 0 und 6.

Die offiziellen Zahlen Ende Mai 2013 wie folgt (vornean die Gesamtzahl, in Klammern die Anzahl der MCMs davon, die nicht direkt für Microsoft arbeiten):

0 (0) Windows Advanced Infrastructure (hier gibt es gleich keine MCMs in Deutschland, aber weltweit auch nur 16)
5 (4) Windows Server Directory
9 (3) SQL Server                         
9 (6) SharePoint
7 (4) Microsoft Office Communications Server and Lync Server 2010
12 (5) Microsoft Exchange Server

(Quelle: www.microsoft.com/learning/en/us/mcm-certification.aspx - Hinweis, diese Quelle erhebt keinen Anspruch auf Vollständigkeit, ist aber die beste, die es gibt und kann daher gut für einen Vergleich herangezogen werden.)

•  seit Beginn der Umfrage sind 2 MCMs für SQL Server 2008 dazugekommen, das sind 28%, kurz vor Auslaufen der Prüfung :-)
• Das heißt, dass ich nun nach einem Jahr nicht mehr der einzige von Microsoft unabhängige MCM für SQL Server in Deutschland bin, sondern nur noch der Erste. :-)
• siehe auch www.insidesql.org/blogs/uricken/2013/05/24/mcm-sql-server-2008

Was sind nun die Gründe für diese geringe Anzahl?

Ganz abgesehen davon, das mit Sicherheit die gestellten Ansprüche ein Grund sind, sind bei der Umfrage folgende Antworten Zusammengekommen:

- Bislang haben sich 47 Teilnehmer an der Umfrage beteiligt. (Noch offen bis Ende Mai – ich werde die finalen Ergebnisse hier dann nochmal übernehmen)
Hier geht es zur Umfrage: www.xing.com/app/newsfeed?op=poll_detail;id=9673

Nun kann man dort sicherlich vieles vermuten, und ich erhebe auch nicht den Anspruch einer wissenschaftlich fundierten Analyse. Aber einige Dinge fallen doch sehr ins Auge, darum möchte ich die einzelnen Punkte frei aus meiner (persönlichen) Sicht kommentieren.

1) 57% - Zeitlicher Aufwand

-           hier wäre natürlich eine Aufteilung in WAS den zeitlichen Aufwand denn ausmacht interessant gewesen. Aber eigentlich können es nur 2 Dinge sein: Die Prüfung selber. – mit 5,5 Stunden ist die Lab in der Tat zeitaufwändiger als alle anderen Prüfungen. Aber kann das so viel ausmachen?
Bleibt: Die Vorbereitung, also das Lernen der Stoffe, die man vielleicht noch nicht in hinreichender Tiefe beherrscht. Interessanterweise ist Punkt 3 (erforderliches Know-How) dafür offenbar gar nicht das Problem. …

2) 57% - Zu teuer (Prüfung)

- zugegeben, die Prüfung ist nicht „billig““.
(Für das Erreichen dieser Zertifizierung sind ja 2 Prüfungen notwendig. Ein „Knowledge-Exam“, und ein „Lab-Exam“. Die Kosten liegen bei dem ersteren bei 367,- Euro. Das Lab-Exam ist das teurere, mit 2000 USD, was z. Z. rund 1550 EUR entspricht. Damit liegen die gesamt-Prüfungskosten also unter 2000 Euro. :-) )
PS: Möglicherweise ist das bei den Nicht-SQL Zertifizierungen etwas anders. Dabei sind mir Details nicht bekannt.

Insofern also die Frage unter Experten: können 2000 Euro so abschreckend viel sein?
Um mal aus dem Nähkästchen zu plaudern, was ich in meine Fortbildung investiere:
Ich bin jedes Jahr in den USA auf der großen SQL Server Konferenz. Ich bin zwar bekanntermaßen dort i.d.R. als Sprecher geladen, aber natürlich sind die Reisekosten nicht unerheblich. Den sogenannten „Verdienstausfall“ spreche ich jetzt nicht weiter an, denn das gilt für jegliche Fortbildung. Und ohne Fortbildung bleibt man stehen. - Das muss man sich einfach Wert sein.
Dazu kommen mindestens 2-3 weiteren Konferenzen, die dann noch so in Europa stattfinden und wo ich auch spreche. Für Vorträge muss man sich vorbereiten und im Zweifelsfall auch lernen. Selbiges gilt, wenn ich Schulungen gebe, ganz gleich welcher Art. Da kommen also schon einige tausend Euro zusammen.
Aber wie gesagt, diese Zertifizierung spricht auch eher Experten an, und da gehe ich davon aus, das das keine Summe ist, für die man lange sparen muss. Und wenn doch, dann wäre das eine Gelegenheit, einen höheren Stundensatz zu verhandeln, denn wer mehr weiß, ist im Zweifelsfall auch effizienter und spart seinem Kunden am Ende Zeit und Geld :)
Und spätestens bei wirklich komplexen Problemen geht man entweder an Microsoft CSS, oder eben einen unabhängigen MCM.

3) 11% - Zu breites Know-How erforderlich

- so ist das letztlich auch gedacht :-)
Mehr auf das Thema „Know-How“ gehe ich noch unter den Punkten 8 und 9 ein.

4) 51% - Kein finanzieller Nutzen

- Das kann man gelten lassen, da man seinen Stundensatz nicht unbedingt mal eben anheben kann und sollte. Die Frage ist nur: sollte das DER Grund sein für die Zertifizierung?

Für mich persönlich ist eine Zertifizierung vielmehr ein guter Grund, sich Zeit nehmen zu müssen, sich also zu disziplinieren, um Dinge zu lernen, die man bisher entweder gar nicht kannte, oder noch nicht benötigt hat. Immer mit dem Zweck, am Ende aus einer möglichst großen Bandbreite an Techniken schöpfen zu können, wieder ein wenig mehr zu wissen. Vorwärtskommen also.

5) 28% - Kein Anwendungsbedarf für das erforderliche Know-How

- Ja, das kann ein Grund sein, gerade wenn man vornehmlich in relativ langfristigen Projekten arbeitet, oder auch schlicht keine extrem anspruchsvolle Umgebung zu verwalten hat.

6) 17% - Fehlendes Trainingsangebot

- Das ist ein nur von wenigen als wichtig erachteter Punkt. Dennoch eine kurze Ausführung:
Was für Schulungen gibt es für den Erwerb des MCTS/MCITP, neu MCSA/MCSE?
Es gibt die sogenannten MOC-Kurse, in der Vergangenheit zu recht wegen fehlendem Praxisbezug und auch Fehlerhaftigkeit bemängelt. Um einen solchen zu geben, muss man im Wesentlichen ein MCT (Microsoft Certified Trainer) sein, und auch auf dem Produkt, also z.B. SQL Server ITPro -Level zertifiziert sein. (Das sich viele nicht an diesen Mindeststandard gehalten haben, hat meines Erachtens viel zu dem schlechten Ruf der MOC-Kurse beigetragen – am Ende musste man auch wissen, welcher Schulungsanbieter welche Trainer einsetzt)
Dann gab es schon immer ein mannigfaltiges Schulungsangebot auf dem freien Markt. Denn letztlich ist für das Bestehen der Microsoft-Examen nur das Know-How erforderlich, nicht der Nachweis einer bestimmten Schulung (wie es beispielsweise bei Informatica der Fall ist)

Wie ist das nun beim MCM/MCSM?
Nun, auch da kommt es letztlich nur auf das Know-How an. Zwar ist die Durchfallquote bei der Lab mit 80% sehr hoch, aber schon beim zweiten Versuch schaffen es rund 50% - das weiß ich aus Gesprächen mit den damaligen Master-Programm-Manager.
Und welches Trainingsangebot gibt es nun also, wenn man sich in einzelnen Technologien noch verbessern möchte? Zu Beginn bot Microsoft Schulungen direkt auf dem Campus an. Aufgrund von Qualitätsproblemen (! – Ja, richtig gehört) wurde das dann jedoch ausgelagert und letztlich darf jeder Schulungen mit dem Ziel „Master“ durchführen. (Aktuell sickern Informationen durch, dass es eine Neuauflage von Bootcamps in Redmond geben wird)
In den USA gibt es derzeit 2 mir bekannte Anbieter (SQLSkills: www.sqlskills.com und SQL Internals: www.sqlserverinternals.com )
Da Paul Randall von SQLSkills der ehemaliger Leiter des Microsoft-internen Vorläufers des SQL Server Master-Programms ist, und durch seine Arbeit an DBCC CHECKDB über detailliertes Know-How und internes Wissen über die Engine verfügt, habe ich mir selber alle 4 Wochen Training bei Redmond mit ihm gegönnt. Einfach, um auch noch das letzte an Know-How erlangen zu können, welches sich nicht über Blogs und Bücher erlangen lässt.
War das notwendig für die Prüfungen? – Nein, absolut nicht. Das ist nur persönlicher Ehrgeiz und Anspruch – sowie einfach Spaß am Lernen und Wissen erlangen :-)
Dazu kommt natürlich auch das Networking mit den Kollegen in den USA. Für mich war das also das Richtige zu tun, zumal ich mich auch keinem gegenüber wegen der Zeit rechtfertigen muss :-)

Wie sieht es in Deutschland aus?
Hier bietet Microsoft natürlich auch nichts an.
Ich darf aber auf mein eigenes Trainingsangebot hinweisen. Als MCT und MCM führe ich seit diesem Frühjahr die SQL Server Master-Classes durch. Die erste Runde (Extended Events sogar 2mal) wird im Juni beendet sein. Die nächsten Termine werden im Moment für den Oktober 2013 geplant.
Für alle, die mehr wissen wollen („Hach, diese Doppeldeutigkeit“ :-D): www.sarpedonqualitylab.com/SQL_Master-Classes.htm

7) 4% - Zertifizierung mir unbekannt

- Puh, immerhin in den IT Foren ist der MCM also doch gut bekannt.

8) 40% - Zertifizierung meinen Kunden unbekannt

- Ja, das ist sicherlich so, dass dieser Titel noch nicht den Bekanntheitsgrad hat, wie er sie sicherlich verdient hat. Von einem Bekanntheitsgrad wie des seit über einem Jahrzehnt etablierten MVP ist der MCM weit entfernt. Dabei ist der MVP auch kein Zertifikat sondern ein Award. (Es findet also kein Examen statt. - mvp.microsoft.com) . Die neuerliche Umbenennung zum MCSM (…Solutions Master) wird sicherlich auch wenig helfen.

Und noch etwas möchte ich erwähnen, wie mir aus Gesprächen mit Paul Randall, der die Prüfung mit entwickelt hat, bewusst wurde: Der MCM ist nicht zuletzt deswegen erschaffen worden, um eine Zertifizierung anbieten zu können, welche sich nicht durch unlautere Methoden leichter beschaffen lässt.

- Siehe die Inflation von MCSE’s (dem alten Microsoft Certified System Engineer) aber letztlich auch von MCTS und MCITP, erzeugt durch Boot Camp Angebote, wo schnell viel auswendig gelernt wurde, um genau auf die Prüfungsfragen vorbereitet zu sein – oder durch die sogenannten „Braindumps“  – anstelle wirklich praktisches Wissen zu erlangen, wofür es keine Abkürzungen gibt, sondern Jahrelange Erfahrung. Darunter haben die Zertifizierungen so gelitten, das ein bloßes Zertifikat heute doch eher wenig bedeutet, bis man herausgefunden hat, was der Bewerber wirklich kann.

Die Prüfungen zum MCM sind genau deswegen zum einen so teuer und komplex, um die Weitergabe von Prüfungsinterna zu verhindern, und zum anderen eben auch so aufgebaut, das man sie nur mit echter Praxiserfahrung bestehen kann. Es ist keine Prüfung, an welcher man sich austesten kann und sollte, um zu üben, sondern nach 2 spätestens Versuchen sollte sie zu bestehen sein – ansonsten braucht man vielleicht einfach noch ein paar Jährchen und komplexere Aufgaben („O-Ton“) – deswegen auch die verhältnismäßig langen Fristen für ein Retake.

Und wenn diese Gewissheit, auf geprüfte praktischer Erfahrung im Lösen von komplexen Problemen verweisen zu können kein guter Grund sind, dies seinen Kunden zu erklären.. :-)

Das „Sich abheben“ ist eher ein Side-Effekt. Entscheidender ist der Nachweis/Beweis, den die bisherigen Zertifizierungen leider nicht erfüllen konnten.

(Hierin ist eine versteckte Aufforderung zum Handeln zu sehen.. :-))

9) 9% - Unrealistische Prüfungsthemen

- ich nehme mal an hiermit ist eher Punkt 3 oder Punkt 5 gemeint. („Zu breites Know-How erforderlich“, „Kein Anwendungsbedarf für das erforderliche Know-How“)
Ich kann jedenfalls versichern, dass sämtliche Aufgaben sehr wohl praxisrelevant sind. Mehr ins Detail möchte ich hier nicht gehen, bevor ich mich Verplappere ;-)
- Aber wenn jemand der für das MCM Programm das hier lesen sollte: Es dürfte auch noch ein Stück mehr sein, sowohl Breite, als auch durchaus Komplexität :-D

10) 2% - Leider (noch) nicht bestanden (Alles anonym :-) )

-           Immerhin einer der Stimmabgebenden hat sich die Prüfung auch selber angesehen. Ich hoffe, es fühlen sich bald noch weitere dazu ermutigt.

An dieser Stelle nochmal vielen Dank an alle Teilnehmer der Umfrage.

Hier geht es zu einer kleinen Diskussion, die sich zu dem Poll bei XING entwickelt hat. (Dieser Link ist jedoch nicht öffentlich. Dafür ist eine Xing- sowie Gruppenmitgliedschaft erforderlich.):

www.xing.com/net/pri23e6c8x/mcertified/fragen-und-antworten-q-a-139524/umfrage-zur-zertifizierung-als-microsoft-certified-master-solutions-master-44173596/

Auf sqlpodcast.de/index.php/2013/05/24/003-microsoft-certified-master/ wurde kürzlich auch ein Interview veröffentlicht, in welchem ich persönlich auf einige Aspekte der Zertifizierung zum MCM eingehe.

• Inhalte:
  Microsoft-Zertifizierungen und Lernangebot
  Warum Zertifizierungen Sinn machen – und wann für wen oder für wen auch nicht
  Was den MCM die Prüfung zum MCM von den anderen „Breitenzertifizierungen“ unterscheidet
  Das Maestro-Programm (Das Gegenstück zum MCM für die BI-Suite des SQL Server) und seine ungewisse Zukunft.

Ein weiteres Interview mit mir, durchgeführt im März 2013 auf den Frankfurter Datenbanktagen, möchte ich meinen Lesern auch nicht vorenthalten: www.frankfurter-datenbanktage.de/index.php/interview-mit-andreas-wolter

Zum Schluss möchte ich noch festhalten, das wir als SQL Server Spezialisten, die Vorteile unserer Community, speziell der PASS (www.sqlpass.de) gar nicht genug betonen kann. Damit stehen wir unter allen Produktgruppen bei Microsoft wirklich stark heraus.

• Mehr zum Microsoft Certified Master Programm
  www.microsoft.com/de-de/business/learning/master.aspx
• Die SQL Server Master-Classes von Sarpedon Quality Lab
  www.sarpedonqualitylab.com/SQL_Master-Classes.htm
• Die deutsche SQL Server Community
  www.sqlpass.de

Schöne Grüße

Andreas

Mit diesem Artikel möchte ich gerne ein paar Informationen für diejenigen Leute bereitstellen, die vielleicht planen, den Zertifizierungsmarathon auf sich zu nehmen. Viele MCM haben schon ihre persönlichen Tipps in ihren Blogs verewigt – einige davon habe ich mir bei meinen Vorbereitungen sehr zu Herzen genommen, andere wiederum widersprechen meiner persönlichen Art, Stoff zu lernen und den gelernten Stoff umzusetzen. Eines jedoch gleich vorweg – MCM wird man nicht nur durch Lernen; es bedarf ebenfalls einer breit aufgestellten Erfahrung in den Bereichen “Administration” und “Entwicklung” von und mit Microsoft SQL Server. Ohne diese Erfahrungen – das ist meine Überzeugung – wird  man bei den Tests mit großer Wahrscheinlichkeit scheitern. Ein weiterer wichtiger Punkt; Leidenschaft für die Arbeit mit Microsoft SQL Server. Ohne die notwendige Leidenschaft für seine Arbeit fehlt die erforderliche Motivation, sich intensiv mit einer Sache auseinander zu setzen. Wenn beides stimmt, dann sollte einer Karriere als MCM nichts mehr im Wege stehen…

Dieser Artikel hat mal nicht mit Technik zu tun sondern soll ein wenig meine Freude zum Ausdruck bringen, die ich verspürt habe, als mich eine Email von Bob Taylor (Programm Director MCM Programm) erreichte: Ich habe den LAB-Test für die Zertifizierung zum MCM SQL Server 2008 bestanden. Der “Microsoft Certified Master” ist die höchste technische Auszeichnung, die Microsoft vergibt. Mit diesem Artikel möchte ich den langen – und endlich erfolgreichen – Weg noch einmal reflektieren; in der Hoffnung, dass meine Erfahrungen Anderen dabei helfen können, ebenfalls erfolgreich die MCM-Zertifizierung abzuschließen. Eines gleich vorweg: Wer erwartet, dass ich Hinweise auf Fragen, Lösungen und/oder Lösungswege gebe, den muss ich enttäuschen. Mit der Anmeldung zur MCM-Zertifizierung habe ich gleichzeitig ein NDA (Non Disclosure Agreement) akzeptiert, dass jegliche Weitergabe von Informationen über Fragen oder Lösungen untersagt.

Letzte Woche wurde ich beauftragt, die Ursachen für eine schlechte Performance innerhalb einer Datenbank zu analysieren und gegebenenfalls Hinweise zu geben, wie man die Wartezeiten im Frontend verkürzen kann. Bei der Prüfung der Ausführungspläne und Indexstrukturen ist aufgefallen, dass fast 10% der Relationen HEAPS sind und in vielen Abfragen mit anderen Relationen über JOINS verwendet wurden. Meine erste Empfehlung war demzufolge – basierend auf den Ausführungsplänen – die Implementierung und Verwendung von Clustered Indexes. Da die Anwendung nicht “in House” entwickelt worden ist, wurde sich mit der Bitte um Prüfung und Zusendung von Skripten an den Hersteller gewandt. Das nachfolgende Script soll stellvertretend für den Lösungsansatz des Herstellers dienen. Bei der im Beispiel benannten Relation handelt es sich um eine simple Relation für die Speicherung historischer Daten ohne Fremdschlüssel-Referenzen. 

1. CREATE CLUSTERED INDEX ix_relation_id ON dbo.tbl_relation(id);
2. DELETE dbo.relation WHERE id IN (SELECT id FROM dbo.relation GROUP BY id HAVING COUNT(id) > 1);
3. DROP INDEX ix_relation ON dbo.tbl_relation;
4. ALTER TABLE dbo.tbl_relation ADD CONSTRAINT p_relation_id PRIMARY KEY (id);

Als ich das Script von meinem Auftraggeber erhalten habe, musste ich erst mal tief Luft holen und mich fragen, welcher “Experte” solche Skripte an seine Kunden verschickt. Zunächst wird ein Clustered Index auf dem Attribut [Id] der Relation [dbo].[tbl_relation] erstellt (Zeile 1). Anschließend werden ALLE Datensätze, die eine redundante [Id] besitzen gelöscht (Zeile 2). Nachdem die Daten gelöscht wurden, wird der Clustered Index wieder entfernt und durch einen PRIMARY KEY ersetzt.

Der brisanteste Teil in diesem Script ist sicherlich die Zeile 2; sollen doch tatsächlich Daten aus einem Produktionssystem gelöscht werden ohne diese im Vorfeld in einer Staging-Tabelle zu analysieren. Des Weiteren ist aufgefallen, dass dem Programmierer scheinbar der Unterschied zwischen einem Clustered Index und der Einschränkung eines PRIMARY KEY nicht bekannt ist. Die Intention des Programmierers wird beim Lesen der obigen Skriptzeilen relativ schnell klar; zunächst wird ein “Index” erzeugt, um schnell die redundanten Datensätze zu löschen. Anschließend soll mittels PRIMARY KEY erneut ein Clustered Index erzeugt werden, um unsere Anforderungen zu erfüllen.

Was ist ein Primary Key

Um mitzuteilen, welchen der Schlüsselkandidaten man zur Identifikation eines Datensatzes (Tupel) in einer Relation bevorzugt, wird aus allen Schlüsselkandidaten der Primärschlüssel ausgewählt. Der Primärschlüssel wird üblicherweise so ausgewählt, dass er möglichst klein ist, das heißt möglichst wenige Attribute umfasst bzw. einen möglichst simplen Datentyp hat. Ein Primärschlüssel ist KEIN Index ist sondern eine Einschränkung(CONSTRAINT). Ein Primärschlüssel besitzt die nachfolgenden Besonderheiten:

• Eine Relation kann nur einen PRIMARY KEY besitzen
• In den Attributen des PRIMARY KEY sind keine NULL-Werte zugelassen
• Die Attribute des PRIMARY KEY dürfen nicht redundant sein (doppelte Schlüsselwerte!)
• Die Einschränkung PRIMARY KEY erzwingt immer die Definition eines EINDEUTIGEN Index und nicht zwingend einen CLUSTERED INDEX!
• Ein PRIMARY KEY ist NICHT zwingend für DRI (deklarative referenzielle Integrität)

Die nachfolgenden Beispiele soll die Besonderheiten eines PRIMARY KEY verdeutlichen:

CREATE TABLE dbo.master_table
(
    Id    int       NULL PRIMARY KEY,
    col1  char(20)  NULL
);
GO

Der Aufruf schlägt fehl, da das Attribut [Id] NULL-Werte zulässt während der nächste Aufruf im nächsten Beispiel funktioniert, da die Einschränkung NOT NULL für das Attribut [Id] verwendet wird.

Meldung 8111, Ebene 16, Status 1, Zeile 2 Eine PRIMARY KEY-Einschränkung kann für eine Spalte in der master_table-Tabelle, die NULL zulässt, nicht definiert werden.

CREATE TABLE dbo.master_table
(
    Id    int       NOT NULL PRIMARY KEY,
    col1  char(20)  NULL
);
GO

Sofern für die Relation nicht explizit ein Clustered Index definiert wird, erzeugt SQL Server automatisch für den PRIMARY KEY einen clustered Index. Beweis liefert die Untersuchung der Indexe und Einschränkungen für die zuvor erstellte Relation

SELECT OBJECT_NAME(parent_object_id)  AS table_name,
       k.name                         AS constraint_name,
       k.type                         AS constraint_type,
       k.type_desc                    AS constraint_type_desc,
       unique_index_id,
       is_system_named,
       i.name                         AS index_name,
       i.type_desc                    AS index_type
FROM   sys.key_constraints k LEFT JOIN sys.indexes i
       ON (
            k.parent_object_id = i.object_id AND
            k.unique_index_id = i.index_id
          )
WHERE  parent_object_id = OBJECT_ID('dbo.master_table', 'U');

Das DMO sys.key_constraints enthält jeweils eine Zeile für jedes Objekt, dass entweder eine PRIMARY KEY oder eine UNIQUE Einschränkung besitzt. Die obige Abbildung zeigt, dass der PRIMARY KEY eindeutig ist und der Name der Einschränkung automatisch durch SQL Server erstellt wurde. Handelt es sich um eine eindeutige Einschränkung (UNIQUE), kann der entsprechende UNIQUE Index über die [index_id] der zugehörigen Relation ermittelt werden.

Da eine Einschränkung auch durch individuelle Namensgebung erstellt werden kann, führt das nachfolgende Beispiel ebenfalls zur Erstellung des PRIMARY KEY mit dem Unterschied, dass der Name durch den Ersteller vordefiniert wird.

CREATE TABLE dbo.master_table
(
    Id    int       NOT NULL,
    col1  char(20)  NULL,
    CONSTRAINT pk_master_table_id PRIMARY KEY (Id)
);
GO

Da nun der Name des PRIMARY KEY selbst festgelegt worden ist, ist das Attribut [is_system_named] nun 0. Weitere Einstellungen haben sich nicht geändert. Das ein PRIMARY KEY nicht zwingend ein Clustered Index ist, zeigt das nächste Beispiel sehr deutlich:

CREATE TABLE dbo.master_table
(
    Id    int       NOT NULL,
    col1  char(20)  NULL,
    CONSTRAINT pk_master_table_id PRIMARY KEY NONCLUSTERED (id)
);
GO

CREATE CLUSTERED INDEX ix_master_table_col1 ON dbo.master_table (col1);
GO

Unabhängig von der Existenz eines Clustered Index kann der PRIMARY KEY definiert werden. Da ein PRIMARY KEY nur dann als Clustered Index angelegt wird, wenn noch kein Clustered Index existiert, musste in dem obigen Beispiel der PRIMARY KEY explizit mit der Option NONCLUSTERED definiert werden um eine automatische Erstellung des Clustered Index zu verhindern. Ein Blick auf die Einschränkungen und die vorhandenen Indexe zeigt das Ergebnis.

Wozu wird ein Primary Key verwendet?

Der Sinn und Zweck eines PRIMARY KEY ergibt sich aus den Eigenschaften der Einschränkung selbst. Da ein PRIMARY KEY keine NULL-Werte enthalten darf und eindeutig sein muss, eignet er sich für die Durchsetzung von DRI (Deklarative Referenzielle Integrität).  Unter Referentieller Integrität versteht man Bedingungen, die zur Sicherung der Datenintegrität bei Nutzung relationaler Datenbanken beitragen können. Nach der RI-Regel dürfen Datensätze (über ihre Fremdschlüssel) nur auf existierende Datensätze verweisen.

Danach besteht die Referenzielle Integrität grundsätzlich aus zwei Teilen:

1. Ein neuer Datensatz mit einem Fremdschlüssel kann nur dann in einer Tabelle eingefügt werden, wenn in der referenzierten Tabelle ein Datensatz mit entsprechendem Wert im Primärschlüssel oder einem eindeutigen Alternativschlüssel existiert.
2. Eine Datensatzlöschung oder Änderung des Schlüssels in einem Primär-Datensatz ist nur möglich, wenn zu diesem Datensatz keine abhängigen Datensätze in Beziehung stehen.

SQL Server benötigt für Referenzielle Integrität nicht zwingend einen PRIMARY KEY; vielmehr sind nur die Eigenschaften eines PRIMARY KEY für SQL Server von Relevanz für die Durchsetzung von Referenzieller Integrität. Die beiden nachfolgenden Skriptbeispiele sollen diesen Zusammenhang verdeutlichen. Für die Definition eines Fremdschlüssels ist zwingend erforderlich, dass das Primärattribut der Masterrelation weder NULL-Werte besitzt noch mehrfach vorkommen darf. Das nachfolgende Script wird fehlschlagen, da SQL Server nicht in der Lage ist, eindeutige Schlüsselwerte in [master_table] sicher zu stellen:

CREATE TABLE dbo.master_table
(
    Id   int       NOT NULL,
    col1 char(20)  NULL
);
GO

CREATE TABLE dbo.detail_table
(
    Master_id   int       NOT NULL,
    detail_id   int       NOT NULL,
    col1        char(20)  NOT NULL,

    CONSTRAINT fk_master_table_id FOREIGN KEY (master_id)
    REFERENCES dbo.master_table(Id)
    ON DELETE CASCADE
);

Wird das obige Script ausgeführt, wird der nachfolgende Fehler ausgelöst. Die Fehlerbeschreibung ist selbsterklärend:

Meldung 1776, Ebene 16, Status 0, Zeile 2 In der dbo.master_table-Tabelle, auf die verwiesen wird, befinden sich keine primären oder Kandidatenschlüssel, die mit der verweisenden Spaltenliste im fk_master_table_id-Fremdschlüssel übereinstimmen.

Für eine Fremdschlüsselbeziehung wird ENTWEDER ein PRIMARY KEY oder ein UNIQUE NOT NULL Index benötigt. Statt also eines PRIMARY KEY kann auch eine UNIQUE-Einschränkung verwendet werden. Ändert man das Script zur Erstellung der Relationen wie folgt um, kann die Einschränkung problemlos erstellt werden:

CREATE TABLE dbo.master_table
(
    Id   int       NOT NULL,
    col1 char(20)  NULL,

    CONSTRAINT ux_master_table_id UNIQUE (Id)   
);
GO

CREATE TABLE dbo.detail_table
(
    Master_id   int       NOT NULL,
    detail_id   int       NOT NULL,
    col1        char(20)  NOT NULL,

    CONSTRAINT fk_master_table_id FOREIGN KEY (master_id)
    REFERENCES dbo.master_table(Id)
    ON DELETE CASCADE
);

Das Script läuft fehlerfrei durch und die Fremdschlüssel-Einschränkung wird erstellt, da für das Fremdschlüssel-Attribut [Id] die Einschränkungen “NOT NULL” und “UNIQUE” vorhanden sind. Es bedarf keiner weiteren Einschränkungen mehr. Schaut man sich anschließend die in der Relation [dbo].[master_table] befindlichen Indexe an, stellt man fest, dass die Relation selbst immer noch ein HEAP ist und keinen clustered Index besitzt.

SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID('dbo.master_table', 'U');

Fazit

Die Definition eines PRIMARY KEY für eine Relation hat NICHTS mit der Definition und der Funktionalität eines Clustered Index zu tun. Beide Verfahren sind unabhängig voneinander zu betrachten und verfolgen ganz verschiedene Ansätze. Während ein PRIMARY KEY eine Eigenschaft einer Relation ist, ist der Clustered Index die Relation selbst. Während ein Clustered Index ausschließlich für die physikalische Ordnung der Datensätze verantwortlich ist, dient der PRIMARY KEY der Durchsetzung von klar vordefinierten Vorgaben für das Schlüsselattribut eines Datensatzes (Eindeutigkeit und NOT NULLABLE).

Herzlichen Dank für’s Lesen

• How does DBCC CHECKDB WITH ESTIMATEONLY work (Paul)
• DBCC CHECKDB WITH ESTIMATEONLY: Do you trust it? (Ana)

DBCC CHECKDB runs CHECKALLOC, CHECKTABLE, CHECKCATALOG etc. against database, tables, views and so on. And I have learnded, however CHECKDB is executed against master database, a second CHECKDB is also running internally on the mssqlsystemressource.

So in my way, I want only make consistency check of disk space allocation by DBCC CHECKALLOC WITH ESTIMATEONLY against a ~ 200GB database, to know the estimated amount of tempdb space.

I run following DBCC command on SQL Server 2012 Enterprise Edition:

DBCC CHECKALLOC () WITH ESTIMATEONLY, TABLERESULTS;
GO

And I get this result

Estimated TEMPDB space (in KB) needed for CHECKALLOC on database XXX = 35383596.

OK, nothing special - but I thought about the posts of Ana and Paul, and a blog entry of Running SQP on SQL Server Blog - Faster DBCC CHECKDB Released in SQL 2008 R2 SP1 CU4 : Traceflag 2562 & 2549

So next shot comparing CHECKDB and CHECKALLOC:

DBCC CHECKDB WITH ESTIMATEONLY, TABLERESULTS; 
GO

DBCC CHECKALLOC WITH ESTIMATEONLY, TABLERESULTS;
GO

And the results are diffrent!
For CHECKDB:

Estimated TEMPDB space (in KB) needed for CHECKDB on database XXX = 27165.

And for CHECKALLOC:

Estimated TEMPDB space (in KB) needed for CHECKALLOC on database XXX = 35383596.

This isn't an expected result - what a discrepancy!

By the way I have made a Microsoft Connect entry: http://connect.microsoft.com/SQLServer/feedback/details/787049/discrepancy-by-estimated-tempdb-space-for-checkdb-and-checkalloc-with-estimateonly

So feel free to vote.

I wish you a nice day,
tosc