Diskussion:Db2

Artikel aufteilen

Hallo,

sollten wir den Artikel aufteilen auf einen für Unix/Windows, einen für z/OS und einen für restliche Systeme? Ein Unix-DBA interessiert sich für ZPARMs genausowenig wie ein z/OS DBA etwas mit dem CLI.INI zu tun hat.

Ich bin dafür. Schließlich unterscheiden sich die Systeme sehr voneinander. Es wären aber auch einige Unterabschnitte möglich. Ich schlage hierfür vor: DB2/z/OS, DB2 für Windows/Unix/Linux, DB2/AIX und DB2/400. Die ersten beiden kann ich bearbeiten. --IF 14:45, 15. Nov 2006 (CEST)

Ich bin kein DB2 Profi, aber weil ich da in guter Gesellschaft bin (in Bezug auf den typischen Wikipedia-Leser) würde sagen, mehr allgemeine Infos (Geschichte, Einsatzszenarien, Vor-/Nachteile...) wären wichtiger als diese Masse an technischen Details. --PeterGerstbach 10:58, 15. Feb. 2007 (CET)

Zu den Einsatzszenarien der einzelnen DB2-Produkte gibt es nicht viel zu sagen. Das hängt halt von der Hardware ab. Nach Vor- und Nachteilen der einzelnen DB2-Produkten zu fragen, finde ich auch nicht besonders sinnvoll, da sich die IBM darum bemüht, alle DB2-Produkte mit einem weitgehend einheitlichen Funktionsumfang auszustatten, damit man eine Anwendung, die ihre Daten in DB2 speichert, leicht von einer Hardware zu einer anderen oder von einem Betriebsystem auf ein anderes portieren kann. Viel interessanter finde ich die Frage, worin die Unterschiede der Datenbanken der einzelnen Hersteller liegen. Wo hat DB2 seine Stärken, wo Oracle und SQL-Server? Gerade im Bereich der Open-Source-Datenbanken hat sich in den letzten Jahren sehr viel getan. Diese Fragen zu erörtern, wäre aber hier der falsche Ort. Das sollte z.B. unter dem Begriff Relationale Datenbanken beschrieben werden. 16. Feb. 2007

Ich bereite gerade noch einige weitere Abschnitte für diesen Artikel vor:

• Partitionierungskonzept bei DB2 zOS
• Partitionierungskonzept bei DB2 LUW
• Skalierungsmöglichkeiten von DB2 LUW
• Geschichte von DB2 zOS (Welche Features sind mit den einzelnen Versionen neu hinzugekommen?)

Ich glaube, dass es langsam an der Zeit ist, zwei Artikel daraus auszulagern. Dabei sollte der Artikel DB2 bestehen bleiben und auf die beiden anderen Artikel verweisen. Nur bei den Namen der beiden neuen Artikel bin ich mir noch nicht sicher. Mögliche Namen wären:

• DB2 UDB zOS und DB2 UDB LUW
• oder DB2 z/OS und DB2 LUW Darf man einen Slach in einem Artikelnamen verwenden?
• oder DB2 UDB für zOS und DB2 UDB für Linux, Unix, Windows Darf man Kommas in einem Artikelnamen verwenden?

Das Kapitel Utilities des aktuellen Artikels würde ich in den neues Artikel zu DB2 zOS nehmen, da der Inhalt dieses Artikels eigentlich fast nur diese Installation betrifft. -- 77.176.26.252 08:12, 10. Mär. 2007 (CET)

Der Artikel hat eigentlich noch nicht die Länge erreicht, wo eine Aufteilung Sinn macht. Und wenn, dann sollte das in Form von Unterartikeln geschehen, d.h. der Hauptartikel DB2 bleibt und z.B. im Absatz "DB2 z/OS" steht eine kurze Zusammenfassung und ein Verweis auf den neuen Artikel. Im Übrigen würde ich dem Artikel lieber mal einen Abschnitt "Geschichte" hinzufügen und die Stichwortlisten in Fließtext umwandeln, bevor neue Informationen hinzugefügt werden. --Kurt Seebauer 12:41, 10. Mär. 2007 (CET)

Einen Abschnitt Geschichte gibt es schon lange. Ich habe inzwischen einen Abschnitt Geschichte (DB2 z/OS) hinzugefügt. -- 82.135.37.138 10:05, 15. Mär. 2007 (CET)

sorry, das hab ich in der Eile wohl übersehen. Vielen Dank für die ganze Arbeit! --Kurt Seebauer 10:21, 15. Mär. 2007 (CET)

Artikelqualität

nunja, leicht suboptimal. Schon allein weil nicht zwischen "IBM DB2 software portfolio" und "DB2 Database Servers" (im Gegensatz zu "DB2 Content Management", "DB2 Information Integration", "DB2 Business Intelligence", "DB2 and IMS database management tools") und "DB2 Universal Database" bzw. "DB2 Universal Database for z/OS and OS/390" (im Gegensatz zu "DB2 Connect", "DB2 Everyplace", "IMS family", "IBM Informix product family", "IBM UniData and UniVerse (U2)") unterschieden wird. Die IBM-interne Seite ([1], wie gesagt, nur IBM-intern!), die die ganze DB2/Famile ganz kurz aufschlüsselt (enzyklopädischer Stil) hat knapp 50kB+Bilder... --Jacob000 16:42:59, 15. Aug 2005 (CEST)

Einige der von Dir genannten Produkte sind inzwischen im Artikel beschrieben. Ich fände es gut, wenn Du die anderen Produkte auch noch in geeigneter Form beschreiben würdest. --Julius-m 10:41, 20. Jun. 2007 (CEST)

Behauptungen oder Fakten? Praxisberichte?

Sehr interessante Behauptung: "Im Großrechnerbereich hat DB2 zu einem großen Teil das hierarchische Datenbanksystem IMS von IBM abgelöst." - es wäre lohnend hier genauer nachzuforschen.

Wer kennt wirklich große Anweder wo diese Behauptung zutrifft? (Industrie, Banken, Versicherungen uws. mit etwa über 5000 Mitarbeiter) Gibt es Praxisberichte, Literatur über Ablösungen? Ich selbst habe die Ablösung einer Teilanwendung mit 120 DB2 Tabellen miterlebt, aber der Großteil bei diesem Anwender (etwa 16 Terabyte) ist noch immer in IMS Datenbanken. Also: von einer "Ablösung zu großen Teilen" kann nach meiner Schätzung noch überhaupt keine Rede sein. Tamas Szabo 11:34, 15. Aug. 2007 (CEST)

Ich habe bei den meisten deutschen Banken bei der Systementwicklung mitgearbeitet. Hier gilt fast überall die Anweisung, dass Neuentwicklungen nur noch mit DB2 gemacht werden dürfen und die bestehenden Systeme, die IMS verwenden, sollen nach und nach durch Neuentwicklungen mit DB2 abgelöst werden. Hier gibt es etliche Systeme, die IMS basiert sind und die schon 20 oder sogar 30 Jahre alt sind und immer noch gut funktionieren. Da kann es durchaus auch vorkommen, dass solche Dinosaurier-Systeme auch noch die nächsten 20 bis 30 Jahre überleben werden. Bei den Versicherungen habe ich nicht so viel Einblick, aber die Versicherungen, die ich kennen gelernt habe, gehen mit diesem Thema ähnlich um.

Die Gründe dafür liegen auf der Hand: IMS ist unflexiebler in der Gestaltung und bietet nur wenige Zugriffsarten im Vergleich mit DB2. Relationale Datenmodelle kann man nur stark eingeschränkt in IMS umsetzen und Joins oder Subselects werden überhaupt nicht unterstützt. Fremdschlüssel-Beziehungen werden nur innerhalb der Hierarchie unterstützt. Da wird die Programmierung viel zu aufwändig und damit zu teuer. IMS ist einfach veraltet. Schon seit Jahren gibt es keine wesentlichen neuen Release und Funktionen in IMS, denn das Produkt wird auch von der IBM nicht mehr weiterentwickelt, sondern nur noch supportet, solange die Kunden es noch nutzen. --Julius-m 11:29, 18. Aug. 2007 (CEST)

Kann so nicht stimmen (Zitat): "...IMS wird auch von der IBM nicht mehr weiterentwickelt" - demgegenüber: neu angekündigt IMS V 10 (also eine GROSSE Neuentwicklung) mit XML, Scalability with more parallelism in IMS Database Recovery and Sharing Control (DBRC), and improved performance/capacity in Fast Path, IMS High Availability Large Database (HALDB), and database utilities, XQuery access to IMS data, and broadened Java™ and XML tooling to ease development .... http://www-306.ibm.com/software/data/ims/v10/ Tamas Szabo 19:06, 18. Aug. 2007 (CEST)

Das ist ja interessant. Schreibe das doch mal in dem Artikel über IMS.--Julius-m 12:46, 20. Aug. 2007 (CEST)

IMS ist scheinbar sehr lebendig, zum Beispiel seit 2004 gibt es immer neue Versionen, V7, V8, V9 seit 2006 angekündigt V10. Eine Version ist mit Überdeckung etwa 2 Jahre mit Support. Siehe Lebenszyklus seit 2004 http://www-306.ibm.com/software/data/ims/v7/index.html Tamas Szabo 17:49, 19. Aug. 2007 (CEST)

"die Anweisung, dass Neuentwicklungen nur noch mit DB2 gemacht werden dürfen und die bestehenden Systeme, die IMS verwenden, sollen nach und nach durch Neuentwicklungen mit DB2 abgelöst werden." habe ich mehrfach gehört seit 1990 etwa. Also wirklich grosse Ablösungen sind mir nicht bekannt, aber es wäre wichtig von konkreten IMS-DB2 Ablösungen mit Zahlen, Leistungsdaten (ohne Preisgabe von Firmen-Namen) Erfahrungen zu bekommen. Tamas Szabo 17:49, 19. Aug. 2007 (CEST)

ich kenne mehrere erfolgreiche Projekte, in denen IMS teilweise oder vollständig durch DB2 ersetzt wurde. Das betrifft Banken wie auch Versicherungen. In allen Einrichtungen galt dabei, dass Neuentwicklungen nur noch in DB2 gemacht werden.

Außerdem bitte nicht IMS/DB und IMS/DC durcheinander werfen. IMS/DC ist ein Transaktionsmonitor und wird sehr gerne für DB2 eingesetzt. Dies steht nicht im Widerspruch zum bisher gesagten.Benutzer:Ingo Federenko

Studien zur Verteilung von IMS und DB2 gibt es vereinzelt, z.B. bei GULP.

In den letzten Jahren habe ich in mehreren Projekten bei der HypoVersinsbank und der IZB-Soft, dem RZ der bayerischen Sparkassen mitgearbeitet. Ich denke, es ist kein Geheimnis, dass bei diesen Firmen der Umgang mit IMS so geregelt ist, wie ich es oben beschrieben habe. Als Trainer für DB2-Seminare habe ich von vielen Seminarteilnehmern erfahren, dass sie die DB2-Seminare besuchen sollten, um danach eine Migration von IMS nach DB2 durchzuführen. In den letzten 12 Jahren meiner Arbeit habe ich von keinem einzigen größeren Neu-Projekt erfahren, bei den die Daten in einer IMS-DB gespeichert werden sollten. Wenn jemand von anderen Projekten berichten kann, dann würde mich das sehr interessieren.

Konkrete Zahlen über Projekt-Butgets und Leistungsdaten kann ich hier nicht weitergeben, weil das meiner Geheimhaltungsverpflichtung gegenüber Firmeninterna widersprechen würde. --Julius-m 22:31, 20. Aug. 2007 (CEST)

Ein großes "Neu-Projekt" mit neueren Technologien kann bei den seit etwa 1985 neu gewachsenen Firmen entstehen (es gibt solche). Firmen die bereits 1978-1988 sehr groß waren haben die großen "Neu-Projekte" hinter sich, mit riesigen Investitionen (15 - 20 Mio LOC PL/I oder COBOL). Ich warte seit 1990 "Migrationen von IMS nach DB2 durchzuführen", wie es oft "geplant" aber nie angefangen wurde. Es bleibt bei relativ "kleinen" Migrationen (etwa 1 Mio LOC Migration habe ich auch miterlebt, weniger als 10%) bei 3-4 Großanwender die ich näher kenne. "von IMS nach DB2" steht in den Richtlinien, seit fast 20 Jahren, mit zunehmender Ernüchterung. Das könnte der Grund Sein für immer neue IMS-Versionen (seit 2005: V7, V8, V9, jetzt V10). Tamas Szabo 19:17, 21. Aug. 2007 (CEST)

Nochmal: IMS/DC wird weiterhin intensiv genutzt. IMS/DB dagegen nur noch vereinzelt. Um Namen zu nennen: Hypo, DreBa, DeuBa, Citi-Bank, KfW, Karlsruher Versicherungen sowie diverse staatliche oder halbstaatliche Einrichtungen.Benutzer:Ingo Federenko

Toter Weblink (erledigt)

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich unerreichbar ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.ibm.com/software/data/db2/udb/viper/ (archive)
  • In DB2 on 2007-06-29 10:33:22, 404 Not Found
  • In DB2 on 2007-08-27 15:30:12, 404 Not Found

Die Webseite wurde vom Internet Archive gespeichert. Bitte verlinke gegebenenfalls eine geeignete archivierte Version: [2]. --KuhloBot 17:30, 27. Aug. 2007 (CEST)

Gliederung (erledigt)

Hallo allerseits,

ich finde die Gliederung ein wenig zu 'flach'. Drei Gliederungspunkte »Eigenschaften«... sowie jeweils zwei für Komponenten Tools auf der obersten Ebene finde ich ein wenig to much. Was haltet Ihr von einer Überareitung der Gliederung? Schlage sie wie folgt vor:

   * 1 Eigenschaften
         o 1.1 Eigenschaften (DB2 z/OS)
         o 1.2 Eigenschaften (DB2 LUW)
   * 2 Komponenten
         o 2.1 Komponenten (DB2 z/OS)
         o 2.2 Komponenten (DB2 LUW)
   * 3 Tools
         o 3.1 Tools (DB2 z/OS)
         o 3.2 Tools (DB2 LUW)
   * 4 Skalierbarkeit (DB2 LUW)
   * 5 Partitionierung
         o 6.1 Datenbankpartitionierung
         o 6.2 Tabellenpartitionierung
         o 6.3 Indexpartitionierung
   * 7 Index-Typen
   * 8 SQL PL
   * 9 Utilities
         o 9.1 RUNSTATS
         o 9.2 REORGCHK
         o 9.3 REORG
         o 9.4 CHECK INDEX
         o 9.5 CHECK DATA
         o 9.6 Monitoring von Utilities (DB2 z/OS)
   * 10 Extensions
         o 10.1 Net Search Extender
         o 10.2 Spatial Extender
         o 10.3 Object Relational Extender
         o 10.4 XML Extender
         o 10.5 OLAP-Extender
   * 11 Geschichte
         o 11.1 Geschichte (DB2 z/OS)
   * 12 Sonstiges
   * 13 Siehe auch
   * 14 Weblinks
   * 15 Quellen

Tolukra 13:45, 02. April 2008 (CET)

Geschichte DB2 LUW

Das fehlt hier noch. Vielleicht findet sich jemand, der fachkundig genug ist, dazu eine Übersicht beizutragen. --Julius-m 20:20, 22. Dez. 2008 (CET)

1990 gab es unter IBM OS/2 1.3 EE (Extended Edition) einen Database Manager, was der Ursprung von DB2/2 zu sein scheint – und damit wohl auch von DB2 LUW? Es gab außerdem eine grafische Oberfläche für den Database Manager, den Query Manager. Ob das bei OS/2 1.1 oder 1.2 auch schon dabei war, weiß ich nicht. Hier steht es auch noch mal: http://www.os2museum.com/wp/os2-history/os2-16-bit-server/ -- Eliza Winterborn (Diskussion) 10:52, 22. Jun. 2018 (CEST)

nur Listen

Hallo Rohieb, ich finde, deine Kennzeichnung des Artikels als "nur Listen" trifft überhaupt nicht zu. In den einzelnen Abschnitten werden viele Begriffe in Fließtext erläutert. Nur die Tatsache alleine, dass hier oft Gliederungspunkte verwendet werden, um nacheinander viele relevante Aspekte zu beschreiben, rechtfertigt Deine Kritik noch nicht. Unter einer Liste verstehe ich eine Aufzählung von einzelnen Begriffen. --Julius-m 19:07, 18. Jan. 2009 (CET)

Inzwischen sind drei Wochen vergangen und weder Benutzer:Rohieb, noch jemand anderes begründet die "nur Listen"-Kritik. Ich schlage vor, noch ein par Wochen zu warten und dann - wenn immer noch keine überzeugende Begründung hier vorgebracht wird - die Markierung im Artikel wieder herauszunehmen. --Julius-m 14:14, 8. Feb. 2009 (CET)

Markierung entfernt --Julius-m 23:20, 14. Apr. 2009 (CEST)

richtig und/oder noch aktuell ?

 BSDS = Bootstrap Data Set. Dateien, die Recovery-Informationen speichern

Der BSDS enthält mehr als das. Er enthält auch Kommunikationsinformationen für DDF bzw. Sysplex

 Datenbank (engl. Database) ist ein logisches Ordnungskriterium von DB2-Objekten, die einer Data Sharing Gruppe zugeordnet sind

Eine Datenbank bei DB2 for z/OS hat nichts mit Data Sharing "am Hut". Sie ist eine logische Verwaltungseinheit von DB2-Objekten.

 SPAS = Stored Procedure Address Spaces. Adressraum, in dem eine Stored Procedure ausgeführt wird.

SPAS sind veraltet. Sie werden von DB2 zwar *noch* unterstützt, aber können nicht mehr neu definiert werden. Stored Procedures laufen jetzt in WLM-managed Adressräumen

 Beispiel 2:
CREATE TABLE t1 (verkaufsdatum date, umsatz decimal(10,2))
IN ts1, ts2, ts3, ts4, t5
partition BY range(verkaufsdatum)
( starting FROM ('01.01.2007') ending at ('31.01.2007') IN ts1,
 ending at ('31.05.2007') IN ts2,
 ending at ('01.06.2007') IN ts3,
 ending at ('10.07.2007') IN ts4,
 ending at ('31.12.2007') IN ts5);

Ich bin leider im LUW-Umfeld nicht so fit, vielleicht kann mal jemand das Statement prüfen. Es erscheint mir nicht plausibel, dass es zweimal eine IN-Klausel enthält.

CREATE tablespace ts1
numpart 5
IN db01;

es muss numparts heissen, nicht numpart. Sonst gibts SQLCODE -104

  Indexpartitionierung  
 ... Es muss ein eindeutiger (unique) Index angelegt werden ...
 CREATE UNIQUE INDEX i1
 ON t1 (verkaufsdatum)
 cluster
 ( part 1 VALUES ('31.01.2007'),
 part 2 VALUES ('31.05.2007'),
 part 3 VALUES ('01.06.2007'),
 part 4 VALUES ('10.07.2007'),
 part 5 VALUES ('31.12.2007'));

Einen eindeutigen Index brauche ich nur bei Referentieller Integrität für die Parent Tabelle, aber nicht für die Partitionierung. Der obige Index i1 ist nonsense, er würde mir maximal einen Verkauf pro Tag erlauben.

Das stimmt nicht. Bei Indexpartitionierung muss ein eindeutiger Index erstellt werden. Außerdem: warum sollte so ein Index nonsense sein? Es könnten doch in dieser Tabellen Umsatz-Summen gruppiert nach dem Verkaufsdatum gespeichert werden. Das könnte sehr wohl sinnvoll sein. Ist alles eine Frage der Datenmodellierung gelle? --Julius-m 21:50, 25. Mär. 2010 (CET)

Widerspruch. Der partitioning index muss nicht UNIQUE sein

Wenn Du mir nicht glaubst, dann schau Dir mal beim CREATE INDEX das Beispiel 2 an:

http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dsnsqh17/5.31?DT=20080722111827

ich hoffe, Du glaubst IBM.

Wenn Du Umsatzgruppen in der Tabelle speichern willst, dann kann der Index natürlich sinnvoll sein. ( Wobei ich mich dann allerdings fragen würde, warum ich für 1 Satz ('01.06.2007') eine eigene Partition brauche. das müssten schon sehr gute Gründe sein, um den Overhead an offenen VSAM-Clustern zu rechtfertigen - aber das ist eine andere Diskussion ) -- 194.145.146.129 (14:53, 14. Mai 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Da habt Ihr beiden Recht. Ich war im Unrecht. Ich hab's im Artikel geändert. Danke für den Hinweis. --Julius-m 21:20, 21. Mai 2010 (CEST)

  Bei der in früheren DB2 Versionen verwendeten Index-partitionierung einer Tabelle konnte nur der Primärschlüssel-Index partitioniert werden

Der CLUSTERing Index, nicht der Primärschlüssel-Index. Das muss nicht zwangsläufig der gleiche sein

Auch hier stimmt Deine Bemerkung nicht: Bei der Index-Partitionierung sind eben genau diese drei Kriterien untrennbar miteinander verbunden: 1. Partitionierungskriterium 2. Clusterreihenfolge und 3. Primary key. Erst bei der Tabellenpartitionierung, die ab Version 8 möglich ist, ist das unabhängig voneinander. --Julius-m 21:50, 25. Mär. 2010 (CET)

stimmt definitiv nicht, s.o. -- 194.145.146.129 (14:53, 14. Mai 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

  Indices vom Typ *1 können natürlich in der aktuellen Version auch erstellt werden.

Type 1 Indices werden schon seit DB2 UDB for OS390 Version 6 nicht mehr unterstützt

Es geht hier nicht um den alten Index Typ 1, sondern um den in der vorstehenden Abbildung beschriebenen Index mit der Markierung *1 also partitionierend und partitioniert. --Julius-m 21:50, 25. Mär. 2010 (CET)

  //REORG    EXEC DSNUPROC,UID='JCA.REORG',TIME=1440,
  //         UTPROC=,
  //         SYSTEM='V71A',DB2LEV=DB2A
  //UTPRINT  DD  SYSOUT=*
  //SYSIN    DD *
  REORG TABLESPACE DSNXXX.DSNABCDE

DB2LEV ist kein gültiger Parameter für die Prozedur DSNUPROC

  CHECK INDEX sollte nach einem conditional Restart oder einem Point-in-time Recovery für alle Tablespace ausgeführt werden

nach einen Point-in-Time Recovery sollte ein REBUILD Index gemacht weerden, kein CHECK INDEX

Deine Kritik ist nicht berechtigt. Nach einem Recover kann man sehr wohl ein CHECK INDEX ausführen, nämlich zum prüfen, ob der Index noch ok ist. Das ist vor allem bei Tabellen sinnvoll, bei denen sich der Datenbestand selten ändert. --Julius-m 16:04, 27. Mär. 2010 (CET)

Das ist wohl eher der Ausnahmefall. Und wenn sich dann auch nur ein einziger Satz geändert hat, dann muss nach dem CHECK sowieso der REBUILD laufen und ich habe doppelten Aufwand, doppelte Kosten und doppelte Ausfallzeit -- 194.145.146.129

  Dynamic Scrol Cursor

der korrekte Ausdruck ist: dynamic scrollable cursor

-- 194.145.146.129 11:07, 21. Aug. 2009 (CEST)

Warum schreibst Du das allen auf die Diskussionsseite. Es handelt sich teilweise nur um Tippfehler, warum korrigierst Du das nicht gleich im Artikel? --93.133.185.176 23:26, 18. Okt. 2009 (CEST)

Ist wohl gar nicht so schlecht, dass er es nicht gleich in den Artikel reingeschrieben hat, denn dann hätte er auch diverse Fehler in den Artikel reingebracht. Die Tippfehler wurden im Artikel inzwischen korrigiert. --Julius-m 21:18, 1. Mai 2010 (CEST)

naja, er/sie hätte es wohl doch machen sollen. Er/sie hätte mehr Fehler beseitigt als reingebracht. Ich selbst administriere DB2/OS390 bzw. DB2/zOS schon seit Version 1.3 und muss sagen, dass er/sie in seinen/ihren Kritikpunkten recht hat. Partitioning Indices mussten noch nie unique sein und CHECK INDEX statt REBUILD INDEX ist völliger nonsense. Schade, dass Julius-m jede Kritik an "seinem" Artikel abblockt, selbst wenn sie berechtigt ist. -- 93.104.103.167 20:31, 17. Mai 2010 (CEST)

Klar lasse ich mich korrigieren. Die Kritik muss allerdings berechtigt sein. Am einfachsten kann jemand das belegen, wenn die Kritik durch andere Quellen belegt wird, wie Du es oben getan hast. Noch einmal Danke für die Kritik. Übrigens ist das nicht "mein" Artikel. Die Abschnitte über die Utilities hat jemand anderes geschrieben. --Julius-m 21:26, 21. Mai 2010 (CEST)

Maximale Größe

Die Maximale Größe ist für eine Tabelle angegeben. Denke das es richtig wäre, wenn die max. Größe für den Tablespace (in welchem sich mehrere Tabellen befinden können) angegeben wird. -- SBrandemann (11:09, 12. Nov. 2009 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Ergänzung

Der Link "Das DB2 SQL Cookbook von Graeme Birchall" zeigt ebenfalls auf eine gelöschte (aber noch erreichbare) Seite. --Milcke (Diskussion) 11:50, 26. Jan. 2015 (CET)

Offizielle Namen der DB2-Versionen

Hallo, wahrscheinlich ist das nur Kleinkram, aber wäre es sinnvoll, die Namen der DB2-Versionen mal zu korrigieren? An vielen Stellen steht noch IBM DB2 UDB, obwohl IBM den Zusatz "UDB" schon länger aus den Produktnamen gestrichen hat. IBM spricht auch inzwischen von IBM i, nicht mehr von iSeries. Ich könnte mich da mal an die Korrektur wagen, frage aber lieber mal nach weiteren Meinungen, schließlich will ich nicht, dass jemand diese Fleißarbeit dann wieder rückgängig macht. Meinungen? --Emmy Sophie (Diskussion) 22:22, 27. Mär. 2016 (CEST)

Der Name wurde nun zu Db2 geändert. Also kleines "b" nutzen. Quelle: http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/7/877/ENUSZP17-0457/index.html&lang=en&request_locale=en --195.212.29.190 12:42, 21. Nov. 2017 (CET)

Oops...

... habe schon lange (V9.x) nicht mehr in DB2 hineingeschaut. Hat man tatsächlich irgendwann den IRLM (IMS Resource Lock Manager) auf beiden Seiten in "Internal R..L..M" umbenannt ... oder hab ich da ein dejavu, hat noch jemand nen Denne aus den 80ern/90ern rumliegen zum Nachsehen? :-D

Noch: Die DB2 Version 3.x (ich meine 3.1, aber nicht sicher) habe ich schon 1989 benutzt. Kann mich nicht erinnern dass das 2.x gewesen sein soll. Wäre aber nett, wenn mal einer nachsehen könnte ...

VG Sscheid (Diskussion) 18:11, 4. Sep. 2019 (CEST)

IDAA (IBM DB2 Analytics Accelerator)

Könnte bitte jemand den IBM DB2 Analytics Accelerator (IDAA) einbauen? Dieses Zusatzsystem wird von einigen großen Firmen verwendet. Literatur wäre bei https://www.ibm.com/support/pages/ibm-db2-analytics-accelerator-zos-v75-guides-and-manuals erhältlich (nicht signierter Beitrag von 2001:171B:C9BB:EC10:C9A2:6FCF:B0EA:EB5E (Diskussion) 17:39, 29. Jun. 2021 (CEST))

Offene Baustellen mit Db2 / zOS Blick

Einige Dinge fehlen im Artikel:

- LOAD / UNLOAD Utility

- COPY Utility

- Bei der Partitionierung die Unterscheidung zwischen partition by range bzw. partition by growth

- time temporal tables

- row permission

Die Frage ist nur: Wo ergänzen / wo bleiben lassen, ohne Gefahr zu laufen, hier ein weiteres Handbuch zu schreiben?!

--BauerJKH (Diskussion) 23:35, 18. Aug. 2022 (CEST)