> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> About the limit of 1140 for write-mode opens:
> I assume that this limit is per TurboImage data base, not per
> system, and that is what I have told our management here. Can
> someone confirm this, please.
You are correct.
Technically the limit is 1140 processes per User Logging id. Image
Logging uses the User Logging subsystem. Each data base has a separate
User Logging identifier. So the limit is "per database". There is a separate
limit on how many User Logging processes per system, 128.
Bottom line, no more than 128 Data Bases can be open concurrently
with logging enabled (per system). No more than 1140 different processes
can have the same database open (for write, with logging enabled)
concurrently.
> What about a scenario where a transaction (DBBEGIN....DBintrinsics
> ....DBEND) spans more than a single data base?
I am not an Image expert, but I don't believe the DBBEGIN ... DBEND
stuff matters with respect to this limit. I believe if you have more
than one data base, and you have logging enabled for each database, you
need separate logging IDs for each database. The 1140 limit is per
logging ID. A process is associated with a logging ID when it does the
DBOPEN (provided is specifies a "mode" that indicates "write access", and
provided Image Logging is enabled for that data base).
> Ken Sletten wrote that HP finds that only a couple of customers
> are hitting the 1140 limit and they seem to have found work-arounds.
> Where does a company write if it is hitting the limit and cannot find
> a work-around?
You write to me. I am basically the one that decides the relative
priority of various limits/capacity enhancments.
This enhancement is on the list, but is NOT near the top. Why? Because
I know of *exactly* two customers that haver reach the limit, and ZERO
additional customers that are close. Both of the two customers I know
of which have reached already own Sharplex. With Shareplex you can
shadow the DB, turn logging off on the master, and turn logging on
on the shadow. This reduces the number of processes per logging id
to 1, regardless of how many users are concurrently accessing the
master DB.
If you, or anyone else, can make a strong(er) case for increasing
the priority of this enhancment, I am listening.
The most important information to include is a description how and why
you use Image Logging. Do you use it for recovery? Have you every
actually had to recover using the log files?
NOTE: most customers answer (when I ask) that they use Image Logging for
recover, but that they have NEVER recovered their DB with it. When I
press they tell that they don't use the log files to recovery lost
transactions in between backups, or anything like that. Basically they
are using Image Logging just as a "security blanket" in case something
goes wrong. Basicaly the kinds of file corruption that used to cause
customer to use Image Logging to recover data bases (say after a System
Abort) on MPE/V do not happen on MPE/iX (because of Transaction Management).
To convince me you need Image Logging, you need to point to some other
need besides "disaster recovery". I am willing to change my opinion, but
I need data.
Does your application read the Image Log files directly? This is not
that unheard of, and makes a stronger case for Image Logging because it
means that applications are dependent on the log files to function.
How many concurrent users you have (peak), that need to concurrently
access a given DB (with WRITE access)?
What is your expected growth?
NOTE: It is my expereience that 90% of the people that ask me about this
limit
have a 100-200 users, and they are not growing or growing slowly. This
does not instill a sense of urgency in me.
What kind of system do you have?
Is this limit keeping you buying an upgrade or causing you to think about
moving your application elsewhere?
What potential workarounds have you considered and ruled out?
This is your change people....give me some data!
|
