Archives for: "April 2013"
Conferences 2013: Frankfurter Datenbanktage und einige “Oracle-Momente”
Apr 11th
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
Tracing Analysis Services (SSAS) with Extended Events – Yes it works and this is how
Apr 9th
Tracing Analysis Services mit Extended Events – Ja, es geht, und zwar so
or: “Hasta la vista, Profiler”... ;-)
|
(en) While there is no GUI support for that, yet, it is however possible to set up a XEvent session via DDL commands - just like it was in the “old days” with SQL Server 2008/ 2008 R2, until 2012 brought the GUI. Since I have been asked a lot at my sessions on Extended Events on how it is done in Analysis Services, and the Books Online sample code is not really working (“Use SQL Server Extended Events (XEvents) to Monitor Analysis Services The following code creates a session to collect the deadlocks events from the Analysis Services Instance: |
(de) Obwohl dafür noch keine grafische Unterstützung da ist, ist es jedoch möglich eine XEvent Session über DDL Kommandos aufzusetzen - genau wie in den alten Zeiten” mit SQL Server 2008/ 2008 R2, bis 2012 die GUI brachte. Da ich im Zuge meiner Sessions zu Extended Events häufig gefragt wurde, wie das bei Analysis Services funktioniert, und das Books Online Beispiel nicht wirklich funktioniert (“Use SQL Server Extended Events (XEvents) to Monitor Analysis Services Der folgende Code erzeugt eine Session um Deadlock Events von einer Analysis Services Instanz mitzuschneiden: |
<Create xmlns="http://schemas.microsoft.com/analysisservices/2003/engine"
mlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2"
xmlns:ddl3="http://schemas.microsoft.com/analysisservices/2003/engine/3"
xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100"
xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200"
xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300">
<ObjectDefinition>
<Trace>
<ID>Sarpedon AS Trace Demo</ID>
<Name>Sarpedon AS Trace Demo</Name>
<ddl300_300:XEvent> <event_session name="SQL_AS_XE" dispatchLatency="10" maxEventSize="4" maxMemory="4" memoryPartitionMode="none">
<event package="AS" name="Deadlock" />
<target package="Package0" name="event_file">
<parameter name="filename" value="D:\SQLData\SarpedonASDeadlockTrace.xel" />
</target>
</event_session>
</ddl300_300:XEvent>
</Trace>
</ObjectDefinition>
</Create>
|
As one can see, the definition like session configuration and targets, is quite similar to SQL Server, since it is in fact based on the same architecture. Via the internal system view $system.discover_traces, we can see the active traces on the instance: the “FlightRecorder” which is still using the old-style Tracing technology (I wonder when Microsoft will add a new one just like system_health in SQL Server) and my sample session. You will also note, that the XEvent session’s trace file name is not visible here. |
Wie man sehen kann, ist die Definition wie Session-Konfiguration und Targets recht ähnlich zu SQL Server, da es tatsächlich auf der selben Architektur basiert. Über die interne Systemsicht $system.discover_traces können wir die aktiven Traces auf der Instanz sehen: der “FlightRecorder”, der noch die alte Tracing Technik verwendet (Ich frage mich, wann Microsoft eine Neue, wie die system_health in SQL Server hinzufügen wird), und meine Beispiel-Sitzung. Man sieht auch, das der Trace Dateiname der XEvent-Session hier nicht sichtbar ist. |
|
To access the collected data one can easily stop and delete the session by name as follows: |
Um auf die gesammelten Daten zuzugreifen, kann man die Trace session wie folgt bequem über den Namen beenden und löschen: |
<Delete xmlns="http://schemas.microsoft.com/analysisservices/2003/engine"
xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<Object>
<TraceID>Sarpedon AS Trace Demo</TraceID>
</Object>
</Delete>
|
The collected data can be viewed, aggregated and filtered as normal with the Extended Events Viewer in Management Studio. |
Die gesammelten Daten lassen sich dann wie gewohnt über den Extended Events Viewer in Management Studio ansehen, aggregieren und filtern. |
|
In the detail pane on the bottom you can notice, that I turned on causality tracking here. Hence the activity ID /GUID correlate activity. |
Im Detailbereich kann man sehen, das ich hier auch “Kausalitätstracking” eingeschaltet habe. Daher die activity ID/GUI um Aktivitäten zu korrelieren. |
|
So as you see, for a fact, the Analysis Services engine has been extended to be using the Extended Events architecture for better performing and more flexible Tracing. Have fun, playing around with the sample. :-) From now on there is no excuse any more, to burden an Analysis Server that is already on its knees with Profiler... |
Wie man sehen kann, sind die Analysis Services tatsächlich erweitert worden um die Extended Events Architektur für performanteres und flexibleres Tracing zu verwenden. Viel Spaß beim Herumspielen mit dem Beispiel. :-) Ab jetzt gibt es keine Entschuldigung mehr, einen Analysis Server, der bereits auf den Knien ist, weiter mit dem Profiler zu belasten... |
“Hasta la vista, Profiler” ;-)
|
Hopefully by MCM buddy and friend Reeves Smith will soon write his promised post on Tracing Analysis Services, maybe with a Performance Comparison. |
Hoffentlich wird mein MCM Kollege und Freund seinen versprochenen Post über XEvent Tracing Analsis Services bald einlösen – vielleicht mit einem Performance-Vergleich. |
|
Meanwhile I’d like to refer you to this article from another fellow MCM, Jonathan Kehayas, where you can see the enormous difference in terms of negative performance-impact of tracing via Profiler and SQL Trace vs XEvents: |
Bis dahin verweise ich gerne auf diesen Artikel eines andern MCM Kollegen, Jonathan Kehayas, wo man den gewaltigen Unterschied des negativen Performance-Einflusses von Tracing mittels profiler aund SQL Trace gegenüber Extended Events sieht: |
www.sqlperformance.com/2012/10/sql-trace/observer-overhead-trace-extended-events
|
Update: I conducted an excessive benchmarking on Extended Events and SQL Trace & Profiler myself now. The results ar now public and can be found here: |
Update: Ich habe nun selber ein exzessives Benchmarking zu Extended Events und SQL Trace & Profiler durchgeführt. Die Ergebnisse sind hier nun auch öffentlich und können hier gefunden werden: |
Andreas
Hinweis: es wird noch im 1. HJ 2013 einen zweiten Termin für die Master-Class Seminare zu Extended Events geben (13. und 14. Juni).
Die nächste Möglichkeit ist am 22.11. bzw. 25.11.2013!
