Hi Brian :)
Tongue-in-Cheek Mode On:
Beware... Caution! Do NOT call Adager unless you want a quick fast
response... even at weird late hours! They will call back!
Tongue-In-Cheek Mode Off:
Rene or someone (Memory fails here!) called me back at a very late
hour one time... and walked me thru a problem... and IIRC my support
contract hadn't been properly paid that year by the University! I hand
walked the PO for the support contract thru the process the next morning!
Art 'wish MS-SQL had an Adager version available! hehe " Bahrs
=======================================================
Art Bahrs, CISSP Information Security The Regence Group
(503) 553-1425 FAX (503) 553-1453
|---------+-------------------------------->
| | "Brian Donaldson" |
| | <[log in to unmask]> |
| | Sent by: "HP-3000 |
| | Systems Discussion" |
| | <[log in to unmask]
| | DU> |
| | |
| | |
| | 09/14/2004 10:08 AM |
| | Please respond to |
| | "Brian Donaldson" |
| | |
| | |-------------------||
| | | [ ] Secure E-mail ||
| | |-------------------||
|---------+-------------------------------->
>--------------------------------------------------------------------------------------------------------------------------|
| |
| To: [log in to unmask] |
| cc: |
| Subject: Re: [HP3000-L] Database corrupted, how to clear the problem? |
>--------------------------------------------------------------------------------------------------------------------------|
Good move calling the guys at Adager.....
Rather than speculate what the problem/solution is best go right to the
big guns....
Brian.
On Mon, 13 Sep 2004 12:03:13 -0700, Emerson, Tom
<[log in to unmask]> wrote:
>OK, good news first: the good folks at Adager were able to walk our
sysadmin through the recovery process -- there was indeed an "in-flight"
transaction in a ...00 file, and later grilling of the usual suspects
revealed that someone had indeed tried to do something unusual...
>
>> -----Original Message-----
>> Behalf Of Brian Donaldson
>> On Fri, 10 Sep 2004 14:16:35 -0700, Emerson, Tom
>> <[log in to unmask]> wrote:
>>
>> >worst thing that can happen on a friday -- "DBG IS DISABLED;
>> > ONLY DBCLOSE ALLOWED"
>>
>> Questions--
>>
>> 1) Was this data base restored from a partial backup?
>>
>> 2) Was the message -- "DBG IS DISABLED; ONLY DBCLOSE ALLOWED"
>> from inside a program updating the database?
>>
>> 3) If so, was it using the DBX procedures?
>
>Answers:
>
> 1) no
> 2) yes (effectively)
> 3) If by this you mean "DBBEGIN/DBEND", then yes (vb using
begintrans/committrans)
>
>Probable actual culprit: a user was deleting a massive amount of data --
something like three thousand rows from a purchase order. The rough VB
code for this process went something like this:
>
> begintrans ' should map to DBXBEGIN
> for idx=1 to spreadsheet.maxrows
> <issue an ODBC/SQL call of the form "delete from header where
id=thisOrder">
> <issue another call of the form "select from detail where
id=thisOrder>
> while not dataset.eod
> <issue "delete from detail where id=thisOrder & thisLine">
> movenext
> wend
> <issue "select from comments where id=thisorder">
> while not dataset.eod
> <issue "delete from comments where id=thisorder &
thiscomment">
> movenext
> wend
> next
> committrans ' and here is the DBXEND
>
>Note the above is boiled down to what "actually" happens; since the usual
case is to only delete a few lines, those inner loops actually have a
qualifying step to ensure that "this line" (or comment) is actually
supposed to be deleted. In this particular case, the user was deleting ALL
lines of the order, so some optimization was being done.
>
>Given that there were 3000+ lines being deleted, I'm almost certain this
hit the XM limit for a single transaction (and probably returned an error
to that effect) However, since this now caused "some sort" of problem,
everyone else was getting the DBG error and that is what got reported.
>
>What I'm curious about is if I would encounter the same sort of problem if
I were to "optimize" it as follows:
>
> begintrans
> odbc("delete from header where id=thisorder")
> odbc("delete from detail where id=thisorder")
> odbc("delete from comments where id=thisorder")
> committrans
>
>i.e., three simple and distinct "deletes" rather than 6000+ individual
deletes. I'm thinking, however, the likely answer is "yes, the same thing
will happen", as this will still "affect" the same amount of data -- can
anyone confirm or deny my hypothesis?
>
>* 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 *
=============================================================================
IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.
=============================================================================
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
