DBIF_RSQL_SQL_ERROR (SQL error 0 or 11)

In SQL Server 2000 systems, Short Dumps of the type DBIF_RSQL_SQL_ERROR are observed, which are also evidenced in ST22. SQL error 0 and/or SQL error 11 are indicated by the details of the Short Dump messages. The errors get raised on various objects (tables and/or views). 

Additionally indications of network library errors 10054 or 10055 may also get recorded by the OS Application Event Log. But in the Windows Application Log, there will be no additional error messages.

The batch jobs or the interactive sessions can get terminated due to these disconnection indications. 

The disconnection between the server and a client are signified by SQL Server 0 and SQL Server 11 errors. There are at least 4 sources of these errors, which are known to us. They are as follows:

1. Network failures are the most common source of these errors apart from operating system. These networking components include Network Interface Cards (NICs), routers, cables, switches, their configuration, their drivers, the firmware, or the bios. Most of the disconnection issues which have been resolved so far have been done by altering one of the above mentioned networking components.

2. In some of the instances, incomplete installations of SQL Server Service Packs generate these indications. This generally happens when a service pack is applied to the data server but does not get properly applied to all application servers (in order to update the client side, database specific components). This can be verified by checking that the dates of the two files (sqloledb.dll and dbnetlib.dll) are same on all application servers and the database server. 

3. In several other cases, the configuration of SQL Server 2000 has also been the source of these errors. For eliminating this type of issue, both "priority boost" and "set working set size" should be set to 0 and the targeted memory of the SQL Server should be configured properly. At last the "network packet size" should be returned to the default settings of 4096 of its SQL Server, and the default packet_size setting of 8192 should be overridden and set to 4096 by the SAP application servers. This reduces the memory consumptions which occur due to other connections. 

4. The other instances of these errors have been tracked down to 3rd party utility executions, specifically the backup utilities. However these situations can also be caused by other resource consuming utilities. 

The other instances of these errors still remain to be unresolved.

To resolve this do as following:

For the proper configuration inside SQL Server:

The following script should be executed inside Query Analyzer, which is being logged on as sa:

EXEC sp_configure 'show advanced options', 1
EXEC sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'set working set size', 0
EXEC sp_configure 'priority boost', 0
EXEC sp_configure 'network packet size', 4096
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure
GO

• The entire R/3 system should be shutdown.
• The SQL Server Service should then be stopped and restarted.
• The profile parameter packet_size (per OSS Note 28667) should be adjusted and the Application Server network packet size should be set to 4096 for each AS which connects to the SQL Server.
• Finally the the R/3 system. should be restarted.

The following steps need to be performed the errors continue to persist:

1. The latest Service Pack for SQL Server should be applied, in the current scenarios Service Pack 4 is the latest one for SQL Server 2000. A later hotfix to address a SP4 problem should also be downloaded if the user is using AWE.

2. The additional work processes that do not look to be performing any productive work (via SM51) should be removed. This helps in making more memory resources free.

3. The value for "mem to leave" should be increased, as described in 884809 and further explained in 885827 to 512.

4. Windows Perfmon should be run, and all counters should be logged in the Memory object, Process object, Processor object, and the Physical Disk object. This should be done during the occurrence of any one of these events. This log file should be properly labeled and zipped. The following 3 Memory object counters should be noted, because they often point to problems with software components which have memory leaks:

Pool Paged Bytes
Pool Nonpaged Bytes
System Driver Resident Bytes

5. The undocumented SQL Server Trace Flags 3689 and 4029 should be set in order to enhance the error messages in the SQL Server ERRORLOG which span at the time of an event. This is done in the SQL Server Enterprise Manager by right-clicking the Server name, choosing properties, going into the "Startup Parameters" button on the General tab. The following two parameters should also be added (including the dashes):

-T3689
-T4029

The R/3 and SQL Server system needs to be restarted once the above mentioned step gets done. Once another error event occurs, these trace flags should be removed. There should be enhanced error information in the SQL Server ERRORLOG which spans the time. The SQL Server ERRORLOG which contains this information should be zipped up.

6. All the 3rd party utilities that are being used should be declared. It has been shown that both Backup and Antivirus utilities can cause system resource depletions. It is important to track whether any of them are in a high phase of activity during the occurrence of the error. A command prompt should be opened and "net start" should be executed. The output should be redirected to a file.

e.g.

C:>net start >> C:netstart.out
The output file should also be zipped.

7. The information for each of these items should be included as attachments to the OSS issue when the next errors appear (i.e. the output files mentioned in the previous points: 3, 4, and 5). This ensures that the connection is open, and the information in the Secure Logon area is updated and accurate. Then the issue should be forwarded to the BC-DB-MSS queue.