Autoshrink and manual shrinking of data files

 

1: When autoshrink is enabled, If you manually contract the data file, an error will be prompted, because there is a background thread shrinking the data file, is there a way to kill this background thread?

 

The answer is no. You can only close the database option autoshrink and wait until the thread ends! For more information, see [here]

 

2: Can I contract a data file?

 

Let's take a look at the disadvantages of shrinking data files: For details, see [here]. The following is an excerpt:

A: When the file is compressed, the large page number in the data file will be moved to the beginning of the file, which will produce a lot of file IO operations and CPU usage.

 

C: After the contraction, a large number of fragments will be generated. Therefore, index reconstruction and restructuring are required to eliminate index fragmentation. The conclusion is that the data file should not be shrunk!

 

However, in some cases, the data file is to be shrunk, because there is no other choice:

A: disk space alarms are constantly triggered due to monitoring requirements. The reason is that the data file or initial capacity is too large, or the data file continues to increase due to business growth, and large table data is subsequently deleted or migrated, can shrink data files,

The database has been running services, and it is impossible to create a new file group. to migrate existing data, we can only contract the data files in the early hours of the morning. This will minimize the impact on the business!

 

B: If you create a new data file group and migrate table data, the workload will be too heavy, and authorization involving operations will increase the workload!

 

B: Create a new job during the final contraction. It will contract after, and each contraction will be 100 mb. This will not produce a long page lock, and will not have a big impact on daily operations!