There are several considerations when using network-based storage or storage abstracted by virtualization that are not issues when databases are stored on local disks. A data durability problem occurs when remote storage or the virtualization environment experiences service interruptions, ranging from connectivity loss to total failure from power loss. Data corruption can occur when the storage layer accepts data for writing that is not made durable before a crash occurs. In these cases, a database property can be set that reduces the likelihood of data loss and data corruption. The database property database-on-virtualized-or-network-storage can be set on a per-backend environment basis to request all database writes to be written durably to the underlying storage.

There is a performance penalty when enabling this property, and in most cases, is not recommended except where network storage is unreliable. For network file systems, the benefits of faster recovery and less likelihood of data loss from unplanned events may outweigh the penalty. The exact overhead of enabling database-on-virtualized-or-network-storage depends on the characteristics of the database, the host file system, storage array configuration, and network and virtualization input and output parameters. The write overhead penalty might be substantial for SAN environments. Incremental and full backup strategies should be used instead if performance is unacceptable.

To enable database-on-virtualized-or-network-storage for each applicable backend, use the following command as an example, which references the configuration for the userRoot backend:
$ bin/dsconfig set-global-configuration-prop \
  --set database-on-virtualized-or-network-storage:true
This should be set to false if the database is on a local disk.