FAQ about storage capacity for ApsaraDB for RDS-ApsaraDB RDS(RDS)-阿里云帮助中心

Storage capacity expansion

You can directly expand storage capacity. If your instance's host has insufficient storage, the system automatically provisions a new primary/standby instance on a host with sufficient storage and synchronizes data from your original instance.

For information about how to expand storage capacity and whether the expansion causes transient connections, see the following topics:

Expansion billing

After you expand an ApsaraDB for RDS instance, your billing changes. For more information, see Billing details about configuration change.

Troubleshoot sudden storage increase

Go to the Instances page. In the top navigation bar, select a region, and then click the ID of the target instance.
In the navigation pane on the left, click Monitoring and Alerts to view the main file types that are using storage space and their change trends. Check the disk space line chart. This chart displays the trends of five metrics over time: Total Disk Space Used, Data Space Used, Log Space Used, Temporary File Space Used, and System File Space Used. Use this information to identify what is causing the sudden increase in storage usage.

Free up storage space

For specific instructions, see the following topics:

Disk usage in a new database

When a database is initialized, the system creates system tables to store accounts, permissions, and other metadata. In addition, database logs (such as redo and undo logs) also consume disk space.

MySQL space usage after data import

Different database storage engines handle data differently. For example, compression capabilities and indexes on specific columns can affect the amount of storage space used.

Instance storage and backup storage

On the Basic Information page of your instance in the ApsaraDB for RDS console, the Storage Capacity parameter in the Usage Statistics section indicates the instance's storage space, excluding backup storage. To view your backup storage usage, see Backup size.

Handling locked instances

When an ApsaraDB for RDS instance runs out of storage capacity, it is automatically locked and enters the "Locking" state. However, this state change may be delayed due to the inspection mechanism.

Once an ApsaraDB for RDS instance is locked, you cannot write data to it. We recommend that you configure alerts to avoid having your instance locked due to insufficient storage capacity. You can also enable automatic storage expansion, which increases the storage capacity when it runs low.

For an ApsaraDB RDS for MySQL instance, see Configure automatic storage expansion.

For ApsaraDB RDS for MySQL instances, you can also enable automatic fragment reclamation to reclaim space occupied by fragments.
For an ApsaraDB RDS for PostgreSQL instance, see Configure automatic storage expansion.
For an ApsaraDB RDS for SQL Server instance, see Configure automatic storage expansion.

Solution:

If your instance enters the Locking state, see How to handle a full instance storage capacity.

SQL Server disk space after deletion

After you run a DELETE operation to delete a large amount of data in ApsaraDB RDS for SQL Server, the disk space may not decrease. This behavior is due to the design of the database management system and its logging mechanisms:

Transaction log recording: To ensure data consistency and recoverability, SQL Server records all data operations, including DELETE, in the transaction log. As a result, even after data is marked for deletion, the corresponding transaction log entries still occupy disk space, which can cause disk usage to remain the same or even increase.
Data pages are not released: In SQL Server, data is stored in data pages. When you delete data, SQL Server does not immediately reclaim these pages. Instead, they are marked as reusable. This design improves the efficiency of subsequent insert operations and avoids frequent physical disk reorganizations. Therefore, although the data is logically deleted, the physical space is not immediately returned to the operating system.
Table and index fragments: Deleting data can leave empty spaces, or fragments, in tables and indexes. This leads to storage fragmentation, but the database still considers this space as allocated.

To reclaim this space, we recommend the following:

Shrink the database or file groups: Use the DBCC SHRINKDATABASE or DBCC SHRINKFILE command to reclaim unused space and reduce the size of data files.

Important
This process can be time-consuming, and frequent shrinking can negatively impact performance. For more details, see Solutions for automatic locking of SQL Server instances due to full storage or Insufficient storage space for ApsaraDB RDS for SQL Server.
Rebuild indexes: After you delete a large amount of data, indexes can become fragmented. Rebuilding indexes reorganizes data pages, reclaims space, and improves query performance.
Back up the transaction log: For databases that use the full recovery model, regularly backing up the transaction log truncates the log and frees up its space. For more details, see Manage logs and Introduction to the simple recovery model.
Consider using TRUNCATE TABLE: In appropriate scenarios, TRUNCATE TABLE is more efficient than DELETE. It releases data pages directly without generating extensive logs, making it much faster.

Important
The TRUNCATE operation is irreversible and does not support a WHERE clause.

In summary, to effectively reduce disk usage, you must choose the right combination of methods based on your specific workload.

Backup quota after storage expansion

Yes. The free quota on backup storage for an ApsaraDB for RDS instance depends on its storage capacity. For instances that use cloud disks, the free quota on backup storage is 200% of the instance's storage capacity. For instances that use Premium Local SSD, the free quota is 50% of the instance's storage capacity. The free quota is measured in GB and is always rounded up.