SAS Scalable Performance Data Server 4.5, Administrator'S Manual

Page: 137 / 271

Dynamic locking is not a replacement for using record-level locking in cases where the
user requires SAS-style record-level integrity across multiple clients. Reading a record
using dynamic locking does not guarantee that the record cannot change before a
subsequent read or update is executed. If a true record-level lock is needed by a client, then
the record-level locking protocol should be used.
It is not possible to use record-level locking on a domain that has dynamic locking enabled.
Dynamic locking is also not supported for tables that use dynamic clusters.
Usage
To enable dynamic locking, use the DYNLOCK= statement in the libnames.parm file
domain declarations. If the DYNLOCK= option is not specified, the default SPD Server
setting for DYNLOCK is NO.
DYNLOCK=<YES/NO>
Organizing Domains for Scalability
Overview of Organizing Domains
SPD Server performance is based on scalable I/O. You can use the libnames.parm file to
optimize the way SPD Server stores files in order to exploit scalable I/O. The “Domain
Access Options” on page 127 section in this document provides instructions on how to
specify named paths for the three data components of SPD Server tables (observation data
tables, index data tables, metadata tables) as well as paths for temporary intermediate
calculation tables. LIBNAME domain declaration statements can specify the system paths
that are associated with each table space component, but the SPD Server administrator must
allocate the correct amount of disk space and I/O redundancy to the various paths.
This section provides functional information about the table spaces that are defined by the
DATAPATH=, INDEXPATH=, WORKPATH=, and METAPATH= options of the
LIBNAME domain declaration statements. SPD Server administrators should use this
information to determine the best sizing, I/O, and redundancy requirements to optimize
performance and scalability for named SPD Server domain paths.
Data Table Space
When a domain is declared in a LIBNAME statement, data tables are stored in the space
defined in the PATHNAME= specification, unless the DATAPATH= option is specified.
The PATHNAME= space is designed to contain metadata tables for a domain, but it can
also contain data tables. As a domain's size and complexity increases, so do the benefits
for organizing data tables into their own DATAPATH= space.
Organizing your data table space significantly impacts I/O scalability. The disk space
allocated to data tables stores permanent warehouse tables that users will access. It is
important for this disk space to support scalable I/O because it facilitates both parallel
processing and real-time multi-user access to the data. In a large warehouse, this disk space
is likely to see the greatest proportion of read/write I/O.
Tables in the data table space are typically loaded or refreshed using batch processes during
evenings or off-peak hours (such as weekends and holidays). Access to data table space is
often restricted to read-only for all users except for the administrators who perform the
load and refresh processes.
Data Table Space
131