So I’m wondering what do you do to get a grip on the SF DB - would love to hear from you what nifty little secrets you do to keep things running smoothly and in tune…
The current size of our SF DB is going to pass 100GB anytime soon.
What is your size of the SF DB, and how do you maintain it?
Do you keep letting it grow or do you drop stuff like branches or projects into an archive or something else maybe to keep the db from growing (too fast)
How many branches and projects do you keep track of in the SF DB and do you just delete them when it has reached a certain age or?
Do you have import/exports scripts for items ( i.e. projects or branches) that you’d like to share? Do you (re-)import the exports before doing an upgrade and then export it all again and drop the ‘archive overhead’ to make sure you can always ‘reload’ a situation as it was before?
How often do you run your statistics? Every new branche or every new project or everyday or three times a day or after every merge or maybe after every deployment? Or maybe you got some sort of performance triggers/measurements that will automagically execute performance enhancements like updating statistics
Best answer by Frank Wijnhout
I usually try to keep an SF under 30GB, but there is no golden rule here. The same goes for the number of branches. Most of the time I use a plan like this:
- I make as many branches as I need.
- When a branch is merged and the new trunk is live on production, I remove the branch.
- In general I keep the old trunk versions, but when my SF gets too large, sometimes I remove some versions.
- When I want to archive old versions or branches, I make a backup of the SF before removing versions.
- I update statistics every night, same for rebuild indexes. After removing or copying a version, sometimes I update statistics manually.
I never import or export versions.
Hope this helps?