I'd go with P-something keys. Back in the mid-eighties we had a problem with
I-something, and switching from binary to packed-decimal fixed it.
FWIW, our old problem was in a data set that had two or three 'ranges'.
Something like 100,000 to 200,000 for pick-tickets for one division, and
400,000 to 600,000 for another division. Since we didn't keep pick-tickets
for long, we had a small capacity, and a picture of where the entries were
located would have looked a lot like an (analog) clock, or an old radar
screen, with bands rotating at different rates. When the two ranges started
to overlap, dbput slowed to a crawl. Changing capacity so they wouldn't
overlap was just a quick fix while we did the programmng to change key type.
There's some sort of moral there about how vile integer keys can be if you
aren't careful.
----- Original Message -----
From: "Ray Shahan" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, January 02, 2007 08:39
Subject: Re: [HP3000-L] Full synonym chain (really ugly)
Hmm, thanks Deny. I get it that I4 and R4 aren't really good choices
for keys, but I don't see (from the manual) just what is happening (note
that I did state I suck at math/algorithms). It may suffice to just
know that an R4 is a bad key choice (but I'd still like to know why).
My co-worker also saw from the manual that we just need to make the
capacity of the auto larger than the value that caused the synonym chain
to fill up, so we're setting about finding the largest current value in
the set of key values because the key value is a dollar amount, and that
may mean the set cap could be required to be a huge number...we'll look
at this and other alternatives.
You stated <<<<Also, I think you are misinterpreting what you are
seeing. First of all, there is no "dataset's synonym path". The
synonym chain is a double-linked list connecting all the entries that
want to occupy the same position. Since the synonym chain counter is a
16 bit value, the maximum number of synonyms that can exist for any
single primary location is 65,536. You have a key value to which all
your entries calculate and the chain has popped.>>>>>>
Please excuse my poor choice of wording, but yes, I do underatnd what
happened (the DBEXPLAIN was very explicit about the error 8-)). Also,
the synonym chain filled up at 32,768, but no matter, it's full, and we
need to make the set cap larger, but we're going to see just how much
larger, so we can review alternatives.
Thanks for your help, Denys.
Raymond Shahan
Computer Programmer
REPUBLIC TITLE OF TEXAS, INC.
2701 W Plano Parkway
Plano, TX 75075
direct 214.556.0202
main 972.578.8611
fax 972.424.5621
www.republictitle.com
[log in to unmask]
-----Original Message-----
From: Denys Beauchemin [mailto:[log in to unmask]]
Sent: Tuesday, January 02, 2007 9:49 AM
To: Ray Shahan; [log in to unmask]
Subject: RE: [HP3000-L] Full synonym chain (really ugly)
The R4 (and I4) are not hashing-type keys. For all intents and purposes
the
key value (or parts of it) dictate the placement of the record in the
dataset. Unless you can change your key to a hashing type key (an X
value),
your only method of controlling the formation of synonyms is by
adjusting
the capacity.
In order to do this effectively, you need to provide some further bits
of
information:
1- What is the current capacity?
2- What is the lowest key value?
3- What is the highest key value?
Also, I think you are misinterpreting what you are seeing. First of
all,
there is no "dataset's synonym path". The synonym chain is a
double-linked
list connecting all the entries that want to occupy the same position.
Since the synonym chain counter is a 16 bit value, the maximum number of
synonyms that can exist for any single primary location is 65,536. You
have
a key value to which all your entries calculate and the chain has
popped.
This can easily be remedied (temporarily) with a capacity change, but
the
capacity must be judiciously chosen, hence the questions at the
beginning of
the message.
Denys
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf
Of Ray Shahan
Sent: Tuesday, January 02, 2007 9:25 AM
To: [log in to unmask]
Subject: [HP3000-L] Full synonym chain (really ugly)
Hi all,
Last Friday eve (as luck would have it), we had a DB lock up
because an Auto Master synonym chain filled up. We did a verify of the
set's synonym path (on a copy of the DB), and just about every entry had
lots of secondaries - (only about 2% of the entries did not have a
secondary). The particular data value that finally filled up its
synonym chain is: 41378.25
After reading the IMAGE manual trying to determine what's
wrong, we can see that it may be a problem with the R4 data type for our
key value? I'm not a math wiz, and have never used real numbers data
types as keys before (heck, I don't ever recall using real number data
types for anything in IMAGE).
1) My questions are why does the R4 data type end up with so many
synonyms?
2) Would the same problem exist if the data type was an I4?
TIA, and Happy New Year!
<http://www.republictitle.com/>
Raymond Shahan
Computer Programmer
REPUBLIC TITLE OF TEXAS, INC. <http://www.republictitle.com/>
2701 W Plano Parkway
<http://maps.yahoo.com/maps_result?addr=2701+w+plano+parkway&csz=75075&c
ountry=us&new=1&name=&qty=>
Plano, TX 75075
direct 214.556.0202
main 972.578.8611
fax 972.424.5621
www.republictitle.com <http://www.republictitle.com/>
[log in to unmask]
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
