"large" transaction bug in 6.5

"large" transaction bug in 6.5

Post by Jon » Fri, 02 Oct 1998 04:00:00



I understand that Microsoft has confirmed a bug in SQL Server 6.5 (I'm
not certain which service pack/s).  Evidently, "large" transactions can
sometimes send the database into recovery.  However, they seem to be mum
as to how many updates constitute a "large" transaction.  Does anyone
know?

I understand that there's a hot patch that fixes this problem.  However,
I'm a little leery about putting a hot fix on production database.
Thanks,

Jon Moorman

 
 
 

"large" transaction bug in 6.5

Post by Neil Pik » Sat, 03 Oct 1998 04:00:00


Quote:> I understand that Microsoft has confirmed a bug in SQL Server 6.5 (I'm
> not certain which service pack/s).  Evidently, "large" transactions can
> sometimes send the database into recovery.  However, they seem to be mum
> as to how many updates constitute a "large" transaction.  Does anyone
> know?

Jon,

 Can't say I've ever seen this myself.  Do you have more information like
a Q or bug number?

 Neil Pike MVP/MCSE
 Protech Computing Ltd
 (Please post ALL replies to the newsgroup only unless indicated
otherwise)

 
 
 

"large" transaction bug in 6.5

Post by Jon » Sat, 03 Oct 1998 04:00:00


Quote:> > I understand that Microsoft has confirmed a bug in SQL Server 6.5 (I'm
> > not certain which service pack/s).  Evidently, "large" transactions can
> > sometimes send the database into recovery.  However, they seem to be mum
> > as to how many updates constitute a "large" transaction.  Does anyone
> > know?

> Jon,

>  Can't say I've ever seen this myself.  Do you have more information like
> a Q or bug number?

I don't have a bug number.  My client manager has a connection at Microsoft
that informed him of this little thingie.  However, there doesn't seem like
there's much more information about it.  I'll try to get more information.

-jon

 
 
 

"large" transaction bug in 6.5

Post by Neil Pik » Sun, 04 Oct 1998 04:00:00


Jon - their contact should be able to give a bug number then.  With
that I can get more details./

 Neil Pike MVP/MCSE
 Protech Computing Ltd
 (Please post ALL replies to the newsgroup only unless indicated
otherwise)

 
 
 

"large" transaction bug in 6.5

Post by Jon » Fri, 09 Oct 1998 04:00:00


[I tried posting this two nights ago, but I haven't seen it in the user
group.  Sorry if this dupes down the line.]
Neil,

I still don't have a bug number, but I do have a little more info.
Evidently this "large" transaction bug concerns some of the bugs being
fixed in the upcoming service pack 4.  It also relates to my post about
recovery.  There *is* a bug in that it is possible to introduce
duplicate keys in very large transactions.  In my case, the transaction
was 5000 INSERTs (give or take one).  I'm going to try to reproduce this
error later in the week, but let me relate the entirety of the problem
(which I thought would be too much info in my earlier post).

I'm converting a large FoxPro database to SQL Server.  I'm running SQL
Server 6.5 Enterprise on a server configured with MSCS.  I'm moving over
and massaging ~5 million rows of data.  I've chunked it into groups of
5000 records.  Each batch was taking ~20 minutes to execute.  On the
night that the big job was run, it clashed with a user-scheduled
checkpoint (I haven't pointed fingers at that culprit yet!) shortly
after midnight.  At 7AM, the same batch was running.  The thread was
killed which (seemingly) triggered an error to MSCS which failed over to
our second server.  This seems to have issued a SQL Server stop on
server A and a SQL Server start on server B.  As it should, the start of
SQL Server B attempted to recover the database.  Three days later, the
database was still in recovery (after 40 hours, attempts were made to
remove the database, set up trace flags, etc.)  Nothing worked and MS
was notified.  A MS tech investigated the problem and determined that
there were duplicates in the database.

Since this time, I've been told (all hearsay, I'm trying to get names)
that MS has identified this bug and has a hot fix that they're willing
to give us prior to the release of the service pack.  Management is not
e*d about this and I'm just trying to get some more information from
anyone that might have any information.  Some of this discussion has
surrounded the long time of recovery (hence my other posts).

I don't have much else to add.  I'm sitting here with a client that is
none too happy, and I'm trying to placate decision-makers.  I'm really
just looking for any info that anyone may have on this/these
problem(s).  My client's downtime is measured in dollars per minute and
if we had a 40 hour database recovery in production, there'd be no need
to come into work because they'd be out of business.

Thanks for the soapbox (and all the help).

-jon