Februar 2013 3A LÖSUNGEN SDE10: TypeID und Type_OID Benutzerhandbuch
AED-SICAD Aktiengesellschaft Postfach 83 07 54 D-81707 München www.aed-sicad.de Ihre Anregungen Wir nehmen gerne Ihre Rückmeldungen und Anregungen zu diesem Handbuch entgegen. Ihre Hinweise helfen uns dabei, die Dokumentation auf die Anforderungen unserer Kunden hin zu optimieren. Ein entsprechendes Faxformular finden Sie im hinteren Teil dieser Dokumentation. Natürlich können Sie uns Ihre Anregungen auch gerne online über unsere Homepage www.aed-sicad.de übermitteln.
3A Lösungen SDE10: TypeID und Type_OID Benutzerhandbuch
Wir bieten Ihnen Schulungen...zu dem in diesem Handbuch beschriebenen Produkt...und zu vielen weiteren AED-SICAD relevanten Themen Unser Training Center steht Ihnen bei Fragen gerne zur Verfügung. AED-SICAD Aktiengesellschaft Training Center Postfach 83 07 54 D-81707 München Aktuelle Informationen über verfügbare Kurse finden Sie auch auf unserer Homepage www.aed-sicad.de Alle verwendeten Hard- und Softwarenamen sind Handelszeichen und/oder Warenzeichen der jeweiligen Hersteller. Copyright by AED-SICAD Aktiengesellschaft, 2013. All rights, including rights of translation, reproduction by printing, copying or similar methods, even of parts, are reserved. Offenders will be liable for damages. All rights, including rights created by parent grant or registration of a utility model or design, are reserved. Delivery subject to availability; right of technical modifications reserved.
Inhalt 1 Änderungen in diesem Handbuch... 6 2 Einführung... 7 3 Problem 1 (TYPEID-Problem)... 8 3.1 Feststellung des TYPEID-Problems... 8 3.2 Workaround... 8 3.3 Lösungsstrategie 1... 8 3.4 Anlegen einer neuen SDE... 9 4 Problem 2 (TYPE_OID-Problem)... 10 4.1 Feststellung des TYPE_OID-Problems:... 10 4.2 Lösungsstrategie 2... 10 5 Kombination von TYPEID- und TYPE_OID-Problem... 11 6 Vorgehen bei Migration und Konvertierung von 3A-Datenbanken... 12 6.1 Migration ArcSDE 9.2 nach ArcSDE 9.3... 12 6.2 Migration ArcSDE 9.2 nach ArcSDE 10... 12 6.3 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID ja, TYPEID ja... 12 6.4 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID ja, TYPEID nein... 12 6.5 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID nein, TYPEID ja... 12 6.6 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID nein, TYPEID nein... 13 6.7 ArcSDE 10 nach ArcSDE 10, TYPE_OID ja, TYPEID ja... 13 6.8 ArcSDE 10 nach ArcSDE 10, TYPE_OID ja, TYPEID nein... 13 6.9 ArcSDE 10 nach ArcSDE 10, TYPE_OID nein, TYPEID ja... 13 6.10 ArcSDE 10 nach ArcSDE 10, TYPE_ID nein, TYPEID nein... 13 7 Anlagen... 14 7.1 Feststellung der TYPEID von ST_GEOMFROMTEXT:... 14 7.2 Feststellung der TYPE_OID von ST_GEOMETRY... 14 7.3 Festellung der Tabellen, die Daten mit ST_GEOMETRY enthalten... 14 7.4 Entscheidungsdiagramm für 3A-Datenbanken... 15 AED-SICAD Aktiengesellschaft 5 / 18
1 Änderungen in diesem Handbuch Datum Stichwort Abschnitt 02/2013 Erstellung alle Wichtiger Hinweis: Der AED-SICAD Kundenkreis, der sich in der Planung für die Softwareumstellung von 3A Produktlinie 6.1 auf 6.3 befindet, sollte den Inhalt dieses Dokuments bei den Umstellungsarbeiten unbedingt berücksichtigen. AED-SICAD Aktiengesellschaft 6 / 18
2 Einführung Es gibt zwei wichtige Probleme mit ArcSDE Datenbanken, die VOR einer Migration nach ArcSDE 10 gelöst werden müssen. Dabei geht es um die Speicherung bestimmter ArcSDE-Datentypen (ST_GEOMETRY) in Oracle. Die Probleme hängen eng zusammen, sind aber doch unterschiedlich. Beide Probleme haben den Effekt, dass Daten (z.b. Sicherungen) nicht importiert werden können! Ziel dieses Textes ist einerseits, vorhandene Problemdatenbanken und Konstellationen, unter denen sogar ein Datenverlust droht, zu erkennen und entsprechende Maßnahmen zu ergreifen. Andererseits sollen zukünftige Probleme, die gerade erst bei der Migration nach ArcSDE 10 entstehen, durch die Einhaltung bestimmter Vorgehensweisen von vornherein vermieden werden. Die hier vorgestellten Vorgehensweisen beruhen auf Recherchen von AED-SICAD. Sie stellen keine Lösung der Probleme, sondern nur eine Umgehung dar, die für die aktuellen Oracle-Versionen (bis einschließlich 11.2.0.3) funktioniert. Eine Lösung kann nur durch Oracle und/oder ESRI erfolgen. Eine solche Lösung von dieser Seite ist aber derzeit (Stand: Januar 2013) nicht in Sicht. Zur Feststellung, ob die Probleme bei Kundendatenbanken vorliegen, findet man in der Anlage ein Entscheidungsdiagramm, nach dem man vorgehen kann, ohne die Probleme vollständig verstanden zu haben. Durch Abarbeitung des Diagrammes wird festgestellt, ob die hier diskutierten Probleme vorliegen und ob die Sicherungsstrategie für eine solche Datenbank ausreichend ist. Außerdem wird ein Vorgehen zur Umgehung der Probleme dargestellt, dass bewirkt, dass Datenbanken transportabel sind und wieder mit üblichen Verfahren gesichert werden können. Kapitel 6 Vorgehen bei Migration und Konvertierung von 3A-Datenbanken behandelt das Vorgehen bei verschiedenen Migrationsszenarien, durch das erreicht wird, dass die Umgehung der Probleme im Rahmen der Migration erfolgt. Außerdem wird hier noch einmal das Vorgehen bei bereits auf ArcSDE 10 migrierten Datenbanken dargestellt. AED-SICAD Aktiengesellschaft 7 / 18
3 Problem 1 (TYPEID-Problem) Oracle DataPump-Dumps von ArcSDE 10 Datenbanken lassen sich aufgrund eines Oracle-Fehlers häufig nicht in neue Datenbanken einspielen, wenn auch der Benutzer SDE mit importiert wird. Damit sind viele Sicherungen von Kundendatenbanken, die ausschließlich mit DataPump erstellt verwenden, praktisch wertlos. Es sollte daher möglichst umgehend festgestellt werden, bei welchen Kunden eine Problemsituation vorliegt! Das Problem tritt auf, weil sich beim Import des Benutzers SDE die TYPEIDs der von ESRI-definierten ArcSDE-Datentypen (ST_GEOMETRY) ändern. In den Kundendaten werden dann die falschen TYPEIDs referenziert, sodass die Daten nicht importiert werden können. Einmal durch Import geänderte TYPEIDs werden allerdings bei Folgeimports nicht wieder geändert. Datenbanken, die bereits die geänderten Werte verwenden, sind also von diesem Problem nicht betroffen. Die Lösung des Problems verfolgt daher das Ziel, alle Datenbanken auf die geänderten TYPEIDs umzustellen. Auch wenn für die Kundendaten selbst nicht ST_GEOMETRY als Datentyp verwendet wird, so gibt es ab ArcSDE 10 immer mindestens eine zentrale Tabelle im ArcSDE Repository, die diesen Typ verwendet, und zwar die Tabelle GDB_ITEMS. Diese Tabelle ersetzt unter ArcSDE 10 die bisherigen GDB-Tabellen und enthält die wesentlichen Punkte des SDE Data Dictionaries. 3.1 Feststellung des TYPEID-Problems 1. Setzt der Kunde ArcSDE 10 ein? 2. Wie lautet die TYPEID von ST_GEOMFROMTEXT? TYPEID ist 13: Problem liegt vor, TYPEID ist 6 : Problem liegt nicht vor. Als Benutzer sde: select TypeID from user_types where type_name='st_geomfromtext'; 3.2 Workaround Setzt der Kunde nun expdp zur Sicherung ein, so muss die Sicherung um einen exp-dump derjenigen Tabellen erweitert werden, die Daten mit von der ArcSDE definierten Datentypen (ST_GEOMETRY) enthalten. Bei 3A-Datenbanken ist dies in aller Regel nur die Tabelle GDB_ITEMS. In der Anlage dieser Dokumentation findet man ein Skript, mit dem ein Benutzer mit DBA-Rechten dies überprüfen kann. Anschließend sollte die Lösungsstrategie 1 (s. u.) so bald wie möglich umgesetzt werden. Wenn der Kunde RMAN statt expdp zur Sicherung einsetzt, sind seine Sicherungen in Ordnung. Allerdings ist die ausschließliche Verwendung von expdp zum Transport der Daten in andere Datenbanken (z.b. für Wartungszwecke) dann nicht möglich. Auch in diesem Fall sollte daher die Lösungsstrategie 1 in absehbarer Zeit umgesetzt werden. 3.3 Lösungsstrategie 1 1. Datenbank mit expdp exportieren Tabellen, die Daten mit ST_GEOEMTRY enthalten, mit exp exportieren. 2. Neue Datenbank ohne SDE-Postinstallation anlegen. Daten aus 1. zunächst mit impdp importieren. Falls Benutzer einzeln importiert werden, muss der SDE Benutzer vor den anderen Benutzern importiert werden. Hierbei werden die Tabellen mit ST_GEOMETRY zwar angelegt, es werden aber aufgrund eines Oracle-Fehlers keine Daten importiert. Daten der Tabellen, die Daten mit ST_GEOMETRY enthalten, mit imp importieren. Hierbei mit IGNORE=Y die schon existierenden Tabellen ignorieren und lediglich die Daten nachladen. 3. Nach dem Import muss die Oracle Datenbank rebooted werden AED-SICAD Aktiengesellschaft 8 / 18
Bei einer so erstellten ArcSDE ist die TYPEID von ST_GEOMFROMTEXT 6 und bleibt bei weiteren Exund Import-Aktionen auch 6. Gleiches gilt für die weiteren ArcSDE-Datentypen. In der Folge kann eine gültige Sicherung wieder ausschließlich als DataPump-Dump (expdp) erstellt werden. 3.4 Anlegen einer neuen SDE Neue SDEs sollten ab sofort nur noch mit geänderten TYPEIDs angelegt werden. Hierfür gibt es zwei Möglichkeiten: 1. Variante: - Neue Datenbank anlegen und ArcSDE Postinstallation durchführen. - Benutzer SDE mit expdp exportieren. - Tabelle SDE.GDB_ITEMS zusätzlich mit exp eportieren. - Benutzer SDE löschen. - SDE mit impdp wieder importieren. - Tabelle SDE.GDB_ITEMS aus dem exp-dump mit imp IGNORE=Y importieren. - Oracle Datenbank rebooten 2. Variante: DataPump-Dump einer SDE mit einer wie unter 1. erstellten Datenbank sichern und SDEs durch den Import dieses Dumps erstellen. Oracle Datenbank anschließend rebooten. WICHTIG: Eine ggf. im Dump enthaltene Lizenz ist durch die eigene Lizenz zu ersetzen. Zu einzelnen Schritten dieser Prozedur gibt es je nach Situation auch alternative Vorgehensweisen mit demselben Ergebnis. Die hier aufgeführte Vorgehensweise garantiert nach derzeitigem Wissenstand aber eine Datenbank, die korrekt mit expdp exportiert und in neue Datenbanken fehlerfrei mit impdp wieder importiert werden kann, sodass ein sicherer Schutz vor einem Datenverlust gewährleistet ist. AED-SICAD Aktiengesellschaft 9 / 18
4 Problem 2 (TYPE_OID-Problem) Das zweite Problem betrifft Datenbanken, die von SDE 9.2 auf neuere Versionen aktualisiert wurden. 4.1 Feststellung des TYPE_OID-Problems: 1. Setzt der Kunde ArcSDE 9.3 ein? 2. Wie beginnt die TYPE_OID von ST_GEOMETRY? (dazu als Benutzer SDE folgende SQL-Abfrage ausführen: select TYPE_OID from user_types where type_name='st_geometry';) - TYPE_OID beginnt mit A618: Problem liegt nicht vor, - TYPE_OID beginnt anders: Problem liegt vor. Dieses Problem verhindert das Einspielen von Benutzerschema-Geodatabases in neue oder andere Datenbanken. Der Grund ist, dass Datenbanken, die durch Migration von SDE 9.2 in neuere Versionen entstanden sind, zufällige TYPE_OIDs für die ArcSDE Datentypen (ST_GEOMETRY) enthalten. (Hinweis: TYPE_OIDs sind tatsächlich etwas anderes als TYPEIDs!) Zum Einspielen der Benutzerschema-Geodatabases in andere Datenbanken muss daher auch der Benutzer SDE importiert werden, damit die TYPE_OIDs der referenzierten Datentypen in der Master-Geodatabase gefunden werden. Bei einer Sicherung muss daher immer auch die Master-Geodatabase des Benutzer SDE mitgesichert werden. Dumps solcher Benutzerschema-Geodatabases können bei Wartungsfällen nicht einfach in andere Datenbanken eingespielt werden. Man muss die Master-Geodatabase des Benutzers SDE mit importieren, also für jeden solchen Fall eine vollständige Datenbankinstanz anlegen. Dies hebt den Vorteil der Verwendung von Benutzerschema-Geodatabases teilweise auf und erhöht den Aufwand für die Bereitstellung von Datenbanken für 3A-Wartungsfälle erheblich. Eine Lösung funktioniert nur mit ArcSDE-9 Datenbanken (bzw. genauer: mit ArcSDE-9 Datenbanken, die keine Daten mit ST_GEOMETRY enthalten). Die Behebung dieses Problems muss also VOR der Migration nach ArcSDE 10 erfolgen (genauer: VOR Verwendung von ST_GEOMETRY, das bei ArcSDE 10 immer zumindest in SDE.GDB_ITEMS Verwendung findet). Wenn eine ArcSDE einmal nach ArcSDE 10 migriert ist, gibt es keine Möglichkeit mehr, die zufälligen TYPE_OIDs zu ersetzen. Das Problem tritt bei erstmalig unter 9.3 (oder höher) angelegten ArcSDE Geodatabases nicht auf. 4.2 Lösungsstrategie 2 1. Datenbank mit expdp exportieren. 2. Neue SDE wie unter Anlegen einer neuen SDE beschrieben anlegen. 3. Datapump-Import aller Benutzerschema-Geodatabases (ohne Benutzer SDE). 4. Integration der Benutzerschema-Geodatabases in die Master-Geodatabase (manuell über Anheben der ID_GENERATOR-Sequenzen, INSERT in die Tabelle SDE.INSTANCES). 5. Neustart der Datenbank. 6. Anlegen des entsprechenden ArcSDE-Dienstes. AED-SICAD Aktiengesellschaft 10 / 18
5 Kombination von TYPEID- und TYPE_OID-Problem Bei der Kombination von TYPEID- UND TYPE_OID-Problem droht bei einem nur auf expdp basierendem Backup ein Datenverlust! Wenn zufällige TYPE_OIDs vorliegen also die Daten bereits von ArcSDE 9.2 migriert wurden und nun nach ArcSDE 10 migriert werden, bleiben die zufälligen TYPE_OIDs erhalten. Wenn nun gleichzeitig nicht geänderte TYPEIDs vorliegen, was sehr wahrscheinlich ist, da ja die Master- Geodatabase nicht ersetzt werden kann, und die Datenbank nach ArcSDE 10 migriert wurde, kann anschließend mit einem DataPump-Dump allein die Datenbank im Desaster-Fall (vollständiger Verlust der Datenbank z.b. durch Hardwaredefekt) nicht wiederherstellt werden. Bei Import der Master-Geodatabase, der ja wegen der zufälligen TYPE_OIDs notwendig wäre, würden sich die TYPEIDs ändern, sodass die Daten der Benutzerschema-Geodatabase nicht importiert werden könnten, weil sie falsche TYPEIDs referenzieren. In diesem Fall würde auch ein exp-dump der Tabelle SDE.GDB_ITEMS benötigt, um die Daten korrekt importieren zu können. Für 3A-Datenbanken ist daher wichtig, mindestens das TYPE_OID-Problem spätestens bei der Migration nach ArcSDE 10 zu lösen. Um ein kompliziertes Handling der Daten oder einen drohenden Datenverlust zu vermeiden, sollte auch TYPEID-Problem gelöst werden. AED-SICAD Aktiengesellschaft 11 / 18
6 Vorgehen bei Migration und Konvertierung von 3A-Datenbanken Im Folgenden werden die empfohlenen Vorgehensweisen zur Migration einer ArcSDE-Datenbank mit unterschiedlichen Ausgangssituationen dargestellt. Dabei gehen wir davon aus, dass die Master-GDB keine Daten enthält (kann in Tabelle SDE.TABLEREGISTRY festgestellt werden). Sollten Daten in der Master-GDB abgelegt worden sein, müssen diese.z.b. mit ArcCatalog manuell migriert werden. Wenn im Folgenden von Benutzerschema-GeoDatabase (BS-GDB) geredet wird, sind jeweils alle vorhandenen BS-GDBs gemeint. 6.1 Migration ArcSDE 9.2 nach ArcSDE 9.3 Vorgehen: - expdp der BS-GDB. - neue ArcSDE 9.3 Master-GDB wie unter 2.4 beschrieben anlegen. - impdp der BS-GDB und Anflanschen an neue Master-GDB (manuell über Anheben der ID_GENERATOR-Sequenzen, INSERT in die Tabelle SDE.INSTANCES) - anschließend Migration der BS-GDB nach 9.3. 6.2 Migration ArcSDE 9.2 nach ArcSDE 10 Vorgehen: Erst wie in Abschnitt 6.1, dann wie in Abschnitt 6.6 beschrieben ausführen. 6.3 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID ja, TYPEID ja Vorgehen: - expdp der BS-GDB erstellen. - neue ArcSDE 10 Master-GDB wie unter 2.4 beschrieben anlegen. - impdp der BS-GDB und Anflanschen an neue Master-GDB (manuell über Anheben der ID_GENERATOR-Sequenzen, INSERT in die Tabelle SDE.INSTANCES) - anschließend BS-GDB auf Version 10 migrieren. 6.4 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID ja, TYPEID nein Vorgehen: Wie in Abschnitt 6.3 beschrieben vorgehen. 6.5 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID nein, TYPEID ja Vorgehen: Fall 1: Migration in neue Datenbank: - expdp (full) erstellen. - impdp (full) in neue Datenbank inkl. Benutzer sde. - Master-SDE und BS-GDB auf Version 10 migrieren. Fall 2: Migration innerhalb einer Datenbank: - expdp (full) erstellen; - Datenbank löschen, d.h. alle Benutzer (außer vordefinierte Oracle-Benutzer) löschen. WICHTIG: Benutzer sde zuletzt löschen! - Datenbank neu starten - per impdp (full) Benutzer neu erstellen - Master-SDE und BS-GDB auf Version 10 migrieren. AED-SICAD Aktiengesellschaft 12 / 18
6.6 Migration ArcSDE 9.3 nach ArcSDE 10, TYPE_OID nein, TYPEID nein Vorgehen: Migration innerhalb der Datenbank möglich; auch expdp/impdp inkl. Benutzer sde mit anschließendem Upgrade auf 10 problemlos. 6.7 ArcSDE 10 nach ArcSDE 10, TYPE_OID ja, TYPEID ja TYPE_OID nicht mehr lösbar! BS-GDB kann nicht mehr an andere Master-GDB angehängt werden. Datentransport muss immer inkl. dieser Master-GDB (Benutzer SDE) erfolgen, dadurch erhöhte Aufwände beim Support und bei Umstrukturierungen. Vorgehen: - expdp (full) und exp (alle GDB_ITEMS, zur Sicherheit besser full) erstellen; - alle Benutzer löschen; WICHTIG: Benutzer SDE zuletzt! - Datenbank neu starten - impdp (full) und anschließendes imp der Tabellen GDB_ITEMS aller Benutzer (mit IGNORE=Y). 6.8 ArcSDE 10 nach ArcSDE 10, TYPE_OID ja, TYPEID nein TYPE_OID nicht mehr lösbar! BS-GDB kann nicht mehr an andere Master-GDB angehängt werden. Datentransport muss immer inkl. Benutzer SDE erfolgen, dadurch erhöhte Aufwände beim Support und bei Umstrukturierungen. Vorgehen: Keine Aktion erforderlich. 6.9 ArcSDE 10 nach ArcSDE 10, TYPE_OID nein, TYPEID ja Vorgehen: Wie in Abschnitt 6.7 beschrieben vorgehen, d.h. Re-Import aller Benutzer durchführen. 6.10 ArcSDE 10 nach ArcSDE 10, TYPE_ID nein, TYPEID nein Es liegt kein Problem vor! AED-SICAD Aktiengesellschaft 13 / 18
7 Anlagen 7.1 Feststellung der TYPEID von ST_GEOMFROMTEXT: select TypeID from user_types where type_name='st_geomfromtext'; 7.2 Feststellung der TYPE_OID von ST_GEOMETRY select TYPE_OID from user_types where type_name='st_geometry'; 7.3 Festellung der Tabellen, die Daten mit ST_GEOMETRY enthalten -- Schreibt alle nichleeren Tabellennamen mit Spalten von Typ ST_GEOMETRY set serveroutput on set feedback off spool listtables.out DECLARE rowcnt integer; -- alle Tabellen mit ST_GEOMETRY, DBA_TAB_COLUMNS enthaelt auch Views cursor c1 is select tv.owner, tv.table_name from DBA_TAB_COLUMNS tv, DBA_TABLES t where tv.data_type = 'ST_GEOMETRY' and tv.owner = t.owner and tv.table_name = t.table_name; -- liefert die Anzahl Zeilen einer Tabelle function rowcount(tablename in user_tables.table_name%type) return integer is cursornum integer; numrows integer; ignore integer; begin cursornum := dbms_sql.open_cursor; dbms_sql.parse(cursornum, 'select count(1) from ' tablename, dbms_sql.v7); dbms_sql.define_column(cursornum, 1, numrows); ignore := dbms_sql.execute(cursornum); ignore := dbms_sql.fetch_rows(cursornum); dbms_sql.column_value(cursornum, 1, numrows); dbms_sql.close_cursor(cursornum); return numrows; end; BEGIN END; / quit dbms_output.enable(100000); for tbl in c1 loop rowcnt := rowcount(tbl.owner '.' tbl.table_name); if (rowcnt > 0) then dbms_output.put_line(tbl.owner '.' tbl.table_name); end if; end loop; AED-SICAD Aktiengesellschaft 14 / 18
7.4 Entscheidungsdiagramm für 3A-Datenbanken Start ArcGIS 9.3 oder höher? Nein Noch kein TYPE_OID Problem Upgrade gemäß Leitfaden (3) (3) dabei Datenbank gemäß 2.4 (mit geänderten TYPEIDs) anlegen Ja TYPE_OID von ST_GEOMETRY beginnt mit A618? (1) Ja TYPE_OID Problem liegt nicht vor (1) als Benutzer SDE: select TYPE_OID from user_types where type_name='st_geometry'; Nein TYPE_OID Problem liegt vor (2) als Benutzer SDE: select TYPEID from user_types where type_name='st_geomfromtext'; SDE 10? Nein Lösungsstrategie 2 umsetzen! Ja TYPE_OID Problem nicht mehr lösbar! ENDE TYPEID von ST_GEOMFROMTEXT = 6? (2) Ja Lösungsstrategie 1 umsetzen! Nein TYPEID Problem liegt vor Sicherung um exp- Dump aller Tabellen mit ST_GEOMETRY erweitern! Sicherung mit RMAN? Nein Sicherung mit expdp UND exp? Nein ACHTUNG: Datenverlust droht! Ja Ja Sicherung OK AED-SICAD Aktiengesellschaft 15 / 18
AED-SICAD Aktiengesellschaft Postfach 83 07 54 D-81707 München Ihre Anregungen www.aed-sicad.de Absender: Produkt: Kommentare:
Herausgegeben von / Published by AED-SICAD Aktiengesellschaft Postfach 83 07 54 D-81707 München Printed in Germany