Results 1 to 11 of 11
  1. #1
    Join Date
    Apr 2004
    Posts
    24

    Unanswered: Odd problem with a single record

    The database is the back end for an application and the record that is throwing an error is in a table that stores a great deal of text. I can't get to specific about it.

    The behavior is that when I attempt to access one field of this specific record, we'll call it textdata, sybase throws an error:

    Error: 806, Severity: 21, State: 1 Could not find virtual page for logical page 1718681601 in database 'application'

    Sybase then generates a stack trace it looks like and disconnects the active session.

    I can access that field for other records and I can access every other field of that record.

    DBCC records no errors for the database, even in single user mode.

    Thoughts?

  2. #2
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    1. What version are you using?
    2. I guess its just that one record is a problem and all other records for that column is fine?
    3. Can you paste the stacktrace which got generated?

  3. #3
    Join Date
    Jan 2004
    Posts
    545
    Provided Answers: 4
    Have you tried bcp-ing the data out, recreating the table and bcp-ing the data back in?
    I once had a similar problem, and this was the way i could solve it.
    I'm not crazy, I'm an aeroplane!

  4. #4
    Join Date
    Apr 2004
    Posts
    24
    Quote Originally Posted by trvishi
    1. What version are you using?
    2. I guess its just that one record is a problem and all other records for that column is fine?
    3. Can you paste the stacktrace which got generated?

    1. 12.5.0.3
    2. Yep, just the one record.
    3.
    00:00000:00000:2008/06/21 17:44:36.15 kernel sddone: read error on virtual disk 0 block 875:
    00:00000:00000:2008/06/21 17:44:36.15 kernel sddone: Windows NT system error 2: Not a valid filename.
    00:00000:00020:2008/06/21 17:44:36.15 server
    Error 823 encountered .
    00:00000:00020:2008/06/21 17:44:36.15 server Original error was 694, severity 24, state 10
    00:00000:00020:2008/06/21 17:44:36.15 kernel ************************************
    00:00000:00020:2008/06/21 17:44:36.15 kernel SQL causing error : sp_server_info 1
    00:00000:00020:2008/06/21 17:44:36.15 kernel ************************************
    00:00000:00020:2008/06/21 17:44:36.15 server SQL Text: sp_server_info 1
    00:00000:00020:2008/06/21 17:44:36.15 kernel curdb = 1 pstat = 0x14000 lasterror = 694
    00:00000:00020:2008/06/21 17:44:36.15 kernel preverror = 0 transtate = 1
    00:00000:00020:2008/06/21 17:44:36.15 kernel curcmd = 224 program = PBRunTime
    00:00000:00020:2008/06/21 17:44:36.15 kernel pc: 0x00B01A9D os_get_cur_stk_desc+ 0x13a (0x0AD9D280, 0x7C5C2160, 0x7C5721F0, 0xFFFFFFFF)
    00:00000:00020:2008/06/21 17:44:36.15 kernel pc: 0x00B01A9D os_get_cur_stk_desc+ 0x13a (0x0AD9D280, 0x0AD9D038, 0x0000270F, 0x00000002)
    00:00000:00020:2008/06/21 17:44:36.15 kernel pc: 0x00ADACFA pcstkwalk+ 0x204 (0x3ED30041, 0x00000002, 0x0000270F, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.15 kernel pc: 0x00ADA984 ucstkgentrace+ 0x224 (0x3ED30041, 0x00000001, 0x0AD9E914, 0x21D07030)
    00:00000:00020:2008/06/21 17:44:36.15 kernel pc: 0x00A9472B ucbacktrace+ 0xab (0x00000000, 0xFFFFFFFF, 0x0AD9E650, 0x00466D90)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x00407343 terminate_process+ 0xbed (0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x0046AC34 close_network+ 0xc (0x000002B6, 0x00000018, 0x0000000A, 0x0AD9E6D0)
    00:00000:00020:2008/06/21 17:44:36.16 kernel [Handler pc: 0x00466560 ex_stop_recursion installed by the following function:-]
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x00466D90 ex_doprint+ 0x137 (0x000002B6, 0x00000018, 0x0000000A, 0x0AD9E6D0)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x00466C52 ex_print+ 0x7e (0x00000006, 0x0000005E, 0x00000018, 0x0000000A)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x0046AC09 hdl_default+ 0x2a (0x00000006, 0x0000005E, 0x00000018, 0x0000000A)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x00463E3D lookup_handler+ 0x2f (0x00000006, 0x0000005E, 0x00000018, 0x0000000A)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x0046A81B ex_raise+ 0x2b3 (0x21788728, 0x0000000A, 0x0AD9E914, 0x21D07030)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x005F11E1 getpage__raise_io_error+ 0x7d (0x21788728, 0x00000004, 0x00000000, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x005ED916 getpage_with_validation+ 0x566 (0x21788728, 0x00000001, 0x21D06FD8, 0x00000001)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x005E7A07 apl__startscan+ 0x46f (0x21788728, 0x00000001, 0x00000001, 0x217887DC)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x005E757B startscan+ 0x74f (0x00000001, 0x00C68D78, 0x0000000E, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.16 kernel [Handler pc: 0x00463E0E lookup_handler installed by the following function:-]
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x0045EFDB getdbrow+ 0x1d7 (0x00C68D78, 0x0000000E, 0x0AD9EFAC, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.16 kernel [Handler pc: 0x00463E0E lookup_handler installed by the following function:-]
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x0045EDE4 getdbid+ 0x17f (0x0AD9EFCC, 0x00000000, 0x00000000, 0x00000003)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x006D1D3A ha_getsybsystemprocs_dbid+ 0x96 (0x231CBE58, 0x0000000E, 0x0AD90001, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x005DDF1A isasystemproc+ 0x135 (0x231C0001, 0x00000001, 0xFFFFFFFE, 0x231CBE58)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x005DC4BF open_for_cacheid+ 0x543 (0x00000000, 0x00000000, 0x20B60001, 0xFFFFFFFE)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x005DBCC8 open_user_table+ 0xb8 (0x00000000, 0x00000000, 0x00000000, 0x00000001)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x00559FC5 proc_get+ 0x164 (0x00000000, 0x00000000, 0x00000000, 0x00000001)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x0079686D s_getTreeOrPlan+ 0x3d (0x231CBD20, 0x231CBDB0, 0x00000000, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x00742976 execproc+ 0x146 (0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0x7C5864AD)
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x00739E26 s_execute+ 0x3596 (0x22A3B800, 0x0044AB85, 0x2178FB7D, 0x0AD9FEA2)
    00:00000:00020:2008/06/21 17:44:36.16 kernel [Handler pc: 0x0076F623 s_handle installed by the following function:-]
    00:00000:00020:2008/06/21 17:44:36.16 kernel pc: 0x0076C0BD sequencer+ 0x17fd (0x21788100, 0x0AD6E914, 0x21D07030, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.18 kernel pc: 0x00445DF4 tdsrecv_language+ 0x540 (0x0000002F, 0x0AD6E914, 0x21D07030, 0x22433A20)
    00:00000:00020:2008/06/21 17:44:36.18 kernel [Handler pc: 0x0046A887 hdl_backout installed by the following function:-]
    00:00000:00020:2008/06/21 17:44:36.18 kernel [Handler pc: 0x006B7330 ut_handle installed by the following function:-]
    00:00000:00020:2008/06/21 17:44:36.18 kernel [Handler pc: 0x006B7330 ut_handle installed by the following function:-]
    00:00000:00020:2008/06/21 17:44:36.18 kernel pc: 0x00412E43 conn_hdlr+ 0x34f7 (0x22433A20, 0x0AD6E914, 0x21D07030, 0x22433A20)
    00:00000:00020:2008/06/21 17:44:36.18 kernel pc: 0x00A89407 kpntwrapper+ 0x84 (0x00A89383, 0x22433A20, 0x00000000, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.18 kernel pc: 0x7C57B3BC KERNEL32.dll (0x00000000, 0x00000000, 0x00000000, 0x00000000)
    00:00000:00020:2008/06/21 17:44:36.18 kernel end of stack trace, spid 20, kpid 1054015553, suid

  5. #5
    Join Date
    Apr 2004
    Posts
    24
    Quote Originally Posted by Martijnvs
    Have you tried bcp-ing the data out, recreating the table and bcp-ing the data back in?
    I once had a similar problem, and this was the way i could solve it.
    I'm trying to avoid it since the table is in the area of about 9gb in size.

  6. #6
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Quote Originally Posted by madamos
    1. 12.5.0.3
    2. Yep, just the one record.
    3.
    00:00000:00000:2008/06/21 17:44:36.15 kernel sddone: read error on virtual disk 0 block 875:
    00:00000:00000:2008/06/21 17:44:36.15 kernel sddone: Windows NT system error 2: Not a valid filename.
    00:00000:00020:2008/06/21 17:44:36.15 server
    Error 823 encountered .
    00:00000:00020:2008/06/21 17:44:36.15 server Original error was 694, severity 24, state 10
    00:00000:00020:2008/06/21 17:44:36.15 kernel ************************************
    00:00000:00020:2008/06/21 17:44:36.15 kernel SQL causing error : sp_server_info 1
    00:00000:00020:2008/06/21 17:44:36.15 kernel ************************************
    00:00000:00020:2008/06/21 17:44:36.15 server SQL Text: sp_server_info 1
    00:00000:00020:2008/06/21 17:44:36.15 kernel curdb = 1 pstat = 0x14000 lasterror = 694
    00:00000:00020:2008/06/21 17:44:36.15 kernel preverror = 0 transtate = 1
    00:00000:00020:2008/06/21 17:44:36.15 kernel curcmd = 224 program = PBRunTime
    Hm. The stack seems to come from sp_server_info. And the parameter for that is definitely not 1.

    Also, see an 823, read errors just on the top of the output. Can you please check that?

  7. #7
    Join Date
    Apr 2004
    Posts
    24
    Sorry I was away for a bit.

    The error with the 823 I don't understand since this is an entirely different server than the original one with the problem - I took a dump and loaded it on my test system.

    In other news, it turns out that table was only about 2.2gb in size. I BCP'ed it out, truncated the table and BCP'ed it in. No changes other than that. And I can access the record now!

    However I had to increase the log segment of that DB to just over 5gb for it to finish the BCP in. Does anyone know of a way to avoid that?

  8. #8
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Quote Originally Posted by madamos
    Sorry I was away for a bit.

    The error with the 823 I don't understand since this is an entirely different server than the original one with the problem - I took a dump and loaded it on my test system.

    In other news, it turns out that table was only about 2.2gb in size. I BCP'ed it out, truncated the table and BCP'ed it in. No changes other than that. And I can access the record now!

    However I had to increase the log segment of that DB to just over 5gb for it to finish the BCP in. Does anyone know of a way to avoid that?
    You could split the bcp file into a few files or try it in batches with -b option. Also make sure you have trunc log on chkpt on OR have proper thresholds to dump the log if you have transaction log backups.

  9. #9
    Join Date
    Apr 2004
    Posts
    24
    Quote Originally Posted by trvishi
    You could split the bcp file into a few files or try it in batches with -b option. Also make sure you have trunc log on chkpt on OR have proper thresholds to dump the log if you have transaction log backups.

    I'll look into splitting it up - I have trunc log on but its apparently gets done as a single large transaction.

  10. #10
    Join Date
    Apr 2004
    Posts
    24
    I'm having some trouble finding information on splitting the bcp - its not in the syntax documentation I have.

    Does anyone have information on that?

    EDIT- or are we talking about the -F and -L commands to copy specific sets of rows?
    Last edited by madamos; 08-22-08 at 19:37.

  11. #11
    Join Date
    Apr 2004
    Posts
    24
    Just a quick update. BCP'ing out the table and importing it back in cleared up the error. Thanks for help!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •