Database increase a lot

Question

Question

Augusto Estefan · Sep 1, 2021

#Red Hat Enterprise Linux (RHEL) #System Administration #Caché

Hello,

The database is increasing a lot (almost a 1TB) and getting bigger with no sense after migration, the use of the plataform did not increase after the migration so is strange for us this increase.

how can I check everything is ok in the database? for example any table getting bigger.

Before the migration the logs were like:

07/22/21-17:18:26:304 (19701) 0 Starting Expansion for database /opt/Intersystems/HS/HS_201521705/mgr/cachetemp/. 276 MB requested.

07/22/21-17:18:26:373 (19701) 0 Expansion completed for database /opt/Intersystems/HS/HS_201521705/mgr/cachetemp/. Expanded by 276 MB.

but after migration the expansions are:

09/01/21-17:51:44:363 (15731) 0 Starting Expansion for database /opt/Intersystems/HS/HS_201521705/mgr/REGINUS/. 1000 MB requested.

09/01/21-17:51:51:935 (15731) 0 Expansion completed for database /opt/Intersystems/HS/HS_201521705/mgr/REGINUS/. Expanded by 1000 MB.

09/01/21-17:54:04:632 (15723) 0 CACHE JOURNALING SYSTEM MESSAGE

Automatic journal file roll to: /opt/Intersystems/HS/HS_201521705/mgr/journal/MIRROR-MPIPROD-20210901.097

09/01/21-18:03:39:755 (15723) 0 CACHE JOURNALING SYSTEM MESSAGE

Automatic journal file roll to: /opt/Intersystems/HS/HS_201521705/mgr/journal/MIRROR-MPIPROD-20210901.098

09/01/21-18:12:36:931 (15723) 0 CACHE JOURNALING SYSTEM MESSAGE

Automatic journal file roll to: /opt/Intersystems/HS/HS_201521705/mgr/journal/MIRROR-MPIPROD-20210901.099

09/01/21-18:14:08:881 (15731) 0 Starting Expansion for database /opt/Intersystems/HS/HS_201521705/mgr/REGINUS/. 1000 MB requested.

09/01/21-18:14:15:630 (15731) 0 Expansion completed for database /opt/Intersystems/HS/HS_201521705/mgr/REGINUS/. Expanded by 1000 MB.

Any idea what might be happening?

Thanks!!

Product version: HealthShare 2016.2

$ZV: Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2016.2.1 (Build 806_0_17136U) Tue Mar 7 2017 12:32:06 EST [HealthShare Modules:Core:15.02.9912 + Linkage Engine:15.02.9912 + Patient Index:15.02.9912]

Discussion (7)1

Log in or sign up to continue

Alexander Pettitt · Sep 2, 2021

I don't know a way that you can do that.

You can run ^%GSIZE against a specific CACHE.DAT

0 0

score 0 · Answer 1 · 2021-09-01T18:24:32-04:00

Many things could be happening.

How do you cleanup journal files? Purge after so many backups? Are your backup working?

You could look in a journal file and see what global data is causing the expansion.

If you have the system management portal you can look at journal data there too.

You might need to go to the application vendor to tell what data a global holds.

score 0 · Answer 2 · 2021-09-01T18:27:14-04:00

My journal cleanup looks like this

How can I look on the system management portal the data you talk about?

right now im running a GZISE on a specific namespace (the one that is getting bigger) but takes a lot of time.

Thanks

score 0 · Answer 3 · 2021-09-01T18:34:12-04:00

Here is a link to the Cache document - https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal#GCDI_journal_view

score 0 · Answer 4 · 2021-09-01T19:30:37-04:00

Augusto Estefan · Sep 1, 2021

Another question, do you know if I can see the size of a global from portal manager?

Thanks

0 0

score 2 · Answer 5 · 2021-09-02T03:38:32-04:00

Go to System > Journals, choose any 1GB journal which was just created and press Profile.

Now recalculate by size and you'll see which globals created the most journal records.

score 1 · Answer 6 · 2021-09-03T05:26:02-04:00

Hi,

It would seem that your REGINUS database expansion size has been set to 1000, this can be checked via the SMP using System->Configuration->Local Databases and clicking on the relevant database link.

I would hazard a guess that your cachetemp database has an expansion size of 0 which is the system default hence why it is growing at a lesser rate.

If you run ^%GSIZE in the relevant namespaces then you will be able to see which globals are taking up so much space.

There is of course the possibility that you had work objects/globals being created that have since been deleted and therefore you could have a lot of empty space in your database. This can be resolved using both Database Compact and Truncate. These options can be found in the SMP under System->Databases and clicking on the relevant database link.