4 ms·

> In what case would it be that disastrous to reboot a database server? To assure data integrity, an interactive database system has to log off all its users a

by lutusp 12y ago

> In what case would it be that disastrous to reboot a database server? To assure data integrity, an interactive database system has to log off all its users and shut down open databases before rebooting. If the reboot can't be orchestrated that way, if users can't be logged off in an orderly way, there will be data loss.

jmalicki 12y ago
If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. That's the entire point of transactions...
- lutusp 12y ago
  > If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. Yes -- all except the ongoing transactions at the users' workstations. That by itself could represent a serious synchronization problem. For a serious business, an emergency power system might represent a better choice.
  - dllthomas 12y ago
    If you've not pulled the plug on your users' workstations, the clients should be perfectly capable of retrying the broken transactions when the database comes back up. There can, of course, be constraints that make this impossible, but sloppy coding making it impossible is more common.
- newman314 12y ago
  If your DB is ACID AND your underlying storage has not lied to you about committing the write...
  - CaptainZapp 12y ago
    This is the basic reason why raw devices where the way to go for decades for use as database devices and are still in use in most installations. I'm talking about Sybase here. But any database, which shifts the commit responsible to the operating system (without explicit guarantees that committed data is indeed written to disk) may invite you in for a huge and very unpleasant surprise.
    - newman314 12y ago
      Counting on raw devices when you have a SAN underneath presenting LUNs to the server means unless you are very careful, it does not mean that said write necessarily made it all the way onto disk.

by lutusp 12y ago

jmalicki 12y ago

If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. That's the entire point of transactions...

lutusp 12y ago
> If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. Yes -- all except the ongoing transactions at the users' workstations. That by itself could represent a serious synchronization problem. For a serious business, an emergency power system might represent a better choice.
- dllthomas 12y ago
  If you've not pulled the plug on your users' workstations, the clients should be perfectly capable of retrying the broken transactions when the database comes back up. There can, of course, be constraints that make this impossible, but sloppy coding making it impossible is more common.
newman314 12y ago
If your DB is ACID AND your underlying storage has not lied to you about committing the write...
- CaptainZapp 12y ago
  This is the basic reason why raw devices where the way to go for decades for use as database devices and are still in use in most installations. I'm talking about Sybase here. But any database, which shifts the commit responsible to the operating system (without explicit guarantees that committed data is indeed written to disk) may invite you in for a huge and very unpleasant surprise.
  - newman314 12y ago
    Counting on raw devices when you have a SAN underneath presenting LUNs to the server means unless you are very careful, it does not mean that said write necessarily made it all the way onto disk.