Can customers rebuild an Exadata machine with the latest stack versions?

Question

There’s a possibility that we’ll be purchase two new Exadata machines (X3) in the near future. I'd be getting very excited if I wasn't already entirely swamped :)
If it happens, we’ll be asking Oracle to install the latest and greatest of the software stack when they arrive on-site with our new toys. Currently, this means:
<i>OEL: 5.7 (with latest kernel)
ESS: 11.2.3.2.1 (write-back FC, mmmmm!)
RDBMS/GI: 11.2.0.3.17</i>
Our current Production database is on a V2 machine and has the following versions of the stack:
<i>OEL 5.5
ESS 11.2.2.3.2
RDBMS/GI 11.2.0.2 BP7</i>
We are hoping, once the dust settles, that we can re-purpose our existing V2 machine as a Development environment. However, in order for that to be of any use, we need the software stack to match what will be running in Production on the X3s.
As far as I understand, the upgrade path is as follows (as per 888828.1)
<i>Upgrade the O/S to OEL 5.7 and the latest kernel on storage cells and comp nodes
Upgrade the firmware on the IB switch to 1.3.3-2 (which we already have)
Upgrade the Exadata Storage Server on the storage cells and comp nodes to 11.2.3.2.1
Install the 11.2.0.3.17 GI and RDBMS binaries
Upgrade ASM from 11.2.0.2 to 11.2.0.3.17
Install the 11.2.0.3.17 RDBMS binaries
Make/move/restore/copy Development onto the newly-upgraded V2 machine.</i>
I’m wondering whether it’s better for us to upgrade the V2 machine from our current versions of the stack to the latest or whether it’s better to attempt a rebuild?
As a customer, are we able to rebuild the stack ourselves with the new software or do we have to have Oracle come in and go through their installation process (we are putting a different version of the stack on than we presently have)?
Mark

Answer 1

frits hoogland wrote:
I don't understand the answers.
A V2 Exadata system (and up, X2, X3) is full supported up to the newest Exadata software releases, so you just can upgrade. Of course you need to check with MOS 888828.1 what path to take (not all software might be upgradable to the latest release in one go). Need need to puzzle, just upgrade.I'm fairly sure that we would be able to upgrade - in fact, when we weren't entertaining a hardware upgrade earlier in the year, I had planned out a upgrade path from our current versions to what was the current stack before the FlashCache became write-able.
We didn't have much of a choice at this point because the V2 was planned to be our Production environment for the foreseeable. Our upgrade was possible, but would have been relatively cumbersome as we would have had to upgrade the O/S, the ESS on cells/nodes, the GI and then the RDBMS in chunks to satisfy the various pre-requisites.
My question was whether it was possible/better/cleaner to simply rebuild the whole box with the latest software stack instead of upgrading now that the V2 environment is likely to be designated for Development if we get the new hardware and there isn't the associated pressure of it being a Production box.
>
If you want to change the space ratio between DATA and RECO, the easy path is to delete all the databases, remove the data and reco diskgroups, remove the grid disks on the cells, and create them again, and create the diskgroups on top of it. This also can be done online by dropping the griddisks per cell/storage server in ASM, recreating them with different sizes, and get them in ASM again.I believe that Tycho said he had to choose between upgrading the stack AND change the space ratio between his diskgroups OR just rebuild the system from scratch: and he chose to rebuild.