When you enable set delayed_commit, SAP ASE notifies the client application before the actual physical disk write completes.
Because of this, the application perceives that the transaction is complete whether or not the physical disk write is successful. In the event of a system failure (disk errors, system crash, and so on), transactions that were not written to disk (transactions whose commit records were on the last log page) are not present after recovery in spite of the application being notified they were committed.
Systems that require tight system interdependencies, such as through a messaging system using Real Time Data Services (RTDS), further complicate the consequences of using set delayed_commit.
The application maintains its own trace or log, and, after a system failure, ensures that the database state corresponds to its own trace or log.
You can restore the database to the state it was in before the application was run. This assumes you took a complete database backup before a batch-job type application is run. In case of failure, the database backup is loaded and the batch job is restarted.