Data Hit Ratio shows zero percent in RZ20/ST04

[former_member211576]

Hi experts,

Data Hit Ratio shows zero percent in RZ20/ST04 although performance counters

are not missing. Please see attachment.

[xymanuel · Accepted solution]

Hi Dennis,

i searched for my old SAP call. This was my behavior.

(empty values).

Go to SE38 and add breakpoint to row 80 (see screenshot above) step over the C Call and check the sy-subrc, like in my screenshots described.

Class: SAPLSMSSDBCOLL Function: MSS_COLL_LIST und Class:

CL_SQL_RESULT_SET Method: Next() und der Kernelcall C_DB_FUNCTION

If you get only sy-subrc 4, then you have this problem.

Now please try to run the stored procedure directly in SQL Server Management studio, and check if you get returnvalues.

USE SID
execute sid.sap_p_snapshot 'sid','4','0'

Kind regards

Manuel

[former_member211576 · Accepted solution]

Hi Manuel,

  I don't know why but it is fixed after restart. Maybe because I fixed the missing index and it will be fixed after Windows reboot.

[xymanuel · Accepted solution]

Hi Dennis,

keep in mind that the problem at our system ouccoured again after approx 30 days uptime.

I think this is an rounding problem of some counters if the values are to big.

Have a look at the counters after a longer uptime if the problem persits.

Regards Manuel

[former_member211576 · Accepted solution]

Hi Manuel Herr,

  SAP replied, FYI.

The data is collected by SAP Stored

Procedure sap_memusage which is using the following command:

select database_id,

db_name(database_id),

N' ',N' ',

count(*),

sum(row_count),

sum(free_space_in_bytes)

allocation_unit_id

from sys.dm_os_buffer_descriptors

where HAS_DBACCESS(db_name(database_id)) = 1 and

database_id <> 32767

group by database_id, allocation_unit_id

order by database_id

For the sum aggregate function SQL Server uses an integer by default

while, depending on the system, this might not be sufficient and the

statement will therefore fail with an SQL Error 8115. I adjusted the

SP to include a cast to bigint:

select database_id,

db_name(database_id),

N' ',N' ',

count(*),

sum(row_count),

sum(cast(free_space_in_bytes as bigint)),

allocation_unit_id

from sys.dm_os_buffer_descriptors

where HAS_DBACCESS(db_name(database_id)) = 1 and

database_id <> 32767

group by database_id, allocation_unit_id

order by database_id

and the monitor shows correct data again. We will include this fix with

future support packages while in TCP I have fixed it now and no further

steps are required.

[xymanuel · Accepted solution]

Problem is solved by SAP in Note:

1763425 - Arithmetischer Überlauf in Prozedur sap_memusage

[xymanuel]

Hi Dennis,

i had the same problem about 3 month ago.

The effect occoured after approx. 1month uptime and was gone, after i rebooted the DB server.

But after 1month the problem came up again.

My problem was, that i was not able to show this problem to SAP, because we reboot every month (planned maintainance). I opened a call, but closed it without a solution.

I also debugged into the ABAP code to the line, where the SAP Kernel calls the Stored procedure to get the performance data. In the abap code, i only get performancevalues from the SP after every ~5th call. So i first thought, the SP has a problem. But after this, i run the SP directly in the SQL Management Studio. Here, i always get values.

So the data must get lost between the SQL Server and the native C call in abap.

-> Kernel or DB Libary problem.

Try to refresh the view again and again, and maybe you will get values. In my opinion, there must be a problem with huge numers that cant be interpreted, because the problem only occours after some uptime. (I see, you have 1TB RAM and 9,6TB DB..)

I must say, i lost view of the problem after we implemented 7.20 EXT Kernel. I never saw this effect again. I recommend to switch to 7.20 EXT.

We are currently running DB:

Kernel

*edit*

I think you normaly see the performancecounters!

Otherwise Ravi may be right

Regards

Manuel

[former_member211576]

Hi Ravi & Manual,

  Thanks.

Hi Ravi,

  The first two jobs are scheduled but I check SM36 -> standard jobs and there is no jobs like you mention in the last 4 items. Although the note 1300273 mention a lot of SAP_COLLECTOR_PERFORM_*, I still don't know if it is necessary.

Hi Manuel,

  I run 10 refreshes but the problem persists. Also, I am using kernel 7.20EXT right now and my problem happenes recently(After I implement EHP5 and use kernel 7.20EXT.)

[former_member211576]

Hi Ravi & Manual,

  Thanks.

Hi Ravi,

  The first two jobs are scheduled but I check SM36 -> standard jobs and there is no jobs like you mention in the last 4 items. Although the note 1300273 mention a lot of SAP_COLLECTOR_PERFORM_*, I still don't know if it is necessary.

Hi Manuel,

  I run 10 refreshes but the problem persists. Also, I am using kernel 7.20EXT right now and my problem happenes recently(After I implement EHP5 and use kernel 7.20EXT.)

[former_member211576]

Hi,

  By the way, the history data(DBACOCKPIT->History->DB Collector History) is correct.

[former_member209924]

Do you have the following SAP standard jobs running?

SAP_COLLECTOR_FOR_PERFMONITOR

SAP_CCMS_MONI_BATCH_DP

SAP_COLLECTOR_PERFMON_RSORACOL

SAP_COLLECTOR_PERFMON_RSSTAT98

SAP_COLLECTOR_PERFMON_SLMRBO02

SAP_COLLECTOR_PERFMON_SWNCCOLL

Ravi