Reorg Rebuild generating more 8233 errors

Cory Sane

unread,

Mar 19, 2009, 10:55:52 AM3/19/09

to

Guys,
My site just finished upgrading a 12.5.3ESD#7 instance to ASE 15.0.2ESD#6.

Adaptive Server Enterprise/15.0.2/EBF 15959 ESD#6/P/Sun_svr4/OS
5.8/ase1502/2537/64-bit/FBO/Thu Oct 2 05:54:54 2008

The REORG REBUILD maintenance jobs are generating Error 8233 Sev 16 errors.

Was that a change in the REORG Locking and interactions between other queries?
Is there a trace flag to resolve these conflicts?

Cory

Bret Halford [Sybase]

unread,

Mar 19, 2009, 1:25:02 PM3/19/09

to

Yes, there was a change in the way REORG was implemented, resulting
in the object descriptor not being as available to other processes;
as a result they get the error rather than blocking.

There is no traceflag for this; there is an open feature request to
have such processes block rather than fail - CR 475139. It is not
currently being worked on.

-bret

Cory Sane [TeamSybase]

unread,

Mar 19, 2009, 2:05:43 PM3/19/09

to

Bret,

My co-worker has found that if he only reorgs the indexes by name, then we can
prevent these problems. Do you agree?

Cory

On 19 Mar 2009 09:25:02 -0800,
in sybase.public.ase.administration

Bret Halford [Sybase]

unread,

Mar 19, 2009, 4:43:53 PM3/19/09

to

Cory Sane [TeamSybase] wrote:
> Bret,
>
> My co-worker has found that if he only reorgs the indexes by name, then we can
> prevent these problems. Do you agree?
>
> Cory

You mean REORG REBUILD INDEX <indexname> vs REORG REBUILD <table>?
Yes, that makes sense. The table level operation essentially does
a select into a new table, drops the old one, and patches up the object
ids and descriptors so the new table looks like the old one to
everything hooked into it. REORG index is more like drop and rebuild
the index, except you don't have to know the index definition; no games
are played with the object descriptor in memory.

Cheers,
-bret

Michael Heaney

unread,

Mar 19, 2009, 5:16:18 PM3/19/09

to

I'm experiencing this same issue with 'reorg rebuild' causing
user processes to abort rather than block. It really puts a
crimp in my maintenance activities. How can we customers
encourage Sybase to work on CR 475139?

Michael Heaney
JCVI

Cory Sane [TeamSybase]

unread,

Mar 20, 2009, 12:14:13 AM3/20/09

to

Michael,
Contact Sybase Support and ask them to attach your support site id to the CR.
I did this today. If they get enough Sites tied to the CR they take a little more notice.

--
Cory Sane
[TeamSybase]
Certified Sybase Associate DBA for ASE 15.0
"Michael Heaney" <mhe...@jcvi.org> wrote in message news:49c2b622$1@forums-1-dub...

Michael Heaney

unread,

Mar 20, 2009, 8:05:55 AM3/20/09

to

Cory Sane [TeamSybase] wrote:
> Michael,
> Contact Sybase Support and ask them to attach your support site id to
> the CR.
> I did this today. If they get enough Sites tied to the CR they take a
> little more notice.
>
>
>

Thanks, Cory - I just did, and I encourage others to do the same.
Maintenance activities such as reorg's or index rebuilds should
never cause user processes to abort. Since it's not possible to
predict when a particular table might be used, running 'reorg
rebuild' on it at any time now becomes a crapshoot. That's just
not acceptable in a production environment.

Michael Heaney
JCVI