Re: Slightly Urgent ASM Question - Cancel Rebalance operation
Date: Wed, 24 Apr 2013 12:47:18 -0700 (PDT)
Message-ID: <1366832838.46774.YahooMailNeo_at_web121605.mail.ne1.yahoo.com>
In that case you could as an 'alter diskgroup .... drop disk ...' operation should rebalance the extents across the remaining disks and you should be fine.
I obviously misread your intentions. :) David Fitzjarrell
From: "Christopher.Taylor2_at_parallon.net" <Christopher.Taylor2_at_parallon.net> To: Dave.Herring_at_acxiom.com; Mark.Bobak_at_proquest.com; oratune_at_yahoo.com Cc: oracle-l_at_freelists.org
Sent: Wednesday, April 24, 2013 1:38 PM
Subject: RE: Slightly Urgent ASM Question - Cancel Rebalance operation
It appears I should have clarified – I meant drop them from the disk group – not drop them from the system :)
I'm a bit concerned that the initial rebalance operation has to complete before an additional rebalance operation is attempted – do either of you know?
(I'm thinking along the lines of order of operations for disk groups – assuming there are some)
Chris
From:Herring Dave - dherri [mailto:Dave.Herring_at_acxiom.com]
Sent: Wednesday, April 24, 2013 2:34 PM
To: Bobak, Mark; Taylor Christopher - Nashville; oracle-l_at_freelists.org
Subject: RE: Slightly Urgent ASM Question - Cancel Rebalance operation
Chris,
I'd say no to removing those disks. If they show any space allocated to them in ASM then they've got AUMs on them and can't be removed.
And of course Mark and David F. have replied while I'm writing this, but sending anyway to show I'm not ignoring Chris. :-)
Dave Herring
DBA
Acxiom Corporation
EML dave.herring_at_acxiom.com
TEL +1 630.944.4762
3333 Finley, Downers Grove, IL 60515, U.S.A
www.acxiom.com
From:Bobak, Mark [mailto:Mark.Bobak_at_proquest.com]
Sent: Wednesday, April 24, 2013 2:22 PM
To: Christopher.Taylor2_at_parallon.net; oracle-l_at_freelists.org; Herring Dave - dherri
Subject: RE: Slightly Urgent ASM Question - Cancel Rebalance operation
Hi Chris,
Did you just add the new disks, or did you issue a single alter diskgroup command that specified an add and a drop?
What state are the disks in?
select group_number,disk_number,name,path,mount_status,header_status,mode_status,state from v$asm_disk;
If all you did was add new disks, then you should be able to just as easily drop them again, with no harm.
-Mark
PS Not directly related to your question, but all the disks in a given diskgroup should be the same size, or you can run into weird space allocation errors, where there’s free space in a DG, but it can’t be used, and you’ll get out of space errors with free space available.
From:Christopher.Taylor2_at_parallon.net [mailto:Christopher.Taylor2_at_parallon.net]
Sent: Wednesday, April 24, 2013 3:15 PM
To: oracle-l_at_freelists.org; Bobak, Mark; Dave.Herring_at_acxiom.com
Subject: Slightly Urgent ASM Question - Cancel Rebalance operation
We're in the process of migrating existing ASM Disk Groups to a new storage configuration (new disks (metavolumes), same array).
We've done this in DEV/QA and everything went fine.
Now, in Prod, I started the ARCHIVELOG diskgroup migration and discovered that the disks I was given aren't enough for the space I'm currently using.
So, the first thing I did was set the REBALANCE POWER for the operation to 0.
Now v$asm_operation shows no rows.
My Diskgroup in question now shows the below - what I need to know is: Can I now REMOVE the disks I started to add which are RAW112 through RAW117 until I get the right number of disks from storage, or am I in a weird/bad situation?
Thanks!!
DG_DATABASE_NAME_ARCHIVE_01
/dev/raw/raw112 DG_DATABASE_NAME_ARCHIVE_01_0001 69,044 2,326 3.37 /dev/raw/raw113 DG_DATABASE_NAME_ARCHIVE_01_0002 69,044 2,324 3.37 /dev/raw/raw114 DG_DATABASE_NAME_ARCHIVE_01_0003 69,044 2,326 3.37 /dev/raw/raw115 DG_DATABASE_NAME_ARCHIVE_01_0004 69,044 2,325 3.37 /dev/raw/raw116 DG_DATABASE_NAME_ARCHIVE_01_0005 69,044 2,326 3.37 /dev/raw/raw117 DG_DATABASE_NAME_ARCHIVE_01_0006 69,044 2,327 3.37 /dev/raw/raw70 DG_DATABASE_NAME_ARCHIVE_01_0050 138,097 71,422 51.72 /dev/raw/raw71 DG_DATABASE_NAME_ARCHIVE_01_0051 138,097 71,422 51.72 /dev/raw/raw72 DG_DATABASE_NAME_ARCHIVE_01_0052 138,097 71,412 51.71 /dev/raw/raw73 DG_DATABASE_NAME_ARCHIVE_01_0053 138,097 71,412 51.71 /dev/raw/raw79 DG_DATABASE_NAME_ARCHIVE_01_0054 138,097 71,832 52.02 /dev/raw/raw83 DG_DATABASE_NAME_ARCHIVE_01_0055 69,044 35,717 51.73 /dev/raw/raw84 DG_DATABASE_NAME_ARCHIVE_01_0056 69,044 35,733 51.75 /dev/raw/raw97 DG_DATABASE_NAME_ARCHIVE_01_0057 69,044 35,734 51.76
Chris Taylor
Oracle DBA
Parallon IT&S
The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged.
If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system.
Thank You.
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 24 2013 - 21:47:18 CEST