A relational database such as a LLDB must reside on physical media somewhere in your network under the control of the database server, which is the process or processes belonging to the DBMS (Oracle or Sybase). In order to create a LLDB, the administrator must arrange for space to be allocated by the database server for the storage of the LeasePak database's tables, indexes, views, stored procedures and triggers. This space is often made up of a conglomeration of different storage areas, which are generically referred to in LeasePak as Storage Segments." The DBMSes have different approaches to the physical storage process.
When db_create is run, a list of one or more storage segments is displayed to the administrator. The administrator selects one or more of these segments, indicating the size of space allocation needed, and certain other housekeeping data. The information collected during this part of db_create is stored in the file $uetc/physdb.msirc.
Sybase has "disk devices" each with a certain capacity; the administrator provisions a LLDB by selecting certain devices and indicating how much of their capacity is required. The system administrator must pre-configure these devices using Sybase utilities; there are no LeasePak utilities for this purpose. Each allocation made on a disk device configured for LeasePak use is also considered to be a "storage segment". In the context of the system at large, the disk devices are storage segments; in the context of a single LLDB, a fractional part of a disk device is also a storage segment.
Sybase requires that an LLDB have two separate parts, one for the transaction logs, and the other for data and indexes. Accordingly, the administrator must select at least two storage segments to construct a LLDB; multiple storage segments may be selected to make up the required capacity. A Sybase disk device must be dedicated to either log or data. Multiple LLDBs can allocate different portions of a single device, but they all must use that device either for log only or for data only. Data and log should never be allocated on the same device or indeed on the same physical medium (disk).
Expansion of the space allotted to an LLDB is accomplished using Sybase utilities to add additional space from available storage segments. Additional storage segments can be allocated to the LLDB, using Sybase utilities. It is recommended that, when making new allocations to a LLDB, to modify $uetc/physdb.msirc so that in case of a database rebuild, db_create can simply provision the LLDB based on phydb.msirc.
It is highly recommended, but not enforced, that the administrator adopt a naming convention for the Sybase devices: lpk_log## and lpk_data##, for example, producing log device names such as lpk_log01, lpk_log02, etc, and data device names such as lpk_data01, lpk_data02, etc. This will help determine which storage segments to use during db_create.
When db_create is run, the administrator will be presented with a list of one or more storage segments (devices) with available capacity. The device name and the current available capacity is displayed. The display of Sybase system devices is avoided if possible; in the event that it is not possible, having a naming convention similar to the one described above will provide invaluable assistance in avoiding configuring an LLDB on a system device. LLDBs should never be configured to use any portion of a Sybase system device.
The administrator will be prompted to enter a storage segment name, and then to indicate how much of that segment's capacity is required in megabytes.
The administrator will be prompted to indicate whether the selected storage segment is to be used for log or for data. Again, log allocations and data allocations must never be made on the same storage segment or physical media.
When creating a LLDB to hold the Level7 dataset, the administrator should allocate 150MB for data and 50MB for log, minimum.
Oracle has datafiles on top of which are built tablespaces. A tablespace may occupy multiple datafiles. The system administrator must pre-configure these datafiles and tablespaces using Oracle utilities; there are no LeasePak utilities for this purpose. Each tablespace created for use by LeasePak is considered to be a "storage segment". Each allocation made on a tablespace configured for LeasePak use is also considered to be a "storage segment". A single tablespace can support multiple LLDBs. In the context of the system at large, the tablespaces are storage segments; in the context of a single LLDB, a fractional part of a tablespace is also a storage segment.
As a matter of convention, LeasePak distinguishes between common and dedicated tablespaces. Common tablespaces can support multiple LLDBs; each dedicated tablespace is used exclusively by a particular LLDB.
For small LLDBs requiring less than 300MB of space, the administrator may use a Common tablespace; in any case, a dedicated tablespace may be created using Oracle utilities. The size of a tablespace can be increased by adding one or more datafiles to the tablespace. There is a LeasePak utility, db_add_datafile, that will create a new datafile and add it to the tablespace. For LLDBs greater than 300MB in size, dedicated tablespaces must be used.
During db_create, when selecting the tablespace, the administrator is asked to indicate how much of the tablespace to allocate to the LLDB. If creating a small (< 300MB) LLDB, then the administrator should indicate the quota or size in megabytes. If creating a larger LLDB, the administrator should indicate the dedicated tablespace (which must be pre-existing), and for the size enter UNLIMITED.
Expansion of a tablespace is accomplished by using db_add_datafile. Expansion of the quota on a tablespace allotted to a LLDB is accomplished by using Oracle commands. It is recommended that, when making new allocations, to modify $uetc/physdb.msirc so that in case of a database rebuild, db_create can simply provision the LLDB based on phydb.msirc.
If the administrator adopted the Strict Naming Convention when LeasePak was installed, then the tablespace names used by LeasePak must conform to that convention, as only conforming tablespaces are displayed during db_create under strict naming. The strict name for common tablespaces must begin with LPC. A dedicated tablespace will be used by only one LLDB. Strict naming for LLDBs requires that the LLDB name begins with LPT; the corresponding strictly named tablespace replaces the LPR prefix with LPT. Thus, under strict naming, the administrator will see displayed any common tablespaces and if it exists, the single dedicated tablespace for the LLDB being created.
Examples of strict naming in Oracle:
Object | Strict Name |
Logical LeasePak DB | LPRPROD |
Dedicated tablespace | LPTPROD |
Default common tablespace | LPCOMMON |
Support tablespace (a second common tablespace) |
LPCSUPPORT |
Under loose naming, all of the common and dedicated tablespaces created for LeasePak are displayed. Additionally, tablespaces which weren't created for LeasePak, such as system tablespaces and tablespaces for other software packages, may also be displayed. LeasePak data should be stored only on tablespaces created for LeasePak by the administrator.
The administrator should always provide for a common tablespace so that small test LLDBs can be created for diagnostic purposes. The minimum tablespace for a NetSol test LLDB using the Level7 dataset is 150MB in v76a. The default common tablespace should be named LPCOMMON. The SETUP program for installing LeasePak asks the administrator for the name of this default common tablespace.
When
The administrator will be prompted to enter a storage segment name, and then to indicate how much of that segment's capacity is required. In common storage segments, the capacity should be in megabytes; in dedicated storage segments, the administrator should enter "UNLIMITED" to utilize the entire storage segment.
Oracle does not require any separate allocations for transaction logging.