Minimum 7.00 Basis sp level for 7.20 kernel?

[Matt_Fraser]

Hello all,

I am in the QA phase of updating the kernel in our systems to 7.20, based upon the looming

maintenance expiration of 7.0x kernels in about two months (Note 1629598: SAP Kernel 720 will replace older kernel versions).  This is going very well on our ECC 6.04 system on NetWeaver/Basis 7.01 -- no problems there.  However, for our SRM 5.0 system on Basis 7.00, not so much.  According to Note 1633731 (Usage of the 7.20 Downward-Compatible Kernel)http://service.sap.com/sap/support/notes/1633731, the 7.20 kernel should be fully compatible for Basis 7.00 "with any ABAP support package" (direct quote).  I have been following the directions in Note 1636252 (Installing a 7.20 kernel in SAP Web AS 7.00/7.01/7.10/7.11) carefully.

The problem I'm running into on the Basis 7.00 system but not on the Basis 7.01 system is that, after applying the new kernel, the work processes have issues connecting to the database.  They do eventually connect, but only after several iterations of errors and timeouts.  This makes the system rather slow.  It shows up also in SE10 when releasing a transport request, STMS when importing a request, and SPAM when importing a support package:  The step "tp connecting to database" just seems to hang for 1-2 minutes, then eventually it connects and things proceed.  This is a well-known issue with some older kernel releases and patches, but I am using pretty much the latest and greatest 7.20 kernel.  Furthermore, I am using exactly the same kernel (disp+work.exe, pl222), r3trans (pl221), tp (pl219), and dbmssslib.dll (pl218) on both systems, the one that works well and the one that doesn't.  Both systems are going against the same release and patch level of SQL Server 2005 sp4 cu3 (09.00.5292.00) with the same SQLNCLI.DLL driver release (09.00.5000).  Both are using SQL Native Client ODBC drivers and lpc (local) connections to databases that are on the same box with the SAP installation.

In the work process developer trace I see the following:

M Fri Jun 29 11:31:17 2012
M  ThInit: running on host SNOCFBD2
M  calling db_connect ...
B  Loading DB library 'F:\usr\sap\B01\SYS\exe\run\dbmssslib.dll' ...
B  Library 'F:\usr\sap\B01\SYS\exe\run\dbmssslib.dll' loaded
B  Version of 'F:\usr\sap\B01\SYS\exe\run\dbmssslib.dll' is "720.00", patchlevel (0.218)
C  Callback functions for dynamic profile parameter registered
C  Thread ID:4224
C  Thank You for using the SLODBC-interface
C  Using dynamic link library 'F:\usr\sap\B01\SYS\exe\run\dbmssslib.dll'
C  dbmssslib.dll patch info
C    SAP patchlevel  0
C    SAP patchno  218
C    Last MSSQL DBSL patchlevel 0
C    Last MSSQL DBSL patchno         218
C    Last MSSQL DBSL patchcomment Stored procedure delivers no rows in EXEC SQL or ADBC (1330085)
C  ODBC Driver chosen: SQL Native Client native
C  lpc:(local) connection used on SNOCFBD2
C
C Fri Jun 29 11:31:32 2012
C  ERROR: -1 in function SQLConnectWithRetry (SQLConnectWithRetry) [line 2351]
C  (2) [08001] [Microsoft][SQL Native Client]Shared Memory Provider: Could not open a connection to SQL Server [2].
C  native_db_err 2 severity 0 errclass set to DBSL_EC_RESTART
C  sl_glob.dbsl_ca.errclass set to DBSL_EC_RESTART
C  ERROR: -1 in function SQLConnectWithRetry (SQLConnectWithRetry) [line 2351]
C  (0) [HYT00] [Microsoft][SQL Native Client]Login timeout expired
C  ERROR: -1 in function SQLConnectWithRetry (SQLConnectWithRetry) [line 2351]
C  (2) [08001] [Microsoft][SQL Native Client]An error has occurred while establishing a connection to the server. When connecting to

The set of three ERRORs is repeated two more times, and then finally I get:

C  Driver: SQLNCLI.DLL Driver release: 09.00.5000
C  GetDbRelease: 09.00.5292.00
C  GetDbRelease: Got DB release numbers (9,0,5292,0)
B  Connection 0 opened (DBSL handle 0)
M  ThInit: db_connect o.k.

This doesn't happen on the system with Basis 7.01, only with Bais 7.00.  As I said, other than the Basis release, all other things are the same between the two systems.

I should point out that this is with Basis support pack level 7.00.25.  I am putting sp26 (as part of SRM 5.0 sp stack 20) into my DEV system right now, in a somewhat forlorn hope that the higher sp level will resolve the error.  This action is based upon noticing (late) that kernel 7.20 is offered with SRM 5.0 sp stack 20 but not with stack 19.  From this I've concluded that perhaps there is an undocumented minimum Basis support pack for the new kernel.  So far, sp26 doesn't seem to be helping, but perhaps after SGEN completes and I can restart the system I'll notice some different behavior.

Anyone else run into this?

Best regards,

Matt

[former_member189725 · Accepted solution]

I believe this is not related to Basis release 700, it has more to do with the database connection settings of SQL Native client. Please check with any other Basis release 700 system by upgrading the kernel to 720  if that issue persists which ideally should not .

Please check this tread and see if it helps you with any clue .

http://blogs.msdn.com/b/sql_protocols/archive/2005/10/22/sql-server-2005-connectivity-issue-troubles...

Regards

Ratnajit

[Matt_Fraser · Accepted solution]

In fact, just about an hour ago I resolved the problem.  For reasons not entirely clear, all my 7.00 systems did not have Shared Memory enabled as a connection protocol for the SQL client; only TCP/IP and Named Pipes were enabled.  All my 7.01 systems did have it enabled.  With the old kernel, this wasn't a problem, as I believe the database interface defaulted to wanting to connect via TCP/IP anyway.  With the 7.20 kernel, for a local database it switches to wanting to try Shared Memory first (as it's a little more efficient when no network is involved), but with it disabled it tries three times, waiting 20 seconds for a timeout each time, before falling back to TCP/IP and connecting successfully.  This is why a connection that was perfect with the 7.00 kernel became horrendously slow with the 7.20 kernel.  Once I realized that Shared Memory wasn't actually enabled it was a quick and easy fix.

With the 7.01 systems it was enabled, and my only theory about why these were different is that those ones were actually upgraded via EHPI to NetWeaver Enhancement Pack 1 a while back, and the upgrade process must have made the SQL Server configuration switch behind the scenes.

[Former Member · Accepted solution]

Hello,

Thanks for this feedback. I had the same issue during a system copy:

R3ta.exe: START OF LOG: Wed Jul 25 10:03:52 2012
R3ta.exe -o Split/CDCLS.WHR -t CDCLS%2 -check_utf8 -f Split/CDCLS.STR -l R3ta_CDCLS.log 
][SQL Native Client]Shared Memory Provider: Could not open a connection to SQL Server [2]. 
(rc = 256)
R3ta.exe: END OF LOG: Wed Jul 25 10:05:24 2012

Blog from Microsoft is confirming this (Message 7) :

http://blogs.msdn.com/b/sql_protocols/archive/2005/10/22/sql-server-2005-connectivity-issue-troubles...

Activating Shared Memory provider helps.

regards

Antoine Bonnefoy