How to deploy ODA lite models with (active-active) VLAN configuration easily

This blog entry is a description of deploying an Oracle Database Appliances X6-2 S in a VLAN environment, but it is valid for all models of the X6-2 and X7-2 lite versions (X6-2 S, X6-2 M, X6-2 L, X7-2 S, X7-2 M). The release of the ODA software we used to deploy was - the newest version at the time of the installation.

Re-imaging the ODA

The easiest way to start with the deployment (if the delivered machine does not already have the latest version installed) is to just re-image the ODA following the instructions that can be found at the manual for this software version. So just configure the ILOMs and start with re-imaging. You can also use the already installed ODA software and upgrade it to the newest release. Then you do test the different steps to upgrade an ODA, but as there are more steps included it's easier to re-image and the time used for both approaches doesn't differ much.


After re-imaging, the VLAN creation can take part. We have taken the fiber bond to configure our VLAN, but one can use this article also to create VLANs using copper (then use btbond1 or btbond2 instead of sfpbond1). We didn't used the copper interface for our deployment, but on ODA X6-2 machines both network interfaces can be used in parallel (on X7-2 you have to decide either using copper OR fibre).. 
To create a VLAN, Oracle kindly provides a script called which can be found at the note 2216567.1.
At this note, at the manual and even on the ODAs itself one can also find a template of a json file, which is needed to deploy the ODA. VLAN is supported on the ODA light models (since software release, but the graphical deployment user interface doesn't work in VLAN environments.
Taken the provided json template file one has to change everything that is needed to deploy the ODA silent for the own environment. We saved the json template as file /tmp/create-appliance-ODA.json before we changed the entries.
The points to change are especially the name of the instance/database, the database edition, if one want to use standard edition (actually you can't mix SE and EE deployments on the same machine), the time zone, all ip-addresses and domain names. Do NOT change the nodeNumber as it is always "0" on the ODA light models S and M. To use the right VLAN for the public interface the nicName must be changed to match the VLAN configuration.

"instance" : {
"name" : "ODA1",
"instanceBaseName" : "PROD",
"dbEdition" : "EE",
"timeZone" : "UTC",
"ntpServers" : [""],
"dnsServers" : ["","",""],
"domainName" : "",

"nodes" : [ {
"nodeNumber" : "0",
"nodeName" : "ODA1",
"network" : [ {
"nicName" : "sfpbond1.200",
"ipAddress" : "",
"subNetMask" : "",
"gateway" : "",
"networkType" : [ "Public" ],
"isDefaultNetwork" : true

One needs to remove the whole ILOM tree from the json file as the ODA deployment otherwise can fail (and we did had the right names / ip addresses put in there but there may be a routing problem between the different VLANs and the management network). Also one needs to remove the Auto Service Request "asr" tree from the json file, if the ASR should be configured later on. If a non existing account is used at the ASR part or the user/password combination is not right, the whole deployment fails and one needs to start over again (undeploying the ODA first and re-start with the deployment). 

If needed, the disk group redundancy can be changed (NORMAL equals mirroring, HIGH equals triple mirroring which is not available with only 2 NVMe cards) and the disk percentage. The documentation tells:

Storage Configuration Options
When Oracle Database Appliance X6-2 is deployed, you can select one of the following configuration options to divide the storage capacity between DATA diskgroup and RECO diskgroup:
  • External: Storage capacity is split between 80% for DATA and 20% for RECO.
  • Internal: Storage capacity is split between 40% for DATA and 60% for RECO.
  • Custom: Storage capacity is configurable from 10% to 90% for DATA and the remainder for RECO.
Therefore, the deployment was done with a 50% split between DATA and RECO as we needed some kind of "internal" for storing the FRA (backups, archivelogs, flashback logs) locally on the ODA but kept some more space for "DATA".

Do not forget to change the entries inside the database tree at the json file. dbType can only be single instance on ODA lite models, but everything else can be set. The admin password is not only used by the database, but is set as the new "master password", e.g. also for the oracle user at linux (everything can be set after the deployment, you don't need to keep a master password for all).

Enable dbConsole if you want to use Enterprise Manager Express on 12c! Provide the right database shape you want to use (db shapes documentation). Keep ACFS as dbStorage, so you are able to use e.g. standard backup agents to backup files from the disks. The character set can't be changed later on, so it is also needed to change it before the deployment starts.

"database" : {
"dbName" : "PROD",
"dbVersion" : "",
"instanceOnly" : false,
"isCdb" : false,
"pdBName" : "pdb1",
"pdbAdminuserName" : "pdbuser",
"adminPassword" : "welcome1",
"dbType" : "SI",
"dbTargetNodeNumber" : "0",
"dbClass" : "OLTP",
"dbShape" : "odb2",
"dbStorage" : "ACFS",
"dbCharacterSet" : {
"characterSet" : "AL32UTF8",
"nlsCharacterset" : "AL16UTF16",
"dbTerritory" : "AMERICA",
"dbLanguage" : "AMERICAN"
"dbConsoleEnable" : false


Creating the VLAN

After finishing the preparation, the creation of the VLAN can be done. In our deployment we have created two different VLANs on the spfbond1.  So we connected as root and provided the vlan, the bondname, the ip address, network mask and the gateway as parameters to the script we have downloaded from the note.

./ add -v 3001 -i sfpbond1 -ip -n -g

./ add -v 200 -i sfpbond1 -ip -n -g

In our case, we needed to change the bond to run active-active instead of active-failover (the default):

vi /etc/sysconfig/network-scripts/ifcfg-sfpbond1
BONDING_OPTS="mode=8.2.3ad miimon=100 lacp_rate=0" 

If one has used configure-firstnet, it may is necessary to remove ip-address, netmask and gateway from the icfg-sfpbond1 file. 

After the configuration has been changed the network service and the dcs agent must be restarted:

service network restart

initctl stop initdcsagent
initctl start initdcsagent 

Best practice is to check  the network configuration afterwards with:
odacli list-networkinterfaces

#/opt/oracle/dcs/bin/odacli list-networkinterfaces
#ID Name NIC Type
#---------------------------------------- -------------------- ------------- #----------
#b324f474-627e-4b15-af83-2ed21eda845a btbond1 btbond1 Bond
#595dfda9-67a6-4fc9-96af-afe966c287a7 em1 em1 Physical
#2033de33-99fb-4d53-8235-6ef088db54fe em2 em2 Physical
#62a09165-d9a5-4b8d-8eaa-45022988215b em3 em3 Physical
#40070762-6e87-42b4-8eb2-b8f9aa642849 em4 em4 Physical
#d70bbb83-e7de-462a-8892-42bdb687d6dc sfpbond1.3001 sfpbond1.2001 Bond
#26a0c940-5705-460a-b51d-ab8723d06f35 priv0 priv0 Dummy
#49cf2709-3c75-4c2c-bf53-718757385335 sfpbond1.200 sfpbond1.200 Bond

Deploying the ODA

As the VLANs are now fully functionable, one can start the deployment (still connected as root):
/opt/oracle/dcs/bin/odacli create-appliance -r /tmp/create-appliance-ODA.json

As you can see, the previously created json file is used as an input parameter for the odacli create-appliance statement. After waiting a couple of minutes, the ODA is now deployed with spfbond1.200 as standard network interface.
So one is now able to use both VLANs for different tasks. As the listener is configured by default only with the VLAN 200 (specified at the json file), one needs to configure the second ip-address as listener endpoint manually, if needed (ssh as grid user and run netmgr). So in our case the public interface for the application is the VLAN 200 and the private interface for the data guard and the backup is VLAN 3001. 


Even if the deployment with the GUI is not working for VLAN environments, the ODA lite models using bare metal installation without OVM (so called virtualized platform) can easily be deployed with VLAN configuration and, if you keep in mind to remove the entries from the json files you don't need, it is fast and straightforward and works on from ODA light software release (until at least, but I think this is also available for later software releases). If needed, configure additional network things (like permanent routes and rule sets in /etc/sysconfig/network-scripts).

DOAG conference review (Nuremberg, 21.-23.11.2017)

Robotron Booth
Time flies by - so it's time now to reflect the 3 days at the DOAG conference this year at Nuremberg. It was my second time I have held a presentation at this big event, this time it was about "Flashback Database, Backup and Recovery for Oracle Database 12c Release 2". The presentation was held at 9am at the second day and it was astonishing, the room was filled up in total. 

As the main goal of my presentation was to sensualize the administrators how to avoid traps in the new default “Single-tenant” architecture, some of the spectators may have had problems to divide between my advices for best-practice and “things not working” in database release 12.2. But they can download the presentation in the next days and I think they will see the differences then.

In addition to my own presentation, the DOAG conference was full of news and interesting other slots. I tried to follow topics I like most – tuning for example, and I have seen some really good presentations there (with new ideas for my daily work). In addition, I have met a product manager responsible for the cost-based optimizer and discussed with him the “Autodesk” tuning problem (details can be found at an older post here). I’ll send him the dump and the selects and I am wondering, which outcome I’ll get later (I'll keep you informed).

Another cool presentation was held by a Swiss employee of trivadis, regarding connecting the “Keepass” freeware to the oracle database to avoid using open passwords in database scripts. This could be something for some of my customers, too.

A lot of presentations are now without any live demos. I didone, but the lady that was presenting at my room just before me had a lot of problems with her live demo - she broke everything. I have tested my live demo two evenings before I held the presentation - and the virtualbox with my Oracle Linux crashed. My disk was full and I needed two hours in the late night to get everything running again. Thank god I did this test (because otherwise this were happen at the presentation time) and at the end it worked, but I can  comprehend, why more and more speakers don't do live demos anymore.

My German colleagues had some cloud workshops - unfortunately, cloud does not seem to be a big topic for DOAG participants. There were not so many people which wanted to do some hands on. That was really a pitty.

A funny presentation was the one from Chris Saxon, where he was doing "More SQL magic!". Magic tricks with PL/SQL and SQL options - the small room was really filled up and even if I have known the technology behind each trick - it is really nice to see what is possible within the database and Chris was able to make a show out of it. Our daily work does not seem to be magic or funny all the time, so it was really a great moment to see him. One of the tricks he showed at the DOAG you can find at youtube ( and I think it's worth to follow him (and his blogs) as a developer as well as a dba (

Most impressive are presentations which do not have anything to do with our daily work – at least at a first glimpse. One of the keynotes were held by a German Lufthansa pilot trainer and it was a very impressive presentation. He took some aircraft accidents and told in detail why they happened – and why people died or why not, and what the aircraft industry is doing to avoid crashes from a team member perspectives view. At the end, it is all about respect – trust – teaming and avoiding hierarchical levels at the cockpit (for sure they exist) for the time two pilots are working together. The aircraft industry is more or less forced since years to do a lot of the stuff, other industries are talking about now: Knowledge clusters, flat hierarchies, trust, responsibility and respect. All people on a plane are co-workers and all are doing everything to bring “my aircraft” safe home.

In total, the DOAG was again a big success, I think, for the referents as well as for the participants. You can attend dozens of presentations over 3 days – but with a high number of presentations in parallel, you sometimes decide to attend the wrong presentation. I had that only once this time. The DOAG is THE place for the DACH region to learn, to share, to see, to be seen and to meet old friends and new, interesting people!
The next DOAG conference (the 31st) will again be at Nuremberg in November 2018 - so if you understand German, you should attend. One of the main topics there, I think, will be the database release 18. The first release with the new naming convention. I’m looking forward to that…