| 1 |
Qian Qiao schrieb: |
| 2 |
> On 10/30/05, Alexander Skwar <listen@×××××××××××××××.name> wrote: |
| 3 |
|
| 4 |
>> Well, but how does it work in a DBMS? Does a transaction |
| 5 |
>> log there save you from a 'DELETE FROM table; COMMIT;'? |
| 6 |
>> I mean, I suppose you could see - thanks to the transaction |
| 7 |
>> log - that a 'DELETE FROM table;' was done, who did it |
| 8 |
>> and when it was done. |
| 9 |
>> |
| 10 |
> |
| 11 |
> It does, technically. |
| 12 |
|
| 13 |
Does it? How? So the log contains what rows are in the |
| 14 |
table? How large is the log? If I have a look at the |
| 15 |
archived redo logs of some Oracle DBs, I see that they |
| 16 |
tend to be gigantic - if you also count what's been |
| 17 |
written away and archived on backup tapes. |
| 18 |
|
| 19 |
But those logs are a bit different than FS journals. |
| 20 |
The DBMS logs contain everything that's been done. |
| 21 |
Every row that's added (INSERT) or every change (UPDATE). |
| 22 |
|
| 23 |
|
| 24 |
> The way DBMS maintains table consistancy opon |
| 25 |
> failure is to re-play transactions logged. |
| 26 |
|
| 27 |
Yes. This would mean, that the system would notice |
| 28 |
that "DELETE FROM table;" has not yet been (successfully/completely) |
| 29 |
run, wouldn't it? |
| 30 |
|
| 31 |
> These logs are not the logs |
| 32 |
> that appear in /var/log, they are maintained internally by the DBMS. |
| 33 |
|
| 34 |
Sure. |
| 35 |
|
| 36 |
Alexander Skwar |
| 37 |
-- |
| 38 |
gentoo-user@g.o mailing list |
Archives