Can SQL Server's crash resilience be improved?

I am aware that SQL Server is not designed for such scenarios and the correct solution is to fix the cause of the power loss […]

Actually it's designed to deal with power loss, that's why there are things like write ahead logging (WAL) and crash recovery upon startup (or whatever you want to call it). One of the ways this is done is by choosing to not cache writes which it seems is what the tablet is doing, hence the corruption.

Nevertheless, are there any tuning options in SQL Server that I can set to reduce the risk of database corruption on power loss?

No, SQL Server is doing what it should. You should look either outside SQL Server (windows settings for drive caching [which SQL wants to be off but we can't force you], hardware/firmware updates, etc.) or as Eric has said, buy an external power supply for relatively cheap which could solve the symptoms (the actual issue is probably some type of caching or battery backed write that isn't actually backed).


If the tablet has a working battery, you can configure Windows to shut down when the battery power is low.

If the tablet has a non-working battery, consider replacing the battery. (I've had laptops like that - you'd be surprised how inexpensive replacement batteries can be on eBay. They don't work as well as OEM, but hey, anything's better than nothing in this situation.)

If the tablet does not have battery capabilities at all, consider adding a small uninterruptible power supply (UPS) with USB outputs that can communicate with Windows to tell it when it's running on battery power. (For example, I have my own desktop configured to shut down when the UPS is low on battery power - that way it'll shut down on power outage even if I'm not at home.)

If none of those are an option, you're kinda out of luck. It's an old white paper, but the SQL Server 2000 I/O Basics from Microsoft basically explains that you need an I/O subsystem that can handle power outages gracefully.

There are options you can use to increase risk - like Delayed Durability or memory-only (non-durable) tables - but by default, SQL Server is already doing its best to maximize reliability with every write to the transaction log. If even transaction log writes can't be guaranteed due to random power outages, spend the $100 on a UPS battery.


Assuming you have a local DB on the forklift rather than a server because of spotty wireless connections? Obviously getting SQL off the forklift would be the preferable solution.

Anyway, like Brent suggested, set the tablet to power down on its own after x minutes on battery power or some similar criteria.

Failing that, a small UPS that can initiate a normal shutdown is probably going to be your best bet in that case. Relying on users for things like that is asking to fail.