All -

Be careful if you need to ALTER your Tablespaces to use
LARGE_RIDs...it isn't entirely clear from the documentation that you
positively need to ALTER the base table to LARGE in addition to the
index tablespace to get LARGE_RIDS.

The documentation assumes that we all have our indexes in the same
tablespace as the base table data...and so sure an ALTER of the
tablespace followed by reorgs will be enough. But if you have your
indexes in a separate tablespace from your base table then you
positively need to ALTER that base tablespace as well.

I know I'll be flamed by some folks for saying these things but it
might help some poor schmuck who didn't get the word. It all comes
down to documentation and IBM even admitted that in this case theirs
'falls short'.

-Me

Hi Bruce,

On 02/04/2011 10:38 AM, Bruce wrote:
You are right. Sometimes the documentation is missing information.

But since you have to reorg the indexes to grow beyond the old limit, it
should be clear that you have to convert the index tablespace as well.
Anyway, for matters of completeness, this should be added to the
documentation.

I suggest that you click the Feedback link at the bottom of the help
page and send a mail to db2docs. They appreciate any feedback and are
happy to make the documentation better.

Overall I have to say that I'm very impressed by the DB2 documentation.

--
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab

On Feb 4, 2:50*pm, Helmut Tessarek <tessa... (AT) evermeet (DOT) cx> wrote:
Helmut - No, you have it reversed. I altered the index space to
LARGE...reorged and found that I, in fact, had not gotten my
LARGE_RIDS as expected. I did not alter the base tablespace to
LARGE...that's my point. The book doesn't say to do that and while it
may be obvious to some it wasn't obvious to me or others who, in the
same situation did the same thing that I did.

IBM's documentation lacks appropriate examples and in some cases the
command actually does not do what you think it will. We did a
singleton REORG INDEX INDEX_PK (of a primary key) and we got ALL
indexes for that table reorged...I am frankly appalled at this sort of
thing and I have to spend way too much of my time figuring out what
works and what doesn't. I have 23 years in DB2 and I haven't seen
things this bad.

Ok, this is definitely different, although without setting the data tablespace
to large, how should the index point to large rids, if there aren't any?
As I said, you are right. There is room for improvement.

I really urge you to send feedback to the Information Development guys. Your
input is more than valid and these are things that should be addressed, but
just talking about it, is not going to change anything.
I've found several topics and areas where the help could be more specific and
require (more) examples. I opened internal defects and they were addressed
accordingly.
Your feedback is taken seriously and usually you get a reply within a day.

--
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab

On Feb 4, 5:57*pm, Helmut Tessarek <tessa... (AT) evermeet (DOT) cx> wrote:
I know it sounds obvious that the data tablespace would need to be
also converted to LARGE...but I am not the only person operating at
different shops who came to the conclusion that it was not needed.
And are we forced to reorg the table first and THEN do the reorg of
the indexes? Turns out, no a reorg of the table is not necessary.

But these are not issues that are addressed in the documentation.

Sorry Helmut but I've had a heck-of-a-long week going through these
issues...I'm tired of it and I'm sure management is tired of having me/
us/we have to muck-about with this stuff as well.

IBM just needs to do better and I will try to do my part by reporting
to IBM where they fall short...but then I get that famous 'You
obviously didn't read the manual throughly' when I did/do read.

Off to sleep...bummer of a week having to put up with inadequate
customer support and sub-standard documentation not to mention
commands that do more or less than they should.

A reorg of the table is only necessary, if you want to use more than 255
records on one page.

Whenever you get a reply like this from IBM, let me know.

--
Helmut K. C. Tessarek
DB2 Performance and Development
IBM Toronto Lab

On 5 feb, 00:59, Helmut Tessarek <tessa... (AT) evermeet (DOT) cx> wrote:
It is about reading the manual and also interpreting the manual.

Some (long) time ago, IBM (and many other vendors) decided to merge
support fees and new-releases fee, in one offer, software maintenance.
For good and bad.

But IBM did not merge the support tracking application and the DCR
(Design Change Request) application.

As a result, if 'somebody' at IBM says a reported issue is not a
'bug' (and here interpreting the manual can come in), but a reqeust
for a new feature, it goes the DCR way. But the customer has no direct
interface to the DCR. So, 'requests' will enter the DCR database on
features a customer can not track as a PMR.

An example.

A query after rewrite by the user, gives still correct results and
goes 10 times faster than the original one. So the user was capable of
doing what the optimizer can not do at that time.

Nothing new as such.

Where does it have to go? In the 'bug' list or in the DCR list?

For the end-user it is the same. The user has (here) a workaround but
would like to have it improved. When? Maybe in 3 months, maybe in 1
year, but would like an improvement. The time things are improved can
be an issue (customer pays maintenance for support and 'new'
capabilities, so certainly has rights) but the catogory a dull
discussion.

As maintenance covers support and new releases, the actual approach is
obsolete and gives rise to less than optimal relation with the support
and can result in staggering customer satisfaction.

Bernard Dhooghe

On Feb 11, 5:35*am, Bernard <dhoog... (AT) yahoo (DOT) com> wrote:
Thank You, Bernard. I just expect the documentation to be complete
and correct.

This statement from you: "It is about reading the manual and also
interpreting the manual." did not please me at all.

Look, if I am doing reorgs to get 'above the line' and converting to
LARGE tablespace I expect clear, conceise and good documentation to
show me immediately what to do with no problems.

How did anybody get 'ALLOW NO ACCESS' to be a euphemism for 'CONVERT
TO LARGE'? What rocket scientist came up with that? And why isn't
it explained in the book that I can do a REORG INDEX and specify
'allow write access' but end-up locking the entire table? I can't
trust the documentation at all and I feel I need to test each and
every little thing I find. And please don't tell me to RTFM because I
do.

On Feb 14, 2:21*pm, Bruce <bwmille... (AT) gmail (DOT) com> wrote:
Hello Bruce,


"It is about reading the manual and also interpreting the manual.":

With the part 'and also interpreting the manual' I mean the
interaction with the support line when reporting an unexpected or
insufficient behavior or a side effect. Then 'interpreting the manual'
can be an issue. If the customer and support agree, a documentation
change can be asked for, to trust the manuals again and to meet
general expectations (again).


Bernard

Hello.

Thank you for taking the time to describe your scenario and the
problem you had with the documentation for the benefit of your fellow
DB2 users.

I am a member of the DB2 LUW information development team. I will
work with my colleagues to improve the documentation related to your
scenario.

Sarah

*In general, the suggestion above to use the "feedback" button (at the
bottom of topics in the on-line Information Center) is a good one.
When you use that feedback button, your note goes right to us and we
investigate.