Advanced Search


No announcement yet.

SQL - Shrinking Production Databases

  • Filter
  • Time
  • Show
Clear All
new posts

  • SQL - Shrinking Production Databases

    Sometimes you run out of SQL storage space and it is tempting and the easy option to shrink your databases. While this practice on a small scale, addresses your immediate needs, it is something that eventually becomes a zero sum game. Shrinking a data file causes index fragmentation, takes up resources, and ultimately leads to performance issues. It should not be part of your regular maintenance exercise as you get into a vicious shrink/grow cycle.

    If you shrink and you have log back up part of your maintenance plan, this information is backed up and thus takes up unnecessary space in your backup drive. As you process data or users perform additional work in your review case, the database will auto-grow which leads you back to the shrinking again. My advice: allocate the proper amount of storage based on usage, add more storage when needed, and STOP shrinking.
    Last edited by Ipro_Sharmarke; 07-29-2017, 04:57 PM.

  • #3
    What are your 5 best tips for maintaining SQL, environments that just run eCap and/or eclipse? thanks, L


    • #4
      Hi Luke,

      We don't have a "Top 5 SQL tips" for running eCapture/Eclipse per se, however we provide a SQL best practices document available for download on This is listed under Resources > ADD Workflow > Best Practice & Implementation documents. This lists our recommendations for install, configuration, data/log file management, maintenance, backup/restore and alerts monitoring.