Jump to content
Khaled

How to Reduce Jet database size

Recommended Posts

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.

How archive command works

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,

 

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...