Im restricted with a few things which means running a rebalance is out of the questions so method of migration is
backup database
shutdown database
drop old DATADG
unpresent luns from os (will still be stamped with ASM and have data on them) (lets say I have 50 x 64gb luns)
Present new luns (6 x 512gb ), create new DATADG on new luns
restore database
I have a few other things I have to do, move FRA, tidy up some other things.

However If anything goes wrong, Im going to unpresent new luns, present old luns. should this just work? where are the dangers?

Im restricted with a few things which means running a rebalance is out of the questions so method of migration is
backup database
shutdown database
drop old DATADG
unpresent luns from os (will still be stamped with ASM and have data on them) (lets say I have 50 x 64gb luns)
Present new luns (6 x 512gb ), create new DATADG on new luns
restore database
I have a few other things I have to do, move FRA, tidy up some other things.

However If anything goes wrong, Im going to unpresent new luns, present old luns. should this just work? where are the dangers?

If you Drop DataDG this will make Luns of Diskgroup irrecoverable.

where are the dangers?

The whole process that you described above is DANGEROUS.

Just perfom this steps is safe and secure.
{message:id=10312787}

Did you have MoS Support? (if yes, just open a SR to Oracle assist you)

thanks levi, I have to do the migration in a maintenance window of around 40 hours max. data size = 3tb.
Rman Full backup = 8 hours.
Rman Restore = 6 hours. (tested)
I tested rebalance and even if I add new and drop old in the same rebalance statement with power 11 it took 25 hours. Window too small if something goes wrong. I also have 3-4 hours of other work (moving control, redo, undo, voting, testing RAC failover).

If I restore from full backup, I only need a window of 20 hours to do everything. Trying to think of possible risks, if for some reason the restore fails, then if I restore ASM to point of commencement, unpresent new ASM group, re-present the OLD ASM luns. then ASM should start. I just need a point in time snap of the ASM at the time I unpresented the old luns.

I'll put a big flag up to say, yes, its not ideal, rebalance is the way to go, but I just dont have the maintenance window to do the work and also build in rollback in case something goes wrong.

ASM rebalance requires zero downtime, so for most customers it really does not matter how long it takes to do the rebalance. Set the power level to a low number like 2 and let it run over a weekend. The backup / restore requires a very long full outage, if you do a cold backup.

Another idea is to create a new diskgroup with the new storage, and use "alter tablespace ... rename datafile" commands to move your datafiles to the new diskgroup. This requires you first take the tablespace offline, but this might be less downtime than doing a full backup and restore.

902835 wrote:
ASM rebalance requires zero downtime, so for most customers it really does not matter how long it takes to do the rebalance. Set the power level to a low number like 2 and let it run over a weekend. The backup / restore requires a very long full outage, if you do a cold backup.

And for sure is a method I have used many times in the past when adding storage or indeed moving small datafiles across storage. But also have encountered issues where it only fails right at the end. Admittedly this was bug related and shouldnt happen but if nothing happened that shouldnt then we'd never a recovery plan.

Another idea is to create a new diskgroup with the new storage, and use "alter tablespace ... rename datafile" commands to move your datafiles to the new diskgroup. This requires you first take the tablespace offline, but this might be less downtime than doing a full backup and restore.

doh, Im moving datafiles 15 years, why didnt I think of this. this is probably an infinitely more superior and safer method.

thanks levi, I have to do the migration in a maintenance window of around 40 hours max. data size = 3tb.
Rman Full backup = 8 hours.
Rman Restore = 6 hours. (tested)
I tested rebalance and even if I add new and drop old in the same rebalance statement with power 11 it took 25 hours.

I don't want to influence your decision since you already says which way to follow.

IMHO,
Backup to a Stage Location (TAPE or Whatever) and Restore from a Stage Location be more fast than ASM Extend Copy Block Level, something is wrong.

I have done tons of ASM Lun Migration on 11.2 release and I never faced bug (does not means that not exist).

If you concern is about ASM Rebalance, you can do that:

You don't need use backup/restore only create a copy of database on NEW diskgroup without use BACKUP/RESTORE.

IMHO,
Backup to a Stage Location (TAPE or Whatever) and Restore from a Stage Location be more fast than ASM Extend Copy Block Level, something is wrong.

Are you saying rman block restore should be quicker than an ASM copy or even an

rman {copy datafile x to y;
set new name for datafile x to y
switch datafile all;
}

I have done tons of ASM Lun Migration on 11.2 release and I never faced bug (does not means that not exist).

If you concern is about ASM Rebalance, you can do that:

search support for "asm rebalance", there are lots of bugs. I hit one with corruption, fixed since, there are many others though. If my maintenance window was bigger and my time to rebalance was shorter I would do the rebalance but the window is too tight

You don't need use backup/restore only create a copy of database on NEW diskgroup without use BACKUP/RESTORE.

Are you saying rman block restore should be quicker than an ASM copy or even an

rman {copy datafile x to y;
set new name for datafile x to y
switch datafile all;
}

This is not normal Backup/Restore operation. That is Backup Image and there is no Restore only Recovery.

I have done tons of ASM Lun Migration on 11.2 release and I never faced bug (does not means that not exist).

If you concern is about ASM Rebalance, you can do that:

search support for "asm rebalance", there are lots of bugs. I hit one with corruption, fixed since, there are many others though. If my maintenance window was bigger and my time to rebalance was shorter I would do the rebalance but the window is too tight

You are saying that you don't trust on "asm rebalance" and you are using ASM Feature. I don't get the point.
The most filesystem do "rebalance" stripping when necessary.
ASM automatically initiates a rebalance after storage configuration changes, such as when you add, drop, or resize disks, using ASM you will depend on that.

Please show me one MoS note with ASM rebalance Bug on 11.2.0.2 or above...

Please show me one MoS note with ASM rebalance Bug on 11.2.0.2 or above...

No, the bug I hit was several versions ago and Im not aware of any in 11.2 or higher (not that they do or dont exist, Im just not aware of any). But my argument is not that ASM is stable or that something is definitely going to happen to it, it is that the long chair of experience tells us things can go wrong, things can go bump in the night and to just prepare for it if they do. We prepare for the unknown. My window for recovery is too small if something happened during rebalance.
Its in a financial sector, the cost implications are too high to risk not being open after the maintenance window.

Please show me one MoS note with ASM rebalance Bug on 11.2.0.2 or above...

No, the bug I hit was several versions ago and Im not aware of any in 11.2 or higher (not that they do or dont exist, Im just not aware of any). But my argument is not that ASM is stable or that something is definitely going to happen to it, it is that the long chair of experience tells us things can go wrong, things can go bump in the night and to just prepare for it if they do. We prepare for the unknown. My window for recovery is too small if something happened during rebalance.
Its in a financial sector, the cost implications are too high to risk not being open after the maintenance window.

I understand your concern since I also have same precaution. As I recommend before just open a SR to Oracle assist you, that will minimize risk of some bug or another thing happens.

I use ASM all the time without issue. That does not mean other people won't run into problems, so I was poking around MOS looking for bugs related to ASM rebalancing. There were quite a few (390?), but if you limit your search to patchset 11.2.0.3 the list of bug documents drops down to 38. Most say "fixed in 11.2.0.3", but a few are still open. Of the open bug reports that I can see some are dependent on the hardware platform (a few for Exadata cell disks, one for Cisco, a few for servers running AIX, and so on). It seems if you apply patchset 11.2.0.3.4 you will only be subject to 1 or 2 open bugs related to ASM rebalancing, but honestly I am using 11.2.0.3 ASM daily and never hit one of those bugs.

902835 wrote:
I use ASM all the time without issue. That does not mean other people won't run into problems, so I was poking around MOS looking for bugs related to ASM rebalancing. There were quite a few (390?), but if you limit your search to patchset 11.2.0.3 the list of bug documents drops down to 38. Most say "fixed in 11.2.0.3", but a few are still open. Of the open bug reports that I can see some are dependent on the hardware platform (a few for Exadata cell disks, one for Cisco, a few for servers running AIX, and so on). It seems if you apply patchset 11.2.0.3.4 you will only be subject to 1 or 2 open bugs related to ASM rebalancing, but honestly I am using 11.2.0.3 ASM daily and never hit one of those bugs.

Im on 11.2.0.2, no chance of patching before this work.

See above though, I dont "think" Id hit any bugs with the rebalance. I think my chances of doing so are very very low as 11.2 onwards is quite stable. But I have to cater for the possibility that I will by building rollback time into the work and bullet proofing the rollback methods from whichever migration path I take.