Impact of extended storage on DISKGROUP in ASM

During this period, when purchasing storage and communicating with many storage vendors, we mentioned that it supports dynamic expansion of storage capacity. For example, if the original storage capacity is 5 TB, A lun will be allocated. Later, due to business needs, it will need to be extended to 1.

During this period, when purchasing storage and communicating with many storage vendors, we mentioned that it supports dynamic expansion of storage capacity. For example, if the original storage capacity is 5 TB, A lun will be allocated. Later, due to business needs, it will need to be extended to 1.

During this period, when purchasing storage and communicating with many storage vendors, we mentioned that it supports dynamic expansion of storage capacity. For example, if the original storage capacity is 5 TB, A lun will be allocated. Later, due to business needs, it will need to be extended to 10 TB. The subsequent five TB capacity can be directly added to the original storage, the original lun size is changed to 10 TB.

The stored lun exists as a disk in the operating system. This is equivalent to an increase in the disk size. According to the vendor's technical explanation, if a file system is used, in the file system, you can see that the disk corresponding to the lun is larger, but the size of the previously used file partition remains unchanged. If you need to use the new space, you can expand the existing partitions, it is not hard to understand or divide new partitions into U.S. servers.

I am confused that, because I am using oracle 11g rac + asm, and I am not using asmlib, I am directly attaching a bare disk to asm. If a lun becomes larger, can asm identify the new space? Will the change in disk space affect the use of the original asm? The manufacturer failed to give an answer to this question, so he decided to perform a test in the virtual machine environment to verify it.

The test environment is under vmware 8. A dual-host RAC environment has been set up, using 11gr2 + asm + OEL6.1. In this environment, I have created three disk groups, ocr, data, and fra. ocr uses a hard disk, data, and fra, both of which are 2 GB Virtual Disks. The experiment logic is to manually scale the 2g disk corresponding to fra to 2.5 GB, and then check whether the disk group capacity in diskgroup has changed.

The test procedure is as follows:

1. Check that the disk/dev/sdd size of the fra disk group on the host is 2 GB.

2. view the size of each disk group in asmca as follows:

3. log on to the grid user using sqlplus/as sysdba and check the disk size:
Run select name, type, total_mb, free_mb, required_assist_free_mb, usable_file_mb from v $ asm_diskgroup;

4. Stop two VM nodes

5. Use commands under vmware to expand the Virtual Disk corresponding to fra

A) Go to the vmware installation directory.
Cd "C: \ Program Files (x86) \ VMware Workstation"

B) Execute the management command:
C: \ Program Files (x86) \ VMware Workstation> vmware-vdiskmanager.exe-x 2.5 GB "F: \ vhd \ erpsharedisk \ fra. vmdk"

C) after completing this operation, you can see that the disk file corresponding to fra is extended to 2.5 GB.

6. Start the two rac nodes, Hong Kong server, and use fdisk-l to view the corresponding disk size.

7. Use asmca to view the disk group. It is found that all the disk groups cannot be viewed in asmca. The cause of this problem is not found yet.

8. Use sqlplus to log on to the query view and check that the disk space does not change.

9. in this case, it is suspected that the disk group needs to be re-mounted to identify the new capacity, and the Hong Kong server is rented. Therefore, try to re-mount the FRA disk group. the operation on the disk group cannot be performed on the asmca interface, so the command line is used instead.

10. Run the command to unmount the FRA disk group first. A permission error is reported.

11. Later, it was found that in the 11G environment, asm needs to use sysasm users to manage the disk groups. Instead, sysasm users can perform operations to remount the FRA disk group.

After the disk is remounted, it is found that the disk capacity does not change to the actual size as we imagined. Therefore, in this environment, if you directly expand the Lun size to expand the available space of the database, it is best to increase the available capacity of the database on the database storage end, allocate the new capacity to a new lun. on the server, mount the new lun as a disk to the disk that needs to be expanded, in this way, we can easily and efficiently expand the database capacity in the ASM environment.

This article is from the "Tian Zhi technical blog" blog. For more information, contact the author!