Skip to main content
Nintex Community Menu Bar

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!


 

 

Production Database:
1- Database Must be in Full Mode Option.
2- This is trace of how transaction database grow rapidly.

Finally: we need straight forward best practice for this PROBLEM, and if it is not K2 thing,
we need the not K2 thing solution to solve The K2 PROBLEM.

 


  

As a Temporary solution, create schedule job backup transaction database log every one hour, and create another schedule to delete trn files every 5 hours or set time.

schedule job to create trn and another schedule to delete trn files

 


Reply