Verteilte Verarbeitung in in SQL Server Technologie Memo April 2006 Dr. Arno Schmidhauser

Größe: px
Ab Seite anzeigen:

Download "Verteilte Verarbeitung in in SQL Server 2005. Technologie Memo April 2006 Dr. Arno Schmidhauser"

Transkript

1 Verteilte Verarbeitung in in SQL Server 2005 Technologie Memo April 2006 Dr. Arno Schmidhauser

2 Inhalt 1 Referenz Einleitung Lokale Transaktionen Isolationsgrade Verteilte Transaktionen Partitionierung Replikation Partitionierung und Replikation...23 Technologie Memo Arno Schmidhauser 2

3 1 Referenz Die folgenden Kapitel beziehen sich auf Microsoft SQL Server 2005, Version Einleitung In diesem Technologie-Memo wird auf verschiendene Aspekte der Transkationssteuerung in SQL Server 2005 eingegangen. Insbesondere werden die Möglichkeiten zur Verwaltung verteilter Datenbestände besprochen. Hierzu gehören die Abwicklung verteilter Transaktionen, die Optimierung des Datenzugriffs in verteilten Transaktionen, die Partitionierung von Tabellen und die Replikation von Daten auf verschiedene Datenbank- Knoten, sowie neue Ansätze des Concurrency Control. Es wird nur über Mechansimen gesprochen, die innerhalb der Datenbank aufgebaut und konfiguriert werden können, und gegenüber Applikationen, die mit SQL- Befehlen auf die Datenbank zugreifen, transparent sind. In vielen Fällen ist dies als Vorteil anzusehen, da der Data-Tier gegenüber den Applikationen (Business Logic) als einheitliches, konsistentes Gesamtsystem in Erscheinung tritt. Der Nachteil kann darin liegen, dass für kleine Datenbankhersteller nur eingeschränkte Schnittstellen-Module (Minimaler ODBC) zur Verfügung stehen, welche die Server-to-Server Kommunikation einschränken. 3 Lokale Transaktionen Explizite Transaktionen werden mit BEGIN TRANSACTION gestartet. Sie können verschachtelt sein, aber nur das äusserste Commit/Rollback hat tatsächlich Auswirkungen auf die Datenbank. Defaultverhalten ist autocommit. Mit SET IMPLICIT_TRANSACTIONS ON wird auf verkettete Transaktion umgeschaltet. Das heisst nur commit und rollback werden explizit abgesetzt. Das Transaktionslog in SQL Server ist eine wesentliche Komponente für o Transaktions-Recovery o Incremental Online-Backup o Erzeugen von Snapshot-Datenbanken o Replikation von Daten Technologie Memo Arno Schmidhauser 3

4 4 Isolationsgrade Beim konkurrierenden Zugriff auf Daten durch mehrere Prozesse spielt die Art der Zugriffssteuerung eine entscheidende Rolle für die Performance (Gesamtdurchsatz an Transaktionen) der Datenbank. Die Zugriffssteuerung muss auf Anforderungen Rücksicht nehmen, die teilweise gegeneinander wirken: Hohe Parallelität aller zugreifenden Prozesse, möglichst wenig Wartesituationen. Ein Prozess soll durch Änderungen von anderen Prozessen nicht beeinflusst werden. Es dürfen keine Inkonsistenzen entstehen, weil zwei Prozesse gleichzeitig mit der Datenbank arbeiten (Isolation, Serialiserbarkeit). Möglichst wenig Deadlocks sollen auftreten (Deadlocks sind prinzipiell unmvermeidlich). Transaktionssicherheit muss gewährleistet werden, das heisst ein Rollback muss zu jedem Zeitpunkt möglich sein. Heutige Datenbanksysteme müssen ausserdem immer stärker zwei grundsätzlich verschiedenen Gebrauchsarten zufriedenstellen: 1. Lesen, Ändern, Einfügen, Löschen von Datensätzen in geringem Umfang im Verhältnis zur Datenbankgrösse. Beispielsweise das Einfügen einer Bestellung in einem Webshop, das Ändern eines Statuseintrages der Bestellung oder das Hinzufügen einer neuen Bestellposition. Diese Operationen sind auch unter dem Namen OLTP (On Line Transaction Processing) bekannt. 2. Lesen eines grossen Teils oder der gesamten Datenbank für Überwachungsaufgaben, für statistische Auswertungen, oder für Backups. Diese Art Operationen sind unter dem Namen OLAP (On Line Analytical Processing) bekannt. Der Entwickler oder DBA entscheidet aufgrund obiger Kriterien, mit welchen Isolationsgrad Daten bearbeitet werden. Der SQL-Standard kennt vier Arten von Isolationsgrad: Isolationsgrad Vorteile Nachteile SERIALIZABLE Alle Transaktionen unterliegen dem Se- rialisierbarkeits- Paradigma) Absolute Konsistenzgarantie. Parallelität klein, Deadlockgefahr gross. REPEATABLE READ (Eine Abfrage liefert immer dasselbe Resultat, mit Ausnahme neu hinzukommender Datensätze) Einmal gelesene Daten bleiben eingefroren. Parallelität mittel. Je nach Applikationsart entsteht das Phantom-Problem. Deadlockgefahr gross. Lesende Pprozesse behindern schreibende Prozesse erheblich (Livelock möglich). Technologie Memo Arno Schmidhauser 4

5 READ COMMITTED (Es werden nur Daten gelesen, die einem bestätigen Zustand entsprechen) READ UNCOMMITTED (Aktuelle Datenwerte werden gelesen, unabhängig vom Transaktionszustand) Gelesene Daten sind korrekt, aber nicht eingefroren. Können sofort nach dem Lesen durch andere modifiziert werden. Parallelität hoch. Kaum Deadlocks. Es wird gelesen, was da ist. Leseoperationen werden nie blckiert. Deadlockfrei. Wird Auch als Dirty Read bezeichnet. Lost Update-Problem kann auftreten und gravierende Inkonsistenzen zur Folge haben. Berechnungen über mehrere Abfragen hinweg können inkonsistent sein, weil Daten zwischen den Abfragen geändert wurden. Keine Konsistenzgarantie. Gelesene Daten können von einem anderen Prozess, der diese gerade modifiziert hat, gerollbacked werden. Ob und wie stark die genannten Nachteile auftreten, hängt entscheidend von der Implementationsart abhängig. Heutige Datenbanksysteme haben erhebliche Fortschritte in der Behebung dieser Nachteile gemacht. SQL- Server 2005 vereinigt einige vorteilhafte Konzepte unter einem Dach. Die Zugriffsparallelität und die Deadlock-Minimierung konnte dadurch massiv verbessert werden. SQL Server 2005 hat für die Kontrolle des konkurrenzierenden Zugriffs zwei Mechanismen, zum Ersten ein sehr fein steuerbares Locking, und zum Zweiten einen Datensatz-Versionierung. 4.1 Locking Locks werden auf Datensätze, IO-Pages und Tabellen gesetzt. Beim Lesen werden normalerweise Shared Locks auf einzelne Datensätze gesetzt, beim Schreiben immer Exclusive Locks. Wenn genügend Datensätze betroffen sind, können Locks vom Datenbanksystem automatisch auf Ebene IO-Page oder Tabelle eskalieren. Die Lockstrategie kann manuell eingestellt werden oder sie wird durch den gewählten Isolationsgrad bestimmt. Eine manuelle Einstellung wird für einzelne Tabellen im Rahmen eines SQL-Befehles vorgenommen. Beispielsweise: SELECT * FROM Bestellung WITH (TABLOCKX). Folgende manuelle Optionen existieren: NOLOCK, NOWAIT, PAGLOCK, READCOMMITTED, READCOMMITTEDLOCK, READPAST 1, READUNCOMMITTED, REPEATABLEREAD, ROWLOCK, SERIALI- ZABLE, TABLOCK, TABLOCKX, UPDLOCK, XLOCK. Achtung: Die Lock-Art (UPDLOCK, XLOCK) kann nur für Lesebefehle geändert werden. Schreiboperationen finden immer mit Exclusive Locks statt. Ein Update-Lock bewirkt, dass andere Prozesse Daten noch lesen, aber selber nicht mit einem Update-Lock belegen können. Ein Update Lock ist dann sinnvoll, wenn ein Prozess die gelesenen Daten später verändern will. Gegenüber einem Shared Lock liegt der Unterschied in der Vermeidung von Deadlocks zwischen Prozessen, die zuerst Lesen dann Schreiben wollen. 1 Gesperrte Datensätze überpringen. Technologie Memo Arno Schmidhauser 5

6 SQL-Server arbeitet mit Range-Locks zur Gewährleistung von serialisierbaren Transaktionsabläufen. Range-Locks können vom Typ S-S, S-U, I-N und X-X sein. Der erste Teil definiert den Lock auf dem Range, der zweite Teil den Lock auf den eigentlich Datensätzen in diesem Range. Angeforderter Lock Bestehender Lock S U X RangeS-S RangeS-U RangeI-N RangeX-X Shared (S) Yes Yes No Yes Yes Yes No Update (U) Yes No No Yes No Yes No Exclusive (X) No No No No No Yes No RangeS-S Yes Yes No Yes Yes No No RangeS-U Yes No No Yes No No No RangeI-N Yes Yes Yes No No Yes No RangeX-X No No No No No No No Kompatibilitätstabelle für Range-Locks in SQL-Server 4.2 Datensatz-Versionierung Jede Transaktion bekommt vom Datenbanksystem eine fortlaufende Nummer zugeteilt. Modifiziert eine Transaktion einen Datensatz, wird vorerst der alte Datensatz aufbewahrt. Dieser alte Datensatz besitzt eine Versionsnummer, nämlich die Nummer der Transaktion, die ihn als letztes modifiziert oder erzeugt hat. Der neue Datensatz bekommt die laufende Transaktionsnummer als Versionsnummer zugeteilt. Mit diesem Vorgehen können zwei nützliche Ziele erreicht werden. Snapshot Isolation: Eine Transaktion T mit dem Isolationgrad Snapshot sieht nur Datensätze, die vor ihrem Start committed wurden. Das Datenbanksystem liefert nur Datensätze an T aus, die zwei Bedingungen erfüllen: 1) die Datensatzversion ist die höchste, noch kleinere Nummer als die Transaktionsnummer der laufenden Transaktion, 2) die Datensatznummer gehört nicht zur Liste der Transaktionen, die beim Start der Transaktion T laufend waren, ausser der eigenen (Das Datenbanksysteme muss als für T eine Liste der bei Beginn von T laufenden Transaktionen mitführen). Lost-Update-Problem werden vermieden, indem beim Zurückschreiben die ursprünglich gelesene Datensatzversion mit der aktuellen Version in der Datenbank verglichen wird. Falls keine Übereinstimmung besteht, wird die Transaktion zurückgesetzt (Dies entspricht dem oft genannten Zeitstempel- oder optimistischen Verfahren). Read Committed Isolation ohne Lesesperren: Für jede SQL-Abfrage wird vor ihrem Start die letzte vergebene Transaktionsnummer N ermittelt, sowie die beim Start der Abfrage laufenden Transaktionen. Als Abfrageresultate kommen nur Datensätze in Frage, deren Versionsnummer kleiner ist als N, und deren Versionsnummern nicht in der Liste der laufenden Transaktionen zu Beginn der SQL-Abfrage waren. Technologie Memo Arno Schmidhauser 6

7 4.3 Isolationsgrade in SQL Server Isolationsgrad im SQL Server SERIALIZABLE SNAPSHOT REPEATABLE READ READ COMMITTED, DB-Option READ_COMMITTED_SNAPSHOT auf ON gesetzt. READ COMMITTED, DB-Option READ_COMMITTED_SNAPSHOT auf OFF gesetzt. READ UNCOMMITTED Eigenschaften Entspricht dem Isolationsgrad SERIALIZABLE nach ANSI-Standard. Entspricht dem Isolationsgrad SERIALIZABLE nach ANSI-Standard. Update-Konflikte werden erst am Schluss der Transaktion festgestellt, im Gegensatz zum klassischen Lock-Verfahren. entspricht REPEATABLE READ nach SQL Standard. Realisierung mit Shared Locks. entspricht READ COMMITTED nach SQL Standard. Kein Warten auf Sperrfreigaben und garantiert deadlockfrei. Lost-Update-Probleme können auftreten. entspricht READ COMMITTED nach SQL Standard. Realisierung mit kurzen Lesesperren, deadlockarm, Behinderungen möglich. entspricht READ UNCOMMITTED nach SQL Standard. Änderungen einer anderen Transaktionen sind sofort sichtbar. 4.4 Allgemeines Befehl zum Setzen des Isolationsgrades SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED READ COM- MITTED REPEATABLE READ SNAPSHOT SERIALIZABLE } Für Snapshot Isolation muss die entsprechenden Datenbankoption gesetzt sein: ALTER DATABASE MYDB SET ALLOW_SNAPSHOT_ISOLATION ON Für READ COMMITTED mit Datensatzversionierung muss die entsprechenden Datenbankoption gesetzt sein: ALTER DATABASE MYDB SET READ_COMMITTED_SNAPSHOT ON. Default ist off. Der Datenbank-Default ist READ COMMITTED. Ein anderer Default kann nicht direkt in der Datebank gesetzt werden. 4.5 Verteilte Isolation Für verteilte Transaktionen steht keine Snapshot Isolation zur Verfügung, weil dafür übergeordnete Transaktions-Nummern erforderlich wären. Hingegen kann mit SET TRANSACTION ISOLATION LEVEL jeder andere Isolationsgrad gewählt werden. Technologie Memo Arno Schmidhauser 7

8 5 Verteilte Transaktionen Architektur von SQL Server für verteilte Transaktionen: 5.1 Distributed Transaction Coordinator DTC Der DTC ist der Transaktionsmanager für verteilte Transaktionen für alle Arten von OLE-fähigen Resource Managern (Datenbanken). Der DTC ist über OLE-DB Schnittstellen ansteuerbar. Er kann seinerseits OLE- (SQL Server, Access, Excel) fähige Resourcen ansteuern. Über eine OLE-ODBC API sind auch ODBC-fähige Resourcen ansprechbar. Das Mapping der OLE DB-Transaktionsbefehle in das XA-Protokoll obliegt dem ODBC-Treiber. DTC kann das 2PC-Protokoll asynchron durchführen, das heisst, alle Resource-Manager parallel ansprechen für prepare-, global commit- oder global abort-befehle. 5.2 Ausführung verteilter Transaktionen Folgende Schritte für die Konfiguration sind vorerst notwendig: 1. Registrierung eines fremden Servers als OLE DB Datenquelle (SQL Management Studio) 2. Zulassung des Servers in der lokalen Datenbank für verteilte Transaktions- und SQL-Aufgaben (Interaktiv oder via sp_addlinkedserver) 3. Bekanntgabe, unter welchem Login auf einem fremden Server gearbeitet werden solll (Interaktiv oder via sp_addlinkedsrvlogin) Es kann nun beispielsweise folgende Transaktion durchgeführt werden: BEGIN DISTRIBUTED TRANSACTION; Technologie Memo Arno Schmidhauser 8

9 -- Join einer lokalen und einer entfernten Tabelle SELECT * FROM Kunde k, remoteserver.remotedb.dbo.bestellung b WHERE k.idkunde = b.idkunde COMMIT; Mit dem Befehl BEGIN DISTRIBUTED TRANSACTION wird der DTC (Distributed Transaction Coordinator) involviert. In obiger Abfrage ist allerdings noch erkennbar, dass die Bestellungs- Tabelle auf einem Remote-Server (Server corpus, Datenbank remotedb) liegt. Dem kann durch Definition eines Synonyms abgeholfen werden. Beispiel: CREATE SYNONYM Bestellung FOR remoteserver.remotedb.dbo.bestellung; Damit wird nun folgende Befehlssequenz möglich: BEGIN DISTRIBUTED TRANSACTION; SELECT * FROM Kunde k, Bestellung b WHERE k.idkunde = b.idkunde COMMIT; 5.3 Verteilte Optimierung Obiges Beispiel wirft sofort die Frage nach der Performance und Optimierung auf, weil der Join über zwei Datenbanksysteme und über ein Netzwerk hinweg stattfindet. Ein Query Optimierer arbeitet heute nach einem Cost-Based-Verfahren: Er versucht, den Ausführungsplan mit dem kleinsten Zeitaufwand zu finden. Die Anzahl Zugriffe auf IO-Pages eines Speichermediums (physical reads) spielen dabei eine ausschlaggebende Rolle. Bei SQL-Abfragen, die Zugriffe auf Remote-Tabellen enthalten, geht der Query-Optimierer davon aus, dass der Transfer von Datensätzen über ein Netzwerk die teuerste Operation ist, neben dem Zugriff auf lokale IO- Pages 2. Es gilt also in erster Linie, die Anzahl transferierter Datensätze zu minimieren. Für Abfragen, welche ausschliesslich Tabellen eine Remote-Datenbank betreffen, wird die gesamte Abfrage an diese Remote-Datenbank delegiert. Für Abfragen, welche Tabellen aus verschiedenen Datenbanksystemen enthalten, wird versucht, möglichst geringe Transferraten zu erreichen. Beispiel einer zu optimierenden Abfrage: 2 Das Anfordern und der Transport einer IO-Page über ein Netzwerk bei einem anderen Datenbanksystem benötigt ganz grob die doppelte Zeit wie die Anforderung bei einem lokalen IO-System (Protokollstack-Zeit, IO-Zeit auf dem Remote-Rechner). Technologie Memo Arno Schmidhauser 9

10 SELECT * FROM Kunde k, remnode.remdb..bestellung b, remnode.remdb..artikel a WHERE k.idkunde = b.idkunde AND b.idartikel = a.idartikel AND k.kundennr = 3 Kunde sei 10'000 Einträge gross, Bestellung 100'000 und Artikel 1'000. Beispiel von zwei möglichen Ausführungsplänen: Plan 1 select Join Transfer 100'000 Datensätze Restriction Join Kunde Bestellung Artikel Plan 2 select Transfer 10 Datensätze Join Transfer 1 Datensatz Join Artikel Restriction Bestellung Kunde Graue Rechtecke sind Tabellenzugriffe oder Operationen, die auf dem Remote-Server stattfinden, weisse Rechtecke sind Tabellenzugriffe oder Operationen die lokal stattfinden. Dicke Pfeile symbolisieren Netzwerk- Transfers. Technologie Memo Arno Schmidhauser 10

11 Plan 2 wird als günstiger angesehen, weil wesentlich weniger Datensätze zwischen Servern transerferiert werden müssen, obwohl zwei Transfers insgesamt erfolgen. Die OLE-DB Schnittstelle bietet nur grobe Funktionen für das Ausführen von Abfragen an. Es können daher nicht direkt Operationenbäume, sondern nur folgende API-Funktionen ausgeführt werden: Remote Query, Remote Scan, Remote Update, Remote Delete, Remote Insert, RID Lookup. Der Query Optimizer muss die ermittelten Operationen-Teilbäume meist wieder in ein SQL-Query umformulieren und dieses an den Remote-Server übergeben. Der Query Optimizer wird daher auch versuchen, einen möglichsten grossen Teilbaum in einem einzigen Query zu verpacken. In Plan 2 wäre das beispielsweise: select * from Bestellung join Artikel join AbfrageResultatKunde. 6 Partitionierung Partitionierung ist eine Art verteiltes System auf Ebene Speichermedien. Datensätze einer Tabelle werden dabei auf mehreren physikalischen Medien (Disks), aber innerhalb derselben logischen Datenbank untergebracht. Die Aufteilung dient der Parallelisierung von Zugriffen oder der Vergrösserung des maximalen Diskplatzes. Greifen bestimmte Abfragen nur auf Datensätze einer Partition zu, kann mit der Partitionierung eine wesentliche Verbesserung der Performance erreicht werden. Die Verteilung von Datensätzen auf unterschiedliche Disks heisst horizontale, die Verteilung von Tabellenspalten auf unterschiedliche Disks heisst vertikale Paritionierung. SQL-Server ermöglicht die horizontale Partionierung (Nur Enterprise Edition). Die Formulierung von SQL-Abfragen ist natürlich u- nahbhängig vom Standort der betroffenen Datensätze. Die Partitionierung beeinflusst nur die Performance, nicht die Logik der Datenbankbenutzung. Mit der Partitionierung können beispielsweise wenig benützte Daten in die eine, aktuelle und viel benutzte Daten in eine andere Partition gelegt werden. Die Definition der Partitionen erfolgt aufgrund von konstanten Wertebereichen. Diese sind nicht dynamisch, dürfen also beispielsweise nicht das Aktuelle Datum enthalten, welches jeden Tag ändert. Jedoch können die Wertebereiche explizit durch den Administrator weiter gesplittet oder wieder verschmolzen werden. Die Lagerung (oder Umlagerung nach einem Update-Befehl) eines Datensatzes erfolgt automatisch durch das Datenbanksystem. Tabelle T1 a b c Partition 1, b <= 100 Technologie Memo Arno Schmidhauser 11

12 Partition 2, b > 100, b <= 200 Partition 3, b > 200 Befehle für den Aufbau einer Partitionierung: -- Erstellen einer Datenbank mit unterschiedlichen File-Gruppe, -- die später Tabellenpartitionen aufnehmen. CREATE DATABASE large_db ON PRIMARY ( name = 'file1', filename = ' ', size = 10GB ) FILEGROUP FG1 ( name = 'file2', filename = ' ', size = 10GB, name = 'file3', filename = ' ', size = 10GB ) FILEGROUP FG2 ( ) FILEGROUP FG3 ( ); -- Partitionierungsfunktion definieren. Diese ist noch unabhängig von einer -- Tabelle, auf die sie angewendet wird. CREATE PARTITION FUNCTION PF1 AS RANGE FOR VALUES ( 100, 200 ); -- Zuweisung von physischem Platz zu den Partitionen. Die durch die -- Partitionierungsfunktionen erzeugten Partitionen werden der Reihe -- nach den aufgeführten Filegruppen zugewiesen. CREATE PARTITION SCHEME PS1 AS PARTITION PF1 TO ( FG1, FG2, FG3 ); -- Abbildung einer Tabelle auf das Partitionierungsschema. CREATE TABLE T1 ( a varchar, b, varchar, c varchar ) ON PS1( c ); Indexe werden entsprechend der Tabellendefinition partitioniert. Grundsätzlich kann ein Index aber auf eine anderes Partionierungsschema gelegt werden als die Basistabelle. Beispiel: CREATE PARTITION SCHEME PS2 AS PARTITION PF1 ALL TO ( PRIMARY ); CREATE INDEX X1 ON T1( c ) ON PS2( c ); Der Partitionierungsmechanismus dient quasi auch seinem Gegenteil, dem Clustering von zwei Tabellen. Für das Durchführen von Join-Operationen, kann es nützlich sein, wenn zu verbindende Datensätze mit demselben Wert für das Join-Attribut auch in derselben Partition liegen. CREATE TABLE T2 ( c varchar, d, varchar, e varchar ) ON PS1( c ); Alle Partitionierungsdefinitionen können geändert werden mit ALTER DATABA- SE, ALTER PARTITION FUNCTION, ALTER PARTITION SCHEME und ALTER TABLE. Allerdings können Änderungen sehr resourcen-intensiv sein, da sie unter Umständen die Umlagerung sehr vieler Datensätze erfordern. Auch ein Update auf Datensätze, der ihre Partitionszugehörigkeit ändert, hat natürlich eine Umlagerung zur Folge. Technologie Memo Arno Schmidhauser 12

13 7 Replikation 7.1 Warum Replikation? Skalierbarkeit und Verfügbarkeit erhöhen Data Warehouses und Reporting von OLTP trennen Bedienung heterogener Datenbanken (Bsp. Oracle, DB2) Integration heterogener Datenbanken Integration von Point-of-Sale Sites (Einsammeln/Konsolidieren/Verteilen) Mobile Clients bedienen und synchronisieren 7.2 Vorbemerkungen Verteilte Transaktionen und Replikation sind zwei unabhängige Konzepte. Mit verteilten Transaktionen können Daten auf mehreren Datenbanksystemen konsistenz gehalten werden. Dabei wird nichts darüber ausgesagt, ob es sich um Kopien derselben Daten oder um verschiedene Daten handelt. Replikation von Daten kann über verteilte Transaktion oder -heute praktisch immer- über asynchrone Mechanismen, beispielsweise ein Messageing-System oder einen datenbankeigenen Replikationsprozess nach dem Publisher/Subscriber-Verfahren abgewickelt werden. Replikationsarten Synchronität Symmetrie Asymmetrisch Symmetrisch Asynchron Lesen überall möglich, Update nur an einem Ort möglich. Master-Slave-Topologie. Schwache Inkonsistenzen (kurzzeitig unterschiedlicher Informationsstand) möglich. Änderungen von Daten bei jedem Replikat möglich. Grundsätzlich schwere Inkonsistenzen möglich. Konfliktauflösungs-Strategie erforderlich. Synchron Verteilte Transaktion notwendig. Keine Inkonsistenzen möglich. Wird auch für Hot-Standbye-Systeme verwendet. Verteilte Transaktion notwendig. Keine Inkonsistenzen möglich. Einziger Vorteil: Lesen wird verteilt. SQL-Server unterstützt auf vielfältige Weise die asynchrone, sowie teilweise die synchrone Replikation. Bei allen asynchronen Verfahren gelten folgende Grundsätze: Es werden nur korrekte und bestätigte Daten aus der Quelldatenbank repliziert. Daten, die sich gerade in Änderung befinden, werden nie für die Replikation berücksichtigt. Der Replikationsprozess ändert am Zielort Daten. Diese Änderungen müssen den allgemeinen Transaktionsregeln (ACID-Eigenschaften) un- Technologie Memo Arno Schmidhauser 13

14 terliegen. Ein unvorhergesehen abgestürzter Replikationsprozess darf keine Inkonsistenzen zurücklassen. Der Replikationsprozess muss darauf Rücksicht nehmen, dass die Daten während der (Erneuerungs-) Replikation durch andere Benützer in Gebrauch sind (mindestens lesend). Der Replikationsprozess führt also eine eigene Transaktion gegen die Zieldatenbank aus, die dem Concurreny Control unterliegt. SQL Server Lösungen Zeitliche Koordination Symmetrie Asymmetrisch Symmetrisch Asynchron Snapshot-Replikation Zweiseitig transaktionale Replikation mit Message-Queue Merge-Replikation Transaktionale Peer-to-Peer Replikation (Keine Konfliktauflösung) Synchron Einseitig transaktionale Replikation mit Two Phase Commit Zweiseitig transaktionale Replikation mit Two Phase Commit 7.3 Publisher/Subscriber-Prinzip Die Grundlage zum Festlegen der Replikationstopologie ist eine Publisher/Subscriber-Prinzip. Dieses legt fest, wer von wem welche Information bezieht. Eine Publikation hat einen Namen. Die Publikation kann über diesen Namen abonniert (subscribed) werden. Eine Publikation ist eine Sammlung von Artikeln. Ein Artikel ist typischerweise eine Tabelle, die sowohl bezüglich der Datensätze, wie der ausgewählten Spalten eingeschränkt sein kann. Die Datensatz-Einschränkung findet über eine WHERE-Klausel statt. Eine Tabelle kann nur publiziert werden, wenn sie einen Primärschlüssel besitzt. Ein publizierter Artikel kann auch eine Stored Procedure, eine U- ser Defined Function oder eine View sein. Eine Subskription bezieht sich auf eine Publikation. Die Subskription wird auf dem Server definiert, der die Daten haben will. 7.4 Replikationarten von SQL Server Es werden folgende drei Replikationsarten unterschieden: Technologie Memo Arno Schmidhauser 14

15 7.4.1 Snapshot-Replikation Von einer Publikation wird ein kompletter Snapshot aller Daten, inklusive Schema-Definition der zugehörigen Artikel (Tabellen, Views), erstellt. Dieser Snapshot wird auf das Filesystem oder auf einem FTP-Server bereitgestellt. Der Snapshot kann in einem Klartextformat erstellt werden und ist damit sehr robust gegen Details der Konfiguration in der Zieldatenbank. Der Snapshot-Agent ist für die Erstellung verantwortlich. Er kann den Snapshot einmalig (respektive durch explizite Auslösung) oder periodisch erstellen. Der Distribution-Agent (oder Merge-Agent) lädt den Snapshot in die Zieldatenbank, gemäss Einstellungen entweder manuell oder nach Schedule. Die Snapshot-Replikation stellt die geringsten Anforderungen an die Datenstruktur, beispielsweise sind keine Primärschlüssel in den Tabellen erforderlich. Sie ist ausserdem die Ausgangslage für die transaktionale und die Merge-Replikation. Die Snapshot-Publikation ist ihrer Natur nach eine asynchrone, asymmetrische Replikation. Achtung: Snapshot-Replikation hat nichts mit Snapshot Isolation 3 zu tun. Eine Snapshot-Replikation erfordert umfangreiche Locks auf der publizierten Daten (Tabelleninhalt und Schemainformation) während der ganzen Erstellung des Snapshots. Es wird also ein transaktionskonsistentes (serialiserbares) Abbild der publizierten Objekte erzeugt. Snapshot-Replikation Transaktionale Replikationen Einseitig transaktionale Replikation Ausgehend von einer einmaligen Snapshot-Replikation (Initialisierungsphase) wird im Wesentlichen das Transaktionlog vom Publisher beim 3 Snapsho- Backup und Database-Snapshot haben ebenfalls nichts mit Snapshot Isolation zu tun. Snapshot-Backups und Datenbank-Snapshots sind zwar transaktionskonsistent, werden aber nach dem Copy-on-Write-Verfahren erstellt: Von zu modifizierenden Seiten wird ab Beginn des Backups/Snapshots vorgängig eine Kopie erstellt zuhanden des Backup-Prozesses. Von Seiten, die bei Backup-Start bereits in Gebrauch waren, wird aus dem Logfile der originalen Zustand wiederhergestellt. Technologie Memo Arno Schmidhauser 15

16 Subscriber nachgespielt. Es handelt sich um eine Art Simulation der Publisher-Transaktionen beim Subscriber. Die Vorteile dieses Verfahrens sind: Transaktionstreue: Erfordert eine Transaktion die Einhaltung von Constraints oder löst sie bei jeder Änderungsbefehlen Trigger aus, so werden diese 1:1 in den replizierten Datenbanken nachgespielt. Die transaktionale Replikation ist ausgelegt für hohe Performance und hohe Änderungsraten in der Publisher-Datenbank. Sie hat eine kleine Latenzzeit, das heisst, die Propagierung der Änderungen erfolgt in kurzen Zeitabständen (1 Sekunde). Diese Replikationsart arbeitet asynchron und asymmetrisch (unidirektional). Es wird bei dieser Replikationsart ausserdem davon ausgegangen, dass die Netzwerkverbindungen aktiv und stark sind. Für nicht immer verfügbare Datenbanken ist die Merge Replikation anzuwenden. Die transaktionale Replikation wird durch zwei Prozesse, den LogReader- Agent, und den Distribution-Agent kontrolliert. Der erste liest Transaktionen vom Logfile des Publishers und spielt sie in die Distributionsdatenbank, der zweite spielt sie von der Distributionsdatenbank zu den Subscribern. Der Distribution-Agent kann im Push-Vefahren arbeiten, wenn er auf der Publisher-Engine (oder Distribution Engine) läuft, oder er kann im Pull-Verfahren auf der Subscriber-Engine laufen. Einseitig transaktionale Replikation, asynchron Zweiseitig transaktionale Replikation, synchron Prinzip wie normale transaktionale Replikation, aber mit der Möglichkeit von Änderungen beim Subscriber. Die Änderungen werden, ausgelöst durch einen zusätzlichen Trigger auf den replizierten Tabellen, synchron an den Publisher propagiert, das heisst mit einem Two-Phase-Commit Pro- Technologie Memo Arno Schmidhauser 16

17 tokoll 4. Sie ist damit frei von Konsistenzkonflikten. Vom Publisher zu den anderen Subscribern werden die Änderungen wie bei der einseitigen Replikation propagiert. Wenn die Subscriber unter sich disjunkte Datenmengen haben und nur gegenüber dem Publisher gemeinsame Daten, dann entspricht dies einer vollständig synchronen Replikation. Zweiseitig transaktionale Replikation, synchron Zweiseitig transaktionale Replikation, asynchron Prinzip wie normale transaktionale Replikation, aber mit der Möglichkeit von Änderungen beim Subscriber. Die Änderungen werden asynchron propagiert über eine Replikations-Queue in der Subscriberdatenbank. Die Messsages in dieser Queue sind die aufgezeichneten Replikations- Transaktionen. Wird ein Datensatz in zwei oder mehr Replikaten gleichzeitig geändert, tritt beim Transfer dieser Änderung ein Konflikt auf. Es können drei Strategien für die Konfliktlösung eingestellt werden: a) immer die Version des Publishers behalten, b) die Version des Subscribers behalten, c) die Version des Publishers behalten und den Subscriber mit neuem Snapshot des Publishers initialisieren. Wird die Version des Subscribers behalten, entstehen gewisse Zufälligkeiten, wenn ein Datensatz bei mehreren Subscribern geändert wurde: Der Subscriber welcher zuletzt abgleicht, gewinnt über alle anderen Subscriber, da die absolute Zeit von Änderungen nicht berücksichtigt wird. 4 Isolation Level READ COMMITTED. Technologie Memo Arno Schmidhauser 17

18 Zweiseitig transaktionale Replikation, asynchron Wie merkt der Replikationsmechanismums, dass ein Konflikt aufgetreten ist? In einer publizierten Tabelle wird vom System ein neues Attribut eingefügt mit dem Namen MSrepl_tran_version und diesem mit newid() ein global eindeutiger, zufälliger Wert zugeteilt (Dieser Wert wird nicht als Primärschlüssel, sondern nur als Versionenkennzeichnung verwendet). Bei jeder Änderung des Datensatzes wird per Trigger diesem Attribut ein neuer Wert zugewiesen. Bei der Initialisierung einer replizierten Tabelle haben korrespondierende Datensätze im Publisher und in den Subscribern denselben Wert. Wird nun beispielsweise auf dem Subscriber ein Datensatz geändert, und sein Transaktions-Log an die Replikations-Queue geschickt, passiert dort folgendes: Es wird die alte Versionenkennzeichnung im Transaktionlog mit der aktuellen Versionenkennzeichnung in der Publisher- Tabelle verglichen. Ist sie gleich, wurde im Publisher der Datensatz nicht geändert und kann von der Queue (also eigentlich vom Subscriber) in den Publisher übertragen werden. Der neue Wert der Versionenkennzeichnung im Transaktionslog wird zum aktuellen Wert in der Publisher-Tabelle. Ist der alte Eintrag im Transaktionslog nicht identisch mit dem aktuellen Wert in der Publisher-Tabelle, wurde letztere entweder direkt oder durch einen vorgängigen Abgleich mit einem anderen Subscriber geändert und es besteht ein Konflikt. Somit kommt eine der drei Konfliktlösungsmechanismen kommt zum Zug Transaktionale Peer-to-Peer Replikation Jede beteiligte Datenbank ist gleichzeitig Publisher und Subscriber. Es wird asynchron repliziert und zwar in einer N:N Strategie. Allfällige Konflikte werden nicht detektiert. Der Vorteil dieser Architektur liegt in einer hohen Skalierbarkeit für Leseoperationen, zum Beispiel im Rahmen von Datawarehouse-Lösungen. Das Propagieren von Änderungen ist aufwändig, da mit N 2 wachsend. Während der Initialisierung darf keine Aktivität auf der Datenbank stattfinden. Technologie Memo Arno Schmidhauser 18

19 7.4.3 Merge-Replikation Peer-to-Peer Replikation Die Merge-Replikation ist für folgende Situationen ausgelegt: Replikation und Abgleich von Datenbanken, die zeitweise offline betrieben werden. Änderungen an den replizierten Daten sind sowohl auf dem Publisher wie auf den Subscribern möglich. Daten werden zu einem bestimmten Zeitpunkt repliziert, dann offline bearbeitet und später wieder abgeglichen. Der Abgleich zwischen den Replikation kann zu unterschiedlichsten Zeitpunkten stattfinden. Beim Abgleich zwischen den beteiligten Replikaten sind nur Brutto- Änderungen von Interesse, also nur der Zustand der Daten unmittelbar vor dem Abgleich. Die Merge-Replikation ist vielseitig konfigurierbar: o Transfer bidirektional oder unidirektional o Der Abgleich der Daten kann auf Ebene Feld, physischer Datensatz oder logischer Datensatz (z.b. Bestellung inkl. Bestellpositionen) erfolgen. Der Ablauf der Merge-Replikation besteht aus einer Initalisierungsphase und einer Betriebsphase. In der Initialisierungsphase wird durch einen Snapshot-Agent ein Snapshot der Publisher-Datenbank erstellt und in den Subscriber-Datenbanken installiert. In der Betriebsphase werden durch einen Merge-Agent periodisch die Änderungen bei den beteiligten Daten- Technologie Memo Arno Schmidhauser 19

20 banken eingesammelt, konsolidiert und zurückgespielt. Die Publisher- Datenbank hat einerseits eine Drehscheibenfunktion für die Durchführung des Abgleichs: Änderungen von Subscribern werden zum Publisher propagiert, von dort zu allen anderen Subscribern. Auf dem Publisher können aber andererseits auch direkt Änderungen an den Datentabellen vorgenommen werden. Eigenschaften der Merge-Replikation Merge-Replikation Die einzelnen Replikate sind untereinander praktisch unabhängig. Es können Abgleich-Konflikte auftreten, die aufgelöst werden müssen. Für diese Konfliktauflösung stehen verschiedenste vorprogrammierte Varianten zur Verfügung (Prioritäten, Zeitstempel, Sum/Min/Max/Avg- Wert usw.) Die Merge Replikation ist für eine hohe Funktionalität, aber für kleine Datenmengen ausgelegt. Die Performance ist kritisch, da umfangreiche Hilfsdaten gesammelt werden und ein N:N Abgleich unter allen beteiligten Datenbanken stattfindet. Die abzugleichenden Datensätze werden einzeln behandelt, so dass pro Datensatz mindestens ein SQL- Update-, Insert- oder Delete-Befehl für jede abzugleichende Datenbank notwendig ist, neben zahlreichen Kontrollabfragen und aktionen Hilfsstrukturen für die Merge-Replikation Für den Betrieb der Merge-Replikationen werden einige Hilfsstrukturen benötigt: Für den Abgleich muss jeder Datensatz in einer publizierten Tabelle global identifizierbar sein. Es wird hierzu, falls es noch nicht besteht, ein Attribut namens rowguid vom Typ uniqueidentifier hinzugefügt und mit dem Defaultwert newsequentialid() belegt. Technologie Memo Arno Schmidhauser 20

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen Transaktionen Fachbereich MNI Technische Hochschule Mittelhessen Sommersemester 2015 Motivation ACID-Eigenschaften Übersicht Transaktionen Motivation ACID-Eigenschaften Ursachen für Logging und Backup

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager FILESTREAM für Microsoft SQL Server aktivieren FILESTREAM für Microsoft SQL Server aktivieren

Mehr

Whitepaper. Produkt: combit Relationship Manager. Replikation mit Microsoft SQL Server 2005. combit GmbH Untere Laube 30 78462 Konstanz

Whitepaper. Produkt: combit Relationship Manager. Replikation mit Microsoft SQL Server 2005. combit GmbH Untere Laube 30 78462 Konstanz combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager Replikation mit Microsoft SQL Server 2005 Replikation mit Microsoft SQL Server 2005-2 - Inhalt Übersicht 3 Einführung

Mehr

Whitepaper. Produkt: combit Relationship Manager. Replikation mit Microsoft SQL Server 2008. combit GmbH Untere Laube 30 78462 Konstanz

Whitepaper. Produkt: combit Relationship Manager. Replikation mit Microsoft SQL Server 2008. combit GmbH Untere Laube 30 78462 Konstanz combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager Replikation mit Microsoft SQL Server 2008 Replikation mit Microsoft SQL Server 2008-2 - Inhalt Übersicht 4 Einführung

Mehr

Transaktionen in der Praxis. Dr. Karsten Tolle

Transaktionen in der Praxis. Dr. Karsten Tolle Transaktionen in der Praxis Dr. Karsten Tolle Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch (Exception e) { e.printstacktrace(); } con.setautocommit(false);

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

PostgreSQL in großen Installationen

PostgreSQL in großen Installationen PostgreSQL in großen Installationen Cybertec Schönig & Schönig GmbH Hans-Jürgen Schönig Wieso PostgreSQL? - Die fortschrittlichste Open Source Database - Lizenzpolitik: wirkliche Freiheit - Stabilität,

Mehr

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr

Eine weitere Möglichkeit "die grosse weite Welt" zu erschliessen sind ODBC/JDBC bzw. ESS Verbindungen.

Eine weitere Möglichkeit die grosse weite Welt zu erschliessen sind ODBC/JDBC bzw. ESS Verbindungen. Database Designs Alexis Gehrt / alexis@database-designs.ch - Erster Kontakt mit FileMaker ca. 1991 ( Version 2, 2.1) - Jan 2000 - Database Designs - Seit 2007 bei einem Kunden (Linden-Grafik AG) angestellt

Mehr

TimeSafe Leistungserfassung

TimeSafe Leistungserfassung Keep your time safe. TimeSafe Leistungserfassung Adressimport 1/8 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 Allgemeines... 3 1.1 Adressen in der TimeSafe Leistungserfassung... 3 1.2 Organisationen und/oder

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

SQL (Structured Query Language) Schemata Datentypen

SQL (Structured Query Language) Schemata Datentypen 2 SQL Sprachelemente Grundlegende Sprachelemente von SQL. 2.1 Übersicht Themen des Kapitels SQL Sprachelemente Themen des Kapitels SQL (Structured Query Language) Schemata Datentypen Im Kapitel SQL Sprachelemente

Mehr

Oracle Datenbank - Recovery

Oracle Datenbank - Recovery Oracle Datenbank - Recovery H.-G. Hopf Georg-Simon-Ohm Fachhochschule Nürnberg Datenbank-Recovery / 1 Η. G.Hopf / 10.04.2003 Inhaltsverzeichnis Transaktionsablauf Prozess - Recovery Instanz - Recovery

Mehr

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung Inhalt Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle Daten und Tabellen Normalisierung, Beziehungen, Datenmodell SQL - Structured Query Language Anlegen von Tabellen Datentypen (Spalten,

Mehr

Einsatz von Replikation. Florian Munz

Einsatz von Replikation. Florian Munz Einsatz von Replikation Florian Munz Agenda Wofür braucht man Replikation? Anwendungsszenarien Wie funktioniert Replikation? Konsistenzbegriff und Strategien Wie implementiert man Replikation? Lösungen

Mehr

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine.

In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine. Kapitel 2 Datenverwaltung durch SQL Server Wir wollen das obige Skript zwei Mal laufen lassen, einmal mit und einmal ohne eingeschalteten Schreibcache der Festplatte. Für eine lokale Festplatte können

Mehr

Unterabfragen (Subqueries)

Unterabfragen (Subqueries) Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und

Mehr

Verteilte Systeme - 5. Übung

Verteilte Systeme - 5. Übung Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity

Mehr

Whitepaper. Produkt: combit Relationship Manager 7, address manager 17. Import von Adressen nach Firmen und Kontakte

Whitepaper. Produkt: combit Relationship Manager 7, address manager 17. Import von Adressen nach Firmen und Kontakte combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager 7, address manager 17 Import von Adressen nach Firmen und Kontakte Import von Adressen nach Firmen und Kontakte

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse

Download:.../~rieche. gehalten am 2. Februar 2004. Stephan Rieche. Vortrag. Thema: Index Selection. von. Seminar Advanced Data Warehouse Seminar Advanced Data Warehouse Thema: Index Selection Vortrag von Stephan Rieche gehalten am 2. Februar 2004 Download:.../~rieche Inhalt des Vortrages 1. Einleitung - Was ist das Index Selection Problem?

Mehr

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Seit der Datenbankversion 9i bietet Oracle das Feature Change Data Capture an. Aber was genau

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012

Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012 Isolationsstufen für Transaktionen / Sicherheit Dr. Karsten Tolle Dienstag 31. Januar 2012 Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch

Mehr

Handbuch Datensicherung

Handbuch Datensicherung Copyright 1995-2009 by winvs software AG, alle Rechte vorbehalten Gewähr Urheberrechte Haftung Die in diesem Handbuch enthaltenen Angaben sind ohne Gewähr und können jederzeit ohne vorherige Benachrichtigung

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Dokumentation QuickHMI-Schnittstelle. Datenbanken

Dokumentation QuickHMI-Schnittstelle. Datenbanken Dokumentation QuickHMI-Schnittstelle für SQLServer Datenbanken Version 1.0 D-28359 Bremen info@indi-systems.de Tel + 49 421-989703-30 Fax + 49 421-989703-39 Inhaltsverzeichnis Was ist die QuickHMI-Schnittstelle

Mehr

Produkt TELAU Installationsanleitung Integrales Management und Informatik

Produkt TELAU Installationsanleitung Integrales Management und Informatik Produkt TELAU Installationsanleitung Integrales Management und Informatik Inhaltsverzeichnis 1 Systemvoraussetzungen... 4 1.1 Einsatz eines MYSQL... 4 1.2 Vorgehen... 5 2 Datenbank SQL Server... 7 2.1

Mehr

15 Bilder und Dateien im SQL Server

15 Bilder und Dateien im SQL Server Leseprobe aus Access und SQL Server http://www.acciu.de/asqllesen 15 Bilder und Dateien im SQL Server Eines der großen Probleme von Access-Datenbanken ist der vergleichsweise geringe Speicher platz. Sicher,

Mehr

Grundlagen der PostgreSQL Administration

Grundlagen der PostgreSQL Administration Jens Wilke Vortrag bei der BELUG 16.03.2011 Der Vortrag behandelt die Installation und Konfiguration von PostgreSQL, dem fortschrittlichsten Open Source Datenbanksystem. Es wird auf die wichtigsten Konfigurationsparameter

Mehr

Microsoft SQL Server 2005 für Administratoren

Microsoft SQL Server 2005 für Administratoren Microsoft SQL Server 2005 für Administratoren Irene Bauder ISBN 3-446-22800-4 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22800-4 sowie im Buchhandel Sichern von

Mehr

Erste Schritte, um selber ConfigMgr Reports zu erstellen

Erste Schritte, um selber ConfigMgr Reports zu erstellen Thomas Kurth CONSULTANT/ MCSE Netree AG thomas.kurth@netree.ch netecm.ch/blog @ ThomasKurth_CH Erste Schritte, um selber ConfigMgr Reports zu erstellen Configuration Manager Ziel Jeder soll nach dieser

Mehr

Replikation in Datenbanken

Replikation in Datenbanken Replikation in Datenbanken Vortrag: Datenbanken II Yves Adler Hochschule für Technik, Wirtschaft und Kultur Leipzig Fachbereich Informatik, Mathematik und Naturwissenschaften Y. Adler (HTWK Leipzig) Replikation

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

Mehr

Archive / Backup System für OpenVMS

Archive / Backup System für OpenVMS Archive / Backup System für OpenVMS DECUS Symposium 2002 Bonn Vortrag-Nr. 3C04 Günther Fröhlin Compaq Computer Corporation Colorado Springs, USA 1 Highlights V4.0 Auslieferung Januar 2002 Hauptversion

Mehr

Performance Tuning mit @enterprise

Performance Tuning mit @enterprise @enterprise Kunden-Forum 2005 Performance Tuning mit @enterprise Herbert Groiss Groiss Informatics GmbH, 2005 Inhalt Datenbank RMI JAVA API HTTP Konfiguration Analyse Groiss Informatics GmbH, 2005 2 Datenbank

Mehr

Persönlichkeiten bei bluehands

Persönlichkeiten bei bluehands Persönlichkeiten bei Technologien bei Skalierbare Anwendungen mit Windows Azure GmbH & co.mmunication KG am@.de; posts..de/am 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit

Mehr

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software SQL Tutorial SQL - Tutorial SS 06 Hubert Baumgartner INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt des Tutorials 1 2 3 4

Mehr

ANDREAS PROUZA. Wien, 2015-03-27. andreaspr@aon.at andreas@prouza.at. http://www.prouza.at

ANDREAS PROUZA. Wien, 2015-03-27. andreaspr@aon.at andreas@prouza.at. http://www.prouza.at DB2 & SQL E I N F Ü H R U N G T U N I N G O P T I M I E R U N G S E C R E T S ANDREAS PROUZA andreaspr@aon.at andreas@prouza.at http://www.prouza.at Wien, 2015-03-27 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis...

Mehr

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C3: Structured Query Language Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können elementaren

Mehr

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar Qt-Seminar Dienstag, 10.2.2009 SQL ist......die Abkürzung für Structured Query Language (früher sequel für Structured English Query Language )...ein ISO und ANSI Standard (aktuell SQL:2008)...eine Befehls-

Mehr

Whitepaper. Produkt: combit Relationship Manager. Datensatzhistorie mit dem SQL Server 2000 und 2005. combit GmbH Untere Laube 30 78462 Konstanz

Whitepaper. Produkt: combit Relationship Manager. Datensatzhistorie mit dem SQL Server 2000 und 2005. combit GmbH Untere Laube 30 78462 Konstanz combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager Datensatzhistorie mit dem SQL Server 2000 und 2005 Datensatzhistorie mit dem SQL Server 2000 und 2005-2 - Inhalt

Mehr

PHP und MySQL. Integration von MySQL in PHP. Zellescher Weg 12 Willers-Bau A109 Tel. +49 351-463 - 32424. Michael Kluge (michael.kluge@tu-dresden.

PHP und MySQL. Integration von MySQL in PHP. Zellescher Weg 12 Willers-Bau A109 Tel. +49 351-463 - 32424. Michael Kluge (michael.kluge@tu-dresden. Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) PHP und MySQL Integration von MySQL in PHP Zellescher Weg 12 Willers-Bau A109 Tel. +49 351-463 - 32424 (michael.kluge@tu-dresden.de) MySQL

Mehr

MGE Datenanbindung in GeoMedia

MGE Datenanbindung in GeoMedia TIPPS & TRICKS MGE Datenanbindung in GeoMedia 10. September 2002 / AHU INTERGRAPH (Schweiz) AG Neumattstrasse 24, CH 8953 Dietikon Tel: 043 322 46 46 Fax: 043 322 46 10 HOTLINE: Telefon: 043 322 46 00

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006 Datenbankstammtisch Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers 1. Februar 2006 Autoren: Andreas Reis, Sebastian Mehl Dipl.-Phys. Thomas Richter Gliederung

Mehr

Datenbanken: Backup und Recovery

Datenbanken: Backup und Recovery Der Prozess der Wiederherstellung der Daten einer Datenbank nach einem Fehler im laufenden Betrieb in einen konsistenten, möglichst verlustfreien Zustand heißt Recovery. Beteiligt an diesem Recovery sind

Mehr

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11 Datenbanksysteme WS 05/ 06 Gruppe 12 Martin Tintel Tatjana Triebl Seite 1 von 11 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 3 2. Datenbanken... 4 2.1. Oracle... 4 2.2. MySQL... 5 2.3 MS

Mehr

PostgreSQL unter Debian Linux

PostgreSQL unter Debian Linux Einführung für PostgreSQL 7.4 unter Debian Linux (Stand 30.04.2008) von Moczon T. und Schönfeld A. Inhalt 1. Installation... 2 2. Anmelden als Benutzer postgres... 2 2.1 Anlegen eines neuen Benutzers...

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Übung 1: Ein Website News-System mit MySQL

Übung 1: Ein Website News-System mit MySQL Übung 1: Ein Website News-System mit MySQL In der Vorübung haben wir bereits mit Hilfe eines ERMs den Datenbankentwurf erstellt und daraus die folgenden Tabellen abgeleitet: Nun muss diese Datenbank in

Mehr

IV. Datenbankmanagement

IV. Datenbankmanagement Wirtschaftsinformatik 2 (PWIN) IV. Datenbankmanagement Kapitel 2: Datenmanipulationssprache SQL Wirtschaftsinformatik 2 (PWIN) SS 2009, Professur für Mobile Business & Multilateral Security 1 Agenda 1.

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

NoSQL mit Postgres 15. Juni 2015

NoSQL mit Postgres 15. Juni 2015 Tag der Datenbanken 15. Juni 2015 Dipl.-Wirt.-Inform. Agenda l Vorstellung l Marktübersicht l Warum PostgreSQL? l Warum NoSQL? l Beispielanwendung Seite: 2 Vorstellung Dipl.-Wirt.-Inform. [1990] Erste

Mehr

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

Datenbanken und SQL. Kapitel 1. Übersicht über Datenbanken. Edwin Schicker: Datenbanken und SQL (1)

Datenbanken und SQL. Kapitel 1. Übersicht über Datenbanken. Edwin Schicker: Datenbanken und SQL (1) Datenbanken und SQL Kapitel 1 Übersicht über Datenbanken Übersicht über Datenbanken Vergleich: Datenorganisation versus Datenbank Definition einer Datenbank Bierdepot: Eine Mini-Beispiel-Datenbank Anforderungen

Mehr

C# - Einführung in die Programmiersprache Arbeiten mit ADO.NET. Leibniz Universität IT Services Anja Aue

C# - Einführung in die Programmiersprache Arbeiten mit ADO.NET. Leibniz Universität IT Services Anja Aue C# - Einführung in die Programmiersprache Arbeiten mit ADO.NET Leibniz Universität IT Services Anja Aue Experteneinstellungen in Visual Studio Express Extras Einstellungen Experteneinstellungen. Es werden

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

Kurs. Teil 7 UNDO-Management. Universität Hannover. Agenda. Einführung. Nutzung RBS Oracle 9i Einführung Performance Tuning.

Kurs. Teil 7 UNDO-Management. Universität Hannover. Agenda. Einführung. Nutzung RBS Oracle 9i Einführung Performance Tuning. Kurs Oracle 9i Performance Tuning Teil 7 UNDO-Management Timo Meyer Wintersemester 2005 / 2006 Seite 1 von 23 Seite 1 von 23 1. 2. Nutzung des Rollback Segments 3. 4. 5. Größe von UNDO- TBS berechnen 6.

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht Dipl. Inf. Eric Winter Entwicklungsleiter PTC GPS-Services GmbH PostgreSQLals HugeData Storage Ein Erfahrungsbericht Inhalt 1. Problembeschreibung 2. Partielle Indexierung 3. Partitionierung 1. Vererbung

Mehr

Referenzielle Integrität SQL

Referenzielle Integrität SQL Referenzielle Integrität in SQL aus Referential Integrity Is Important For Databases von Michael Blaha (Modelsoft Consulting Corp) VII-45 Referenzielle Integrität Definition: Referenzielle Integrität bedeutet

Mehr

Einführung in Hauptspeicherdatenbanken

Einführung in Hauptspeicherdatenbanken Einführung in Hauptspeicherdatenbanken Harald Zankl Probevorlesung 13. 01., 13:15 14:00, HS C Inhaltsverzeichnis Organisation Überblick Konklusion Harald Zankl (LFU) Hauptspeicherdatenbanken 2/16 Organisation

Mehr

DB2 SQL, der Systemkatalog & Aktive Datenbanken

DB2 SQL, der Systemkatalog & Aktive Datenbanken DB2 SQL, der Systemkatalog & Aktive Datenbanken Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Auf DB2 Datenbanken zugreifen DB2 Datenbanken benutzen Abfragen ausführen Den Systemkatalog

Mehr

17.2 MS-Access Projekte

17.2 MS-Access Projekte 964 Von MS-Access 2000 zum SQL-Server 17.2 MS-Access Projekte MS-Access-Projekte, die die Dateiendung adp besitzen, werden als Front-End-Anwendung verwendet. Für die Back-End-Seite gibt es mehrere Möglichkeiten.

Mehr

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig)

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig) 1 Grundlagen Begriffe Daten bekannte zutreffende Tatsachen über die Domäne/Miniwelt DBS Einsatz eines DBMS für eine Datenbank, DBS besteht aus folgenden Komponenten: 1. DBMS 2. Datenbank DBMS Software

Mehr

Datenbankadministration

Datenbankadministration Datenbankadministration 4. Zugriffskontrolle AG DBIS University of Kaiserslautern, Germany Karsten Schmidt kschmidt@informatik.uni-kl.de (Vorlage TU-Dresden) Wintersemester 2008/2009 Einführung Architektur

Mehr

5. SQL: Erstellen von Tabellen. Erzeugen und Löschen von Tabellen. Umgang mit Bedingungen (Constraints) Einfügen und Löschen von Daten

5. SQL: Erstellen von Tabellen. Erzeugen und Löschen von Tabellen. Umgang mit Bedingungen (Constraints) Einfügen und Löschen von Daten 5. SQL: Erstellen von Tabellen Erzeugen und Löschen von Tabellen Umgang mit Bedingungen (Constraints) Einfügen und Löschen von Daten 106 SQL Structured Query Language Historie: Anfänge ca. 1974 als SEQUEL

Mehr

Einstieg in das SQL- und Datenbanktuning 14.01.2009. Loblied auf den Tabellen-Index!

Einstieg in das SQL- und Datenbanktuning 14.01.2009. Loblied auf den Tabellen-Index! 1/40 PHP-User-Group Stuttgart 14.01.2009 Warum Datenbanken einen Hals bekommen und was sich dagegen tun lässt. Tuning und Performancesteigerung ohne zusätzliche Hardware. Ein. Loblied auf den Tabellen-Index!

Mehr

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung

3 Indizes. 3.1 Indexarchitektur von SQL Server. SQL Server 2008: Datenbankentwicklung 3 Indizes 3.1 Indexarchitektur von SQL Server Die folgende Abbildung zeigt die Organisationsstruktur einer Tabelle. Eine Tabelle befindet sich in einer oder mehreren Partitionen, und jede Partition enthält

Mehr

Und ewig "locked" die Datenbank - Locking in Oracle R11 und IBM DB2

Und ewig locked die Datenbank - Locking in Oracle R11 und IBM DB2 Und ewig "locked" die Datenbank - Locking in Oracle R11 und IBM DB2 PROMATIS software GmbH Ettlingen (TechnologieRegion Karlsruhe) Schlüsselworte R11, DB2, Locking, Partitionierung, LOB, Materialized Views,

Mehr

IRF2000, IF1000 Application Note ModbusTCP API

IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Stand: 28.10.2014 ads-tec GmbH 2014 IRF2000 IF1000 2 Inhaltsverzeichnis 1 Einführung... 3 2

Mehr

Technik der SAP-Anbindung Christian Aigner Team Entwicklung, Kranzberg

Technik der SAP-Anbindung Christian Aigner Team Entwicklung, Kranzberg Christian Aigner Team Entwicklung, Kranzberg Inhalt Schnell- und Kürzestübersicht über SAP Architektur Inhalt, Login, Session SapGUI Workbench,Editor,Explorer Mechanismen Die Gemeinsamkeiten: nutzbare

Mehr

Der Parameter CLOSE bewirkt, dass sich das Sicherungsprogramm am Ende der Sicherung automatisch schliesst

Der Parameter CLOSE bewirkt, dass sich das Sicherungsprogramm am Ende der Sicherung automatisch schliesst 1 Sicherung 1.1 Einleitung Die Applikation WSCAR basiert auf der Datenbank-Engine Firebird 1.5.5 / 2.5.2. Beide Programme sind nur auf der Hauptstation(Server) installiert und dürfen nie deinstalliert

Mehr

7 Die Reorganisation von DB2

7 Die Reorganisation von DB2 Ab und an sollte eine Tabelle reorganisiert werden. Besonders, nachdem größere Datenmengen eingefügt oder gelöscht wurden, muß über eine Reorganisation nachgedacht werden. Eine optimale Performance ist

Mehr

Einführung in die Informatik II

Einführung in die Informatik II Einführung in die Informatik II Die Structured Query Language SQL Prof. Dr. Nikolaus Wulff SQL Das E/R-Modell lässt sich eins zu eins auf ein Tabellenschema abbilden. Benötigt wird eine Syntax, um Tabellen

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 8 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 12.01. 2004 Integritätsbedingungen

Mehr

MySQL Replikationstechnologien

MySQL Replikationstechnologien MySQL Replikationstechnologien Lenz Grimmer MySQL Community Relations Specialist $ whoami 1998 2002 2008 2010 Agenda Replikation: Definition und Klassifizierung Anwendungsgebiete

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. Einrichtung einer Merge Replikation für Offline-Clients

Whitepaper. Produkt: combit Relationship Manager / address manager. Einrichtung einer Merge Replikation für Offline-Clients combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager Einrichtung einer Merge Replikation für Offline-Clients Einrichtung einer Merge Replikation

Mehr

Oracle Datenbankadministration Grundlagen

Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Grundlagen Seminarunterlage Version: 12.02 Version 12.02 vom 14. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Datenbankentwicklung mit dem Microsoft SQL Server 2005

Datenbankentwicklung mit dem Microsoft SQL Server 2005 Holger Schmeling Datenbankentwicklung mit dem Microsoft SQL Server 2005 ISBN-10: 3-446-22532-3 ISBN-13: 978-3-446-22532-9 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-22532-9

Mehr

SQL, MySQL und FileMaker

SQL, MySQL und FileMaker SQL, MySQL und FileMaker Eine kurze Einführung in SQL Vorstellung von MySQL & phpmyadmin Datenimport von MySQL in FileMaker Autor: Hans Peter Schläpfer Was ist SQL? «Structured Query Language» Sprache

Mehr

Server: Vice nach Tanenbaum, van Steen

Server: Vice nach Tanenbaum, van Steen 3 Fallbeispiel: Coda Nachfolger des Andrew File Systems (AFS) Carnegie Mellon University, 1990 (CMU) Zielsetzung hohe Verfügbarkeit bei mehreren 10.000 Client-Rechnern Fehlertoleranz abgesetzter Betrieb

Mehr

IBM Informix SQL. Seminarunterlage. Version 11.04 vom

IBM Informix SQL. Seminarunterlage. Version 11.04 vom Seminarunterlage Version: 11.04 Version 11.04 vom 27. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Mit dem 6. Rundbrief gelange ich mit einem Update des Zeitservers an Alle.

Mit dem 6. Rundbrief gelange ich mit einem Update des Zeitservers an Alle. Rundbrief 6 Aktuelles aus der SAS Softwarewelt. 0.1 Zeit Server Update Werte Anwender Mit dem 6. Rundbrief gelange ich mit einem Update des Zeitservers an Alle. Das Update wurde aus Kompatibilitätsgründen

Mehr

Kapitel 7 Datenbank-Tuning

Kapitel 7 Datenbank-Tuning Kapitel 7 Datenbank-Tuning Flien zum Datenbankpraktikum Wintersemester 2012/13 LMU München 2008 Thmas Bernecker, Tbias Emrich 2010 Tbias Emrich, Erich Schubert unter Verwendung der Flien des Datenbankpraktikums

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr