Error: 692, Severity: 20, State: 1
Tahir
During our daily operations, we got an Error 692, Severity: 20, State:
1 server Uninitialized logical page '5427199' was read while
accessing object '1372636033' in database '6'. Please contact Sybase
Technical Support.
We tried to figure out the page chains on this specific object - but
it was un-successful on one specific page. Anyway, we tried to run
dbcc commands like checktable, tablealloc etc to correct this - but we
didn't succeeded.
As a last resort, we created a new table and copy all the data with
the help of index and everything worked fine after that.
My question here -- Error 692 normally caused by some O/S level issue.
As a solution, we just discarded or deallocated the pages which may
have problems by creating new table and moving data. Just a concern
that the pages which are de-allocated now, can be used next time in
future - for some other object or growth in existing objects. Is
there any technique to check the health of un-allocated pages?
Regards,
Tahir
Derek Asirvadem
>
> We tried to figure out the page chains on this specific object - but
> it was un-successful on one specific page. Anyway, we tried to run
> dbcc commands like checktable, tablealloc etc to correct this - but we
> didn't succeeded.
1 What was the error msg ?
2 What about the regular dbcc checkalloc, why did it not pick the error up ?
> As a last resort, we created a new table and copy all the data with
> the help of index and everything worked fine after that.
>
> My question here -- Error 692 normally caused by some O/S level issue.
Yes, generally a hard error, disk failure. Apparently your disks are
not mirrored.
> As a solution, we just discarded or deallocated the pages which may
> have problems by creating new table and moving data. Just a concern
> that the pages which are de-allocated now, can be used next time in
> future - for some other object or growth in existing objects.
Yes, definitely, since you did not recreate the database on diff
devices, or disable the fragment (device allocation).
> Is there any technique to check the health of un-allocated pages?
Not as far as I know, but ...
- dbcc checkalloc does it partially (in certain circumstances, but not
this one)
- dump database does it indirectly as well
- it will depend on how new allocations are grabbed by ASE
Normally this issue is handled by the Volume Manager (which includes
mirroring and striping; keeping track of bad blocks, etc). You are
better off identifying the device and logical block from the database
fragment (device allocation) which received the error, and testing
writes to those blocks. If you do not have good disks, or mirrored
disks, then get the database fragment OFF that set of disk blocks; then
create a file there so that it does not get used by anything else.
The best advice I can give you is to read up on the Troubleshooting &
Error Messages guide. I think Vol II has the write-up on how to
approach errors of this kind in general, and how to distinguish between
hard and soft errors.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
"Patient, normalise thyself"
![Jason L. Froebe [TeamSybase]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWtFO3Z-Ed2xXdNkgYXHBbZgF6O22kgP6Je6Mcqd7zWbrpT3Q=s40-c)
Jason L. Froebe [TeamSybase]
Hash: SHA1
Hi Tahir,
checkalloc & tablealloc basically just flip bits for allocation and
aren't able to fix 69x errors.
To answer your question: no, there isn't a way to check the consistency
of unallocated pages - they would contain left over unused data which
could contain just about anything. It would be handy if the structure
of the page(s) could be validated though IMHO.
692 errors can be caused by several things. Major causes are:
1) disk/controller/SAN errors - usually a corresponding os error is
logged in the os error logs but not always
2) OS bug - not so common anymore but they do happen with the older
OSs... as well as if you have some funky os mount settings ;-)
3) ASE bug - not as common as back in the 11.9x days but they still
occur as well
4) overlapping partitions (file system and/or raw partitions)
What is the exact version of ASE you're using? (select @@version)
Can you provide a bit of the errorlog? I ask because 69x errors can be
accompanied by stacktraces or other error messages that may provide more
information on how this occurred.
In the future: If the 692 error is on an nonclustered index, you can
just drop/recreate the index. If on a clustered index (APL table), you
will want to bcp the data in/out or go to backups.
hope this helps
- --
Jason L. Froebe
TeamSybase
http://www.froebe.net/blog
http://www.froebe-fibers.com
http://www.isug.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmSTMMACgkQ73tB17phUQC/nQCgnj/jh0wvH5/XdvrhgzBNZWg0
9QMAoK9cgoeFaau5rzYPy+gxJeNE+7Lw
=U3lu
-----END PGP SIGNATURE-----
Tahir
We are using ASE 12.0.8 on HP-UX, old stuff :-)
We are using SAN with Veritas managed raw devices. We tried to figure
out the issues on O/S level, but there was no error in fact there.
We tried to figure out the issues with page chain checking. The chain
of pages looks broken (in forward direction). I identified the
problematic page which points to the next was not initialized.
The output of tablealloc was like this:
DBCC TABLEALLOC
***************************************************************
TABLE: myTable OBJID = 1372636033
INDID=1 FIRST=5830209 ROOT=5830201 SORT=1
Msg 2529, Level 16, State 7:
Server 'myDataBase', Line 1:
Table Corrupt: Attempted to get page 5427199, object 1372636033; got
page 0, object 0.
INDID=2 FIRST=2549296 ROOT=2361149 SORT=0
Indid : 2. 1185368 Index pages allocated and 161516
Extents allocated.
INDID=3 FIRST=3696184 ROOT=2655576 SORT=0
Indid : 3. 1124587 Index pages allocated and 160115
Extents allocated.
TOTAL # of extents = 321631
-------
DBCC PGLINKAGE FROM 5427192 up to the problem
dbcc pglinkage(6, 5427192, 0,2,0,1)
[10052] MyServer.master.2> ;
Object ID for pages in this chain = 1372636033.
Page : 5427192
Page : 5427194
Page : 5427195
Page : 5427196
pprevpg pointer for page 5427196 does not point to previous page in
chain
as scanned. pprevpg pointer = 5372131, previous page as scanned =
5427195.
4 pages scanned. Object ID = 1372636033. Last page in scan =
5427196.
-----------
DBCC PAGE FOR 5427196
PAGE HEADER:
Page header for page 0xc00000000ddc9000
pageno=5427196 nextpg=5427199 prevpg=5372131 objid=1372636033
timestamp=0004 d7598825
nextrno=19 level=0 indid=0 freeoff=698 minlen=31
page status bits: 0x11 (0x0010 (PG_RNOFREE), 0x0001 (PG_DATA))
DBCC PAGE FOR 5427199
PAGE HEADER:
Page header for page 0xc00000000ddc9000
pageno=0 nextpg=0 prevpg=0 objid=0 timestamp=0000 00000000
nextrno=0 level=0 indid=0 freeoff=0 minlen=0
page status bits: 0x0 (0x0000)
DBCC PAGE FOR 5427197
PAGE HEADER:
Page header for page 0xc00000000ddc9000
pageno=5427197 nextpg=5427198 prevpg=5415796 objid=1372636033
timestamp=0003 97186c3e
nextrno=18 level=0 indid=0 freeoff=680 minlen=31
page status bits: 0x11 (0x0010 (PG_RNOFREE), 0x0001 (PG_DATA))
-------
We used dbcc tablealloc (MyTable,full,fix) in single user mode, which
never finish because of this error.
Anyway, this topic of resolution is over now and we have moved to next
step.
What I presume from your discussions here, we have made a strategy, we
are going to create a big table to fill up all the database space,
which is fortunately left a little. During this fill-up process, if we
encounter the error again, means we have some real hardware issue,
otherwise everything is just fine. What you think about this?
Thanks anyway for your comments/help.
Regards,
Tahir
Derek Asirvadem
>
> We are using ASE 12.0.8 on HP-UX, old stuff :-)
In my personal experience 12.0 was a very buggy release, in the same
class as 11.0. 11.5 was a class better. 11.9.2 and 12.5 are in a
different class again. Not one of my customers used it.
> We are using SAN with Veritas managed raw devices.
As mentioned, you have not set up mirrored subdisk groups, and then
created Logical Volumes on top of those mirrored groups. Disks break,
especially old ones. Most sites that need an enterprise database
server for critical apps mirror the disks at the Veritas (Logical
Volume Manager) level: the bad blocks are taken care of there (marked,
substituted, overcome). And thus they do not show up in ASE.
> We tried to figure
> out the issues on O/S level, but there was no error in fact there.
It normally does not show up at the o/s level, just in the LVM log
file. You need to look at disk diagnostics in Veritas.
> We tried to figure out the issues with page chain checking. The chain
> of pages looks broken (in forward direction). I identified the
> problematic page which points to the next was not initialized.
>
> <snip>
Good that you followed the page chain yourself, but it only proved the
692 was real, that is was a hard error, a disk write failed to make it
to the disk. Now you may want to dig further and prove that a write
failed, but there is no point, most of us know that when it gets to
this level, it was not ASE, it was one of the lower level components in
the chain, and disks just age and start getting bad blocks. In case it
needs to be said, a SAN is not a magic box, it is just a computer with
a large cache and an array of disks, used for a special-ised purpose.
If the SAN isn't configured properly (or for dealinf with bad blocks
via mirroring or RAID5) then it cannot provide that facility
(overcoming bad blocks; substituting a new extent for the damaged one,
etc).
BTW do not use RAID5 for databases; use RAID1+0 (mirrored, then
striped) in preference over RAID0+1.
> Msg 2529, Level 16, State 7: Server 'myDataBase', Line 1: Table
> Corrupt: Attempted to get page 5427199, object 1372636033; got page 0,
> object 0.
AFAIC, the 2529 proves the table is still corrupt. Actually, if you
keep going, it will get worse. Read up on hard errors, and how to
approach them, and specifically how to fix a 2529. IIRC since the
table name is displayed, it is fairly safe that the object is well
established, and therefore recoverable.
> We used dbcc tablealloc (MyTable,full,fix) in single user mode, which
> never finish because of this error.
Sure it got stuck, hung up at the same point bu that might be a
different problem or shed more light on the nature of the set of bad
blocks. Getting hung up could mean the drivers/LVM is re-trying itself
silly.
> Anyway, this topic of resolution is over now and we have moved to next
> step.
I do not wish to be pedantic, but no, you have not resolved the issue;
so far you have confirmed one or more bad blocks in the db; fortunately
they are [now ?] in unused allocation units. Resolution will be
achieved when either the bad blocks have been separated out in some way
(until next time) or the possibility of bad blocks have been
eliminated/overcome via LVM.
> What I presume from your discussions here, we have made a strategy, we
> are going to create a big table to fill up all the database space,
> which is fortunately left a little. During this fill-up process, if we
> encounter the error again, means we have some real hardware issue,
> otherwise everything is just fine. What you think about this?
There may be a question in your mind as to whether it is a "real"
hardware issue, but there is no question in my mind. Just like chasing
down the page chain only proved that the 692 was "real", this test will
only prove that the reported [692/2529] hard error is real: you have a
set of bad blocks (just like anyone who has purchased disks). Now the
real question is, how are you going to insulate your database from such
errors.
Yes, there is a good chance of encountering the error again, in the
same place, due to not having addressed it at the LV level; until then,
the same physical disk blocks within the SAN are hosting the same
logical location in the ASE device. In terms of the next step ... two
methods:
1 The db is critical, you cannot dump/load, you have to live with the
terrorist cells in certain villages.
You accept living with a small black hole in the db.
Find the db fragment (device allocation) that the 692/2529 is on;
remove all segments from it; copy all tables out of it onto new tables
on other fragments (create a segment there; create the table there, or
sp_placeobject before inserting); drop all [old] tables from the
damaged fragment. Document it so that someone else does not try to use
the damaged fragment.
2 The database is mission critical, you need the highest levels of
recoverability (and if you do not have it, you are ready to create it).
- dump all databases
- record the exact sequence of fragments (sysusages.lstart order)
- drop all databases
- configure the SAN (all physical disks available for the business
unit) for RAID1+0
- create a reasonable no of LVs (you need a balance between no of I/O
queues within ASE vs db size; more small LVs rather than fewer large)
- create new device allocations for the dbs as per a good plan (keep
device stats, recovery via copying the SAN LVs to another site, in mind)
- create new dbs (with distribution over the LVs and growth in mind)
but in the original sequence (not size) of fragments
- load dbs from dumps
- online
- clean up any data/log issues
If you go with [2] and your server devices (those that master,
sybsystemprocs, sybsystemdb, reside on) are not mirrored, then
obviously you have to mirror them as well, you may as well rebuild the
server. You may want to post another thread re any questions you have.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright Š 2008 Software Gems Pty Ltd
--
With the financial meltdown, consolidating many databases into one ASE
server and managing mixed load is a demand. Ask people who have been
doing it for years.
Jason L. Froebe [TeamSybase]
Hash: SHA1
Hi Tahir,
thanks for the info. A 692 error does NOT prove one way or the other
that there is a hardware problem. It only means that the specific page
is messed up for an UNKNOWN reason.
I'm not suspecting hardware *failure* as there aren't any i/o errors in
the errorlog that you've shown us.
The 5427199 was zeroed out for some reason (maybe ASE, maybe os, or
something else). What do the page headers for 5427198 and 4527200 look
like? If those are also zeroed out, maybe it might be os. maybe.
A more likely culprit (at least statistically with other installations -
I don't know if this is likely at your site) is:
1) at some point in the past page 5427199 was linked but not allocated.
2) the database was backed up but not this particular page because it
wasn't marked as allocated
3) the database was restored some point in the past, which will zero
out any unallocated pages
4) some unknown time later, the page is referenced in a query throwing
a 692 error
That's *one* way for it to happen. I'm not ruling out overlapping
partitions quite yet nor an ASE bug.
Again, it is possible that the SAN or hard drive magically zeroed out
this page but I think the odds are against it.
The debate of RAID 0+1 and 5 has been going on for years. RAID 5 is
fine but is slower for writes than 0+1 so a benchmark would likely have
to be done to determine if it is fast enough to keep up with your
transaction load.
- --
Jason L. Froebe
TeamSybase
http://www.froebe.net/blog
http://www.froebe-fibers.com
http://www.isug.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmS1zoACgkQ73tB17phUQC30wCg5aGU0DmxIidPLJ+0ilh/Ytwk
PmwAnRRFZTlfEYR7W6ePGonaHpNzu1+a
=HQbu
-----END PGP SIGNATURE-----
Jason L. Froebe [TeamSybase]
Hash: SHA1
whatever
- --
Jason L. Froebe
TeamSybase
http://www.froebe.net/blog
http://www.froebe-fibers.com
http://www.isug.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmS5L0ACgkQ73tB17phUQDTfwCgt3CgsePfYHpLRLGtZ+8qznuJ
e/MAn0fEjZRaXKnVIkfgPafJGxoZAefo
=J6w7
-----END PGP SIGNATURE-----
Derek Asirvadem
> <ja...@froebe.net> said:
Everyone has various levels of expertise, and different actual
experience. You are welcome to your opinion, but there is no need to
put other responders down.
> The debate of RAID 0+1 and 5 has been going on for years.
Only for people who like debates and are committed to non-resolution.
For the rest of us, it has not been a debate for a long time. Having
done more than a few benchmarks, we are hard pressed to do yet another
benchmark for those who still need proof, but who have not formed a
conclusion from the dozens of benchmarks in the past.
What matters is if the responder can backup their advice.
- RAID5 is a dog, and unsuitable for any RDBMS
- RAID5 on a SAN is particularly stupid (when you have mirroring and
striping as faster alternatives without the loss of a spindle), the
days of a generic SAN config with a single massive RAID5 LV are long
gone
- (fair enough, you can recommend it, but I will not; but do not
inflate its relevance by casting it as a debated or debatable issue)
- RAID1 is a necessity for any critical database/app
- RAID1+0 is far superior wrt both performance and recoverability, to
RAID0+1 (if you disagree, then post the technical reasons, rather that
a put-down; if you do not understand why, then post a question).
> RAID 5 is
> fine but is slower for writes than 0+1
And what about RAID5 vs RAID1+0 which was stated (0+1 was not stated)
> so a benchmark would likely have
> to be done to determine if it is fast enough to keep up with your
> transaction load.
Since you are suggesting benchmarks (to those of us who aren't forever
questioning ours), why don't you produce the benchmark and save us the
work (which our benchmarks were designed to do, and already have done).
There is no value in trying out a square wheel, at every site, just in
case, because the square-wheel debate has been going on for years, to
see if it is faster than a round wheel. Most of us drive on Earth, not
the the Moon.
--
Regards
Derek Asirvadem
Director / Senior Sybase DBA / Information Architect
Sybase BSA [OEM/VAR] Partner
Derek Asirvadem
> <ja...@froebe.net> said:
"whatever " is typical of losers who just have to get the last word in,
not to mention it breaches the guidelines (it is not a technical post,
it has no techncial value), which you do consistently.
Put up (a technical argument) or shut up (refrain from posting opinions
that cannot be backed up with technical evidence; refrain from
diminishing the posts of others unless you can back up your opinions).
No use crying "whatever" as you run away from the issue.
Eg. separate to the square wheel issue, you and I disagree re the hard
error. That's fine. Two different people with totally different
expertise and experience levels. Neither needs to diminish the other
or the others opinion. Remember it is a newsgroup for the free
exchange of technical info, not someone's personal blogspot. See if
you can advise the square wheel without having to make the round wheel
look bad, and without the suggestion that they are comparable.
Derek Asirvadem
>
> look at the thread "Need ideas regarding identifying what could cause
> Error: 12546 [ASE 12.5.4 ESD#8, Sol x64]"
in sybase.public.ase.backup+recovery
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
Derek Asirvadem
Re the value/relevance of chasing down a hard error, have a look at the
thread "Need ideas regarding identifying what could cause Error: 12546
[ASE 12.5.4 ESD#8, Sol x64]". NFS is not suitable for any RDBMS; there
is no need to (a) trust it (b) place database devices on it (c)
encounter hard errors (d) inspect the errors (e) confirm the hard
errors (f) move the dbs off it, onto some worthy /fs or raw partition.
That's why peope like me will tell you from the outset, do not waste
your time, NFS is not suitable for any RDBMS.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright Š 2008 Software Gems Pty Ltd
--
Tired of databases that are more cost than benefit ? Wondering why you
cannot get Sybase performance from Sybase ? Find out
mh
[...] NFS is not suitable for any RDBMS [...]
In that case it is not a good thing that Sybase has NetApp (NFS) on the
platform certification list. I guess it is just a paper certification
and no real testing (recovery is my main concern at this point).
Ref:
http://certification.sybase.com/ucr/search.do
/Matt
Derek Asirvadem
That may not be fair. For product availability purposes, all db
vendors make their products available on, and certify them on, a subset
of whatever the industry provides as platforms. Sybase is certified on
Windows, RAID5, NFS, NAS, filesystem devices ... that does not mean
that any of those are advisable ... but some people insist on (eg.)
running ASE on Windows and expecting mid-range h/w speeds out of it;
some people run it on RAID5 (great for Intel file "servers" but not for
DBMS, Intel or otherwise) and post questions as to why is it so slow.
There is no implication that heavy load testing has been performed.
There is a clear indication that the product has been installed; all
issues have been resolved; and that it "operates as documented". It is
more a list of "here's what you can possibly run on", which really
means the exclusions are "do not bother trying"; it is not a list of
"here's what it runs well on" or "here's what it designed for".
And a lot has to do with the physical config, the I/O subsystem
purchased and configured (that is not tested in the certification).
If recovery is a significant concern, then by all means put that at the
top of your list of priorities when you evaluate your hardware and disk
I/O subsystem options and choose carefully. Windows (and to a lesser
extent any Intel-based linux) are severely limited in that department,
once you move to a mid-range box with a backplane (instead of a
"motherboard"), you are in a different class of moving large volumes of
data between the components, and of recoverability. Trying out new
cheap technologies is fine, but there is always a trade-off and that
shows up in recoverability and stability; it is not possible, in this
industry which is highly competitive at least in the hardware side, to
get a filesystem for half the price of raw partitions and not lose
something. In the shop I am working in at the moment, all the Windoze
"servers" get "bounced" (just to clear their little rubber ball heads)
every night; the Solaris machines come down once a month for scheduled
maintenance only.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright Š 2008 Software Gems Pty Ltd
Quality Standards = Zero Maintenance + Zero Surprises
Performance Standards = Predictability + Scaleability
Derek Asirvadem
> [...] NFS is not suitable for any RDBMS [...]
Ok, there have been some other posts, so I will provide a bit more
detail as to how/why it is not suitable. Refer also to Luc's post on
another thread that you participated in recently.
1 Typically, NetApp/nfs is set up with one host being direct, and a
number of other hosts being indirect. For performance, the db server
needs direct connection to the disks, not indirect, for obvious
reasons. Sure, you can improve speed a little by using fibre,
increasing ASE or NetApp cache memory, but not much. The architecture
has finite limits.
2 The load on the array-of-disks is the entire set of hosts; your db
server on one host cannot get the throughput it is capable of, because
the NetApp/nfs array-of-disks plus cache is saturated by the load of
the entire set of hosts. If you take the bus to work, it is not
reasonable to expect the transfer times of getting there by private
vehicle.
If you can partition off a set of physical spindles for EACH of the db
servers, so that each of them is isolated from the load of the others,
then you get a return to reasonable speeds, but that is not feasible on
the scale of NetApp/nfs. Fine, stay with nfs, but it is unreasonable
to expect NOT to be affected by the load of all hosts using the unit.
The problem, and the resolution, by the way, is identical in SANs; the
difference is that isolating a set of physical spindles for each server
IS feasible on that scale. When people are paying that king of money
and they have fibre all the way to the disks, they want the performance
that they purchased, and it is easy enough to prove what the problem
is, and the resolution of course proves itself. The main difference
with a SAN is, all the hosts are direct-connected (usually by fibre
only).
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright © 2008 Software Gems Pty Ltd
--
Sherlock, Kevin [TeamSybase]
really not much different from the competition. Although one big difference
is the NetApp "filer" layer (ie, it's OS called Data OnTap). It supports
NFS (as well as many other network protocols), but you wouldn't use it that
way as a DBMS platform. FC configuration expose raw devices to the OS using
block level protocol.
"mh" <m...@bostreammail.com> wrote in message
news:CC5DA85CE62D4A50...@ad.bossmedia.se...
Tahir
Gentlemen !
We are not using RAID 5 - which is the safest but slow. We are using
RAID 1+0, which we think is the "best" for our environment. Someone
may have different views and I dont think it require any debate.
Thanks both of you for having almost the same concern - I will check
the SAN Log in order to figure out the issue further deep, either it
is a driver issues or other. Overlapping, I doubt about it, but even I
will check that.
Based on your advice, I assume that probably, we will have some
blackholes inside database. The exiting data distribution, size of
data will not allow us to do some object re-placement, but I am going
ahead with my plan to check the database in full.
Thanks anyway, you all for your valued comments.
Regards,
TK
Derek Asirvadem
>
> We are not using RAID 5 - which is the safest but slow. We are using
> RAID 1+0, which we think is the "best" for our environment. Someone
> may have different views and I dont think it require any debate.
(I am not interested in "debates that go on for years" without
resolution, I am only interested in technical facts, which killed the
"debate" years ago.)
RAID5 (losing a spindle; hamfisted striping; adding parity calcs) is
not the safest.
RAID1 (mirroring) is the safest.
RAID1+0 (mirror, then stripe) is the fastest, and much faster than RAID5.
RAID0+1 (stripe then mirror) is inferior to RAID1+0.
Derek Asirvadem
<ja...@froebe.net> said:
> Again, it is possible that the SAN or hard drive magically zeroed out
> this page but I think the odds are against it.
>
> The debate of RAID 0+1 and 5 has been going on for years. RAID 5 is
> fine but is slower for writes than 0+1 so a benchmark would likely have
> to be done to determine if it is fast enough to keep up with your
> transaction load.
Hey Jason
When you provide answers to seekers questions, I do not have a problem,
even when they are different from other responders answers. Seekers
are mature enough to take what they like and leave the rest.
When you comment on other responders answers, you create conflict where
there was none, and contaminate the seekers thread. The original
responder has a dilemma: either leave it as is and let the original
response be diminished by your comments, and let readers (we have many
newbies here) think there is some validity in your point; or respond to
your comments and thus get dragged into conflict. It is a lose/lose
proposition. Given that you have an established record of engaging in
conflict without resolution:
sybase.public.ase.product_futures_discussion/The Oracle DBMS is a
*legacy technology*, bring in hybrid ASE and IQ
engaging with you yet again will be a time wasting engagement without
you conceding anything. So it is a lose/lose/lose proposition.
(and that is beside your condoning of illegal and immoral behaviour in
that thread)
IM experience the RAID1+0 (I did not advise 0+1, but you are free to)
vs RAID5 debate was closed many years ago as an ordinary result of
benchmarks, which were conclusive. There is no debate. If, as you
report, there has been a "debate" going on for years, then the debaters
and the benchmarkers must be totally incompetent. Or committed to
debate without resolution. They might be doing stupid things such as
comparing RAID5 on a Windoze box vs RAID1+0 on a Solaris box (that's
not a benchmark, that's a bowl of fruit), or fibre with SCSI; they
should be comparing RAID5vs RAID 1+0 on the same box/disk array, and
fibre with fibre.
Since we have technical facts which forms the basis of the advice we
provide here, and do not believe in magic, and since you are suggesting
[the labour of] benchmarks to prove facts which were proved many years
ago, why don't you post any facts you may have re the "debate" or
benchmarks that were inconclusive.
Better yet, just respond to the seeker, and refrain from commenting on
the posts of other responders.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright Š 2008 Software Gems Pty Ltd
"Patient, normalise thyself"
Peter Collard
> Thanks Derek & Jason,
>
> We are using ASE 12.0.8 on HP-UX, old stuff :-)
>
> We are using SAN with Veritas managed raw devices. We tried to figure
> out the issues on O/S level, but there was no error in fact there.
>
> We tried to figure out the issues with page chain checking. The chain
> of pages looks broken (in forward direction). I identified the
> problematic page which points to the next was not initialized.
>
> The output of tablealloc was like this:
>
> DBCC TABLEALLOC
> Thanks anyway for your comments/help.
>
> Regards,
> Tahir
The most common cause of this in my experience is hardware related -
specifically disk cache. Certain disks have been known to be very prone to
it. I guess its a bug in the disk caching subsystem.
Derek Asirvadem
> fine but is slower for writes than 0+1 so a benchmark would likely have
> to be done to determine if it is fast enough to keep up with your
> transaction load.
Since you are posting re my response, and the readership (particularly
the original seeker, but we have many new users here) may believe there
is some relevance to your statement, and thus a diminishment of my
statements, I have to respond and state that what you are stating is
opinion, not technical fact (if you have facts re "debates" or
"benchmarks", please post them). I have stated facts, not opinion; if
you are going to comment on other responses, I would ask that you post
facts.
If you posted responses to the seekers, without reference to the
responses of others, it would avoid conflict and focus on serving the
seeker.
--
Cheers
Derek
Senior Sybase DBA / Information Architect
Copyright Š 2008 Software Gems Pty Ltd