2 Replies Latest reply: Jul 3, 2014 5:30 PM by Kasey.Parker RSS

    Is there a way to create different diskgroups in exadata?

    user569151

      We have a need to have some other diskgroups other than +DATA and +RECO.

       

      How do we do that? Exadata version is x3.

       

      Thanks

        • 1. Re: Is there a way to create different diskgroups in exadata?
          Vivek12-Oracle

          Its possible.

          You can search it in Exadata Owner's Guide or check the link below:

           

          2.1 Configuring Storage

          • 2. Re: Is there a way to create different diskgroups in exadata?
            Kasey.Parker

            user569151 -

             

            As 1188454 states this can be done. I would first ask why is it you need to create additional disk groups than the data, reco and dbfs disk group created by default? I often see Exadata users question the default disk groups and want to add more or change the disk groups to follow what they've previously done on non-Exadata RAC/ASM environments. However, usually the data and reco disk groups are sufficient and allow for the best flexibility, growth and performance. One reason to create multiple disk groups could be for wanting to have different two different redundancy options for a data disk group - to have a prod database on high redundancy and a test database on normal redundancy for example; but there aren't a lot of needs to change it.

             

            To add disk groups you will need to also re-organize and add new grid disks. You should keep the grid disk prefix and corresponding disk group names equivalent. Keep in mind that all of the Exadata storage is allocated to the existing grid disks and disk groups - and this is needed to keep the necessary balanced configuration and maximize performance. So adding and resizing the grid disks and disk groups is not a trivial task if you already have running DB environments on the Exadata, and especially if you do not have sufficient free space in Data and Reco to allow dropping all the grid disks in a failgroup - because that would require removing data before doing the addition and resize of the grid disks. I've also encountered problems with resizing grid disks that end up forcing you to move data off the disks - even if you think you have enough space to aloo dropping an entire fail group.

             

            Be sure to accurately estimate the size of the disk groups - factoring in the redundancy, fail groups and reserving space to handle cell failure - as well as the anticipated growth of data on the disk groups. Because if you run out of space in a disk group you will need to either go through the process again of resizing all the grid disks and disk groups accordingly - or purchase an Exadata storage expansion or additional Exadata racks. This is one of the reasons why it is often best to stick with just the existing Data and Reco.

             

            To add new grid disks and disk groups and resize the others become very familiar with the information in and follow the steps given in the the "Resizing Storage Griddisks" section of Ch. 7 of the Exadata Machine Owner's guide as well as the information and examples in MOS Note: "Resizing Grid Disks in Exadata: Examples (Doc ID 1467056.1)". I also often like to refer to MOS note "How to Add Exadata Storage Servers Using 3 TB Disks to an Existing Database Machine (Doc ID 1476336.1)" when doing grid disk addition or resize operations. The use case may not match but many steps given in this note are helpful as is discusses adding new grid disks and even discusses creating a new disk group for occasions when you have cell disks of different sizes.

             

            Also, be sure you stay true to the Exadata best practices for the storage as documented in "Oracle Exadata Best Practices (Doc ID 757552.1)". For example, the total number of griddisks per storage server for a given prefix name (e.g: DATA) should match across all storage servers where the given prefix name exists. Also, to maximize performance you should have each grid disk prefix, and corresponding disk group, spread evenly across each storage cell. You'll also want to maintain the fail group integrity, separating fail groups by storage cell allowing the loss of cell without losing data.

             

            Hope that helps. Good luck!

             

            - Kasey