Generally you do not want to go much higher than 70 to 80% utilization.
This is because the system may need the free space for system operations, temporary storage and to allow for spikes in storage that may occur when processing heavy workloads, such as temporary work space or for transient files, journal receivers, system logs and spool entries (QSPL as opposed to SAP's own spooling).
Certain systems functions, such as dedicated physical file reorganizations, have specific minimum requirements with respect to the need for free space.
At this point, you are at 75% utilization which puts you right in the middle of the range where you really want to examine what is going on.
Usually when you hit 90% or above you will start to get messages from the OS about high storage.
You can free up space in several ways. Only keep journal receivers for as long as you need them. Once they are detached and saved offline (tape/remote jounals etc) they can be deleted. You need to have a strategy in place for this, however. Our shop archives a full save on a weekly basis, and all journal receivers up to that point (with a small margin retained for visibility) are deleted.
In addition, we use Datamirror's High Availability product which scrapes the journal receivers to mirror the production system on a hot backup. The receivers must remain on the system until they are replicated (this is also true for other High Availability products). This is usually near real-time, but it can be an issue if you do not manage it properly. (Given our weekly archive strategy, this is not an overriding consideration for us, but it may be important for those with a different strategy.)
SAP uses the reuse deleted records feature of DB2, but sometimes excessive amounts of deleted records build up due to spikes, especially in files like VBDATA and related files, or after purging older transaction history or deleting old clients. You can periodically reorganize physical files to reclaim deleted space.
You can also use RCLSTG (Reclaim storage) and RCLSPLSTG (Reclaim Spool Storage) to reclaim some temporary space.
However, RCLSTG should only be used if there is a specific need for it, as outlined in IBM's technical note: <a href="http://www-912.ibm.com/s_dir/slkbase.NSF/0/9373303619fb4b89862565c2007d4bcf?OpenDocument&ExpandSection=1">Overview of the RCLSTG Command</a>
Periodic IPLs will also reclaim space, including spool space as if RCLSPLSTG had been run..
If you have other libraries on your system, you can also see if they are being managed wisely using the same ideas as you would use for your SAP libraries.
Within SAP itself there are tools to manage tables that are within the scope of you various SIDs and clients. When SAP purges data, however, it only does a soft delete via DB2 SQL, and a physical file reorg as noted above may be required to reclaim space at the OS level.
As the previous respondent noted, you should keep track of the growth of your system and then take whatever steps are necessary to bring storage down or increase storage.
You may also want to consider your storage strategy. We had been using full mirroring, and we were able to increase our effective storage by going to RAID-5, and therefore put off the need to buy more disk for a time.
Good luck.
Brian
Message was edited by:
Brian Sammond
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.