info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Einsatzgebiete von Transaktionen
12 views
Skip to first unread message
Wolfgang May
Apr 21, 2016, 4:32:31 PM4/21/16
to
Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> Man sollte ja bestimmte Experimente mit einer Datenbank nicht
> im laufenden Betrieb machen, sondern besser auf einer extra
> Kopie für Testzwecke.
>
> Neulich vertrat jemand die Meinung, man könnte doch solche
> Experimente als Transaktionen machen, da man sie ja dann am
> Schluß mit ROLLBACK wieder rückgängig machen könne.
Rollback betrifft ueblicherweise ausschliesslich DML-Kommandos.
Das ist sicher nicht das, was man als "Experimente mit einer
Datenbank" versteht.
> Intuitiv überzeugt mich das nicht, aber mir fällt nicht
> sofort ein gutes Gegenargument ein.
DDL-Kommandos machen ueblicherweise ein automatisches Commit.
Selbst wenn man also als einfachster User irgendwas an den
Daten am rumpopeln ist, und zwischendurch feststellt,
dass man eine kleine Zusatztabelle oder ein View braeuchte,
oder auch nur stoerende Constraints disablen will, macht's ehe
man sich versieht ein Autocommit.
> Ich nehme aber an, daß
> Änderungen an der Struktur der Datenbank oder Systemvariablen
> nicht vom ROLLBACK rückgängig gemacht werden.
Sowieso nicht.
Fuer fast alles, was man als Admin machen kann, gibts kein Rollback.
> Abgesehen von
> dem Risiko, daß man versehentlich COMMIT eingegen könnte,
> gibt es sonst noch Argumente, die dagegen sprechen?
Eigentlich jegliche Grundkenntnisse ueber Transaktionen.
Wolfgang
> Man sollte ja bestimmte Experimente mit einer Datenbank nicht
> im laufenden Betrieb machen, sondern besser auf einer extra
> Kopie für Testzwecke.
>
> Neulich vertrat jemand die Meinung, man könnte doch solche
> Experimente als Transaktionen machen, da man sie ja dann am
> Schluß mit ROLLBACK wieder rückgängig machen könne.
Rollback betrifft ueblicherweise ausschliesslich DML-Kommandos.
Das ist sicher nicht das, was man als "Experimente mit einer
Datenbank" versteht.
> Intuitiv überzeugt mich das nicht, aber mir fällt nicht
> sofort ein gutes Gegenargument ein.
DDL-Kommandos machen ueblicherweise ein automatisches Commit.
Selbst wenn man also als einfachster User irgendwas an den
Daten am rumpopeln ist, und zwischendurch feststellt,
dass man eine kleine Zusatztabelle oder ein View braeuchte,
oder auch nur stoerende Constraints disablen will, macht's ehe
man sich versieht ein Autocommit.
> Ich nehme aber an, daß
> Änderungen an der Struktur der Datenbank oder Systemvariablen
> nicht vom ROLLBACK rückgängig gemacht werden.
Sowieso nicht.
Fuer fast alles, was man als Admin machen kann, gibts kein Rollback.
> Abgesehen von
> dem Risiko, daß man versehentlich COMMIT eingegen könnte,
> gibt es sonst noch Argumente, die dagegen sprechen?
Eigentlich jegliche Grundkenntnisse ueber Transaktionen.
Wolfgang
Harald Fuchs
Apr 22, 2016, 4:00:25 AM4/22/16
to
m...@informatik.uni-goettingen.de (Wolfgang May) writes:
> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> Man sollte ja bestimmte Experimente mit einer Datenbank nicht
>> im laufenden Betrieb machen, sondern besser auf einer extra
>> Kopie für Testzwecke.
>>
>> Neulich vertrat jemand die Meinung, man könnte doch solche
>> Experimente als Transaktionen machen, da man sie ja dann am
>> Schluß mit ROLLBACK wieder rückgängig machen könne.
>
> Rollback betrifft ueblicherweise ausschliesslich DML-Kommandos.
> Das ist sicher nicht das, was man als "Experimente mit einer
> Datenbank" versteht.
Es gibt auch Datenbanken, die diesbezüglich nicht zwischen DML und DDL
> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> Man sollte ja bestimmte Experimente mit einer Datenbank nicht
>> im laufenden Betrieb machen, sondern besser auf einer extra
>> Kopie für Testzwecke.
>>
>> Neulich vertrat jemand die Meinung, man könnte doch solche
>> Experimente als Transaktionen machen, da man sie ja dann am
>> Schluß mit ROLLBACK wieder rückgängig machen könne.
>
> Rollback betrifft ueblicherweise ausschliesslich DML-Kommandos.
> Das ist sicher nicht das, was man als "Experimente mit einer
> Datenbank" versteht.
unterscheiden, z.B. PostgreSQL.
Peter J. Holzer
Apr 24, 2016, 4:54:46 AM4/24/16
to
implizite Commit von Oracle und MySQL hingegen ziemlich sicher nicht.
Das hilft aber natürlich dem Oracle-User nicht: Wenn er Oracle
verwendet, muss er mit den Bugs/Features dieses Systems leben.
Aber auch in PostgreSQL ist kann man nicht uneingeschränkt Experimente
in einer Transaktion machen.
Zum einen gibt es sehr wohl die Gefahr, dass man den Rest des Systems
stört (ein »drop table« z.B. braucht einen exklusiven Lock und blockiert
damit alle anderen Zugriffe auf diese Tabelle bis zum Ende der
Transaktion).
Zum anderen - und das ist für mich häufig der wichtigere Grund - möchte
man die Ergebnisse seiner Experimente auch sehen; und zwar nicht in der
SQL-Session, sondern in einer Applikation, die auf die Datenbank
zugreift. Die hat aber natürlich auf den temporären Zustand einer
nicht-abgeschlossenen Transaktion einer anderen Session keinen Zugriff.
Somit komme ich für Experimente nicht um eine Test-Datenbank herum.
Wofür sich Transaktionen hingegen gut eignen, sind manuelle, komplexere
Updates, also insert/update/delete-Statements mit komplexen Bedingungen
(oft mit (sub)selects oder CTEs), wo ich mir beim Tippen nicht so 100%
sicher bin, dass ich das fehlerfrei hinkriege. Da kann ich mir das
Ergebnis noch ansehen und anschließend ein commit oder rollback machen.
(auch hier sollte man beachten, dass MVCC seine Grenzen hat und eine
Transaktion eine andere blockieren kann, wenn es Konflikte gibt.)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Stefan Froehlich
Apr 24, 2016, 12:54:29 PM4/24/16
to
On Sun, 24 Apr 2016 10:54:46 Peter J. Holzer wrote:
> Aber auch in PostgreSQL ist kann man nicht uneingeschränkt
> Experimente in einer Transaktion machen.
> Zum einen gibt es sehr wohl die Gefahr, dass man den Rest des
> Systems stört (ein »drop table« z.B. braucht einen exklusiven Lock
> und blockiert damit alle anderen Zugriffe auf diese Tabelle bis
> zum Ende der Transaktion).
> Zum anderen - und das ist für mich häufig der wichtigere Grund -
> möchte man die Ergebnisse seiner Experimente auch sehen; [...]
> Aber auch in PostgreSQL ist kann man nicht uneingeschränkt
> Experimente in einer Transaktion machen.
> Zum einen gibt es sehr wohl die Gefahr, dass man den Rest des
> Systems stört (ein »drop table« z.B. braucht einen exklusiven Lock
> und blockiert damit alle anderen Zugriffe auf diese Tabelle bis
> zum Ende der Transaktion).
> Zum anderen - und das ist für mich häufig der wichtigere Grund -
Und zum dritten meint PostgreSQL irgendwann, wenn man beliebig DML-
und DDL-Kommandos mischt, "ich kann nicht mehr" und bricht mit einer
Fehlermeldung ab (vermutlich nicht irgendwann, sondern anhand
wohldefinierter Gesetzmäßigkeiten, aber so weit habe ich mich in die
Materie nicht vertieft). Das ist zwar deutlich besser als ein
implizites Commit, sorgt aber letztendlich auch nur dafür, dass man
derartiges in der Praxis eben nicht tut.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
2016! Das Jahr von Stefan. Sauerer geht's nicht mehr.
(Sloganizer)
Peter J. Holzer
Apr 24, 2016, 2:42:51 PM4/24/16
to
On 2016-04-24 16:54, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Sun, 24 Apr 2016 10:54:46 Peter J. Holzer wrote:
>> Aber auch in PostgreSQL ist kann man nicht uneingeschränkt
>> Experimente in einer Transaktion machen.
>
>> Zum einen gibt es sehr wohl die Gefahr, dass man den Rest des
>> Systems stört (ein »drop table« z.B. braucht einen exklusiven Lock
>> und blockiert damit alle anderen Zugriffe auf diese Tabelle bis
>> zum Ende der Transaktion).
>
>> Zum anderen - und das ist für mich häufig der wichtigere Grund -
>> möchte man die Ergebnisse seiner Experimente auch sehen; [...]
>
> Und zum dritten meint PostgreSQL irgendwann, wenn man beliebig DML-
> und DDL-Kommandos mischt, "ich kann nicht mehr" und bricht mit einer
> Fehlermeldung ab (vermutlich nicht irgendwann, sondern anhand
> wohldefinierter Gesetzmäßigkeiten, aber so weit habe ich mich in die
> Materie nicht vertieft). Das ist zwar deutlich besser als ein
> implizites Commit, sorgt aber letztendlich auch nur dafür, dass man
> derartiges in der Praxis eben nicht tut.
Ja, ich kann mich erinnern, dass Du das Problem hattest. Ist mir noch
> On Sun, 24 Apr 2016 10:54:46 Peter J. Holzer wrote:
>> Aber auch in PostgreSQL ist kann man nicht uneingeschränkt
>> Experimente in einer Transaktion machen.
>
>> Zum einen gibt es sehr wohl die Gefahr, dass man den Rest des
>> Systems stört (ein »drop table« z.B. braucht einen exklusiven Lock
>> und blockiert damit alle anderen Zugriffe auf diese Tabelle bis
>> zum Ende der Transaktion).
>
>> Zum anderen - und das ist für mich häufig der wichtigere Grund -
>> möchte man die Ergebnisse seiner Experimente auch sehen; [...]
>
> Und zum dritten meint PostgreSQL irgendwann, wenn man beliebig DML-
> und DDL-Kommandos mischt, "ich kann nicht mehr" und bricht mit einer
> Fehlermeldung ab (vermutlich nicht irgendwann, sondern anhand
> wohldefinierter Gesetzmäßigkeiten, aber so weit habe ich mich in die
> Materie nicht vertieft). Das ist zwar deutlich besser als ein
> implizites Commit, sorgt aber letztendlich auch nur dafür, dass man
> derartiges in der Praxis eben nicht tut.
nicht untergekommen, aber mehr als ein Dutzend drop/create table und 100
Millionen eingefügte/geänderte Zeilen in einer Transaktion hatte ich noch nie.
Wenn es da Limits gibt, bin ich offenbar noch nicht angestoßen.
(Das MVCC-Konzept von Postgres ist jedenfalls auch deutlich besser an
meine Bedürfnisse angepasst als das von Oracle - da bin ich dauernd an
die Limits von irgendwelchen Undo- oder Redo-Segmenten gestoßen und
musste meine Transaktionen in kleine Häppchen aufteilen)
Florian Weimer
Apr 24, 2016, 2:57:24 PM4/24/16
to
* Peter J. Holzer:
> Ja, ich kann mich erinnern, dass Du das Problem hattest. Ist mir
> noch nicht untergekommen, aber mehr als ein Dutzend drop/create
> table und 100 Millionen eingefügte/geänderte Zeilen in einer
> Transaktion hatte ich noch nie. Wenn es da Limits gibt, bin ich
> offenbar noch nicht angestoßen.
PostgreSQL branch zumindest früher die Transaktion nach rund 2**31
Befehlen in einer Transaktion ab.
> Ja, ich kann mich erinnern, dass Du das Problem hattest. Ist mir
> noch nicht untergekommen, aber mehr als ein Dutzend drop/create
> table und 100 Millionen eingefügte/geänderte Zeilen in einer
> Transaktion hatte ich noch nie. Wenn es da Limits gibt, bin ich
> offenbar noch nicht angestoßen.
Befehlen in einer Transaktion ab.
Stefan Froehlich
Apr 24, 2016, 4:39:02 PM4/24/16
to
On Sun, 24 Apr 2016 20:42:50 Peter J. Holzer wrote:
> > Und zum dritten meint PostgreSQL irgendwann, wenn man beliebig DML- und
> > DDL-Kommandos mischt, "ich kann nicht mehr" und bricht mit einer
> > Fehlermeldung ab (vermutlich nicht irgendwann, sondern anhand
> > wohldefinierter Gesetzmäßigkeiten, aber so weit habe ich mich in die
> > Materie nicht vertieft). [...]
> > Und zum dritten meint PostgreSQL irgendwann, wenn man beliebig DML- und
> > DDL-Kommandos mischt, "ich kann nicht mehr" und bricht mit einer
> > Fehlermeldung ab (vermutlich nicht irgendwann, sondern anhand
> > wohldefinierter Gesetzmäßigkeiten, aber so weit habe ich mich in die
> Ja, ich kann mich erinnern, dass Du das Problem hattest. Ist mir noch
> nicht untergekommen, aber mehr als ein Dutzend drop/create table und 100
> Millionen eingefügte/geänderte Zeilen in einer Transaktion hatte ich noch
> nie. Wenn es da Limits gibt, bin ich offenbar noch nicht angestoßen.
Tabellen von ganz klein bis ganz groß gereicht haben: die *Änderungen*
haben haben meist aus ADD/DROP COLUMN und auf UPDATE bestanden, ergänzt
um ein paar Modifikationen bei Indizes. Wirklich nichts großartiges, aber
offenbar einfach mit Pech.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Peter Schneider
Apr 26, 2016, 9:06:26 AM4/26/16
to
Am 24.04.2016 um 10:54 schrieb Peter J. Holzer:
> On 2016-04-22 08:00, Harald Fuchs <hari....@gmail.com> wrote:
>> m...@informatik.uni-goettingen.de (Wolfgang May) writes:
>>
>>> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>>>> Man sollte ja bestimmte Experimente mit einer Datenbank nicht
>>>> im laufenden Betrieb machen, sondern besser auf einer extra
>>>> Kopie für Testzwecke.
>>>>
>>>> Neulich vertrat jemand die Meinung, man könnte doch solche
>>>> Experimente als Transaktionen machen, da man sie ja dann am
>>>> Schluß mit ROLLBACK wieder rückgängig machen könne.
>>>
>>> Rollback betrifft ueblicherweise ausschliesslich DML-Kommandos.
>>> Das ist sicher nicht das, was man als "Experimente mit einer
>>> Datenbank" versteht.
>>
>> Es gibt auch Datenbanken, die diesbezüglich nicht zwischen DML und DDL
>> unterscheiden, z.B. PostgreSQL.
>
> Ja. Wobei das Verhalten von PostgreSQL standardkonform ist, das
> implizite Commit von Oracle und MySQL hingegen ziemlich sicher nicht.
> Das hilft aber natürlich dem Oracle-User nicht: Wenn er Oracle
> verwendet, muss er mit den Bugs/Features dieses Systems leben.
Oracle hat keine Bugs, sondern nur wunderbare Features. ;-)
> On 2016-04-22 08:00, Harald Fuchs <hari....@gmail.com> wrote:
>> m...@informatik.uni-goettingen.de (Wolfgang May) writes:
>>
>>> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>>>> Man sollte ja bestimmte Experimente mit einer Datenbank nicht
>>>> im laufenden Betrieb machen, sondern besser auf einer extra
>>>> Kopie für Testzwecke.
>>>>
>>>> Neulich vertrat jemand die Meinung, man könnte doch solche
>>>> Experimente als Transaktionen machen, da man sie ja dann am
>>>> Schluß mit ROLLBACK wieder rückgängig machen könne.
>>>
>>> Rollback betrifft ueblicherweise ausschliesslich DML-Kommandos.
>>> Das ist sicher nicht das, was man als "Experimente mit einer
>>> Datenbank" versteht.
>>
>> Es gibt auch Datenbanken, die diesbezüglich nicht zwischen DML und DDL
>> unterscheiden, z.B. PostgreSQL.
>
> Ja. Wobei das Verhalten von PostgreSQL standardkonform ist, das
> implizite Commit von Oracle und MySQL hingegen ziemlich sicher nicht.
> Das hilft aber natürlich dem Oracle-User nicht: Wenn er Oracle
> verwendet, muss er mit den Bugs/Features dieses Systems leben.
> Aber auch in PostgreSQL ist kann man nicht uneingeschränkt Experimente
> in einer Transaktion machen.
>
> Zum einen gibt es sehr wohl die Gefahr, dass man den Rest des Systems
> stört (ein »drop table« z.B. braucht einen exklusiven Lock und blockiert
> damit alle anderen Zugriffe auf diese Tabelle bis zum Ende der
> Transaktion).
Exclusive Locks auf die angefaßten Daten.
> Zum anderen - und das ist für mich häufig der wichtigere Grund - möchte
> man die Ergebnisse seiner Experimente auch sehen; und zwar nicht in der
> SQL-Session, sondern in einer Applikation, die auf die Datenbank
> zugreift. Die hat aber natürlich auf den temporären Zustand einer
> nicht-abgeschlossenen Transaktion einer anderen Session keinen Zugriff.
>
> Somit komme ich für Experimente nicht um eine Test-Datenbank herum.
nimmt man eine Dev-DB.
> Wofür sich Transaktionen hingegen gut eignen, sind manuelle, komplexere
> Updates, also insert/update/delete-Statements mit komplexen Bedingungen
> (oft mit (sub)selects oder CTEs), wo ich mir beim Tippen nicht so 100%
> sicher bin, dass ich das fehlerfrei hinkriege. Da kann ich mir das
> Ergebnis noch ansehen und anschließend ein commit oder rollback machen.
> (auch hier sollte man beachten, dass MVCC seine Grenzen hat und eine
> Transaktion eine andere blockieren kann, wenn es Konflikte gibt.)
echten, "legitimen" Production Transaction ein Deadlock bastelt.
Auf Production-DBs spielt man nicht.
Gruß
Peter
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
0 new messages