Most Urgent : Shrinking SPS2013 on-premise WSS logfiles on productions server RRS feed

  • Question

  • Dear All,

    we want to know solution on following:

    A.  we have to shrink windows search service log files on our sharepoint 2013 on-premise server,those have grown in GBs.

    B. can all these files be set to grow not more than a few MBs?

    C. if yes, how to shrink them?

    D. can these be set to not to grow in the SQL after the server is set for production & if yes, how?

    Pls treat this as most urgent , as, we have some more tasks to be carried out on this productions server, we which are pending due to excessive space consumption of these log files.

    warm regards,

    Ajit S. Govilkar


    Monday, July 7, 2014 10:26 AM


All replies

  • You can always shrink your SQL server log file and set the database to simple recovery so that log files dont grow more. but this will be a problem when you plan to recover database.

    1. Expand the Databases node and expand User Databases
    2. Right-click the database, and click Properties, which opens the Database Properties dialog box.
    3. In the Select a page pane, click Options.
    4. View the current recovery model in the Recovery model list box, which should be set to Full
    5. Click the dropdown arrow in the recovery model section and select the Simple recovery model
    6. Click OK.
    7. Right-click on the same database name and click Task-> Shrink-> Files 
    8. Use the File type drop-down menu and choose Log
    9. You can use the default setting of Release Unused Space or select Reorganize pages before releasing unused space, and you can specify the file size by supplying a value in the Shrink file to option.

               Note: the shrink may take some time depending on how large the file is and how much it has to shrink.

    1. After the shrink completes, change the recovery model back to Full by clicking the recovery model dropdown arrow and selecting the Full recovery model

    Keep it simple of you dont want to have log files

    If this helped you resolve your issue, please mark it Answered

    Monday, July 7, 2014 10:39 AM
  • B) Possibly. As a rule of thumb your log files are typically around 10-25% the size of your database files. These can vary heavily but they should almost always be smaller than your database files which are probably 'mdf' files.

    You do not want to cap the size of these files nor do you want to set the autogrowth value to something small. The best performance and least trouble is to find out how large they need to be during normal use and then make them slightly larger than that. Then set the autogrowth to a large number (100mb might be ok, I prefer 1GB).

    C) Shrinking is well documented elsewhere but you only do it to correct the file size after something has gone wrong. You cannot do it as a part of normal operation and if you did run it on a healthy database then you'll only make things worse.

    D) No. See B for more detail.

    How large is your mdf file and how large is your ldf file?

    Monday, July 7, 2014 10:56 AM
  • Are you referring to SharePoint ULS logs in your Point A. If yes, may you have a look in Central Admin-->Monitoring-->Configure diagnostic logging , etc...

    if not then, other suggestions are very valid.

    Naveed.DG MCITP, MCTS -SharePoint 2010 Administrator "Vote As Helpful" If it helps!!

    Monday, July 7, 2014 11:14 AM
  • hey Navid,

    thanks for the help..

    i m talking about wss content DB logfiles..


    Monday, July 7, 2014 11:48 AM
  • WSS_Content_984e2b2d131240afabe4e6b9de93cf6a :

                                         .ldf file is 11 GB

                                         .mdf file is 18 GB

    pls suggest..


    Monday, July 7, 2014 12:06 PM
  • That looks like you don't have a working backup schedule. If you think you do; check your job history as it seems to be broken.

    Once you've fixed the backup process, either by setting the database to simple recovery mode or by correcting the backup job, you can run a shrink command to reduce the ldf file size.

    Monday, July 7, 2014 12:09 PM
  • backup sometimes gives an error of space..which again requires extending space as this server resides onto a VM..


    Monday, July 7, 2014 12:13 PM
  • Then you need to fix that.

    In the mean time if you're really against a wall you can switch the recovery mode to simple (some might leave it as simple) then run the shrink as Inderjeet describes.

    Monday, July 7, 2014 12:16 PM
  • hey Alex,

    we were wondering,what could be the reason that sometimes it wont backup search services DB..

    really difficult to work the resolution out on this..


    Tuesday, July 8, 2014 1:18 PM
  • when it is failing, what error you get, at SQL & At sharepoint?

    Also when you run the backups, what is the status of crawl...running or idle? if they are running that might cause the problem.

    Please remember to mark your question as answered &Vote helpful,if this solves/helps your problem. ****************************************************************************************** Thanks -WS MCITP(SharePoint 2010, 2013) Blog:

    Tuesday, July 8, 2014 1:37 PM
  • Hey Waqas,

    thanks for the feed-back...

    do u mean, crawl needs to be stopped,while data backup from sharepoint CA were running?

    then what could be the aftereffects of stopping crawl?

    also, let us know if there is some way to correct/reconfigure WSS.


    Wednesday, July 9, 2014 10:45 AM
  • Hey Waqas,

    also want to know if the wss_content DBs can be shrunk without any hassle in future..


    Wednesday, July 9, 2014 12:16 PM
  • To fix the log file issue, probably. Just don't get into the habit of doing it regularly

    • Edited by Alex Brassington Wednesday, July 9, 2014 1:05 PM
    • Marked as answer by Lindali Sunday, July 20, 2014 9:38 AM
    Wednesday, July 9, 2014 1:03 PM