ACID PROPERTY

                   In database technology, atomicity, consistency, isolation, and durability (ACID) refers to the set of requirements that are assessed for reliability:

vA transaction has to be atomic; that is, if part of a transaction fails, the entire transaction has to fail and therefore leave the database state unchanged.

vThe consistency of a database must be preserved, meaning that only valid data will be written to the database. If, for some reason, a transaction is executed that violates the database's consistency rules, the entire transaction will be rolled back, and the database will be restored to a state consistent with those rules. On the other hand, if a transaction successfully executes, it will take the database from one state that is consistent with the rules to another state that is also consistent with the rules.

vA transaction must be isolated so that no one transaction interferes with another transaction.

vFinally, a transaction has to be durable; that is, after a transaction has been committed to the database, it will remain there..

        Although the first three requirements are not affected by in-memory technologies, the durability requirement cannot be met by storing data in main memory alone. Main memory is volatile storage, which means it loses its content if it loses power. To make data persistent, it has to reside on nonvolatile storage, such as hard drives. (Stay with us now—this is going to be a bit technical for a couple of minutes.)

        The medium used by a database to store data (in this case, main memory) is divided into pages. When a transaction changes data, the corresponding pages arc marked and written to nonvolatile storage (a hard drive not at risk of power failures) in regular intervals. In addition, a database log captures all changes made by transactions. Each committed transaction generates a log entry that is written to nonvolatile storage. This ensures that all transactions are permanent.

        In-memory databases can save changed pages in savepoints (Figure 1.1), which are asynchronously written to persistent storage in regular intervals (for SAP HANA, every five minutes by default). This log is written synchronously. In other words, a transaction does not return before the corresponding log entry has been written to persistent storage —in order to meet the durability requirement that was described earlier—thus ensuring that in-memory databases meet (and pass) the ACID test.

v After a power failure, the database can be restarted, and the database pages are restored from the savepoints. The database logs are applied to restore the changes that were not captured in the savepoints. This ensures that the database can be restored in memory to exactly the same state as before the power failure.

v In other words, ifyou forget to pay your electric bill and the power gets shut off to your in-memory database hardware, you don't have to panic. Instead, you should take comfort that you will have key operational requirements satisfied with your SAP HANA implementation: disaster recovery, the ability of the system to restore itself after a catastrophic event such as a power outage or system corruption that required a shutdown.

v If you are considering a pilot program for your SAP HANA solution (or a proof of concept), this is a key area that you will want to validate and that will help you gain the confidence of your operational team.

v In fact, disaster recovery is the single biggest proof point that customers will want to confirm before fully embracing and transitioning over to SAP HANA. Organizations want to stand over their SAP HANA-powered test boxes (because they are not about to try this in a productive system) and literally pull the plug on the power to the box.

v They want to let it sit there for a few minutes and see what happens to determine what fail-over systems will kick in, how long the system will be down, and what the operational impact will be overall.

v Disaster recovery becomes absolutely vital when you consider SAP HANA for your transaction systems, such as SAP Business Suite on SAP HANA. The single biggest validation point being discussed by customers who are considering adoption of the Suite on SAP HANA is confirming the capability for disaster recovery. If you have SAP Business Warehouse (BW) on SAP HANA, for instance, and that system goes down, you can reload it and your report will be a bit late —not the end of the world. However, if your sales order processing on SAP HANA goes down, and you can't book, bill, or ship orders, you have a much bigger problem.