Solved

Maintaining the SF DB

  • 11 August 2020
  • 5 replies
  • 183 views
Ricky
Rank
Userlevel 3
Badge +8

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

Thanks, Ricky

 

 

 

 

 

 

 

icon

Best answer by Frank Wijnhout 27 August 2020, 12:29

View original

5 replies

Moller Toma
Rank
Userlevel 6
Badge +11

Hi @Ricky 

You had created your question as a conversation. Because of this, your question was not between the questions. That is why it took so long before you got a response. We will respond to your question as soon as possible. 

We have changed the subject from conversation to question. 

Community Manager
Ricky
Rank
Userlevel 3
Badge +8

Hi @Moller Toma that is excellent! - but I’m still (also) very much interested in how the (other) members (besides the ThinkWisers) cope with this :-)

Moller Toma
Rank
Userlevel 6
Badge +11

To be honest, it rarely happens that someone creates a question as a conversation. 

When you create a topic you specify what kind of topic it is. But the topic ‘question’ is the default, this means that a user has to change it to conversation or idea. 

Community Manager
R
Rank
Userlevel 5
Badge +15

Well, to give you some insights as non Thinkwiser;

As for database size I cannot really tell, it's very customer and product dependent. I’m more worried about the size of the end product databases. For us there is no need to clean up the database (not yet), by removing old data. We’d also prefer not to do so, because you're deleting history.

However, the performance part is I think more interesting. We run on a daily base statistics (dbo.tsf_optimize), but to be honest I don't know if it really helps, some actions remain slow (merging, generating).

Frank Wijnhout
Rank

Hi Ricky,

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:

  1. I make as many branches as I need.
  2. When a branch is merged and the new trunk is live on production, I remove the branch.
  3. In general I keep the old trunk versions, but when my SF gets too large, sometimes I remove some versions.
  4. When I want to archive old versions or branches, I make a backup of the SF before removing versions.
  5. 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?

Frank

Reply


Terms & ConditionsCookie settings