Shrinking clones

CorvetteFan

Is it ok to run shrink operations on very large clones (tens of GBs)? i need the free space the production db holds, but i don't need it in the image/clones. So i don't want to shrink the source db, just want to shrink the clone itself/themselves.

When i do run a shrink, it tends to mess up the clone. The clone remains available but i get storage related errors when expanding Tables in object manager, for example.

TheMaskedData

@CorvetteFan are your clones 10s of GBs right away after provisioning? 

If the clones have been around for a while and grown then I'd recommend source controlling any changes, deploying and then refreshing your Clone Image and Clones anew so you're back to a couple dozen MB.

If the Clones bloat to 10s of GBs right after provisioning it could be that there were some pending changes being made as the image was finalized, and these transactions are being replayed on the clone as it's created (in which case you can add a wait command during Image modifications so everything is complete when the image is created), or it could be that the Clones are being upgraded so you might benefit from an image that is a more compatible SQL Server version - guidance here on the Clones: The files behind the Clone have grown to be very large  - SQL Clone 5 - Product Documentation (red-gate.com)

Shrinking, or doing anything to a Clone will just cause more differences because they're not full copies of the DB and therefore won't respond to normal space saving techniques (i.e. you can truncate all tables in a clone and it'll actually get bigger because it is storing the differences)

There should be (if you're using SQL Clone 4.4+) the option to also compact your image during creation: Image compaction - SQL Clone 5 - Product Documentation (red-gate.com)

donna1205

Enjoy the fast-paced action of Run 3 unblocked game, a popular endless running game that takes you through challenging space tunnels with gravity-defying gameplay.