Kbase 11111: 6.3 Release Notes - Sequent PTX
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
6.3 Release Notes - Sequent PTX
ADDITIONAL NOTES FOR THIS RELEASE
PLATFORM: Sequent ptx
MEDIA TYPE: Cartridge Tape
SOFTWARE RELEASE: 6.3B5P
EXTRACT COMMAND: cpio -iuvcdBm < /dev/rmt/ts0
INSTALL COMMAND: ./proinstall
MACHINE NOTES:
OPERATING SYSTEM NOTES:
UNIX Shared Memory
PROGRESS uses shared memory to allow multiple server processes and
self-service client processes concurrent access to a database
and to coordinate their activities. The shared memory area contains
the buffer pool, lock table, log buffers, and other shared data
structures.
When the database is started (via the proserve command), the broker
creates and initializes the shared memory area of the required
size. The size is based on the values of various startup parameters
which determine the sizes of the data structures.
In UNIX systems, shared memory consists of one or more "segments."
Each segment is identified by a system-wide unique number which
is assigned by the process that creates the segment. PROGRESS
derives the identifier from the inode of the .db file.
There are several UNIX kernel parameters that limit the number and
size of shared memory segments. In addition, PROGRESS has an internal
limit on the size of a single shared memory segment. If the shared
memory size computed by the broker is larger than the maximum
segment size allowed, the broker will create multiple segments to
reach the required total.
The following UNIX kernel parameters control the size and number
of shared memory segments:
SHMMNI - The maximum number of shared memory identifiers allowed
for the system.
SHMALL - The maximum number of in-use shared memory segments
allowed for the system.
Some systems do not have this parameter (e.g., Sun OS).
SHMMAX - The maximum size of a single shared memory segment.
Some systems call this parameter SHMSIZE (e.g., Sun OS).
SHMSEG - The maximum number of shared memory segments a single
process can attach.
Some systems do not have this parameter (e.g., Sun OS).
The total amount of shared memory that can be allocated is
SHMMAX * SHMALL (or SHMMAX * SHMMNI).
When you install PROGRESS, you may have to increase the values
of these parameters. Note that if you are running other software
that also uses shared memory, you must take into account the
combined requirements.
Consult the manuals for your system to find out how to change
these parameters.
Recommended settings:
SHMMNI: Depends on the number of active databases, the values
of startup parameters, and the value of SHMMAX. The larger
SHMMAX is, the fewer segments PROGRESS will create.
64 is probably a good value to start with.
If you set this value too low, you may get PROGRESS error
1137 or 1138.
SHMALL: Same as SHMMNI.
If you set this value too low, you may get PROGRESS error
1137 or 1138.
SHMSEG: Depends on the number of active databases, the values
of startup parameters, and the value of SHMMAX. The larger
SHMMAX is, the fewer segments PROGRESS will create.
When self-service clients connect to multiple databases,
the shared memory segments for the database are attached.
16 is probably a good value to start with.
If you set this value too low, you may get PROGRESS error
1175, 1719, or 1720.
SHMMAX: Sequent: 134217728 bytes
Others: 16777216 bytes
This parameter limits the size of a single segment. PROGRESS
will create one smaller segment if less shared memory is
needed.
Smaller values will work, as long as they are higher than
8192, but are not recommended. If you set this to less
than 8192, you will get PROGRESS error 1135.
If you set this value too low, PROGRESS will create many
small segments, possibly overflowing the limits SHMMNI,
SHMSEG, or SHMALL.
The units that you use to specify a value for SHMMAX vary
from system to system. Some units use bytes, others use
"clicks" (page size). Consult your system manuals for the
proper units.
Note that the amount of kernel memory required for shared memory
descriptions (not the shared memory itself), is relatively small,
so setting SHMSEG, SHMMNI, SHMALL higher than your current needs
probably won't affect performance.
Shared memory is not used for single-user sessions.
Clients that connect to a remote database on a server machine
do not use shared memory on the client machine.
You can use the "Activity" option in promon to find out the total
amount of shared memory allocated and the number of segments
that were created for the database.
The table below gives some typical shared memory sizes (in bytes)
for a few different parameter settings on machines with 1 and 2 kb
database blocks:
Sun 4 (has 1 kb database block size)
proserve demo 204800 (200 kb)
proserve demo -n 10 -B 100 217088 (212 kb)
proserve demo -n 20 -B 100 258048 (252 kb)
proserve demo -n 10 -B 500 663552 (648 kb)
proserve demo -n 20 -B 500 704512 (688 kb)
proserve demo -n 20 -B 5000 5734400 (5600 kb)
Sequent (has 2 kb database block size)
proserve demo 569344 (556 kb)
proserve demo -n 10 -B 100 360448 (352 kb)
proserve demo -n 20 -B 100 421888 (412 kb)
proserve demo -n 10 -B 500 1220608 (1192 kb)
proserve demo -n 20 -B 500 1282048 (1252 kb)
proserve demo -n 20 -B 5000 10973184 (10716 kb)
UNIX Semaphores
PROGRESS uses UNIX Semaphores to synchronize the activities of
server processes and self-service client processes that are
connected to a database. The semaphores are created and initialized
by the broker when the database is started.
UNIX semaphores are grouped into "semaphore sets." Each semaphore
set has a unique identifying number called a semid. Within a
semaphore set, individual semaphores are identified by an integer
ranging from 0 to one less than the size of the semaphore set.
The PROGRESS broker creates a semaphore set when the database is
started. The size of the set is the number of users (-n parameter)
plus the number of servers (-Mn parameter) plus 4.
The following UNIX kernel parameters control the number and size
of the semaphore sets:
SENMNI - The maximum number of semaphore identifiers allowed for
the system.
SEMMSL - The maximum number of semaphores allowed per semaphore
identifier (semaphore set).
SEMMNS - Total number of semaphores allowed for the system.
SEMMNU - Maximum number of semaphore undo structures allowed for
the system.
When you install PROGRESS, you may have to increase the values
of these parameters. Note that if you are running other software
that also uses semaphores, you must take into account the
combined requirements.
Consult the manuals for your system to find out how to change
these parameters.
Recommended settings:
SEMMNI: One per active database.
If you set this value too low, you may get PROGRESS error
1131.
SEMMSL: Max number of users on any database +
Max number of servers for any database + 4
If you set this value too low, you may get PROGRESS error
1093 or 1130.
SEMMNS: SEMMSL * number of active databases.
If you set this value too low, you may get PROGRESS error
1093, 1131, or 1195.
SEMMNU: Set equal to one per PROGRESS process connecting to a database.
(ie: each server process, self-service client, page writer,
bi writer, ai writer, watchdog, proshut, promon).
If you set this value too low, you may get PROGRESS error
1081.
Note that the amount of kernel memory required for semaphores
is relatively small, so setting the limits higher than your
current needs probably won't affect performance.
Semaphores are not used for single user sessions.
Clients that connect to a remote database on a server machine
do not use semaphores on the client machine.
TERMINAL NOTES:
SOFTWARE NOTES:
* TWO-PHASE COMMIT AND AFTER-IMAGING
The following sections describe issues involving two-phase commit
and after-imaging.
After-Image file on a Non-Coordinator Database
If a non-coordinator database has limbo transactions and you delete or
lose the after-image file, you cannot disable after-imaging until you
have deactivated two-phase commit. To deactivate two-phase commit, use
the 2phase end option of the proutil command. Once you disable two-phase
commit,you can disable after-imaging. They can use the 2phase recover
option of the proutil command to recover any limbo transactions. When
finished, you can truncate the before-image file and backup the database.
After-Image and Transaction Log Files on the Coordinator Database
If you have two-phase commit and after-imaging enabled, and if you lose
the coordinator database's after-image file, you cannot recover any
limbo transactions. Also, if after-imaging is not enabled, and you lose
the database's Transaction Log (.tl) file, you cannot recover any limbo
transactions.
Backing up a Two-Phase Commit Database
The PROGRESS Backup utility (PROBKUP) does not backup the .tl file. When
you backup your database, you should deactivate two-phase commit first,
then backup the database with PROBKUP. Before you re-enable two-phase
commit, use the 2phase new option of the proutil command to truncate
the .tl file.
* MULTI-VOLUME - PROSTRCT ADD UTILITY
The command PROSTRCT ADD, which adds multi-volume extents to an
existing database, does not work correctly in all cases. To
add extents to your database, you should create a new multi-volume
structure using the PROSTRCT CREATE utlity, and then either
use procopy to copy the old database into the new one, or
use probkup to backup the old database, and use prorest to
restore the old database into the new structure.
* X-WINDOWS
The startup parameters -bg -fg -bw have no effect on the colors
or size of a window.
* SERVER/SELF-SERVICE CLIENT VERSION INCOMPATIBILITY
You cannot start a Version 6.2K (or previous) self-service client against a
Version 6.2L or 6.3 server. Likewise, you cannot start a Version 6.2L or 6.3
self-service client against a Version 6.2K (or previous) server. In both
cases, the server and self-service client have incompatible version numbers.
If you attempt to start a self-service client against a server with an
incompatible version number, you should get a message indicating that they
are incompatible. However, if you are running PROGRESS on the following
machines:
D Sequent (Dynix and PTX)
D RS6000
D Data General (V.4)
D Pyramid
you get a misleading message; this message incorrectly states that no server
is running for the database you are trying to start the self-service client
against. The reason for this message appearing is that the shared memory IDs
of the self-service client and server do not match. Ordinarily, the self-
service client accesses shared memory and checks the version number of the
server for compatibility. On these machines, the self-service client cannot
access shared memory to check the version number. Therefore, when you see a
message that indicates there is no server running for the database, do not
assume that the database is shutdown. Check to make sure that no server is
running before performing such actions as moving the database or deleting
any database files.
* ON TAB STATEMENT
Specifying an "ON TAB GO" statement in a procedure may cause
PROGRESS to exit abnormally and give a core dump.
* NETWORKING
If you have multiple clients connected to two or more servers via TCP/IP,
and the system runs out of network resources, error message 1160 may appear
repeatedly in the .lg file. This may fill the disk containing the .lg file.
* PROLIB
If you add or delete to PROLIB, the library will continue to grow. In order
to reduce the size of the library, you must do a COMPRESS when you add to or
delete from the library. To effectively use PROLIB, changes to the library
should be made when development is complete. At this time, all changes can
be made to the library at once, allowing better management of the library
size.
* PROSHUT MESSAGE
If you start a database server with 1 userid and try to shut it down with a
different userid, you (correctly) get an error message in the .lg file that
the shutdown request was invalid. However, you also get an erroneous error
message: SRV 1: Usernum 1 terminated abnormally (794).
* DUMP/EXPORT
When trying to DUMP or EXPORT large character fields greater than 3000
characters you will see the message: More than 3000 characters of dump
data (96) and the session will be terminated.
* PROMON
Once a server is started, if you enter "PROMON dbname", then "PROSHUT
-by dbname", PROMON will not be disconnected and the process will still exist.
ADDITIONAL ITEMS
* The PROGRESS Watchdog
Version 6.3 and later includes a new background process intended for use in
multi-user, shared-memory installations. This background process is called
the Watchdog. The Watchdog wakes up every five seconds and examines the user
table in shared memory to determine if processes are still connected. If
Watchdog finds a dead process, it will attempt to roll back any active
transactions abandoned by the dead process and will release record or
resource locks held. Appropriate messages will be recorded in the database
log file (.lg file) when a dead process is discovered.
To start Watchdog, enter: prowdog <database name>
Watchdog will then record a message in the log file indicating that it has
been started, and will continue to run until the database is shut down or
disconnected with proshut.
ADDITIONAL NOTES FOR SYBASE RELEASE
* SYBASE REMOTE GATEWAY AUTO-CONNECT
If you attempt to connect through the data dictionary to a
remote Sybase database with a remote gateway configuration
the session fails with the following messages:
FAILED TO CONNECT TO DATABASE DEMO (2078)
FAILED TO CONNECT TO SYBASE/SQL-SERVER DATABASE (2081)
The session would fail if the Sybase connection information
was defined under SYBASE UTILITIES, EDIT SYBASE CONNECTION
INFORMATION similar to the information below:
LOGICAL DB: SYBASE
DB TYPE : SYBASE
CONNECTION PARAMETERS: -H hostname -S service name
-N network type -U user id -P password
PHYSICAL DATABASE NAME: DEMO
The workaround would be to CONNECT through the data dictionary
and change the PHYSICAL DATABASE NAME to DEMO. The remaining
defaults in the auto-connect file defined under SYBASE UTILITIES
are accepted and the session connects successfully.
Progress Software Technical Support Note # 11111