Oracle MVA

Tales from a Jack of all trades

Archive for the ‘VMWare’ Category

Shrinking thin provisioned ASM disks results in smaller diskgroup

with 5 comments

Just the other day I ran out of space on my laptop. That’s what you get with these “tiny” SSD’s nowadays. Anyway, when looking around where I had most data stored I found that an ASM disk in a VM was taking most of the space. This disk, as all my disks for VM’s, was thin provisioned. Usually I use some zero fill utillity overwrite the free space in a think provisioned disk so VirtualBox can shrink the disk. But this sounded risky to me for ASM, also those utilities need an ext filesystem.

Some googling learned me that I wasn’t the first one with this issue. Oracle actually supports a tool for this called ASRU: ASM Storage Reclamation Utility (ASMSRU must have been to long). So, easy comes easy does. Download the utility, fire it up ( ./ASRU -a sysasm DATA ) wait for some time and *presto* . 30 GB back of my 256 GB SSD. How cool is that!

Until about a week later I run into space issues in ASM in the VM I mentioned before. My ASM disk group was full. That sounded hilarious to me, since it was on a 40GB disk (checked it in VirtualBox and yes: still 40GB). Then I remembered ASRU.

Checking the v$asm_diskgroup showed something interesting:

SQL> SELECT name, total_mb, usable_file_mb FROM v$asm_diskgroup;

NAME       TOTAL_MB  USABLE_FILE_MB
--------- --------- ---------------
DATA          10090            1288

So, ASRU actually not only shrunk the disk, it also resided the disk group in ASM. Now how about that? I didn’t read any statement in the README file saying I had to resize my diskgroup after running ASRU….

SQL> ALTER DISKGROUP data RESIZE ALL;

Diskgroup altered.

SQL> SELECT name, total_mb, usable_file_mb FROM v$asm_diskgroup;

NAME       TOTAL_MB  USABLE_FILE_MB
--------- --------- ---------------
DATA          40954           32152

So, if you happen to use ASRU, don’t forget to resize your diskgroup or you will live in interesting times.

Hopes this helps.

Written by Jacco H. Landlust

January 13, 2013 at 3:16 pm

Posted in ASM, RDBMS, VirtualBox, VMWare

Why reboot when you could just scan your scsi-bus?

with one comment

Whenever I read install guides about Oracle and installations on VM-Ware I always see remarks telling you to reboot your system after you added a disk. This is not necessary.

While your virtual machine is running, click on edit hardware and add a disk. When using VMWare workstation you cannot choose which scsi bus to use. Either try all buss-es, or check the .vmx file. In my case, I called the newdisk newdisk.vmdk, which represents these lines in the vmx file:

scsi0:2.present = “TRUE”
scsi0:2.fileName = “newdisk.vmdk”
scsi0:2.redo = “”

By looking at the code, I can see that the disk has been added to scsi bus 0. Next I scan the bus:

[root@wls2 ~]# echo – – – >/sys/class/scsi_host/host0/scan

This command scans every channel, every target and every lun on the host0 device. When checking dmesg, I notice that the disk is present.

[root@wls2 ~]# dmesg
[..]
Vendor: VMware,   Model: VMware Virtual S  Rev: 1.0
Type:   Direct-Access                      ANSI SCSI revision: 02
target0:0:2: Beginning Domain Validation
target0:0:2: Domain Validation skipping write tests
target0:0:2: Ending Domain Validation
target0:0:2: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127)
SCSI device sdf: 16777216 512-byte hdwr sectors (8590 MB)
sdf: Write Protect is off
sdf: Mode Sense: 5d 00 00 00
sdf: cache data unavailable
sdf: assuming drive cache: write through
SCSI device sdf: 16777216 512-byte hdwr sectors (8590 MB)
sdf: Write Protect is off
sdf: Mode Sense: 5d 00 00 00
sdf: cache data unavailable
sdf: assuming drive cache: write through
sdf: unknown partition table
sd 0:0:2:0: Attached scsi disk sdf
sd 0:0:2:0: Attached scsi generic sg5 type 0

Now I can create a partition using fdisk and start using the disk without rebooting.

Written by Jacco H. Landlust

August 18, 2009 at 9:16 am

Posted in Linux, VMWare