Upgrading the Oracle Database Appliance to Version 2.3.0.0.0
As you may have guessed, applying patches on the Oracle Database Appliance can be a little bit different from your standard Oracle environment. Oracle releases a software version that covers all aspects of the ODA - firmware, operating system, and Oracle software stack (grid infrastructure, rdbms). Versions are numbered like this (image courtesy MOS note #1397680.1:
The ODA was initially released with version 2.1.0.0.0, and has seen several releases over the last year:
| Patch | Features |
|---|---|
| 2.1.0.3.0 | CPU bugfix, 11.2.0.2.5 GI PSU5 |
| 2.1.0.3.1 | OAK software updates |
| 2.2.0.0.0 | 11.2.0.3 GI/RDBMS, OEL 5.8, UEK kernel |
| 2.3.0.0.0 | July 2012 PSU for 11.2.0.2/11.2.0.3, firmware upgrades, multiple database home support |
In this post, we'll discuss upgrading an ODA running RAC or RAC one node to version 2.3.0.0.0. Note that before going to 2.3, users must upgrade to 2.2 first. This is because the 2.3 patch upgrade does not include some of the files used for the OEL 5.8 upgrade, among other things.
Inside the Oracle Database Appliance – Part 2
In part 1 of this series, we took a look inside the ODA to see what the OS was doing. Here, we'll dig in a little further to the disk and storage architecture with regard to the hardware and ASM.
There have been a lot of questions about the storage layout of the shared disks. We'll start at the lowest level and make our way to the disks as we move down the ladder. First, there are 2 dual-ported LSI SAS controllers in each of the system controllers (SCs). They are each connected to a SAS expander that is located on the system board. Each of these SAS expanders connect to 12 of the hard disks on the front of the ODA. The disks are dual-ported SAS, so that each disk is connected to an expander on each of the SCs. Below is a diagram of the SAS connectivity on the ODA (Note: all diagrams are collected from public ODA documentation, as well as various ODA-related support notes available on My Oracle Support).
From this, you can see the relationship between the SAS controllers, SAS expanders, and SAS drives on the front end. If you look at the columns of disks, the first 2 columns are serviced by one expander, while the third and fourth columns are services by the other expander. What the diagram refers to as "Controller-0" and "Controller-1" are actually the independent SCs in the X4370M2. What this shows is that you can lose any of the following components in the diagram and your database will continue to run (assuming RAC is in use):
Inside the Oracle Database Appliance – Part 1
We've had a few weeks to play around with the ODA in our office, and I've been able to crack it open and get to into the software and hardware that powers it.
For starters, the system runs a new model of Sun Fire - the X4370 M2. The 4U chassis is basically 2 separate 2U blades (Oracle is calling them system controllers - SCs) that have direct attached storage on the front. Here's a listing of the hardware in each SC:
| Sun X4370M2 System Controller Components (2 SCs per X4370M2) |
|
| CPU | 2x 6-core Intel Xeon X5675 3.06GHz |
| Memory | 96GB 1333MHz DDR3 |
| Network | 2x 10GbE (SFP+) PCIe card 4x 1GbE PCIe card 2x 1GbE onboard |
| Internal Storage | 2x 500GB SATA for operating system 1x 4GB USB internal |
| RAID Controller | 2x SAS-2 LSI HBA |
| Shared Storage | 20x 600GB 3.5" SAS 15,000 RPM hard drives 4x 73GB 3.5" SSDs |
| External Storage | 2x external MiniSAS ports |
| Operating System | Oracle Enterprise Linux 5.5 x86-64 |
Pictures of a real live ODA after the break.
Oracle Announces Oracle Database Appliance
Oracle has announced a new product, the "Oracle Database Appliance," or ODA (pronounced oh-duh) as I like to call it. Enkitec has been fortunate enough to get our hands on a test box. Be sure to check out my post on a deep dive (LINK GOES HERE) inside the ODA.
The gist of the ODA is that it's a small RAC (though RAC isn't required) in a box. Contrary to the rumors, it's not a "mini-Exadata" as some people have speculated. As you would expect, there's no capability for smart scans. The ODA does build on one of Exadata's big advantages, the rapid installation time. Compared to a typical Oracle installation, there is so much time lost in the process of getting a server ready for an Oracle database. On typical installations, the following things have to be done before a system is ready:
- racking and cabling the system to power and network
- connecting servers to the SAN
- allocating LUNs on the SAN
- installing the operating system
- configuring the operating system for Oracle database use (kernel and memory settings)
- mounting LUNs from the SAN and ensuring multipathing
With the ODA, you only have to perform the first task. Everything else is taken care of. The OS is installed and optimized, storage connected, and multipathing configured. It may not sound like much, but how many projects have you seen delayed because the SAN switch wasn't zoned correctly, etc?
While many people will say that this machine doesn't appeal to a mass market, there are plenty of Oracle shops that could use a system with 12-24 cores and 4TB of usable space. It's not built to be a data warehouse or OLTP beast...just a really solid machine with plenty of redundancy running an Oracle database.
Enkitec Extreme Exadata Expo
Speaking Engagements
Follow me on Twitter
My TweetsTopics
Recent Posts
- Exadata 11.2.3.2.1 NFS Issues – Ksplice Support for Exadata?
- 2013 Presentation Schedule
- Oracle Announces Exadata X3-2 and X3-8
- Exadata X3-2 1/8th Rack
- Pre OpenWorld Predictions (Exadata X3-2?)
Recent Comments
- Andy Colvin on Exadata 11.2.3.2.1 NFS Issues – Ksplice Support for Exadata?
- Andy Colvin on Exadata V2 Battery Replacement
- Renan Medeiros on Exadata 11.2.3.2.1 NFS Issues – Ksplice Support for Exadata?
- Suleman Naeem on Exadata V2 Battery Replacement
- nasmel on Inside the Oracle Database Appliance – Part 1