Sequenzgenerator

in der Reihe "Wie sag ich's dem SQL Server?" hier ein Beitrag zum Thema Sequenzgenerierung:

Oracle:

SQL> select rownum
  2    from dual
  3  connect by level <= 10;

    ROWNUM
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10

9 Zeilen ausgewählt.

MS SQL

With NumberSequence 
as
( Select 1 as Number
   union all
  Select Number + 1
    from NumberSequence
   where Number < 10
 )
Select * From NumberSequence

1
2
3
4
5
6
7
8
9
10

Wie bei den hierarchischen Queries verwendet Microsoft also auch hier ein rekursives Verfahren, das zwar etwas umständlicher ist als die Oracle-Lösung, aber durchaus nachvollziehbar. Eine ausführlichere Erläuterung zum Thema findet sich hier.

Aktuelles Datum

Da ich immer mal wieder danach suche, hier ein paar Queries, um das aktuelle Datum in unterschiedlichen RDBMS zu ermitteln:

-- Oracle
select sysdate
  from dual;

-- DB2
select current date 
  from sysibm.sysdummy1;

-- MS SQL
SELECT GETDATE();

Ein ambitionierterer Eintrag könnte jetzt der Frage nachgehen, warum Oracle und DB2 eine Dummy-Tabelle einsetzen und der SQL Server darauf verzichtet, aber das schenke ich mir für diesmal. Ursprünglich wollte ich den Eintrag ''Stein von Rosette'' nennen, nehme aber an, dass er auch dazu zu kurz wäre...

Bitmap- und B-Tree-Indizes

Jonathan Lewis erläutert in seinem Blog ein paar grundsätzliche Eigenschaften von Bitmap- und B-Tree-Indizes. Nichts, was nicht auch anderswo zu finden wäre, aber wie üblich äußerst präzise.

Analytics und Sortierungen

Schon vor einiger Zeit hat Jonathan Lewis ein recht erschreckendes Beispiel für die Probleme mit umfangreichen Sortierungen beim Einsatz von Analytischen Funktionen vorgestellt. Dort erklärt er schließlich:

The code to handle analytic sorts (the WINDOW SORT operation) has some serious defects which show up if the sort spills to disc – and a sort of more the 100MB will spill to disc if you set workarea_size_policy to auto – no matter how large your pga_aggregate_target (and the derived _smm_max_size).

Vermutlich ist es in der Regel die bessere Idee, Analytics eher für übersichtlichere Datenmengen zu verwenden.

Umwandlung von parent-child-Hierarchien

nachdem ich bei ähnlichen Fragestellungen in der Vergangenheit zu recht bizarren Lösungen unter Einsatz der sys_connect_by_path-Funktion und Parsen des gelieferten Strings über substr und instr gekommen war, bin ich inzwischen klüger geworden (möglicherweise auch nach Betrachtung der Erläuterungen zur neuen recursive subquery factoring Syntax bei Rob van Wijk) und habe folgende recht harmlose Query zum Umbau einer parent-child-Hierarchie in eine nicht normalisierte Matrix mit n-Ebenen geschrieben:

with
groups as
(select groupid 
      , groupname
      , parentid
   from ext_groups)
select ig0.groupid groupid_level0
     , ig0.groupname groupname_level0
     , ig1.groupid groupid_level1
     , ig1.groupname groupname_level1
     , ig2.groupid groupid_level2
     , ig2.groupname groupname_level2
     , ig3.groupid groupid_level3
     , ig3.groupname groupname_level3
     , ig4.groupid groupid_level4
     , ig4.groupname groupname_level4
  from 
       -- Root-Ebene
       (select *
          from groups
         where parentid = 0
        ) ig0
       -- Ebene 1
     , (select *
          from groups
        ) ig1
       -- Ebene 2
     , (select *
          from groups
        ) ig2
       -- Ebene 3
     , (select *
          from groups
        ) ig3
       -- Ebene 4 (= Branch-Ebene)
     , (select *
          from groups
        ) ig4
 where ig1.parentid = ig0.groupid
   and ig2.parentid = ig1.groupid
   and ig3.parentid = ig2.groupid
   and ig4.parentid = ig3.groupid
 order by ig0.groupid
        , ig1.groupid
        , ig2.groupid
        , ig3.groupid
        , ig4.groupid

Dabei werden die relevanten Spalten der Basistabelle (in diesem Fall eine external table) ext_groups über subquery factoring als groups verfügbar gemacht, dann auf Root-Ebene alle Elemente mit der parentId 0 ausgewählt (hier könnte natürlich auch ein NULL-Wert stehen) und anschließend alle weiteren Ebenen über Joins = angeschlossen. Das Verfahren sollte auch für unbalancierte Hierarchien funktionieren, dabei müsste man sich aber noch Gedanken über die Formulierung der Outer-Joins machen.

SSAS Musings

für den unwahrscheinlichen Fall, dass außer mir jemand diese Einträge liest, hier der Hinweis auf zwei weitere (allerdings englischsprachige) Blogs, zu denen ich beitrage bzw. beitragen kann|werde:

SSAS Musings: wo diverse Einsichten zum Verhalten der SQL Server Analysis Services (SSAS) gesammelt werden
ROLAP Musings: wo relationale Dinge erhellt werden sollen (was sich unter Umständen mit diesem Blog überschneiden könnte)

Consistent Gets

Mal wieder ein Link, diesmal zum Thema constistent gets und auf den Blog von Harald van Breederode. Erläutert wird, wieso der Zugriff auf eine Tabelle, die nur einen Block umfasst, 8 consistent gets benötigt (3 sind bereits für den Zugriff auf eine leere Tabelle erforderlich, die übrigen ergeben sich aus der verwendeten array size). Erhellend sind auch die Hinweise auf die Effekte von Gruppenfunktionen, Lesekonsistenz und Veränderungen der HWM. Da es gute Gründe gibt, die Anzahl der consistent gets als zentrales Kriterium für die Performance einer Query anzusehen, sollte man (also ich) sich diese Details merken.

Systemstatistiken

Eine schöne und kompakte Einführung zur Rolle der Systemstatistiken für die Kostenberechnung des CBO findet man bei Richard Foote. Dort findet sich auch die grundlegende Berechnungsformel, die Jonathan Lewis in seinem CBO-Buch erläutert, und die ich vor einiger Zeit hier als Erinnerungshilfe hinterlegt hatte.