If it's in use, you should check whether it's mounted, loop-device'd, still cryptsetup-opened, active in LVM, part of a RAID set, etc. and then stop all these things. Also quit any running processes that might be using the device (partitioners, installers, ddrescue, badblocks, ...). The list of possibilities as to what could be using a device, is nearly endless.
fuser are able to catch some of them...
# example only, none of these are accurate
vgchange -a n
cat /proc/mdstat | grep -C 2 sda2
mdadm --stop /dev/md??
Or, if you want to deliberately ignore the issue, you could explicitely put a loop device on top and then format the loop device. You should reboot afterwards to see if whatever was still using the device, would corrupt your LUKS header because of it (if you can't open it after reboot, that's what happened). Without rebooting, you might be able to copy data happily on the device but it's all gone later...
# dangerous hack
cryptsetup luksFormat $(losetup --find --show /dev/sda2) -s 512 -h sha512 ...
Also triple-check that you're actually working with the correct device in the first place. In your post you somehow mentioned both sda1 and sda2 so which is it?
This is not part of your issue, but
aes-xts-plain is deprecated in favour of
aes-xts-plain64. It's also the default cipher so you don't have to specify it at all. (see
cryptsetup --help or luksDump afterwards.)