Freitag, 13. Dezember 2013

ORACLE vs. SQL Server: Wie Werbung blind für die Realität macht!

Die Lektüre eines Whitepaper von ORACLE kann einem tatsächlich die Galle hochkommen lassen ob der vielen tollen Dinge, die ORACLE beherrscht; während der Microsoft SQL Server – scheinbar – nur eine bessere Tabellenkalkulation zu sein scheint (so liest sich dieses Whitepaper zumindest). Über eine Beschreibung bin ich gestolpert, über die ich selbst bereits geschrieben habe – die Behauptung von ORACLE ist schlicht und einfach FALSCH!

Behauptung

Im Dokument “Technical Comparision of ORACLE Database 12c vs. Microsoft SQL Server 2012 – Focus on High Availability” (Stand: November 2013) heißt es auf Seite 60:

Fast Online Add Column

With Oracle, adding new columns with DEFAULT value and NOT NULL constraint does not require the default value to be stored in all existing records. Instead, default values of columns are simply maintained in the data dictionary. This not only enables a schema modification in sub-seconds and independent of the existing data volume, it also consumes virtually no space. SQL Server does not offer online add column, as a schema lock is required, nor does it offer this fast add column optimization [22]:”

Mit Fußnote 22 ist ein Link auf die msdn-Seiten von Microsoft verbunden, der die einzelnen LOCK Modes beschreibt (http://msdn.microsoft.com/en-us/library/ms175519.aspx).

Realität

Diese Aussage ist schlicht und einfach falsch. Microsoft SQL Server 2012 speichert bei Erstellung von neuen Attributen mit DEFAULT-Werten diese neuen Werte NICHT in den Datenzeilen. Vielmehr werden DEFAULTS immer als Schema-Informationen in der dmo  [sys].[system_internals_partition_columns] hinterlegt.

SELECT  c.name                    AS column_name,
        pc.modified_count,
        pc.max_inrow_length,
        pc.has_default,
        pc.default_value
FROM    sys.system_internals_partitions p INNER JOIN sys.system_internals_partition_columns pc
        ON (p.partition_id = pc.partition_id) INNER JOIN sys.columns c
        ON (
             p.object_id = c.object_id AND
             pc.partition_column_id = c.column_id
           )
WHERE    p.object_id = object_id('dbo.foo')
ORDER BY
        c.column_id ASC;

Ich habe zu diesem Thema bereits im Juli 2013 einen umfangreichen Artikel mit nachvollziehbaren Beispielen geschrieben, der hier nachgelesen werden kann (“Verhalten von DEFAULT-Einschränkungen bei nachträglich hinzugefügten Attributen”).


Behauptung


Auf Seite 61 des Whitepapers (Stand November 2013) heißt es weiter:
"Invisble Indexes
An Oracle invisible index is an alternative to making an index unusable or dropping it. An invisible index is maintained for any DML operation, but is not used by the optimizer unless the index is explicitly specified with a hint.
Invisible indexes have great uses in application development and testing. Applications often have to be modified without being able to bring the complete application offline. Invisible indexes enable you to leverage temporary index structures for certain operations or modules of an application without affecting the overall application. Furthermore, invisible indexes can be used to test the removal of an index without dropping it right away, thus enabling a grace period for testing in production environments. SQL Server has no such equivalent index capabilities.


Realität


Selbstverständlich verfügt Microsoft SQL Server über “invisible indexes” – sie heißen nur anders – nämlich “hypothetical indexes”. (Korrigiert auf Grund eines – dankenswerten - Hinweis von Sascha Lorenz!) Tatsächlich gibt es keine “invisible Indexes” in Microsoft SQL Server, die der funktionalen Beschreibung entsprechen, wie bei ORACLE. Dennoch gibt es bei Microsoft SQL Server ebenfalls Möglichkeiten, mit Indexen zu testen, die nur und ausschließlich für Testzwecke zur Verfügung stehen – Hypotetische Indexe. Hypothetische Indexe werden vom “Database Tuning Advisor” verwendet, wenn Optimierungen gesucht werden. Die Möglichkeit, diese “hypothetical indexes” auch selbst zu verwenden, stehen jeden Entwickler auch ohne den DTA zur Verfügung. Man muss es nur wissen! Eine Tabelle mit einem Clustered Index liegt in folgender Struktur (ca. 200 Datensätze vor)



CREATE TABLE dbo.Employees
(
    Id         int IDENTITY(1,1)  NOT NULL,
    FirstName  varchar(64)        NOT NULL,
    LastName   varchar(64)        NOT NULL,
    HiredAt    date               NOT NULL,
    FiredAt    date               NULL,
    Manager_Id int                NOT NULL DEFAULT (0),
 
    CONSTRAINT pk_Employees_Id PRIMARY KEY CLUSTERED (Id)
);
GO

Eine Abfrage nach dem Nachnamen ergibt folgenden Ausführungsplan:



SELECT * FROM dbo.Employees WHERE LastName = 'Brown';

EXECUTION_PLAN_01


Um nun zu testen, wird ein hypothetischer Index angelegt und angewendet.



-- Erstellen des hypothetischen Index
CREATE INDEX ix_Employees_LastName ON dbo.Employees (LastName, FirstName)
INCLUDE (HiredAt, FiredAt, Manager_Id) WITH STATISTICS_ONLY;
GO
 
-- Infomationen über Datenbank, Objekt und Index evaluieren
SELECT db_id(), Object_id, index_id FROM sys.indexes WHERE name = 'ix_Employees_LastName';
GO
 
-- Aktivierung des Index für die hypothetische Verwendung
DBCC AUTOPILOT (0, 6, 270624007, 8)
GO
 
-- Autopilot aktivieren
SET AUTOPILOT ON;
GO
 
-- Abfrage ausführen (und freuen)
SELECT * FROM dbo.Employees WHERE LastName = 'Brown';
GO
 
-- Autopilot wieder deaktiveren
SET AUTOPILOT OFF;
GO

Der Ausführungsplan für die Abfrage nach dem Nachnamen sieht nun folgendermaßen aus:


EXECUTION_PLAN_02

Anschließend kann der Index wieder gelöscht werden. Wichtig ist hierbei, dass der Index eben NICHT manifestiert ist sondern ausschließlich für die Bewertung der Ausführungsstrategie verwendet wird.

Zusammenfassung


Vielleicht bin ich einfach nur altmodisch - Microsoft ist auch in vielen Dingen nicht fair gegenüber dem Markt - aber ich wünsche mir, die Unternehmen würden sich mehr auf die Qualität der eigenen Produkte konzentrieren statt irgendwelche Vorteile des Produkts darzustellen, die der Konkurrent – angeblich – nicht kann oder hat! Und wenn schon Produktvergleiche herangezogen werden, dann sollten sie einfach besser recherchiert sein.


Ein ähnlich unfaires Verhalten hat ORACLE bereits zum Thema “HEKATON” gezeigt:
Thomas La Rock: http://thomaslarock.com/2012/11/are-the-bells-tolling-for-oracle/
SQL Server Blog (SQL Server Team): http://blogs.technet.com/b/dataplatforminsider/archive/2012/11/20/oracle-surprised-by-the-present.aspx


Nachtrag


Meine obige Aussage muss ich selbstkritisch relativieren. Wie schnell passiert es, dass Behauptungen aufgestellt werden, die sich dann als unwahr herausstellen; so ist es mir selbst in diesem Artikel auch passiert. Hier möchte ich mich erneut bei Sascha Lorenz bedanken, der mich auf diesen Fehler mit dem “invisible Index” hingewiesen hat. Vielleicht revidiert ORACLE ja auch einige Passagen in seinem beschriebenen Whitepaper, weil man dort zu der Erkenntnis gekommen ist, dass eben nicht alle Behauptungen der Wahrheit entsprechen!


Herzlichen Dank fürs Lesen!

Kommentare :

  1. Sorry auch, aber Invisible Indexes in Oracle und Hypothetical Indexes in SQL Server sind nicht vergleichbar. Invisible Indexes sind tatsächlich vorhanden, aber "unsichtbar" für den Optimizer, während hypothetical Indexes nicht physisch existieren, bzw. nur ihre Statistik und für ganz andere Zwecke genutzt werden. Werbung hin oder her, wir sollten fair bleiben. ;-)

    AntwortenLöschen
  2. Hallo Sascha,

    Danke für den Hinweis. Tatsächlich hätte ich da etwas Sorgfalt walten lassen müssen.
    Wird auf jeden Fall mit dem entsprechenden Hinweis geändert.

    Gruß, Uwe

    AntwortenLöschen
  3. nur als kleine Ergänzung: hypothetische Indizes (ohne physikalische Indexstruktur - also Objekte, die zur Prüfung von Zugriffsstrategien verwendet werden können) kann man in Oracle auch erzeugen (mit dem Schlüsselwort NOSEGMENT): http://richardfoote.wordpress.com/2008/01/11/introduction-to-fake-virtual-nosegment-indexes/.

    Dass die Marketing-Abteilungen der großen RDBMS-Hersteller die Tatsachen gerne mal außer Acht lassen, ist sicher richtig - aber das ist wohl der Job von Marketing-Abteilungen...

    Viele Grüße

    Martin Preiss

    AntwortenLöschen