SAS Scalable Performance Data Server 4.5, Administrator'S Manual

Page: 141 / 271

permanent table space should be accessible to the specific group (such as analysts) of
regular SPD Server users.
The SPD Server administrator can use the libnames.parm file to configure paths that map
to an area of reserved disk space on a host computer, creating a safe place for permanent
tables with limited user access. To reserve permanent table space, the LIBNAME domain
statement in the
libnames.parm file should use the optional DATAPATH=,
INDEXPATH=, and OWNER= statements to specify unique, appropriately sized disk areas
for data tables and index tables. The OWNER= statement configures ownership and access.
It is up to the SPD Server administrator to ensure that the paths named in domain
declarations have access to sufficient disk space.
User access to permanent table spaces can be established via individual user account access
privileges, or by establishing, through the owner of the domain, an ACL group of approved
users. LIBNAME domain statements will create permanent table space by default.
Semi-Permanent Table Space
Organizations often have short-term data mining projects that rely on production,
inventory, or sales data, but modify the way the data is processed, or augment the
production, inventory, or sales data in some manner with additional information. Those
projects should be conducted in a test data space, safely isolated from the permanent space
that is dedicated to critical production, inventory, or sales data. This design allows
development trials to be conducted without risk of corrupting mission-critical data.
For example, the test data space used for a month-long development project could be
considered a semi-permanent space; it requires the SPD Server administrator to grant access
to an area where data can safely exist, isolated from production, sales, or inventory data,
for a specific period of time longer than a single SPD Server user session. The "test"
environment should persist long enough for works-in-progress to mature to production-
quality (if so destined), but after the project is completed, the data, metadata, and work
tables that are associated with the development phase should be cleaned up and deleted
from the test environment.
Semi-permanent table space can be configured by an SPD Server administrator or by SPD
Server users. It is recommended that administrators allocate semi-permanent spaces using
the
libnames.parm file.
Temporary Table Space
Managers in an organization often ask analysts to query data warehouses for various types
of information. Such ad hoc information requests might be as important as standard
production, inventory, or sales reports, but ad hoc reporting has different data space needs.
Ad-hoc reports tends to have a lower frequency of repetition and broader query scope than
standard daily production, inventory, or sales reporting. Ad-hoc reports are usually best
suited to temporary table space. The life spans of temporary table spaces begin and end
with the user's SPD Server sessions.
Temporary table space is used for more than ad hoc user reporting. Even data warehouse
queries and reports that use permanent table space use intermediate tables and calculation
metadata to process queries. For example, the SPD Server SQL optimization process
requires significant temporary table space while it heuristically finds the most efficient
SQL strategy to resolve the query. Intermediate SPD Server tables and calculation metadata
are normally deleted when the job terminates.
Any of the report types listed previously can require temporary table space for intermediate
calculation tables. Temporary table space can be configured by normal SPD Server users
via LIBNAME domain statements submitted during an SPD Server session. The key to
Temporary Table Space
135