Recreate cache.dat file to increase space on disk

Question

Question

Minu N · Aug 7, 2017

Hi,

I use cache 5.0 and access cache through OpenVMS.

The disk-space under a particular namespace has grown up in size due to cache.dat. How to recreate cache.dat to bring up more space back on disk?

Discussion (11)1

Log in or sign up to continue

Robert Cemper · Aug 8, 2017

definitely a good idea to run routine ^%GSIZE to find the big consumers and packing

directory: c:\intersystems\cache\mgr\user\ Page: 1 GLOBAL SIZE 08 Aug 2017 10:28 AM Global Blocks Bytes Used Packing Contig. -------- -------- --------------- ------- ------- CacheStd 1 140 2 % 0 CacheStdS 1 92 1 % 0 CacheStream 109 764.376 86 % 70 ERRORS 1 12 0 % 0 G1 1 72 1 % 0

3 0

John Murray · Aug 8, 2017

Doc for 5.0 is available at http://docs.intersystems.com/documentation/cache/cache5docs/

At the bottom of that page I found this:

Using the Caché GBLOCKCOPY Routine — This article describes the basics of running GBLOCKCOPY to copy globals.

The link is to a PDF. One of the use cases in the PDF is as follows:

Reclaim unused space in a database
If a large global is created then killed in a database, there may be a large excess of unused space in the database. This space can be removed by copying all the globals in the database to a new one, and then replacing the old database with the new database.

That's what I think you need to do. It sounds like you used GBLOCKCOPY to copy to a namespace in an existing database rather than to a fresh empty database.

Of course, you will need enough disk space to have the smaller new database alongside the big database until you have completed the copying.

1 0

John Murray · Aug 10, 2017

It's a very long time since I used GBLOCKCOPY on a Cache 5.0 system, but I think you may be able to simplify your steps.

1. Create a new temporary database via Configuration Manager. You probably don't need a new namespace as well.

2. Use GBLOCKCOPY to copy your old database contents into your new database.

3. Dismount your old database and your new one. Or just shut down Cache completely.

4. Rename your old database (the big one), e.g. to CACHE.oldDAT

5. Move the temporary database's CACHE.DAT file to where the old one was.

6. Mount your database (or start Cache).

7. Use Configuration Manager to delete the temporary database you defined in step 1.

8 Check everything is working.

9. Delete the renamed big database file you preserved in step 4.

10. Come back to DC, tell us how it went, and set the checkmark against one of the answers to show you have accepted it.

2 0

score 3 · Answer 1 · 2017-08-07T18:03:10-04:00

Wow. 5.0 is roughly 12..15 yrs. back.

Could be ^GBLOCKCOPY existed then already in NS %SYS.
It should be able to cover your needs and create a new smaller CACHE.DAT in a new directory.

score 0 · Answer 2 · 2017-08-07T19:20:47-04:00

Hi...

I tried the ^GBLOCKCOPY which seems to copy all the Globals from the particular database to other namespace.

The cache.dat under the existing namespace still has the same size.

Please let me know how to create a smaller cache.dat using the ^GBLOCKCOPY

Thanks!

score 1 · Answer 3 · 2017-08-08T04:25:36-04:00

Robert Cemper · Aug 8, 2017

thx.
so you confirmed to me that it was't just wishful thinking

1 0

score 0 · Answer 4 · 2017-08-09T12:40:49-04:00

Thanks. Pleas let me know if the following work plan is correct...

Create a new temporary namespace and database using Configuration Manager.
Do ^GBLOCKCOPY from %SYS namespace to copy all the globals to the newly created temporary database
DELETE cache.dat
Create new cache.dat file
Again do a ^GBLOCKCOPY to copy all globals from newly created temporary database to the old one
Delete the newly created namespace and database.

Also would a direct DELETE cache.dat work?

score 2 · Answer 5 · 2017-08-09T13:22:54-04:00

It's not yet time for GBLOCKCOPY.
In namespace %SYS you should find a routine ^GCOMPACT
(at least according to docs http://docs.intersystems.com/documentation/cache/cache5docs/PDFS/GMSM.pdf)

Based on the results of %GSIZE you now compact those globals with most blocks and lowest packing.
This generates free blocks that will be eliminated during GBLOCKCOPY.

Routine ^%FREECNT might help you to follow up your efforts
Purpose: Displays the total amount of disk space within a volume group and the amount of free space.

HTH

score 0 · Answer 6 · 2017-08-09T12:43:03-04:00

Hi... Thanks a lot... So I tried under mine and got the following overall packaging

TOTAL	Blocks	Bytes Used	Packing	Contig.
--------	--------	---------------	-------	-------
	689,704	1,320,275,180	23 %	28,554

So, would a ^GBLOCKCOPY return back space for me?

score 0 · Answer 7 · 2017-08-08T03:02:38-04:00

HI Minu

GBLOCKCOPY is used to create a smaller database, after some data is removed and leaves sparse space in the database. If your database is full, then copying it will not save space. Before anything else, you should check the size of your globals and remove any data that you do not need. GBLOCKCOPY should then reclaim some space for you

score 2 · Answer 8 · 2017-08-08T03:10:31-04:00

Why do you think that it may help you? Do you know how much data in your database?

As 5.0 is so old I even not remember how to check the actual size of data in the Database. But I think you can do the integrity check, and in this report, you will have this information in last rows.

And then if you will have less than 10-20% of free space, I think it will not be needed for you. And with this report, you can see how big all globals in this database, and if some useless globals may be unexpectedly exists or have unexpected size. If so, you should check your code, why it could happen and remove it, so you can increase free space, which can be used then for grown useful globals.

If you will have so much free space, which you want to free, you can use ^GBLOCKCOPY, to copy all or only useful globals to the new database.