Forum Discussion

Azsxdcfvgb's avatar
Azsxdcfvgb
Regular Visitor
2 days ago

SQL Database capacity consumption too high !

I'm copying a few massive tables from an On-prem SQL Server Database into a Fabric SQL Database. Tables are around 1.6TB, 1.3TB and 1.1TB, and there are more smaller tables as well. 
The Database has reached maximum allocated size and I've stopped copying two days ago. One of the batches abruplty stopped during load.
It is still consuming a LOT of CUs !
I'm aware of how even after the copy data activity has stopped there's prolonged capacity consumption (apparently for indexing, statistics etc) but this is a slightly higher percentage of base capacity than what I've seen before and its been going on for much longer than before.

Could this be because of the size of the item (~3416 GB) ?

Also, is there any way to suppress this without having to wait until it dies out, whenever that it. I cannot apply the per-database max vCore setting (as proposed in this solution) because of the size. 







General Question
sql database

1 Reply

  • ShivekMaharaj's avatar
    ShivekMaharaj
    Icon for Community Champion rankCommunity Champion
    2 days ago

    Hi Azsxdcfvgb​,

    I would not expect the SQL Database to continue consuming significant compute for two days simply because the copy activity stopped.

    Microsoft’s current SQL Database in Fabric billing documentation says compute scales down after inactivity and is released after about 15 minutes with no workload activity.

    So if you are still seeing substantial SQL Usage CUs, I would first confirm what is actually running.

    The Capacity Metrics app reports SQL Usage for both user-generated and system-generated SQL queries, modifications and data-processing operations.

    I would check:

    1. Capacity Metrics -> filter to the SQL Database item and inspect SQL Usage.
    2. Drill into the high-CU timepoints and identify which operation/query is still consuming capacity.
    3. In the database, check active requests using sys.dm_exec_requests and look for long-running or blocked sessions.
    4. Check the Performance Dashboard for expensive queries and activity.
    5. Check whether automatic index management or another maintenance/tuning operation is still active.


    Microsoft documents SQL Database monitoring specifically for this type of investigation.

    The ~3.4 TB size can certainly make index creation, statistics work or other maintenance expensive, but the size alone should not continuously consume compute when the database is genuinely idle.

    Regarding the max-vCore setting, your screenshot is also expected.

    Microsoft currently ties the vCore limit to maximum storage:

    2 vCores -> 512 GB
4 vCores -> 756 GB
32 vCores -> 4 TB

    So a ~3.4 TB database cannot be reduced to the smaller vCore limits without first reducing the allocated database size.

    I would therefore identify the active SQL Usage before trying to suppress it. If Capacity Metrics shows high SQL Usage but you cannot find any active request or system operation explaining it, I would capture the database ID, timestamps and Capacity Metrics evidence and raise a Fabric support case.

    AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.