In almost all cases the TSM DB survives an abrupt hardware power off. So I assume (!!!) it will also survive a restore from snaps. Including all log filesystems of course!
But as @RecoveryOne
already stated, this is highly experimental and noone from IBM will help you when you do it this way.
Right, but that abrupt poweroff would likely also affect more than just the DB, it would affect any storage volumes. So, we we are just talking about what would happen if just the DB was restored from hardware based snapshots, what of all the new storage volumes or changes that occurred to said volumes. Now you have volumes and a database out of sync. Where the abrupt poweroff everything is (for lack of a better term) in sync.
Having tested first hand what an alt_disk_upgrade looks like with the /home/tsminst1 on the rootvg, then cloned to hdisk2 while the dsmserv process was running, it wasn't pretty. AIX upgraded fine to the alt_disk, but since /home/tsminst1 was 'changing' during the alt_disk operations, then rebooted from alt disk, db2/dsmserv didn't like all the 'old' data in the alt_root_vg of hdisk2 upon boot. I'd imagine you'd run into a very similar situation. Sure, one could have then halted dsmserv, then run a syncvg -l operation for the hd1 logical volume (or custom logical volume if you have one for /home/tsminst1) and that may have worked. I didn't have time to fully test that however.
That said, try things out in a non-prod environment! Sometimes that is really the best way to learn! Some examples that a non-prod even if not even close to like for like that helped me:
Proved that the SAN infrastructure between my TSM server and storage array wasn't upto snuff.
Proved that the SAN infrastructure between my TSM server / storage array/ tape drives also wasn't up to snuff.
Proved that the Cisco Etherchannel config my NA team originally had in play, was only running at I think 2G instead of the theorized 4G. Going from memory we had 6's so load balancing was 2G with backup of 1G. Think this doc explains it all! https://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html
- OLD setup by the way.
And well, so much more.