Kbase 12682: Release Notes for NCR 486 6.3B
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Release Notes for NCR 486 6.3B
ADDITIONAL NOTES FOR THIS RELEASE
PLATFORM: unix486v4
MEDIA TYPE: Cartridge Tape
SOFTWARE RELEASE: 6.3B1P
EXTRACT COMMAND: cpio -iuvcdBm < /dev/rmt/c0s0
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:
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.
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 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.
* 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.
Progress Software Technical Support Note # 12682