Neuerungen bei MS SQL Server 2012 - RWTH
Werbung
Umstellung von Team4-Komponenten auf den StandardProtokoll-Mechanismus von Microsoft SQL Server 2012 Johann Jansen y Alegret Team4 GmbH Seminarvortrag WS2011/2012 27.01.2012 Inhalt 1. Grundlagen Microsoft SQL Server Integration Services - SSIS Überblick Control Flow Data Flow Connection Manager Erweiterungen von Team4 für SSIS Neuerungen bei MS SQL Server 2012 2. Aufgabenstellung 3. Analyse Team4 MS SQL 2012 GAP-Analyse 4. Beschreibung einer möglichen Realisierung 5. Fazit und Zusammenfassung 1. Grundlagen Microsoft SQL Server Integration Services - SSIS Überblick über SSIS Die SQL Server Integration Services sind ein Bestandteil von Microsoft SQL Server (MS SQL) seit Version 2005 Technologie zur graphischen Erstellung von ETL- und anderen Prozessen als SSISPaketen Entwicklung mit dem Business Intelligence Development Studio, das in Microsoft Visual Studio eingebettet ist. Zwei verschiedene Ebenen der Konfiguration: Control Flow und Data Flow Standardschnittstellen zu verschieden gängigen Datenbanksystemen und Dateitypen. Diese benutzen üblicherweise Connection Manager SSIS erweitert durch Team4-Komponenten SQL Server enthält Integration Services, eine konfigurierbare, programmierbare, hochleistungs ETLEngine (Extraction, Transformation, Load) Team4 Microsoft Dynamics CRM Connector for SSIS Team4 Lotus Notes Connector for SSIS 5 Control Flow Data Flow Connection Manager Erweiterungen von Team4 für SSIS Team4 Microsoft Dynamics CRM Connector for SSIS Team4 Connection Manager Team4 Lotus Notes Connector for SSIS Team4 Log Task for SSIS Protokollierung T4LogHdr T4LogBody PK PK FK1 FK1 ProcName StartTime MsgTime ObjType Status Indent Msg n Team4-Datenbankstruktur 1 ProcName StartTime EndTime RunTime Status Log-Report Bisher: eigene Datenbank SSIS_Log Connection Manager für SSIS_Log notwendig Meldungen wurden in zwei Tabellen der Datenbank gespeichert: T4LogHdr und T4LogBody Ausschließlich Team4Komponenten Team4 Log Report Warum hat Team4 diesen Weg der Protokollierung gewählt? Bisher gab es zum Protokollieren nach Microsoft Standard nur die Möglichkeit, einen Log-Provider auszuwählen, von denen es viele verschiedene gab. Diese Log-Provider hatten sehr unterschiedliche Ziele, z.B. das Windows-Log, eine Textdatei oder eine eigene Datenbankstruktur. Es musste bei der Entwicklung der Paketen ausgewählt werden, welche Events behandelt werden sollte. Nachträglich konnte nicht bei der Ausführung die protokollierten Events geändert werden. Es gab keine standardisierten mitgelieferte Log-Reports. Die Entwicklung eines Log-Reports war nicht so zielführend, da dieser nur für einen bestimmten Typ von Log-Provider angewendet werden könnte, von denen es aber sehr viele gab. Neuerungen bei MS SQL Server 2012 Project Deployment Model Neue Möglichkeit Pakete zu veröffentlichen: (Project Deployment Model anstatt Legacy Deployment Model). Für dieses Modell ist es nötig, einen dazugehörigen SSIS-Katalog anzulegen, eine neuartige Datenbankstruktur. Ein ganzes Projekt bestehend aus Paketen und Parametern wird als ganzes in einer Projektdatei veröffentlicht, anstatt, dass alle Paketen und Konfigurationen einzeln veröffentlicht werden müssen. Projekte werden in den Katalog veröffentlicht, anstatt wie vorher in die Systemdatenbank MSDB oder ins Dateisystem Parameter werden anstatt von Konfigurationen verwendet Parameter werden direkt Katalog gespeichert anstatt in Konfigurationsdateien Events werden bei der Ausführung automatisch gefangen und im Katalog protokolliert. Vorher mussten dafür Log-Provider hinzugefügt werden. SSIS-Katalog Übersicht über den Katalog und ein Standard-Reports von MS SQL Server 2012 Protokollierung im SSIS-Katalog catalog_encryption_keys (internal) data_type_mapping (internal) catalog_properties (internal) property_name mapping_id key_id ssis_data_type key_name object_parameters (internal) executables (internal) parameter_id executab... project_id project_id object_versions (internal) project_version_lsn project_... object_versio... object_type package... object_id object_name package... object_type parameter_name description parameter_data_... created_by executable_statistics (internal) required created_time sensitive statistics_id execution_data_taps (internal) executio... description data_tap_id packages (internal) executab... execution_id package... executio... package_path operation_os_sys_info (internal) project_... start_time dataflow_path_id_str... name Database Schema?????? end_time info_id package... operation_id description execution_component_phases (internal) total_physical_memory... available_physical_me... package... phase_stats_id version_... execution_id version_... package_name operations (internal) version_... package_location_type executions (internal) operatio... operatio... executio... created_... folder_n... object_t... project_... extended_operation_info (internal) package_path_full folder_permissions (internal) task_name id subcomponent_name info_id sid operation_id object_id package... object_id object_name object_n... referenc... status referenc... start_time environ... execution_parameter_values (internal) permission_type object_type execution_parameter_id reference_id execution_id object_type end_time folders (internal) parameter_data_type folder_id parameter_name projects (internal) name parameter_value project_id description sensitive_parameter_value folder_id created_... environment_references (internal) reference_id name project_id environment_variables (internal) environments (internal) description execution_property_override_values (internal) execution_data_statistics (internal) property_id data_stats_id execution_id execution_id package_name property_path package_location_type variable_id project_f... environment_id deploye... name deploye... environm... folder_id description property_value description type package_path_full project_permissions (internal) task_name id dataflow_path_id_string environment_permissions (internal) operation_permissions (internal) id object_id permission_type validations (internal) event_messages (internal) event_message_context (internal) operation_messages (internal) validati... event_m... operation_id event_message_id context_depth package_path context_type Neue Datenbank für Log environ... operation... operation_message... execution... validate... operation_id package_... folder_n... message_time project_... package_... message_type package_... event_na... sid id object_id sid permission_type object_id permission_type sid context_id reference_type environment_folder_name environm... 2. Aufgabenstellung Machbarkeitsstudie zur Umstellung der SSIS-Komponenten von Team4 auf den Protokoll-Mechanismus von MS SQL Server 2012 (Proof of Concept) Folgende Fragen ergeben sich: Welche Informationen werden bisher erfasst? Könnten diese Informationen weiterhin erfasst werden? Welche Unterschiede zwischen den Mechanismen existieren? Ist eine Umstellung möglich? Wie würde die Umstellung durchgeführt werden? Gibt es nach der Umstellung gravierende Unterschiede? Welcher Zeitaufwand ist notwendig? Lohnt sich die Umstellung? 3. Analyse Anforderungen an die Protokollierung aus Sicht Team4 Startzeitpunkt des Paketes Name des Paketes Text der Meldung Ursprungskomponente der Meldung Zeitpunkt der Meldung Status der Meldung Zusammenfassung und Details in Form eines Log-Reports Flexibilität soll erhalten bleiben. D. h., dass beliebige Meldungstexte verwendet werden können. Konzept der Protokollierung bei MS SQL Server 2012 Event-basiert Meldungen unterscheidbar durch Event-Typ Umfassendes Protokoll mit komplexem Datenmodell Abhängig von Log-Level bei Ausführung 4 Log-Level: None, Performance, Basic, Verbose Alle Komponenten, die dem Standard entsprechen, protokollieren in dieselbe Struktur Standard-Reports können genutzt werden Kein Connection Manager für Protokoll notwendig GAP-Analyse Log-Level wird bei jeder Ausführung im SSIS-Katalog neu festgelegt, anstatt bei der Erstellung des Paketen Log-Level kann nicht mehr in jeder verwendeten Komponente einzeln eingestellt werden Es gibt nur noch 4 Stufen anstatt 6 Es werden Meldungen von allen Komponenten erfasst anstatt nur von Team4Komponenten Nachteil: Bei einer Ausführung außerhalb des SSIS-Kataloges findet keine Protokollierung statt. Abhilfe dafür bieten LogProvider. Diese benutze allerdings eigene Speicherstrukturen außerhalb des SSIS-Kataloges, sodass Informationen evtl. mehrfach gespeichert werden. Aus dem umfangreichen Protokoll muss die Kerninformation für den Log-Report extrahiert werden Neue Tabellen enthalten benötigte Informationen über Startzeitpunkt des Paketes, Name des Paketes, Text der Meldung, Ursprungskomponente der Meldung, Zeitpunkt der Meldung, Status der Meldung(ergibt sich aus dem Event-Typ) 4. Beschreibung einer möglichen Realisierung Umstellung der Komponenten Bisher wurde bei Team4-Komponenten für Protokollmeldungen Tabelleneinträge in die SSIS_Log-Datenbanktabelle T4LogBody Stattdessen sollen Protokollmeldungen jetzt bei MS SQL 2012 einen Event auslösen, der auch im SSIS-Katalog erfasst wird Für das Protokollverfahren wird von allen Komponenten eine gemeinsame Bibliothek von Team4 verwendet. Diese muss verändert werden Auch die Masken der Team4-Komponenten müssen angepasst werden: Es soll nicht mehr die Möglichkeit geben, den Log-Level bei den Komponenten anzugeben, denn dieser soll durch die Ausführung im Katalog als Parameter bestimmt werden. Kein Connection Manager für das Protokoll soll mehr notwendig sein bei der Nutzung von Team4 Komponenten 5. Fazit und Zusammenfassung Zusammenfassung Eine 100%ig im Ergebnis identische Umstellung ist nicht möglich. Die Informationen, die zur Auswertung der Protokolls geschrieben werden, sind in verschiedenen Datenbankstrukturen gespeichert. Alle wichtige Informationen wie Art der Meldung, Meldungstext, Zeitpunkt und Komponente sind aber nach wie vor vorhanden. Größter Vorteil ist, dass Meldungen von allen Komponenten gemeinsam protokolliert werden, nicht nur die von Team4. Standardisierte Reporte können zur Auswertung des Protokolls verwendet werden. Eine Zertifizierung von Microsoft ist nur möglich unter der Nutzung des Standards. Der Aufwand der Umstellung ist überschaubar. Fazit Die Umstellung ist möglich. Der Aufwand dafür ist überschaubar. Durch eine Zertifizierung von Microsoft erhöhen sich die Marktchancen. Die Umstellung ist möglich und sinnvoll für Team4! Fragen?
