|
ecognizing and Resolving nl_read_defer,
nl_write_defer, and invalid tds length Errors
The Problem:
For releases prior to 11.0.3.x, SQL Server sometimes crashes
with a stack trace on multiprocessor boxes due to corruption of the
winsock stack. The pivotal error messages in the stack trace are
nl__read_defer, nl__write_defer, and invalid tds length.
Below is a typical stack trace for this type of
error:
<date> <time> kernel pc: <hex>
kisignal: unknown signal (5).
<date> <time> kernel pc: <hex>
ucbacktrace + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
kiexception + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
nast_writepost + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
nl__write_defer + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
kadodeferred + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
kpstartsched + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
servermain + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
scm_main + <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
\177libctl_NULL_THUNK_DATA + <hex>
(<hex>, <hex>, <hex>, <hex>,
<hex>).
<date> <time> kernel pc: <hex> (<hex>,
<hex>, <hex>, <hex>, <hex>).
<date> <time> kernel pc: <hex>
end of stack trace, kernel service process: kpid
<int>).
<date> <time> kernel pc: <hex>
engine 0, os pid <int> exited
<date> <time> kernel pc: <hex>
kisignal: unknown signal (5).
<date> <time> kernel pc: <hex>
kisignal: unknown signal (5).
<date> <time> kernel pc: <hex>
kisignal: unknown signal (5).
Another error message that can be in the mix is invalid tds
length:
<date> <time> kernel pc: <hex>
nast-readpost:invalid tds link (8224),socket 4
listener 0
Note that network problems can also result in nl__write_defer,
nl__read_defer, and invalid tds length errors, but the stack trace
will be dramatically different. Some cases have been corrected by
using fully qualified IPX/SPX connection entries in SQL.INI, thus
resolving port conflicts. If the customer is running Adaptive
Server Enterprise 11.5.x, or SQL Server 11.0.3 or later, look for a
network problem as the likely cause of nl__write_defer,
nl__read_defer, or invalid tds length errors.
The Resolution:
Upgrade to Adaptive Server Enterprise 11.5.x, or SQL Server
11.0.3 or later. Bugs 125610, 129211 and 131195, which together
comprise the problem, were corrected starting with SQL Server
11.0.3. (These corrections were also backported to a release of
11.0.2.2 as a stopgap prior to the release of 11.0.3, but it is
recommended that customers upgrade to ASE 11.5.x or SQL Server
11.0.3.x instead).
Workaround:
Sometimes customers do not have an immediate window of
opportunity to upgrade. To minimize the probability of a crash in
the meantime, set max online engines to 1 so that only one
processor is used, and stop using any other software on the server
that makes use of the winsock stack (e.g. the SAP service, FTP
server software).
To set max online engines from Sybase (SQL) Central, connect to
the server and use the File > Configure
menu option, or right click on the server icon and select
Properties from the context menu.
To set max online engies from isql, issue the command
command sp_configure "max online engines", 1 .
This is a static configuration option, so you will have to
shutdown and restart the server before the change takes
effect.
위에 sql server 11.0.3.x 구문이 나오는데 이게 sybase sql
server를 말하는건가요??
ase 11.5.x 가 sybase sql server 아닌가요??...
헷갈려요...
nl_write_error가 무슨 버젼에서 버그가 일어 난다는걸 적은
내용인같은데요..
위 내용좀 정리 해주세요... sybase도 잘모르고 있는 상태에서 영어
해석 할려니 힘드네요...
부탁드려요~
|
