Skip to main content

The problem:
The K2 database log file grows fast and fills up the partition, causing other systems (that share the same SQL server) to stop working. We have this issue on our DEV environment.

 

Abstract description of our DEV environment:
We have separate servers/machines, one for the K2 server and another one for the SQL server.
Our setup, is a standalone K2 server (no farm/distributed environment).

 

While reading at the K2 forums, I've stumble some threads suggesting to shrink the log file.
Currently the K2 database Recovery model is Full (on DEV environment).
(1) What is the correct way/approach/solution to resolve the issue we are facing?
(2) If the K2 Server database Recovery model can be switched on Simple (permanently) on our DEV environment, will it be safe? Or the K2 system will misbehave?

(3) Deploying our solution on a production environment, how should we handle this?

For any non-prod environment, my opinion is that it is safe to switch to Simple recovery mode on the associated K2 database - that is the way I've been handling this issue.

@tbyrne777  I appreciate your reply. Though I would like to add a follow-up question.
While searching the K2 Documentation, haven't found any articles regarding this matter. Do I miss something?
Though it would be great for an article addressing this kind of questions.

Thank you in advance.

I don't think it is a "K2 thing" but a "SQL Server" thing - like any SQL Server, the DBA can decide whether Simple or Full backup modes are necessary. Being a K2 database doesn't really change the decision making process for the DBA

Handling this issue as a "SQL Server" thing, will simplify the solution.

Thank you for helping me!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings