Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

How to restore a Sybase ASE database server (Windows)

Good afternoon, colleagues.

I apologize for my English, I use a translator.

According to the note 1611715 I'm trying to recover sybase ASE server. I do the following

'

Change to the directory %SYBASE%\ASE-15_0\install. Copy the file 'RUN_<SID>.bat'  to a file 'RUN_<SID>_SINGLE_USER_MODE.bat'.

Edit the new file and add the startup option '-m' at the end of the file.


Start ASE by calling this batch file from a DOS command prompt.

Imporant : ASE is now running as a user process , not as a service. Don't close the DOS command shell where you started ASE as long as the ASE server is running!

'

The server starts, but then when I try to log in as sa with a blank password get an error message in a user name or password.

Login failed.

CT-LIBRARY error:

ct_connect(): protocol specific layer: external error: The attempt to connect to the server failed

However, as user sapsa i can login. This is how to understand? After all, I'm running the server in recovery mode, which is only one login sa with a blank password. What am I doing wrong? And that means an error in the console launch

"Recovery cannot restore the size for '128K' pool in 'default data cache'. The original pool size is 0K. To fix this, run sp_poolconfig to configure the pool size back to the original value."

P.S. Too many question SAP on Sybase  and so almost no answers...

Former Member
replied

Dear Mr Glushchenko

I guess there a couple of issues duscussed in this thread:

1)  missing response files

Depending on the SAPINST version you used, SAPINST removes the original response files from server creation . This is for security concerns when leaving these files on the server.

The SAP note has been updated an does contain sample response files you may review and use.

2) Login with 'sa'  not possible

This is as if you restarted the orignial ASE server (i.e. the one that was created during SAP installation) the 'sa' suer is locked .

The 'sa' user can get unlocked manually with sp_lockogin 'sa' , 'unlock'

However the step in SAP note 1611715 (where you are asked log in to ASe as 'sa' after you started ASE in single user mode)  assumes that you did recreate the ASE server from scratch , i.e. you re-created a new master database. This new ASE serevr only has the 'sa' user of course.

Once you reloaded the latest 'master' dump - you will find that 'sa' is lcioked again.

3) Error message in TST.log

You find this error messages in the error log when restarting ASE:

server  Error: 11068, Severity: 20, State: 1
server  Transaction was found in the incorrect state of 'Command-attached'. The expected state was 'Done command-attached'.
server  Error: 11068, Severity: 20, State: 1
server  Transaction was found in the incorrect state of 'Command-attached'. The expected state was 'Done command-attached'.
kernel  ************************************
kernel  SQL causing error : declare @retstat int exec @retstat=sp_do_poolconfig 'default data cache', '163840K', '128K', '16K', 'true' print ': %1!', @retstat
kernel  Current statement number: 2 Current line number: 134
kernel  ************************************
server  SQL Text: select    @cmdbindingcheck      = 9
        , @cmdsetwashsize       = 10
        , @cmdpoolconfig        = 11
        , @cmdsetapfsize        = 17
        , @cmdupdateconfigfile  = 32

/* declare and init the config options used in this sproc */
kernel  curdb = 1 tempdb = 2 pstat = 0x0 p2stat = 0x4101110
kernel  p3stat = 0x10804 p4stat = 0x0 p5stat = 0x80 p6stat = 0x8000001 p7stat = 0x10000
kernel  lasterror = 11068 preverror = 0 transtate = 0
kernel  curcmd = 193 program =
kernel  extended error information: hostname:  login:
kernel  Symbolic stack trace information is successfully loaded
kernel  pc: 0x0000000140DD0F88 os_get_cur_stk_desc+ 0xf8 (0x000000000435A0A0, 0x000000000435A0A0, 0x000000000435C030, 0x0000000000000000)
kernel  pc: 0x0000000140D4D712 pcstkwalk+ 0x3e2 (0x0000000000000001, 0x0000000000030002, 0x000000000000270F, 0x000007FEFDB51130)
kernel  pc: 0x0000000140D4DF29 ucstkgentrace+ 0x339 (0x0000000000000001, 0x0000000000000001, 0x000000000435D320, 0x0000000000000001)
kernel  pc: 0x0000000140D4C21F ucbacktrace+ 0xbf (0x0000000000000014, 0x0000000000000001, 0x0000000000000001, 0x000000000000006E)
kernel  pc: 0x000000013FEF96A6 terminate_process+ 0x1896 (0x0000000000000000, 0x00000000FFFFFFFF, 0x0000000000000001, 0x000000000000006E)
kernel  pc: 0x0000000140A1218A hdl_default+ 0x3a (0x000000005267DA10, 0x000000000435D240, 0x0000000000000001, 0x000000000000006E)
kernel  pc: 0x000000014094357F s_handle+ 0xf3f (0x000000005267DA10, 0x000000000435D3D8, 0x00000000000000C1, 0x0000000140B53930)
kernel  pc: 0x0000000140A12519 ex_raise+ 0x379 (0x000000000000006E, 0x0000000000000044, 0x0000000000000014, 0x0000000000000001)
kernel  pc: 0x000000014092593C s_estmt_loopend+ 0x21c (0x0000000000000001, 0x000000000435D530, 0x0000000000000000, 0x0000000000000001)
kernel  pc: 0x0000000140938013 s_execute+ 0x7733 (0x000000005267DA10, 0x000000005267DA10, 0x0000000000000001, 0x0000000000000001)
kernel  pc: 0x0000000140946482 sequencer+ 0x1c82 (0x0000000080051000, 0x000000005267DA10, 0x000000000435DF20, 0x0000000080051000)
kernel  pc: 0x000000014092F1A3 execproc+ 0xd03 (0x00000000000000E0, 0x000000000435E2E0, 0x000000000435E2E0, 0x0000000000000000)
kernel  pc: 0x0000000140934B41 s_execute+ 0x4261 (0x000000005267DA10, 0x000000005267DA10, 0x0000000000000001, 0x0000000000000001)
kernel  pc: 0x0000000140946482 sequencer+ 0x1c82 (0x0000000080052000, 0x000000005267DA10, 0x0000000000001007, 0x0000000000000001)
kernel  pc: 0x0000000140AB1A4E internal_sql+ 0x78e (0x000000005F03F010, 0x00000000A32E74C8, 0x0000000000000000, 0x000000005F041129)
kernel  pc: 0x0000000140AB2DAF rec__tune_bufpools+ 0x67f (0x0000000000000000, 0x000000005267DA10, 0x000000005267DA10, 0x00000015405524C3)
kernel  pc: 0x0000000140AC766F rec_run_parallel_recovery+ 0x1af (0x000000008081E000, 0x000000000435F168, 0x0000000000000000, 0x0000000000000001)
kernel  pc: 0x0000000140AC810F dorecover+ 0x18f (0x0000000000000001, 0x000000004CA05380, 0x0000000027F45600, 0x00000000203193C0)
kernel  pc: 0x000000013FEFFD09 ds__recoverdbs+ 0x1439 (0x000000005267DA10, 0x0000000000000000, 0x0000000000000000, 0x0000000020041650)
kernel  pc: 0x000000013FEF5349 dsinit+ 0x23f9 (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)
kernel  pc: 0x0000000140D7BBC1 kpntwrapper+ 0x51 (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)
kernel  pc: 0x0000000076AF8FED CreateFiberEx+ 0x27d (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)
kernel  end of stack trace, spid 1, kpid 196610, suid 0
server  Recovery cannot restore the size for '128K' pool in 'default data cache'. The original pool size is 0K. To fix this, run sp_poolconfig to configure the pool size back to the original value.

HTH

Tilman

this is a known issue , workaround and solution is described in SAP note 1807887.

SYB: Recovery of ASE fails with error 11068 and stack trace

0 View this answer in context
Not what you were looking for? View more on this topic or Ask a question