存档
1、ASE的dsync和directio属性都是针对文件系统上的设备文件的，不适用于裸分区/原始分区。
2、dsync和directio是互斥的，也就是： dsync on对应 directio off , directio on对应dsync off。dsync和directio不能同时启用，但是可以同时关闭。
如果已将设备的dsync属性配置为on，那么不能再将directio设置为on；如果想设置directio为on，那么必须先将dsync设置为off。
3、dsync on/off表示ASE是否保证把数据写入到设备上面去；directio on/off表示ASE是否跳过操作系统的文件系统缓存。
- dsync on和directio off表示ASE的写操作直接在存储介质上进行，能够保证数据完全写入到设备上以及数据库的可恢复性；
- dsync off和directio on表示ASE的写操作跳过操作系统缓冲区高速缓存，直接将数据传输到磁盘，不能保证数据真正写入到设备上；
- dsync off和directio off表示使用文件系统的缓存。
4、在SUSE上测试ASE 15.7使用文件系统设备文件时默认是directio on（dsync off），已经跳过文件系统缓存了。
sybase官方文档上关于设备的dsync,directio这两个属性也是语焉不详，可能不同版本不同平台的ASE这两个属性有不同的默认值。
下面是一位Sybase大牛的论述，很清晰明朗。
The use of dsync/directio (typically) means the dataserver has to wait for a write to complete on the physical disk
before the dataserver considers the write to be 'successful' (aka guaranteed write). While this *wait* will extend the
time it takes to complete the associated database action, the guaranteed write to disk is required to insure
recoverability (in the case of a dataserver/machine/disk subsystem failure).
If dsync/directio are disabled then a dataserver write may finish more quickly due to the disk subsystem *caching* the
write IO. This means the associated dataserver action completes more quickly but there's no guarantee the IO made it to
the physical disk. If the dataserver/machine/disk subsystem fails between the successful disk cache write and the
physical disk write, you could end up losing data (ie, the dataserver thinks the data is on disk while the disk has no
record of the data existing).
For important databases (eg, master, RSSDs, user databases), especially in production environments, the recoverability
of the data usually takes precedence over speed. In these scenarios the dataserver must wait for physical disk writes
to complete 'successfully', with the caveat that the associated database action takes longer to complete.
For trivial/development databases where recoverability is not a concern, or for databases that are rebuilt from scratch
at dataserver startup (eg, temporary databases), guaranteed disk writes are not as important. In these scenarios a
successful write to disk cache is sufficient, with the added benefit that the associated database action completes more
quickly.
So, generally speaking:
dsync/directio enabled : guaranteed disk writes, guaranteed recoverability, associated database actions take more time
to complete
dsync/directio disabled : no guarantee of writes to physical disks, no guarantee of recoverability, associated database
actions take less time to complete
------------------
Now-a-days there are lots of ways to configure disk subsystems ... raw disks, cached disks, cached file systems,
journaled file systems, multiple layers of logical disk management, sans (w/ and w/out cache), etc, etc, etc ...
Some of these configurations may support dsync/directio operations by the dataserver while actually performing the write
to cache, ie, the physical disk write takes place at a later time. For some systems this may be ok if the disk
subsystem vendor can guarantee that those cache writes will always make their way to disk.
The issue here is that regardless of which attribute settings (dsync/directio) are used for dataserver devices, it's the
DBA's responsibility to insure the disk subsystem can really guarantee disk writes for those database actions that
require guaranteed recoverability.
总结一下：文件系统将directio属性关闭。文件系统上临时数据库或者不太“重要”的数据库的设备可以将dsync调整成false，其余数据库为了保证恢复将dsync设置成true。