How to Reduce Jet database size

[Khaled]

Hello,

I wounder if there is any way to reduce or compact the size of Jet database, we are using PlasticSCM for 5+ years now, and it is really great, but we are facing the issue with big database size.

I was trying to workaround this issue using either: archive command or distributing database files on more than one hard drive

1- Archive command

I read about the 'archive' command as the documentation says it is used to reduce the size of the database, so correct me if I am wrong what is the use of 'archive' command?

Here is the documentation about archiving

Quote

Why archiving revisions

In a production environment where there are third party compiled tools or programs, binaries, big documents and other kind of big files that rarely change and/or are rarely accessed, it can consume disk space and time when storing those revisions in the database and afterwards retrieving them from the database.

To help minimize the impact mentioned above, you can use the archive command, which allows the administrator to set up a separate disk device, such as a tape, a USB pen drive, an external disk, a CD-ROM, DVD, or a specific disk space area, and store those big revisions there, so that they do not take space in the database. Thus, every time that a user needs to access those revisions, Plastic SCM will search for them in the external storage area, and retrieve that information to the user.

But I could not find any help regarding 'compact' command for Jet database

2- Distributing database on multiple hard drive

Is there any way to specify hard drive per repository?
or maybe specify multiple hard drives then using some rules if the first drive is almost full the database will start using the secondary drive and so on
I also thought about using 'hardlink' (symlink) but I am not sure if that has a side effect on integrity or performance of Jet database

Related post:

Thanks,

 

 

[calbzam]

Hi,

As we commented, in the linked post (please check the details of the feature request), this is something we have in mind but at the moment I'm afraid there is not a good solution to trim the databases.

There's a workaround you can use, but it is not trivial: push the necessary branches to a new repo and start using the new repo with just the necessary branches.

Regards,

Carlos.

 

[Khaled]

Hello Carlos,

In that case what is the use of 'archive' command and what about Symlink and other suggestion in my post like specify path per repository?

Thanks

[calbzam]

Sorry I forgot to mention on the archive command: 

- I'm afraid there is not currently a way to repack the data to reduce the total Jet database size after archiving the content. So at the moment this feature is not useful reduce the actual size of the Jet databases (it could be helpful with MySQL databases, for instance).

- We internally did't run test with symlinks for the Jet databases.I would avoid it if possible. Even with that, I just run a fast test using a Windows junction for the Jet database and it seems to properly work.

Regards,

Carlos.

 

 

 

[Khaled]

Thank you for your quick reply,

19 minutes ago, calbzam said:

So at the moment this feature is not useful reduce the actual size of the Jet databases (it could be helpful with MySQL databases, for instance).

I suggest to update the documentation to reflect this point, it will helpful for other users who have the same issue and trying to find a way to reduce the size

22 minutes ago, calbzam said:

- We internally did't run test with symlinks for the Jet databases.I would avoid it if possible. Even with that, I just run a fast test using a Windows junction for the Jet database and it seems to properly work.

Thank you very much for the clarification.

I will add my voice to the feature request in that case and hope it'll become available soon.

Regards,
Khaled

[Meceka]

Hello. All 3 of our development devices have a fast SSD and a HDD (or slow SSD) and we always used symlink to move databases to secondary drives to save space in primary drive.

We didn't have any problem because of that. But of course I would prefer a native support.