Hallo, Ich probiere mich gerade an MySQL und habe folgendes Problem: Ich möchte beim Erstellen eines Datensatzes einen der Werte aus einer anderen Tabelle selektieren, und zwar mit Hilfe einer WHERE-Klausel. Ich bekomme aber einfach die richtige Syntax nicht hin: mysql> insert into table1 (feld1, feld2, feld3) values (wert1, wert2, (select wert3 from table2 where feldfoo = 'bar')); Ich hoffe das geht prinzipiell irgendwie in einem Rutsch, es wäre doch sehr umständlich, wenn ich immer selber in table2 nachsehen müsste, wie der zu übernehmende Wert lautet. Christian -- * * Bitte kein CC: bei Antwort an Mailingliste * * Etikette per Mail: To: mailings-suse@gmx.de Subject: send etikette http://home.t-online.de/home/c.w.schult/etikette.html --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 23 Oct 2000, at 14:32, Christian Schult wrote:
Hallo,
Ich probiere mich gerade an MySQL und habe folgendes Problem: Ich möchte beim Erstellen eines Datensatzes einen der Werte aus einer anderen Tabelle selektieren, und zwar mit Hilfe einer WHERE-Klausel. Ich bekomme aber einfach die richtige Syntax nicht hin:
mysql> insert into table1 (feld1, feld2, feld3) values (wert1, wert2, (select wert3 from table2 where feldfoo = 'bar'));
Ich hoffe das geht prinzipiell irgendwie in einem Rutsch, es wäre doch sehr umständlich, wenn ich immer selber in table2 nachsehen müsste, wie der zu übernehmende Wert lautet.
Leider kenne ich MySQL nicht, aber falls so etwas in MySql gehen sollte, dann versuch mal: insert into table1 (feld1, feld2, feld3) select Wert1, Wert2, column3 from table2 where ... wobei column3 dann deinen Wert3 benhalten sollte. So würde es hier (Oracle) gehen. Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi, Christian Schult wrote:
Ich probiere mich gerade an MySQL und habe folgendes Problem: Ich möchte beim Erstellen eines Datensatzes einen der Werte aus einer anderen Tabelle selektieren, und zwar mit Hilfe einer WHERE-Klausel. Ich bekomme aber einfach die richtige Syntax nicht hin:
mysql> insert into table1 (feld1, feld2, feld3) values (wert1, wert2, (select wert3 from table2 where feldfoo = 'bar'));
Ich hoffe das geht prinzipiell irgendwie in einem Rutsch, es wäre doch sehr umständlich, wenn ich immer selber in table2 nachsehen müsste, wie der zu übernehmende Wert lautet.
Mysql kann (noch) keine Subselects: Kapitel 5.4.1 Mysql Doku (Sub-selects) The following will not yet work in MySQL: SELECT * FROM table1 WHERE id IN (SELECT id FROM table2); SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2); However, in many cases you can rewrite the query without a sub-select: SELECT table1.* FROM table1,table2 WHERE table1.id=table2.id; SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id where table2.id IS NULL .... in der doku sind ein paar beispiele drin, wie man das umgehen kann, aber frag mich jetzt nicht wie ;-) -- MfG, M.Stahn ++ Deflector shields just came on, Captain. ++ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects:
Dann kann man Mysql vergessen. Tut mir leid, aber eine anständige DB ohne subselects? Meine Frage nach einem Rollback bei einem Subselect erübrigt sich dann ja wohl. Bernd -- Bitte die Etikette dieser Liste beachten: http://www.ndh.net/home/schult/ Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Bernd Brodesser wrote on Mon, Oct 23, 2000 at 16:59 +0200:
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects:
Dann kann man Mysql vergessen. Tut mir leid, aber eine anständige DB ohne subselects? Meine Frage nach einem Rollback bei einem Subselect erübrigt sich dann ja wohl.
Rollback? mySQL kann doch nichtmal Transaktionen, oder? mySQL kann vermutlich so gut wie gar nichts, aber das unheimlich schnell. Na ja, ist ja klar, mySQL ist ja nicht viel mehr als langsamer Zugriff auf Textdateien :) Hatten ja schon den Thread, wo rauskam, Leute, nehmt lieber Postgres. Das ist ne richtige Datenbank :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi, Steffen Dettmer wrote:
* Bernd Brodesser wrote on Mon, Oct 23, 2000 at 16:59 +0200:
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects:
Dann kann man Mysql vergessen. Tut mir leid, aber eine anständige DB ohne subselects? Meine Frage nach einem Rollback bei einem Subselect erübrigt sich dann ja wohl.
Rollback? mySQL kann doch nichtmal Transaktionen, oder?
Transaktionen gehen in der aktuellen Betas, habs aber noch nicht ausprobiert. Bin ganz froh das jetzt wenigstens Replikation funzt ;-)
mySQL kann vermutlich so gut wie gar nichts, aber das unheimlich schnell. Na ja, ist ja klar, mySQL ist ja nicht viel mehr als langsamer Zugriff auf Textdateien :)
Es kommt immer drauf an was Du machen willst. Fuer viele Dinge ist MySQL sehr gut geeignet (klein und sehr schnell), aber ebend nicht fuer alles.
Hatten ja schon den Thread, wo rauskam, Leute, nehmt lieber Postgres. Das ist ne richtige Datenbank :)
Typisch linux halt, man hat einfach mehrere Loesungen ;-) -- MfG, M.Stahn ++ To eat is human, to digest, divine. ++ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Moin, On Mon, 23 Okt 2000, Steffen Dettmer sent incredible lines:
* Bernd Brodesser wrote on Mon, Oct 23, 2000 at 16:59 +0200:
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects: Dann kann man Mysql vergessen. Tut mir leid, aber eine anständige DB ohne subselects? Meine Frage nach einem Rollback bei einem Subselect erübrigt sich dann ja wohl. Rollback? mySQL kann doch nichtmal Transaktionen, oder? mySQL kann vermutlich so gut wie gar nichts, aber das unheimlich schnell. Na ja, ist ja klar, mySQL ist ja nicht viel mehr als langsamer Zugriff auf Textdateien :)
Hatten ja schon den Thread, wo rauskam, Leute, nehmt lieber Postgres. Das ist ne richtige Datenbank :)
Das hängt immer davon ab was du machen willst, in einigen Bereichen ist Geschwindigkeit halt wichtiger. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 23-Oct-00 Bernd Brodesser wrote:
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects:
Dann kann man Mysql vergessen. Tut mir leid, aber eine anständige DB ohne subselects? Meine Frage nach einem Rollback bei einem Subselect erübrigt sich dann ja wohl.
Niemand hat behauptet, daß mysql eine vollständige DB-Engine ist. MySQL ist eine kleine SQL-Datenbank für einfache Aufgaben, die dafür hochperformant erledigt werden sollen. Wenn Du subqueries, Transaktionen und ähnliche Schmankerl haben willst, ist mysql sicher nicht das richtige Werkzeug. Ich würde mir in dem Fall PostgreSQL, Adabas, Oracle, Informix, Sybase oder SAPDB anschauen, die müßten das können. Wobei Transaktionen auf Datenbanken, die im normalen Filesystem gehalten werden, eh sinnlos sind, weil der transparente Cache des Filesystems die Konsistenz des Logs gefährdet. Sowas gehört auf Raw Devices, die Linux allerdings (noch) nicht von Haus aus beherrscht (nein, Block Devices sind keine Raw Device, die puffern). Alternativ kann man entweder die DB auf ein FS setzen, das synchron gemountet wird (ist aber auch nicht 100%ig sicher AFAIK) oder dem Kernel mittels eines Patches zu Raw Devices verhelfen. Oder eine DB verwenden, die z.B. direkt auf SCSI-Platten zugreifen kann über das generic SCSI Interface. -- =========================================================== Erhard Schwenk - alias Bitrunner =)B==o) =========================================================== No Spam replies please. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mon, Okt 23, 2000 at 11:28:18 +0200, Erhard Schwenk wrote:
On 23-Oct-00 Bernd Brodesser wrote:
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects:
... wobei das mit der Fragestellung eigentlich nichts zu tun hatte, die Syntax für den Insert war einfach nicht korrekt. Das wurde aber schon korrigiert. Wie gesagt: Dabei handelt es sich nicht um einen Inline-Select. [...]
Wenn Du subqueries, Transaktionen und ähnliche Schmankerl haben willst, ist mysql sicher nicht das richtige Werkzeug. Ich würde mir in dem Fall PostgreSQL, Adabas, Oracle, Informix, Sybase oder SAPDB anschauen, die müßten das können.
Da wäre noch Interbase von Inprise (ex Borland) zu erwähnen, ist seit dem letzten Linuxtag OS (AFAIK GPL). Bietet alles, was das Herz begehrt - inklusive einer leistungsfähigen SPL (Stored Procedure Language).
Wobei Transaktionen auf Datenbanken, die im normalen Filesystem gehalten werden, eh sinnlos sind, weil der transparente Cache des Filesystems die Konsistenz des Logs gefährdet. Sowas gehört auf Raw Devices, die Linux allerdings (noch) nicht von Haus aus beherrscht (nein, Block Devices sind keine Raw Device, die puffern).
Das ist so nicht ganz korrekt. Informix-SE z. B. arbeitet mit normalen C-ISAM-Dateien und beherrscht Transaktions-Logging! Es funktioniert auch, frag mich jetzt aber nicht, wie genau das läuft. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 24-Oct-00 Jan Trippler wrote:
Das ist so nicht ganz korrekt. Informix-SE z. B. arbeitet mit normalen C-ISAM-Dateien und beherrscht Transaktions-Logging! Es funktioniert auch, frag mich jetzt aber nicht, wie genau das läuft.
Da würde ich Dir mal einen Blick ins Informix-Handbuch empfehlen, dort steht ausdrücklich geschrieben, daß sich das TA-Logging bei Ablage der DB in Dateien zwar aktivieren läßt, aber für die Zuverlässigkeit ausdrücklich nicht garantiert werden kann, weil die Plattenpuffer die Konsistenz des Logs gefährden. Zumindest beim Dynamic Server steht das drin, und das dürfte bei SE nicht viel anders sein. Kann auch gar nicht anders gehen. Die DB-Engine ist darauf angewiesen, daß im Crash-file das physikalisch auf der Platte liegende Transaction Log genau den ebenfalls physikalisch auf der Platte liegenden Tablespaces entspricht. Das kann gar nicht funktionieren, wenn da ein vom OS gesteuerter transparenter Puffer dazwischen hängt, wie er üblicherweise bei Filesystemen (und auch bei den Linux Block Devices) verwendet wird. Die einzige Variante, die gehen könnte, wäre synchrones Mounten des Filesystems. Das wird aber elend langsam. -- =========================================================== Erhard Schwenk - alias Bitrunner =)B==o) =========================================================== No Spam replies please. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mit, Okt 25, 2000 at 09:15:01 +0200, Erhard Schwenk wrote:
On 24-Oct-00 Jan Trippler wrote:
Das ist so nicht ganz korrekt. Informix-SE z. B. arbeitet mit normalen C-ISAM-Dateien und beherrscht Transaktions-Logging! Es funktioniert auch, frag mich jetzt aber nicht, wie genau das läuft.
Da würde ich Dir mal einen Blick ins Informix-Handbuch empfehlen, dort steht ausdrücklich geschrieben, daß sich das TA-Logging bei Ablage der DB in Dateien zwar aktivieren läßt, aber für die Zuverlässigkeit ausdrücklich nicht garantiert werden kann, weil die Plattenpuffer die Konsistenz des Logs gefährden. Zumindest beim Dynamic Server steht das drin, und das dürfte bei SE nicht viel anders sein.
Tja, jetzt könnte ich kontern: Da hättest Du mal im Handbuch weiterlesen sollen, ich tue es aber nicht ;-) Der Dynamic Server arbeitet mit einer eigenen Verwaltung der HD-Zugriffe am Betriebssystem vorbei und ist demzufolge in Raw-Devices besser aufgehoben. Wenn man ihn in einer Datei einrichtet, dann sollte man das nur in Test- oder Notfällen tun, da er eben darauf nicht eingerichtet ist. SE (= Standard Engine) arbeitet mit den normalen Dateizugriffen des Systems in einer C-ISAM-Struktur und kann gar nicht in einem Raw-Device geparkt werden. Es IST also bei SE definitiv anders als bei ODS. Das war im übrigen auch der Grund, warum Informix die SE wesentlich schneller als ODS (= Online Dynamic Server) auf Linux portiert hatte.
Kann auch gar nicht anders gehen. Die DB-Engine ist darauf angewiesen, daß im Crash-file das physikalisch auf der Platte liegende Transaction Log genau den ebenfalls physikalisch auf der Platte liegenden Tablespaces entspricht. Das kann gar nicht funktionieren, wenn da ein vom OS gesteuerter transparenter Puffer dazwischen hängt, wie er üblicherweise bei Filesystemen (und auch bei den Linux Block Devices) verwendet wird.
Du verwechselst offensichtlich die Themen Datensicherheit und Transaktionskontrolle miteinander. TA-Kontrolle hat nicht die Aufgabe, Datenverluste zu vermeiden, sie soll die Konsistenz der Daten gewährleisten. Und das ist ohne weiteres auch mit gepufferten Zugriffen auf die HD zu realisieren. Dazu werden für jede Transaktion der Start, die Before Images, Änderungen und der Commit gespeichert. Wo steht denn, dass diese Änderungen unbedingt und in jedem Fall auch gleich im Tablespace landen müssen? Das kann doch die DB-Engine verwalten. Schlimmstenfalls werden die geänderten Sätze erst beim nächsten Neustart oder sync in die Tabellen geschrieben. Wenn Du mit Deinen Ausführungen das Thema Datensicherheit / Recovery meinst - da stimme ich Dir zu. Das geht nur mit vollständiger Kontrolle des DBMS über die Festplattenzugriffe (was ist da eigentlich mit den Controller-Caches?). Ungepuffert läuft da allerdings auch nichts. Jan P.S.: Bitte kein CC: ich lese die Liste mit. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 25-Oct-00 Jan Trippler wrote:
Du verwechselst offensichtlich die Themen Datensicherheit und Transaktionskontrolle miteinander.
Nein, tu ich nicht, glaubs mir.
TA-Kontrolle hat nicht die Aufgabe, Datenverluste zu vermeiden, sie soll die Konsistenz der Daten gewährleisten.
Spweot richtig.
Und das ist ohne weiteres auch mit gepufferten Zugriffen auf die HD zu realisieren.
Das allerdings ist definitiv falsch.
Dazu werden für jede Transaktion der Start, die Before Images, Änderungen und der Commit gespeichert.
Wo steht denn, dass diese Änderungen unbedingt und in jedem Fall auch gleich im Tablespace landen müssen?
Ganz einfach. Folgendes Szenario: Die Änderung landet im Tablespace, die Before Image stehen aber noch im Plattenpuffer. Dann Stromausfall. Im Tablespace ist die TA nicht committed --> inkonsistente Datenbank. Im TA-Log steht aber nicht das Before Image --> Rollback nicht möglich.
Das kann doch die DB-Engine verwalten.
Nein, kann sie nicht. Weil sie nicht wissen kann, wann die Daten, die sie in eine gepufferte Datei schreibt, auch auf dem Datenträger landen. Das ist aber die wichtigste Voraussetzung für funktionierendes TA-Logging. Ich empfehle dir dazu mal einen Blick auf comp.os.databases.* bzw. die Archive davon, dort wird das immer wieder mit genau diesem Ergebnis diskutiert (und genau so wird es auch bei Informix Dynamic Server begründet). Deshalb empfiehlt Informix auch SE auf keinen Fall für Mission Critical Anwendungen. Und genau deshalb haben externe Cache Controller auch batteriegepufferten Cache.
Schlimmstenfalls werden die geänderten Sätze erst beim nächsten Neustart oder sync in die Tabellen geschrieben.
Wie denn, wenn der Rechner weg war? Sie stehen in keinen Tabellen, der sync konnte nicht ausgeführt werden. Die DB könnte natürlcih nach jedem Eintrag ins TA-Log einen sync ausführen, aber das würde die ganze Angelegenheit bis zur Unendlichkeit bremsen und den Plattenpuffer obsolet machen.
Wenn Du mit Deinen Ausführungen das Thema Datensicherheit / Recovery meinst - da stimme ich Dir zu. Das geht nur mit vollständiger Kontrolle des DBMS über die Festplattenzugriffe (was ist da eigentlich mit den Controller-Caches?). Ungepuffert läuft da allerdings auch nichts.
Nope, ich meine konkret die Konsistenzsicherung. Die wird durch einen transparenten Plattencache definitiv ausgehebelt. Kannst Du jeden fähigen DB-Prof fragen (wenn er denn fähig ist, auch da hab ich schon so einiges gesehen, wo mir schlecht wurde, daß man solche Leute auf Studenten losläßt). -- =========================================================== Erhard Schwenk - alias Bitrunner =)B==o) =========================================================== No Spam replies please. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 26-Oct-00 Erhard Schwenk wrote:
comp.os.databases.*
Quatsch, meinte natürlich comp.misc.databases.*, wie ich auf os komm weiß ich jetzt auch nicht. -- =========================================================== Erhard Schwenk - alias Bitrunner =)B==o) =========================================================== No Spam replies please. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi, zuerst noch mal die eindringliche Bitte (unten hattest Du sie anscheinend übersehen): Lass das CC: weg. Diese Doppelmails nerven! On Don, Okt 26, 2000 at 09:40:07 +0200, Erhard Schwenk wrote:
On 25-Oct-00 Jan Trippler wrote:
[...]
Und das ist ohne weiteres auch mit gepufferten Zugriffen auf die HD zu realisieren.
Das allerdings ist definitiv falsch.
Siehe unten.
Dazu werden für jede Transaktion der Start, die Before Images, Änderungen und der Commit gespeichert.
Wo steht denn, dass diese Änderungen unbedingt und in jedem Fall auch gleich im Tablespace landen müssen?
Ganz einfach. Folgendes Szenario:
Die Änderung landet im Tablespace, die Before Image stehen aber noch im Plattenpuffer. Dann Stromausfall. Im Tablespace ist die TA nicht committed --> inkonsistente Datenbank. Im TA-Log steht aber nicht das Before Image --> Rollback nicht möglich.
Nochmal: Meine Frage war gerade, wo geschrieben steht, dass jede Änderung gleich im Tablespace landet - Du schreibst, _wenn_ sie da landet, dann gibt es Ärger - hmm. Das genau war _nicht_ meine Frage. Ich will doch gerade, dass Änderungen _nicht_ im Tablespace landen - zumindest nicht gleich den ursprünglichen Datensatz überschreiben. Also von mir auch ein Scenario (das ist Theorie, wie schon gesagt - ich weiss nicht, wie z. B. Informix das nun tatsächlich macht): Der zu ändernde Datensatz wird als *dirty* markiert -> der geänderte Datensatz wird _neu_ in den Tablespace (oder ins TA-Log) geschrieben mit der Verkettung *ich bin jetzt aktuell* -> das Before Image wird in das TA-Log geschrieben -> die Änderungen werden in das TA-Log geschrieben -> der Abschluss der Transaktion wird in das TA-Log geschrieben. Alle Schreibvorgänge laufen üblicherweise mit einem Timestamp ab. Jetzt kannst Du an jeder Stelle des Vorgangs den Stecker ziehen - Du kriegst immer den Zustand vor dem Beginn der Transaktion wieder hin. Du kannst auch die Reihenfolge der Writes von Log und Datensatz austauschen - es gibt für jede denkbare Kombination einen konsistenten Zustand. Selbst wenn das Dirty-Flag erst nach dem Schreiben des neuen Datensatzes auf der Platte landet (was ziemlich unwahrscheinlich ist), dann kann man das über die Existenz eines jüngeren Datensatzes abfangen. Mir fällt zumindest kein Fall ein, wo es nicht funktioniert. Und der *Dirty Page*-Mechanismus ist ein allgemein genutzter (z. B. in Caches, oder?)
Das kann doch die DB-Engine verwalten.
Nein, kann sie nicht. Weil sie nicht wissen kann, wann die Daten, die sie in eine gepufferte Datei schreibt, auch auf dem Datenträger landen.
Doch, kann sie. Siehe oben.
Das ist aber die wichtigste Voraussetzung für funktionierendes TA-Logging. Ich empfehle dir dazu mal einen Blick auf comp.os.databases.* bzw. die Archive davon, dort wird das immer wieder mit genau diesem Ergebnis diskutiert (und genau so wird es auch bei Informix Dynamic Server begründet).
Für den ODS stimme ich Dir ja auch zu - seine Architektur setzt nun mal auf Raw-Devices auf. Das ist hier auch nicht das Thema, ich setze keine DBMS in einem Live-System unter Bedingungen ein, für die sie nicht gemacht sind.
Deshalb empfiehlt Informix auch SE auf keinen Fall für Mission Critical Anwendungen. Und genau deshalb haben externe Cache Controller auch batteriegepufferten Cache.
Über den Grund, SE nicht für diese Anwendungen einzusetzen kann man jetzt wirklich streiten. Nach meiner Erinnerung werden vor allem 2 Gründe genannt: - Performance. - Datensicherheit. Der ODS verfügt über einen fast recovery Mechanismus, und man kann anhand eines Backups und der Logical Logs nach einem Plattencrash der Zustand bis zum letzten auf Backup-Device gesicherten Log (bzw. der letzten darauf als abgeschlossen gekennzeichneten Transaktion) wiederherstellen. Das kann SE natürlich nicht - dort ist man auf das letzte Backup angewiesen.
Schlimmstenfalls werden die geänderten Sätze erst beim nächsten Neustart oder sync in die Tabellen geschrieben.
Wie denn, wenn der Rechner weg war? Sie stehen in keinen Tabellen, der sync konnte nicht ausgeführt werden. Die DB könnte natürlcih nach jedem Eintrag ins TA-Log einen sync ausführen, aber das würde die ganze Angelegenheit bis zur Unendlichkeit bremsen und den Plattenpuffer obsolet machen.
Auch hier wieder: Du bist exakt um 180 Grad an meiner Fragestellung vorbeigeschossen - ich meinte nicht das Schreiben von RAM nach HD, sondern das Aktualisieren des Satzes einer Tabelle durch seinen aktuellen Vertreter (siehe mein Scenario oben), also das Zurücksetzen des Dirty-Flags durch Überschreiben mit dem aktuellen Satz. Um auch noch einmal die ursprüngliche Fragestellung zu rekapitulieren: Deine Behauptung, dass eine Transaktionskontrolle bei DBMS, die auf Betriebssystem-Funktionalitäten (also Buffer) zurückgreifen, sinnlos ist, ist schlicht und einfach falsch: 1. Wie ich gezeigt habe, ist mit etwas Aufwand auch bei gepuffertem I/O die Konsistenz der Daten zu gewährleisten. 2. Transaktionssicherung bedeutet _auch_, aber bei Weitem nicht vorrangig den Schutz vor Systemausfällen. Viel häufiger sind folgende Fälle anzutreffen: - anwendungsbedingte Fehler, die ein Rollback verlangen (Absturz eines W*-Clients während einer Transaktion, Abbruch einer Verbindung zum Host bei Zahlungen im Internet ...) - den gewollten Rollback, weil Bedingungen zum Abschluss einer Transaktion nicht erfüllt sind (Konto-Abbuchung bei fehlender Deckung, matschige Daten, ...) - Timeouts durch Deadlocks - ...? Wie gesagt, diese Fälle treten wesentlich häufiger als Systemausfälle auf und rechtfertigen schon weitgehend die Existenz von Transaktionen in *gepufferten* DBMS. Ein Systemausfall ist Thema der Datensicherheit. TA-Logs können diese unterstützen, aber das ist nicht ihr Haupt-Existenzgrund. Wie ich auch schon geschrieben hatte: Ich widerspreche nicht dem Fakt, dass DBMS besser auf den Komfort des OS verzichten sollten und eigene IO mitbringen sollten. Nur sind meine Begründungen dafür andere. Jan P.S.: Falls Du es oben überlesen hast ;-) - lass die CC:'s weg - ich brauche Deine Mails nicht doppelt. P.P.S.: Wenn kein Widerspruch aus der Liste kommt, sollten wir das Thema vielleicht auf PM verlagern - mit Linux und SuSE hat das eigentlich nix mehr zu tun, auch wenn es interessant ist. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Moin, On Don, 26 Okt 2000, Jan Trippler sent incredible lines: [...]
P.P.S.: Wenn kein Widerspruch aus der Liste kommt, sollten wir das Thema vielleicht auf PM verlagern - mit Linux und SuSE hat das eigentlich nix mehr zu tun, auch wenn es interessant ist.
Dann setzt mich aber in's CC, ich muss mich hier bei G&J demnächst mit Oracle beschäftigen (so ab Montag) da ist sowas recht interessant. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Moin, On Mon, 23 Okt 2000, Bernd Brodesser sent incredible lines:
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects: Dann kann man Mysql vergessen. Tut mir leid, aber eine anständige DB ohne subselects? Meine Frage nach einem Rollback bei einem Subselect erübrigt sich dann ja wohl.
Gehört nicht zum Konzept von MySQL, dort war die Vorgabe möglichst wenig, aber dafür sehr schnell. Zukünftige Versionen sollen diese Möglichkeiten aber bieten mit der Option diese zu disablen damit man nur die Features einbindet die man auch wirklich braucht. Schau mal ins mSQL&MySQL Buch aus dem O'Reilly Verlag, dort wirds näher beschrieben. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Salute
* Martin Stahn schrieb am 23.Okt.2000:
Mysql kann (noch) keine Subselects:
Dann kann man Mysql vergessen. Tut mir leid, aber eine anständige DB ohne subselects? Meine Frage nach einem Rollback bei einem Subselect erübrigt sich dann ja wohl.
Bern
Ich bin da etwas vorbelastet, aber was spricht eigentlich gegen Informix ? Ich arbeite im Baustoffhandel, und unsere Warenwirtschaft läuft unter Informix. Subselects, Rollback, Log Sicherung usw. ... alles kein Problem. Wegen kosten und Linux ... no Prob. Linux ist sowieso kein Thema. Und wer Informix Dynamic Server 7.30 (Workgroup Edition) inkl. der SE haben will (Vollversion !!!) ... für den habe ich einen Tip: Zeitschrift freeX - Ausgabe 2Ž99 Ich hatte die Zeitschrift, aber die CD ist mir irgendwie verloren gegangen. Habe mich an den Verlag per Mail gewendet, und die haben mir zurückgeschrieben dass die Zeitschrift vergriffen ist, mir aber die CD zugeschickt wird. Der Knüller ... die kam wirklich ... "Priortaire" aus "Fronkraisch". Haa, an dem Punkt ... hat jemand vielleicht eine Anleitung parat (auf Deutsch ??? *lächel*) wie man die Datenbank aufsetzt ? In der Firma erstelle ich Queries, Reports usw., stöbere in den 4gl herum, aber mehr als Datenbank rauf, runter habe ich mit tbmonitor nicht gemacht. Abgesehen davon dass die neue Version (tbmonitor -> onmonitor) sich etwas verändert haben dürfte. CU Mike --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo!
Ich bin da etwas vorbelastet, aber was spricht eigentlich gegen Informix ?
Wegen kosten und Linux ... no Prob. Linux ist sowieso kein Thema. Und wer Informix Dynamic Server 7.30 (Workgroup Edition) inkl. der SE haben will (Vollversion !!!) ... für den habe ich einen Tip:
Zeitschrift freeX - Ausgabe 2Ž99
War es nicht 1`99?
Haa, an dem Punkt ... hat jemand vielleicht eine Anleitung parat (auf Deutsch ??? *lächel*) wie man die Datenbank aufsetzt ?
Englische Dokumentation findest Du jedenfalls auf: http://www.informix.de/answers/ cu Marc Mc Guinness --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Marc Mc Guinness schrieb:
War es nicht 1`99?
Hast mich jetzt verunsichert. Auf der CD steht 2`99.
Englische Dokumentation findest Du jedenfalls auf: http://www.informix.de/answers/
Danke, aber die kenne ich schon. Ich darf/muss so ehrlich sein ... der faule Hund in mir musste raus. Englisch kann ich, bei den technischen Sachen wirds dann halt kritisch. Und - *gg* - auf deutsch ists halt einfacher zu lesen und aufzunehmen. Aber es wird auch so funzen MfG Mike --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Don, Okt 26, 2000 at 06:14:53 +0200, Klein Michael wrote: [...]
Wegen kosten und Linux ... no Prob. Linux ist sowieso kein Thema. Und wer Informix Dynamic Server 7.30 (Workgroup Edition) inkl. der SE haben will (Vollversion !!!) ... für den habe ich einen Tip: [...]
Siehe anderer Thread: der Dynamic Server ist _eine_ der Informix Engines, SE (Standard Engine) ist eine andere. IDS *inkl. der SE* gibt es nicht, da SE kein Bestandteil von IDS ist. Bist Du sicher, was Vollversion angeht? Ich kenne bisher nur SE als Freeware, Dynamic Server war bisher immer eine zeitlich begrenzte Testversion. Ich lasse mich aber gerne berichtigen. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (10)
-
Andreas.Kyek＠d2mannesmann.de -
B.Brodesser＠online-club.de -
cschult＠gmx.de -
eschwenk＠fto.de -
Jan.Trippler＠t-online.de -
m.klein＠chello.at -
martin.stahn＠sskm.de -
mc_guinness＠gmx.de -
ml＠bendler-net.de -
steffen＠dett.de