5,9 MByte

Werbung
Client/Server-Systeme
Prof. Dr.-Ing. Wilhelm Spruth
SS 2005
Raum 207, Sand 13
Tel.:07071.297-5482, mobil 0172-8051-485
[email protected]
http://www-ti.informatik.uni-tuebingen.de/~spruth/index_de.html
Teil 9
Transaktionsverarbeitung
cs 0800 ww6
sch 02-97
Probleme mit Stored Procedures
• Lastverteilung - Leistungsverhalten - Skalierung
• Prioritätssteuerung
• High Availability
• Heterogene Datenbanken, z.B. von unterschiedlichen
Herstellern
2 Phase Commit,
es können mehrere Datenbanken involviert sein
Alternative: Transaktionsmonitor
• Stored Procedures nur für einfache Aufgaben
• Bei allen leistungskritischen Anwendungen werden
ausschliesslich Transaktionsmonitore eingesetzt.
• Anwendungen laufen in einem eigenen Adressenraum
gesteuert von einem Transaktionsmonitorprozess
Ein Transaktionsmonitor ist eine Softwarekomponente,
welche den atomaren Charakter vieler gleichzeitig
ablaufender Transaktionen sicherstellt. Der TP Monitor
stellt die Kernfunktionen für ein Transaktionsverarbeitungssysten bereit. Zu diesen gehören:
•
•
•
•
•
•
Message Queuing
Lock Verwaltung
Log Verwaltung
2-Phase Commit Synchronisation
Rollback Funktion
Laststeuerung (Load Balancing)
cs 0823 ww6
rahm 02-99
Beispiel für Transaktionsmonitore
BEA Tuxedo (AT&T→
→Novell → BEA)
DEC ACMS für VMS, Ultrix
IBM CICS
IBM IMS-DB/DC
IBM TPF
SAP R/3
Siemens UTM
Tandem NonStop Kernel (NSK) / Guardian /Pathway
Microsoft Transaction Server (MTS)
Corba OTS (Object Transaction Service)
EJB JTS (Java Transaction Service)
Eigenschaften eines
Transaktionsmonitors:
hohe Verfügbarkeit
kurze Antwortzeit (< 0.3 Sek. erwünscht)
geeignet für hohes Verkehrsaufkommen
niedrige Kosten pro Transaktion
Integrität beim Zugriff auf gemeinsam genutzte
Ressourcen
cs 0824 ww6
wgs 02-99
Heutige Plattformen
Betriebssystem
Hardware
Windows
Pentium,
AMD
Linux
alle
Client
Workstation
Server
x
x
x
x
x
x
Solaris
Sparc
x
x
HP-UX
PA,
Itanium
x
x
MAC OS
PowerPC
AIX
PowerPC
OS/400
PowerPC
x
z/OS
zSeries
(S/390)
x
x
x
x
x
Einordnung des TP Monitors
Klienten
TP
Anwendungen
Daten
haltung
Middleware, hier TP Monitor
Betriebssystem, einschließlichTransport Dienste, z.B. TCP/IP
Es wäre denkbar, die TP Monitor Funktion in das Betriebssystem
einzubauen. Dies ist z.B. beim HP/Tandem „Guardian“ und beim
IBM „TPF“ Betriebssystem der Fall. Ein normales Betriebssystem
ist jedoch strukturiert, vor allem Stapelverarbeitung und lang
dauernde interaktive Time-Sharing Sitzungen zu unterstützen.
Deshalb setzt im Regelfall der TP Monitor als ein einziger
Anwendungsprozess auf dem Betriebssystem auf.
Hierbei vermeidet der TP Monitor nach Möglichkeit die Nutzung der
Betriebssystem Funktionen. Um Leistung und Durchsatz zu
optimieren hat er z.B. eigene Message Handling und Queuing
Einrichtungen und evtl. (z.B. bei CICS) sein eigenes File System.
cs 0829 ww6
wgs 02-99
cs 0826a ww6
wgs 09-00
Eingabe Queue
enqueue
dequeue
Queue
Manager
Transaktions
Verarbeitung
Klient
dequeue
enqueue
Ausgabe Queue
Server
Queue Manager
Jede einzelne Transaktion wird in 3 Subtransaktionen aufgelöst, die
alle eigene ACID Eigenschaften haben.
Subtransaktion 1 nimmt die Eingabenachricht entgegen, stellt sie in
die Eingabe Queue, und commits.
Subtransaktion 2 dequeues die Nachricht, verarbeitet sie, stellt das
Ergebnis in die Ausgabequeue, löscht den Eintrag in der
Eingabequeue und commits.
Subtransaktion 3 übernimmt das Ergebnis von der Ausgabequeue,
übergibt das Ergebnis an den Klienten, löscht den Eintrag in der
Ausgabequeue und commits.
Ein separater Queue Manager ist optimiert für diese Aufgabe.
es 1159
wgs 08-00
Komponenten eines TP Monitors
Endbenutzer kommunizieren mit dem TP Monitor mit Hilfe von
Nachrichten.
Presentation Services bilden die Datenausgabe auf die GUI des
Benutzers ab.
Eingabe-Nachrichten werden mit einer trid (Transaktions ID)
versehen und in einer Warteschlange gepuffert. Aus
Zuverlässigkeitsgründen muß diese einen Systemabsturz
überleben. Eine ähnliche Warteschlange existiert für die Ausgabe
von Nachrichten.
Der Scheduler verteilt eingehende Bearbeitungsanforderungen auf
die einzelnen Server Prozesse.
Ein TP Monitor bezeichnet seine Server Prozesse als Ressource
Manager. Es existiert ein Ressource Manager pro (aktive)
Anwendung. Ressource Manager sind multithreaded; ein
spezifischer Ressource Manager für eine bestimmte Anwendung ist
in der Lage, mehrere Transaktionen gleichzeitig zu verarbeiten.
Der Lock Manager blockiert einen Teil einer Datenbanktabelle. In
Zusammenarbeit mit dem Datenbanksystem stellt er die „Isolation“
der ACID Eigenschaft sicher.
Der LOG Manager hält alle Änderungen gegen die Datenbank fest.
Mit Hilfe der Log Datenbank kann der Recovery Manager im
Fehlerfall den ursprünglichen Zustand der Datenbank
wiederherstellen (Atomizität der ACID Eigenschaft).
In dem Repository verwaltet der TP Monitor Benutzerdaten und
-rechte, Screens, Datenbanktabellen, Anwendungen sowie
zurückliegende Versionen von Anwendungen und Prozeduren.
cs 0827 ww6
wgs 02-99
TP Repository
Andere Bezeichnung: Katalog, Dictionary
Katalogisiert:
Benutzer
Workstation IDs (Terminal IDs)
Screens
Anwendungen
Prozeduren
Tabellen
Z.B. Hinzufügen eines Feldes in einen Screen ändert Client
software, Server Schnittstelle, fügt eine weitere spalte in
eine SQL Tabelle ein, ....
SABRE Flugplatzreservierungssystem
zentraler Verarbeitungsablauf
cs 0922 ww6
wgs 0923 07-00
Backward Recovery
Der Transaktionsmonitor stellt sicher, daß im Fehlerfall der
teilweise Ablauf einer Transaktion rückgängig gemacht
wird, und daß alle abgeänderten Felder einer Datenbank
wieder in ihren ursprünglichen Zustand zurückbersetzt
werden.
Andere Bezeichnungen:
• backout
• rollback
• abort
cs1026 ww6
wgs 02-97
Plattenspeicher
Zwischenpuffer
In LOG File
übernehmen,
dann löschen
5
1
1
4
3
2
ack
2
commit
abzuändernde
Datensätze
zu schreibende Daten
Hauptspeicher
Backward Recovery
Andere Bezeichnungen: backout, roll back abort
1. abzuändernde Information in Puffer zwischenspeichern
2. Datensätze überschreiben
3. Commit Status festhalten. Damit ist es geschehen
4. erfolgreiches Commit dem Benutzer mitteilen
5. Zwischenpuffer löschen
css1010 ww6
wgs 02-97
Log File Concept
Log is a history of all changes to the state.
Log + old state gives new state
Log is a sequential file
Complete log contains entire history of Data BaseCurrent
state is just a "cache" of the log record
When transaction commits
Put it’s log in a durable place (duplexed disk)
Need log to redo transaction in case of failure
• System failure: lost in-memory updates
• Media failure (lost disk)
This makes transaction durable.
In case of system failure,
• Reapply log of all committed transactions
• Force-at-commit insures log will survive restart.
Then UNDO all uncommitted transactions
Flat Transaction
start_transaction {
beginwork ( );
.....
.....
.....
.....
.....
.....
.....
.....
if no_error commit ( ) else rollback ( ) ;
}
cs 0822 ww6
rahm 02-99
Transaction
#1
Begin
Trans.
Transaction
#2
Begin
Trans.
Commit
Transaction
#3
Begin
Trans.
Commit
Commit
Flat Transaction
Alle Arbeit innerhalb einer Flat Transaction findet auf der gleichen
Ebene statt. Die Transaktion überlebt entweder mit allen
Teilfunktionen (commit) oder es erfolgt ein rollback einschließlich
aller Teilfunktion (abort).
start_transaction {
beginwork( );
.....
.....
.....
.....
if no_error commit( ) else rollback( ) ;
cs 0855 ww
wgs 12-99
Logical Unit of Work
LUW
Aktion 1
Aktion 2
Aktion 3
Aktion 4
Aktion 5
Aktion 6
Start Transaktion
Ende Transaktion
LUW 4
LUW 3
LUW 2
LUW 1
Aktionen sind Bausteine, aus denen der (zeitliche) Arbeitsablauf eines
Resource Managers (Server) besteht.
Nicht geschützte (unprotected) Aktionen haben keine ACID
Eigenschaften.
Geschützte (protected) Aktionen haben ACID Eigenschaften und
werden als „Logical Unit of Work“ (LUW) bezeichnet.
Teilweise abgeschlossene LUW´s können rückgängig gemacht
werden.
Reale (real) Aktionen beeinflussen die physikalische Umwelt auf eine
Art, die nur schwer oder garnicht rückgängig zu machen ist (roll
back). Beispiele: Ein Loch bohren, Geldausgabe am Automaten,
vertrauliche Daten an den falschen Empfänger senden. ACID
Eigenschaften für reale Aktionen mögen schwierig oder unmöglich zu
implementieren sein.
cs 0842 ww6
wgs 05-97
LUW
Transaktion
A
Start der
Transaktion
LUW
LUW
Ende der
Transaktion
(Syncpoint)
LUW
Transaktion
B
Start der
Syncpoint Syncpoint
Transaktion
LUW
Syncpoint Ende der
Transaktion
(Syncpoint)
„Logical Units of Work „ (LUW) und Syncpoints
Andere Bezeichnungen für Syncpoints:
Commit points bzw. Save Points
Syncpoints bewirken, daß BACKOUT bzw. ROLLBACK die
Transaktion nur bis zu dem letzten, erfolgreich abgeschlossenen
Syncpoint zurücksetzt.
cs 0903 ww
wgs 02-97
LUW
Backout
cs 0905 ww
wgs 02-97
1. Darlehnskonto abrechnen, Saldo um Tilgungsrate verändern
2. Tilgung und Zinsen im laufenden Konto (Kontokorrent) auf der
Sollseite buchen
3. Globales Limit überprüfen
4. Bilanzpositionen (Konten)
5. G+V Positionen (Gewinn- und Verlust Konten)
6. Zinsabgrenzung monatlich für jährliche Zinszahlung
7. Bankmeldewesen (ein Kunde nimmt je 90 000.- DM bei 10 Banken
auf, läuft am Stichtag)
6
7
1
2
3
4
5
6
7
1
2
3
Zeit
Abarbeitung in Reihenfolge
evt. keine Sync Points erforderlich
cs 0898 ww6
wgs 12-99
Buchungsvorgänge, monatliche Kreditabrechnung
1. Darlehnskonto abrechnen, Saldo um Tilgungsrate verändern
2. Tilgung und Zinsen im laufenden Konto (Kontokorrent) auf der
Sollseite buchen
3. Globales Limit überprüfen
4. Bilanzpositionen (Konten)
5. G+V Positionen (Gewinn- und Verlust Konten)
6. Zinsabgrenzung monatlich für jährliche Zinszahlung
7. Bankmeldewesen (ein Kunde nimmt je 90 000.- DM bei 10 Banken
auf, läuft am Stichtag)
Buchungsvorgang
1
2
3
4
5
6
7
Kunde Nr
1
2
3
.
Beispiel:
Schritte 1 - 3 als 1 Transaktion
Schritte 4 - 7 :
Zwischenergebnisse
persistent speichern
.
99999
cs 0879 ww6
wgs 12-99
Main Transaction
von
Konto 1
abbuchen
auf
Konto 2
zubuchen
Zeit
update
history
start
transaction
2 phase
commit
TP
Monitor
Oracle
Database
TP
Monitor
DB2
Database
TP
Monitor
Sybase
Database
Distributed Flat Transaction
cs 0853 ww6
wgs 12-99
Zwei-Phasen-Festübergabe
Two-phase Commit
Erforderlich bei der gleichzeitigen Änderung mehrerer
Datenbanken, z.B. Banküberweisung von Bank A nach Bank B
Elektronisches Clearinghaus sendet Nachrichten an beide Banken
Problem, wenn entweder Abbuchung oder Gutschrift nicht erfolgt
Daher atomare Transaktionen erforderlich
Konsistenz wird erreicht durch einen „Master“ (CommitKoordinator), der die Arbeit von „Slaves“ überwacht
Clearinghaus übernimmt Rolle des Master, die beiden Banken sind
Slaves. Two-phase-Commit-Protokoll stellt sicher, daß Abbuchung
und Gutschrift entweder beide erfolgen, oder beide nicht erfolgen
Slave #1
Slave #2
Datenbank A
Abbuchung
Konto Nr. xxx
Datenbank B
Gutschrift
Konto Nr. yyy
Commit Coordinator
Master
css1011 ww6
wgs 02-97
Master
Slave
Begin atomic action
Send Request 1
.............
Send Request n
Send „ Prepare to commit“
if action can be performed
then begin
Lock data
Store initial state on disk
Store requests on disk
Send „OK“
end
else
Send „Failure“
if all slaves said „OK“
then send „Commit“
else send „Rollback“
Wait for acknowledgements
if master said commt
then begin
Do work
Unlock data
end
Send „Acknowledgement“
2-Phase Commit Protokoll
cs 0938 ww6
nach Tanenbaum
wgs 12-01
2-Phase Commit Protokoll
cs 0953 ww 6
wgs 12-04
cs 3023 ww6
IBM Transaction Processing Facility
TPF
Eigenständiges Betriebssystem, erlaubt nur eine einzige
Anwendung: Transaktionsverarbeitung
Hervorgegangen aus dem SABER (SABRE) Flugplatzreservierungssystem (American Airlines, 1959). Später umbenannt in
SABRE → ACP → TPF
Keine Einrichtungen für Softwareentwicklung (erfolgt auf einem
anderen Rechner)
Run-to-Completion (non-preemptive) Scheduler/Dispatcher
Betriebssystem Aufruf erfordert ca. 500 Maschinenbefehle
E/A Operation erfordert etwa 500 - 800 Maschinenbefehle
> 10000 Transaktionen/s
Anwendungen:
Flugplatzreservierung (Amadeus)
Geldausgabeautomaten
Kreditkartenverifizierung
cs 0819 ww6
wgs 02-99
Implementierung eines
Transaktionsmonitors
Operationen über Adressraumgrenzen hinweg benötigen
Millisekunden
Operationen im gleichen Adressraum benötigen
Mikrosekunden-Bruchteile
Ein Faktor 10000 Geschwindigkeitsunterschied ist möglich
Deshalb läuft der vollständige Transaktionsmonitor häufig
im Problemstatus (z.B. CICS). Dies erfordert stabile
Anwendungen, da alle Steuerfunktionen nicht geschützt
sind
Bei der IBM TPF (Transaktion Processing Facility, ehemals
ACP und SABRE) laufen Anwendungen,
Transaktionsmonitor und Überwacher gemeinsam alle im
Überwacherstatus
css1008 ww6
wgs 02-97
Anwendungen
API
Transaction
Processing
Monitor
Database
Management
System
DBI
Kernel
Unabhängiger Transaktionsverarbeitungs-Monitor
TP Monitor und Datenbank-System
laufen in getrennten virtuellen Adressenräumen
Beispiele : CICS, SAP R/3
Anwendungen
API
Transaction
Processing
Database
Management
Kernel
Transaktionsmonitor und Datenbank-System
sind in den Kernel integriert
Beispiel: TPF
Betriebssystem-Schnittstelle
cs 0906 ww
wgs 02-97
Die wichtigsten Programmiersprachen
C/C++
Java
Cobol
Visual Basic (in Microsoft Umgebungen)
Fortran (für wissenschaftliche Anwendungen)
Die wichtigsten Script Sprachen
Tcl/Tk
Perl
PHP
REXX
cs 2855 ww6
wgs 04-02
Percent of of Global 2000 enterprises worldwide
using various programming languages
At year-end 2001, Gartner conducted a series of surveys at
its worldwide Symposia in USA, Orlando, Asia/Pacific,
Europe, and Japan
Approximately 70 percent of enterprises use Java to
develop new code. The same number use Visual Basic .
There are twice as many professional VB developers as
professional Java developers.
Approximately 45 percent of survey respondents reported
that they use COBOL; another 45 percent use C++ (and C).
COBOL is used mainly for legacy application enhancement
and integration with newly developed applications, mostly
in Java.
Es 1020 ww6
wgs 02-03
Cobol
COBOL is for morons. (Edsger Dijkstra)
The use of COBOL cripples the mind; its teaching should,
therefore, be regarded as a criminal offence. (Edsger Dijkstra)
With respect to COBOL you can really do only one of two things:
fight the disease or pretend that it does not exist. (Edsger Dijkstra)
Cobol has almost no fervent enthusiasts. As a programming tool, it
has roughly the sex appeal of a wrench. (Charles Petzold)
COBOL: (Synonymous with evil.) A weak, verbose, and flabby
language used by card wallopers to do boring mindless things on
dinosaur mainframes.
-----------------------------------------------------------------------------------------------http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html
http://www.sysprog.net/quotcob.html
es0905 ww6
wgs 10.02
The Significance of COBOL
75% of all business data is processed in COBOL. - Gartner Group
There are between 180 billion and 200 billion lines of COBOL code
in use worldwide. - Gartner Group
This represents over 60 percent of the world’s computer code.
Existing legacy systems are predominantly written in COBOL.
15% of all new applications (5 billion lines) through 2005 will be in
COBOL. - Gartner Group
CICS transaction volume (such as COBOL-based ATM transactions)
grew from 20 billion per day in 1998 to 30 billion per day in 2002. The Cobol Report
Replacement costs for COBOL systems, estimated at $25 per line,
are in the hundreds of billions of dollars. - Tactical Strategy Group
"Integration with Legacies" is the number one concern of IT
managers in 2003. - Gartner Group
There are over 90,000 COBOL programmers in North America in
2002. Over the next four years there will be a 13% decrease in their
number due to retirement and death. - Gartner Group
The most highly paid programmers in the next ten years are going
to be COBOL programmers who know the Internet. - GIGA Group
http://www.cobolwebler.com/cobolfacts.htm
Gartner Inc., From the Dustbin, Cobol Rises, 2001
Reprinted in Microfocus Outlook, COBOL Technology and Contemporary Business Systems, May
2002
http://www.eweek.com/article2/0,3959,25993,00.asp
http://www.info.uni-karlsruhe.de/lehre/2002WS/hps/Cobol-X1.pdf
cs 0944 ww6
wgs 03-03
Informatik Spektrum
Band 26, Heft 2, April 2003
cs 1029 ww6
wgs 05 - 03
Herunterladen