Reason to size liveCache filesystems 2x RAM?

[Former Member]

Hi,

I am sizing liveCache database for future rollouts of existing system. (liveCache 7.7.04, SCM 5.1, Unix platform)

In the liveCache installation guide, the recommendation is to size the unix sapdata filesystems to be 2x the size of RAM.

SAP SCM 5.1 Standalone Engine SAP liveCache Technology 7.7: UNIX Document version: 1.0 ‒ 08/31/2007

Page 11, section 3.3

File System Name Description Recommendation

/sapdb/<LC_NAME>/sapdata[1-n] Data Volumes 2 x RAM, minimum 3 GB

/sapdb/<LC_NAME>/saplog Log Volume 2 GB

What is reason for this recommendation? I assume it has something to do with the history data in datacache during system shutdown and not also the 1x RAM for KernelDumpFileName path, and > 1x RAM for backup directory because only the liveCache database, not the KernelDumpFileName or backup directories are in the sapdata* filesystems.

In these frugal economic times, we are requested to justify hardware expenditures. 2x RAM seems excessive for sapdata filesystems when the RAM is 200-350GB in addition to the 1x RAM KernelDumpFileName and >1x RAM backup space needed.

Also, I assume it means the total space of all sapdata filesystems is requested to be 2x RAM, and not each individual filesystem.

Is there more explanation, clarification or justification on the disk sizing for liveCache?

Thanks in advance,

Margaret

[lbreddemann]

Hello Margaret

> What is reason for this recommendation?

Plain and simple: it's necessary to have that amount of space to put data to.

>I assume it has something to do with the history data in datacache during system shutdown

?? Not totally sure what you mean by that.

However, liveCache implements what is calles a "consistent view" to it's objects.

This means that it needs to keep several versions of the same object in the data area at the same time.

Let's assume that your planning scenarios really use up the whole RAM for the liveCache, this alone does not allow to keep multiple versions.

Thus there need to be more space available in the data area.

Doubling the size of the RAM for the Data area (not for each single filesystem) has proven to be a good starting estimation.

> and not also the 1x RAM for KernelDumpFileName path, and > 1x RAM for backup directory because only the liveCache database, not the KernelDumpFileName or backup directories are in the sapdata* filesystems.

?? did not get that...

> In these frugal economic times, we are requested to justify hardware expenditures. 2x RAM seems excessive for sapdata filesystems when the RAM is 200-350GB in addition to the 1x RAM KernelDumpFileName and >1x RAM backup space needed.

No it isn't.

And, really, what does a TB harddisk space cost these days?

> Also, I assume it means the total space of all sapdata filesystems is requested to be 2x RAM, and not each individual filesystem.

You assume correclty.

> Is there more explanation, clarification or justification on the disk sizing for liveCache?

That's pretty much it.

You may of course start with less then recommended diskspace, but you might run into problems later on with it.

regards,

Lars

[Former Member]

Thanks Lars,

Ths consistent view or history data was what I was referring to in regards to the sizing. At least I can give the $$ holders a reason for this expense.

"and not also the 1x RAM for KernelDumpFileName path, and > 1x RAM for backup directory because only the liveCache database, not the KernelDumpFileName or backup directories are in the sapdata* filesystems.

?? did not get that..."

Yeah, that was a bit cryptic. What I meant was that in addition to the 2X RAM for sapdata filesystem/MaxDB data volumes is that we also need at least the equivalent of RAM in disk space for parameter KernelDumpFileName to write memory dump file (variable which usually points to /sapdb/data/wrk/SID) and of course, the backup directory if we are writing backups as a file and not to tape. There needs to be enough disk to write Logs, Backups, etc.

Hope that clears it up, and thanks for your explanation.