Probleme im Griff mit Extended Events

Beson­ders bei kom­ple­xen Pla­nungs­an­wen­dun­gen oder umfang­rei­che­ren ETL-Vor­gän­gen erschlie­ßen sich man­che SQL-Ser­ver-Pro­ble­me nur bei genau­er Betrach­tung aller invol­vier­ten Fak­to­ren. Ist rei­nes Log­ging“ nicht mehr genug oder kommt eine Live-Betrach­tung in Fra­ge, soll­te statt zu dem Tool SQL Ser­ver Pro­fi­ler“ zu dem Tool Exten­ded Events“ gegrif­fen wer­den. Exten­ded Events“ ist seit dem SQL Ser­ver 2008 ver­füg­bar und ab dem SQL Ser­ver 2012 direkt inte­griert.

In die­sem Bei­trag zei­gen wir, wel­che Mög­lich­kei­ten mit Exten­ded Events“ zur Ver­fü­gung ste­hen. Dabei erläu­tern wie anhand von Pra­xis­bei­spie­len die Vor­ge­hens­wei­se. wei­ter­le­sen…

SQLCMD – Das kleine Schweizer Taschenmesser für die Kommandozeile

In die­sem Bei­trag erläu­tern wir die Funk­ti­ons­wei­se und die Ein­satz­mög­lich­kei­ten von SQLCMD. SQLCMD ist ein klei­nes Hilfs­pro­gramm, das über den OLEDB Pro­vi­der eine Ver­bin­dung zum SQL-Ser­ver auf­baut. Es über­mit­telt SQL-Kom­man­dos und -Skrip­te, ohne dass das Micro­soft SQL Manage­ment Stu­dio erfor­der­lich ist. Wir erklä­ren den grund­sätz­li­chen Syn­ta­x­auf­bau und zei­gen gän­gi­ge State­ments. Anhand von eini­gen Bei­spie­len stel­len wir zudem die Ein­satz­mög­lich­kei­ten vor. wei­ter­le­sen…

Minerva: Die Bissantz-Codebibliothek

In die­sem Bei­trag geht es um die klei­ne Anwen­dung Miner­va“, die Con­sul­tants bei Bis­santz in Pro­jek­ten nut­zen, um auch off­line auf eine zen­tra­le Samm­lung von SQL- und MDX-Code-Snip­pets zuzu­grei­fen. Wir geben einen kur­zen Über­blick über Instal­la­ti­on, Funk­tio­na­li­tät und Archi­tek­tur von Miner­va. wei­ter­le­sen…

Schlüssel sind wichtig. Manchmal aber auch störend.

In unse­ren mit dem Delta­Master Mode­ler auf­ge­bau­ten Daten­ban­ken exis­tie­ren auf allen Dimen­si­ons- und Fak­ten­ta­bel­len Schlüs­sel- und Fremd­schlüs­sel­be­zie­hun­gen. Die­se Tat­sa­che ist uner­läss­lich, will man im Anschluss eine funk­tio­nie­ren­de OLAP Daten­bank­ar­chi­tek­tur auf­bau­en. Jedoch kommt es zuwei­len vor, dass gera­de in gro­ßen und umfang­rei­chen nächt­li­chen Trans­form­pro­zes­sen genau eine, im Ide­al­fall sogar iso­liert betracht­ba­re, Befül­lungs­pro­ze­dur eine Schlüs­sel­ver­let­zung her­vor­ruft. wei­ter­le­sen…

SUM-Where OVER the rainbow

Bereits 2007 haben wir uns in unse­rem Blog Gedan­ken gemacht, wie lan­ge OLAP-Daten­ban­ken wohl noch über­le­ben wer­den. Im Zeit­al­ter des Delta­Master Import­Wiz­zard kommt man auch tat­säch­lich ab und an ins Grü­beln, wozu man die­se Form der Daten­ban­ken über­haupt noch benö­tigt? Bei genau­er Betrach­tung fin­det man aber schnell zahl­rei­che Grün­de, war­um wir immer noch lie­ber Wür­fel als Tabel­len bau­en. Neben dem deut­lich schnel­le­ren Aggre­ga­ti­ons­ver­hal­ten einer mult­idi­men­sio­na­len Daten­bank zählt auch die MDX-Zeit­in­tel­li­genz nach wie vor zu den Plus­punk­ten. Rela­tio­nal Kumu­lie­ren bei­spiels­wei­se erzeugt bei einem T-SQL-Pro­gram­mie­rer nach wie vor ein flau­es Gefühl in der Magen­ge­gend.
2012 ist jetzt auch Micro­soft auf die Idee gekom­men und sagt ihrer eige­nen OLAP-Daten­bank den Kampf an. Mit dem neu­en Tabu­lar Mode“ und der Abfra­ge­spra­che DAX des SQL Ser­vers 2012 gibt Micro­soft ein deut­li­ches State­ment für rela­tio­na­le Daten­ban­ken ab. Im Zuge des­sen wur­den auch Imple­men­tie­rungs­lü­cken bereits exis­tie­ren­der T-SQL-Befeh­le beho­ben, so dass künf­tig eine rela­tio­na­le Kumu­la­ti­on einem Pro­gram­mie­rer nur noch ein müdes Lächeln ins Gesicht zau­bern wird.
Wenn Sie wis­sen wol­len wie, dann fol­gen Sie mir ein­fach auf dem Weg zum Ende des Regen­bo­gens… wei­ter­le­sen…

Einsatz von Merge bei Historisierung von Attributen (Teil 2)

In mei­nem letz­ten Bei­trag lern­ten wir wie die Inhal­te zwei­er Tabel­len, mit Hil­fe von MERGE”, syn­chro­ni­siert wer­den kön­nen. Heu­te schau­en wir uns an, wie MERGE” uns bezüg­lich His­to­ri­sie­rung der Daten behilf­lich sein kann.
Sicher kön­nen Sie sich noch an die His­to­ri­sie­rung von Attri­bu­ten erin­nern? (Bei­trag vom Juni 2011: His­to­ri­sche Betrach­tung von Stamm­da­ten im Data Wareh­ou­se).
Dort wur­de zusätz­lich zu meh­re­ren Lösungs­an­sät­zen auch der opti­ma­le Ansatz vor­ge­stellt, näm­lich das His­to­ri­sie­ren durch Zeit­be­trach­tung. Dabei kamen Update- und Insert-State­ments zum Zuge.
Die Ansät­ze, um Ände­run­gen in Dimen­si­ons­ta­bel­len zeit­be­zo­gen zu erfas­sen und gege­be­nen­falls his­to­risch zu doku­men­tie­ren, sind auch unter dem Begriff Slow­ly Chan­ging Dimen­si­ons” Typ 2 (deutsch: sich lang­sam ver­än­dern­de Dimen­sio­nen) bekannt.
Man kann mit dem MER­GE-Befehl von SQL Ser­ver 2008 die Pfle­ge einer Typ 2 Slow­ly Chan­ging Dimen­si­on (SCD) in einem Data Wareh­ou­se in nur einem Befehl erle­di­gen.
Schau­en wir uns ein­mal alle mög­li­chen Fäl­le bei einem Slow­ly Chan­ging Dimen­si­ons” (SCD2) an. wei­ter­le­sen…

NOT IN = NOT EXPECTED

Da pro­gram­miert man schon Jahr­zehn­te lang T-SQL und erlebt doch noch Über­ra­schun­gen bei ver­meint­lich ein­fa­chen Befeh­len. Jüngst haben wir in einer Kun­den­um­ge­bung ver­schie­de­ne Opti­mie­run­gen durch­ge­führt und unter ande­rem NOT IN Befeh­le durch LEFT JOINs aus­ge­tauscht. Erwar­tet haben wir ein iden­ti­sches Abfra­ge­er­geb­nis bei deut­lich bes­se­rer Per­for­mance. Aber weit gefehlt. Aus einem uns zu dem Zeit­punkt noch nicht bekann­ten Grund lie­fer­te die lin­ke Ver­bin­dung“ ein voll­kom­men ande­res Ergeb­nis als das zuvor ver­wen­de­te IN-Kom­man­do. Nach einer lang­wie­ri­gen Suche, mit wie­der­hol­ten Zwei­feln an der eige­nen Fach­kom­pe­tenz, haben wir den Grund schließ­lich gefun­den. Und wie sich her­aus­ge­stellt hat, ist die­ser selbst für vie­le alte Hasen“ über­ra­schend. Also las­sen auch Sie sich über­ra­schen und nicht trau­rig sein – Sie sind in bes­ter Gesell­schaft… ;o) wei­ter­le­sen…

Partitionierte Tabellen – Faktenladen mit Fast = TRUE” (Teil 2)

Uuuund Action! Wie im ers­ten Teil die­ses Bei­trags­the­mas beschrie­ben, schau­en wir uns heu­te die vor­be­rei­te­ten par­ti­tio­nier­ten Tabel­len in Akti­on an. Im ers­ten Teil haben wir im SQL Ser­ver die not­wen­di­gen Par­ti­tio­nie­rungs­ob­jek­te ange­legt und die­se bereits auf eine Fak­ten­ta­bel­le ange­wen­det. Im zwei­ten Teil ver­su­chen wir jetzt, neue Daten in die Fak­ten­ta­bel­le zu impor­tie­ren. Dies geschieht nicht wie sonst üblich per DELETE und INSERT, son­dern mit einem soge­nann­ten Par­ti­ti­on Swap“. Der vor­lie­gen­de Arti­kel zeigt die not­wen­di­ge Syn­tax, beleuch­tet die Restrik­tio­nen und zeigt wie viel Opti­mie­rung die Par­ti­tio­nie­rung wirk­lich bringt. wei­ter­le­sen…

Partitionierte Tabellen – Faktenladen mit Fast = TRUE” (Teil 1)

Das sagen­um­wo­be­ne Flag Fast = TRUE“ hat sich wohl jeder IT-ler in sei­nem Leben schon ein­mal gewünscht. Micro­soft ver­spricht spä­tes­tens ab SQL-Ser­ver-Ver­si­on 2005 eine Opti­on, die die­sem Flag schon ziem­lich nahe kommt. Die Rede ist hier von der Mög­lich­keit, Tabel­len zu par­ti­tio­nie­ren. Dies soll deut­li­che Per­for­mance­ge­win­ne ins­be­son­de­re beim Laden und Ver­wal­ten von umfang­rei­chen Fak­ten­da­ten ermög­li­chen. Der Clou dar­an ist, dass ein­zel­ne Tabel­len­par­ti­tio­nen einer Fak­ten­ta­bel­le ein­fach gegen eine struk­tur­i­den­ti­sche Del­ta­ta­bel­le aus­ge­tauscht wer­den kön­nen. Bei die­ser Ope­ra­ti­on wer­den ledig­lich Meta­da­ten ver­än­dert, was nur einen Bruch­teil der Zeit eines ech­ten Daten­im­ports benö­ti­gen soll.
Die Restrik­tio­nen, das all­ge­mei­ne Vor­ge­hen sowie die tat­säch­li­chen Per­for­mance­ge­win­ne beim Par­ti­tio­nie­ren wer­den in Teil 1 und 2 des nach­fol­gen­den Arti­kels betrach­tet. wei­ter­le­sen…