Interesting, if convoluted, idea there, Scott. Thanks for offering it.
Aside that we don't use mirroring in our environment, I don't see why that's better than onspaces -cl.
I do believe (corrections invited) that the contents of an SBspace are inherently transitory; only while the data is being used (like ER or geographic searches) and when those functions have completed, whatever is left can be collected by that onspaces command. If that is correct, I don't see how mirroring
Basically, I need to see if there is still something using the SBspace when I want to drop it, before trying and getting an error.
------------------------------
+-----------------------------------------------------------+
| I am pleased to report that I had no problems today. |
| I had only issues, opportunities, challenges and valuable |
| learning experiences. |
+------------------------------------------ Jacob S --------+
------------------------------
Original Message:
Sent: 08/28/26 11:25 AM
From: mark collins
Subject: Is that SBspace really empty?
If the new raw device is currently available, could you use mirroring to move without worrying about emptying the space? Use onspaces to add mirroring to the existing chunk, with the mirror being place on the new raw device. Once the mirrors have synced, use the SQL Admin API command 'execute function task("modify chunk swap_mirror",<chunk number>)' or 'execute function task("modify space swap_mirrors","<space name>")' to swap the primary and mirrored chunks, then disable mirroring to release the current raw device.
------------------------------
mark collins
------------------------------