August 13, 2004 at 6:09 am
I do not have much experience in reading SQL transaction errors. My server falls over allmost every time when receiving this event. I do see the memory load is VERY high, but it is not constant on every transaction.
Computer type is AT/AT COMPATIBLE.
Bios Version is SBR20 v16.00
Current time is 11:07:19 08/06/04.
4 Intel x86 level 15, 3056 Mhz processor(s).
Windows NT 5.0 Build 2195 CSD Service Pack 4.
Memory
MemoryLoad = 97%
Total Physical = 1023 MB
Available Physical = 21 MB
Total Page File = 2462 MB
Available Page File = 676 MB
Total Virtual = 2047 MB
Available Virtual = 820 MB
*Stack Dump being sent to G:\Program Files\Microsoft SQL Server\MSSQL\log\SQLDu
mp0056.txt
* *****************************************************************************
**
*
* BEGIN STACK DUMP:
* 08/06/04 11:07:19 spid 57
*
* Exception Address = 100011F4
* Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION
* Access Violation occurred writing address CE1A625C
* Input Buffer 849 bytes -
* BEGIN TRANSACTION DECLARE @UPDATE_SUCCESSFUL BIT EXEC REQUISITION_H
* EADER_UPDATE @UPDATE_SUCCESSFUL = @UPDATE_SUCCESSFUL OUTP
* UT, @REQUISITION_NUMBER = 'RAC59', @account
* = 'A00294', @NODE = '', @RE
* SOURCE = ' ', @FINANCIAL_PERIOD =
* '2004-08', @REPORT_BACK_ON_PROGRESS = '2', @REQUIRED_AMOUN
* T = 31.5, @ACTUAL_AMOUNT = 0, @D
* ESCRIPTION = 'SPADE TERMINALS POSITIVE FOR BATTERY TE
* MINAL', @LINKED_TO_GROUPING_REQ_NUMBER = 'RAC51', --@COST_CENTRE
* = ' ', @ACTION_DATE_EARLIEST = 'AUG 05 20
* 04', @ACTION_DATE_LATEST = 'JUL 26 2005' --@DIVISION_
* CODE = 'CZ' SELECT @UPDATE_SUCCESSFUL
*
Can anybody help me with this?
Regards
Raino Botha
August 13, 2004 at 7:37 am
Is this code in a stored procedure or just dynamically submitted? Have you run DBCC CHECKDB to be sure you don't have corrupt apges somewhere.
Is this the only transaction that fails?
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
August 13, 2004 at 7:43 am
1. It is indeed a stored procedure
2. Yes I did do a CheckDB to check all the data.
3. It is the only transaction that fails, the specific stored procedure updates 4 tables but should not really be a factor because the database is still very small (200 MB)
The closest resembelence to this I could find was: http://support.microsoft.com/default.aspx?scid=kb;en-us;272418&Product=sql But this also does not really apply to the code being used in the SP.
I also defragged all the indexes to make sure that it was not a corrupt indexes that is screwing us. Another point worth mentioning is that this is SBS, so the SQL server is running with Exchange on the same server.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply