Re: ASM adding disk with different sector size

  • From: John Thomas <jt2354@xxxxxxxxx>
  • To: Sandra Becker <sbecker6925@xxxxxxxxx>
  • Date: Fri, 15 Oct 2021 07:13:29 +0100

What Raj said, but in particular pay attention to your redo logs,
particularly if using Data Guard.

(It used to not be possible even to migrate to storage with a different
sector size, back in the V11 time-frame I think.)

Regards,

John Thomas


On Thu, 14 Oct 2021 at 22:30, Sandra Becker <sbecker6925@xxxxxxxxx> wrote:

Thanks everyone for your input.  Until it was mentioned, I didn't realize
I forgot to mention the OS and oracle versions.  The OS is RHEL 5.11 (I
know, it's old, but I can't get approval to upgrade yet) and the database
is EE 12.1.0.2.  I'm told the new storage will be Netapp.  Our storage team
was pushing us to just use NFS mounted disk instead of ASM.  I flatly
refused since this cluster is the development cluster before things go to
test and then production.  Our policy has always been develop on
"production-like" systems to mitigate issues due to differences in the
configurations.  We do not have Oracle support, so I can't open an SR with
them.  I did open a ticket with Rimini Street, our current support vendor,
and will keep them in the loop for what we plan to do.

I knew you couldn't mix sector sizes in the same disk group, but didn't
know if ASM would support two different disk groups with different sector
sizes for the same database.  I have no concern with getting everything on
the 4k sectors, just wondering what would be the best way to do it while
minimizing downtime.  It's not a production system, so downtime isn't as
big a concern, but some dev teams are just ramping up for a major critical
project that upper management is monitoring closely.

Thanks again,

Sandy

On Thu, Oct 14, 2021 at 3:48 AM Martin Klier - Performing Databases GmbH <
martin.klier@xxxxxxxxxxxxxxxxx> wrote:

Sandra,

on top of what Raj wrote - there can as well be dependencies coming from
the use of the disk group.

For example, Redo Block size is always directly derived from the disk's
LBA size. If you migrate to another one, you may run into another subset of
difficulties.

HTH
Martin

--
Martin Klier // Performing Databases GmbH
Managing Partner // Senior DB Consultant
Oracle ACE Director

martin.klier@xxxxxxxxxxxxxxxxx // https://www.performing-databases.com



------------------------------

*Von: *"Rajesh Aialavajjala" <r.aialavajjala@xxxxxxxxx>
*An: *sbecker6925@xxxxxxxxx
*CC: *"Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
*Gesendet: *Mittwoch, 13. Oktober 2021 02:16:28
*Betreff: *Re: ASM adding disk with different sector size

Sandra,
 To the best of my understanding - ASM does not permit mixed sector sizes
in a single disk group - so I presume that rules out the use of the
'removing the old disks and rebalance as we go'

You didn't include the version of grid infrastructure/ASM that your
environment is running ... but this was not allowed in 12c...

12c -->
https://docs.oracle.com/database/121/OSTMG/GUID-8B656725-D347-4166-8775-1070B6C4D580.htm#OSTMG10203

In 19c and higher - there's the concept of logical_sector_sizes and
physical_sector_sizes but I am unsure of how that would fit into your
migration scenario...


https://docs.oracle.com/en/database/oracle/oracle-database/21/ostmg/create-diskgroups.html#GUID-8B656725-D347-4166-8775-1070B6C4D580

Additions, comments, corrections welcome (and I will gladly defer to the
wiser folks in this group)

Thanks,

--Rajesh



On Tue, Oct 12, 2021 at 2:16 PM Sandra Becker <sbecker6925@xxxxxxxxx>
wrote:

We need to move some databases off of their current storage, which is
old and no longer supported.  The new disk will have a different sector
size.  Can we create a new diskgroup for the new storage and use it along
with the old storage?  If possible, can we do the balancing and then start
removing the old disks and rebalance as we go?  I'm not very familiar with
ASM, so would appreciate some guidance or pointing me to an appropriate
document.  I've been doing some google searches, but still not sure we can
move the databases in this manner.

Thank you,

--
Sandy B.




--
Sandy B.


Other related posts: