存档
Adaptive Server version 15.0.2 uses row-level locking on system tables to enhance performance.
Versions of Adaptive Server earlier than 15.0.2 used exclusive table locks on system tables while executing data definition language (DDL) and utility commands. The set of system tables Adaptive Server locked depended on the type of DDL operation you executed. If another DDL running concurrently tried to take a conflicting exclusive table lock on the same system table, this DDL had to wait to acquire the lock on any system catalogs. These DDL operations were executed serially.
This methodology impeded performance in temporary databases, where their DDL activity is very high also, and consequently their catalog contention is very high. This limited the Adaptive Server throughput for applications using temporary tables.
Adaptive Server version 15.0.2 uses row-level locking to resolve these issues:
*
System-table contention, caused a bottleneck for many DDLs and utilities.
*
tempdb contention. Because the system tables are locked at the row level, Adaptive Server 15.0.2 eliminates tempdb contention.
*
Shared or exclusive table-level locks while executing DDLs and utilities. Earlier versions converted most system tables to data-only locking (DOL), but still created shared or exclusive table-level locks while executing DDLs and utilities. Using row-level locks for system tables eliminates this contention.
Adaptive Server sets intent locks on catalogs only, which removes potential contention (An intent lock indicates that page-level or row-level locks are currently held on a table.).
*
DDLs and utilities blocking each other. Adaptive Server 15.0.2 allows DDLs and utilities to run in parallel.
Earlier versions of Adaptive Server used table locks to achieve system catalog synchronization. Adaptive Server 15.0.2 uses intent locks for table-level synchronization and row locks for row-level synchronization. Earlier releases of Adaptive Server locked the entire system catalog while performing operations on the object, so a single lock request was made. However, Adaptive Server version 15.0.2 requests locks for all applicable rows while performing operations on the object if there are multiple rows corresponding to an object in a system catalog.
This change means that Adaptive Server 15.0.2 requests more locks to perform the same operation than earlier releases, and increases the number of lock resources the system needs. Consequently, you may need to change the number of locks configuration option after you upgrade Adaptive Server.
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。