October 12, 2018

DBID Problem @ ODA ... Bug (?)

long story told short: 

  • Oracle Database Appliance X6-2M and X7-2M, 
  • oak up to

We were not able to create databases anymore on one of our 15 ODAs. Detailled analysis has shown that the dbid - result from an 'odacli describe-database -i <DB identifier>' - grows and grows and, when it reaches a size of more than 255 characters, any subsequent try to create a database will fail and leave the database in status 'creating'. No more databases can be created, neither can You delete the database which is left in status 'creating'.

This is what a correct DBID (result from a describe-database) looks like: 1653395885 - btw: this is exactly the real dbid found in the database (select dbid from v$database).

An - imho - 'corrupted' DBID looks like this: 2791133100113200112102253200112102127320011210212832001121021533200112102154320011210215632001121021573200112102159320011210217323200112102177232001121021793200112102181320011210218323200112102186320011210215800112102576011210251101121021196170968 - the last 'n' numbers represent the real dbid (select dbid from v$database).

Side effect, when the database creation has failed: 
odacli list-databases
DCS-10001:Internal error encountered: could not execute query.

Would be great if You could do this:

  • If You have more than five databases on an ODA, issue an 'odacli list-databases'
  • take the id from the last created database and issue an 'odacli describe-database -i <id>'
  • Post the result as a comment in this blog

Regarding oracle support:

The Service Request is now open since weeks. Started as a Sev 2, relatively early changed sev to 1. The SR is updated from oracle support very rarely, usually no answer at all when I update the SR. In the meantime I escalated the SR, asked for a recall from a manager - no result and no recall. Today asked for another recall from another manager - will see how long that will take. 

@OracleSupport: that is very poor ... leaving customers helpless and uninformed with such severe Problems. Very disappointing ...

August 8, 2018

ODA X7 – no network connect after setup / re-image

Yesterday, I’d prepared an all new X7-2M. During the setup process / network configuration (using VLAN), I ran into a problem: Despite the network configuration was setup absolutely correct, any try to connect to the system from a jumphost was unsuccessful. 

Long story short: If You want to use the SFP28 (Fiberchannel) ports an ODA X7 offers, You have to do some config changes, to make it work. 
First of all: do a firmware upgrade to version or above. 
Next, configure the nic / nics to force the speed to 10000 and turn off autonegotiation. 

The firmware as well as a detailed description of all necessary steps can be found in MOS Note 2373070.1 ‘Using the onboard SFP28 ports on an ODA X7-2 server node’

How to copy Files to an ODA which is not available via network - by using the network

Sounds a little weird, I know - but works ... *lol*

Problem was: 

The all new ODA has installed old firmware for the SPF28 interfaces. This makes it impossible to connect the system to the network. To upgrade the interfaces You need to have the firmware files on the ODA ... but how can I copy the firmware to the ODA without a network connect?


First of all: create an ISO File from the Files You want to have in a virtual cd. With a mac, this is quite easy to do: start disk utility, then 'File / New Image / Image from Folder' and follow the instructions. Disk Utility will create a dmg file which hast to be reamed to iso. That's it, basically.

Next steps:

Open a browser window an connect to the ILOM (https://<ilom's hostname or ip>
Login by using ILOM's root account

Launch console

Open KVMS/Storage 

Add Storage - choose the iso you'd created and klick 'Connect'

Next, in a terminal session, start the console application (start /HOST/console), and mount the cdrom: 

mkdir /media/cdrom
mount /dev/cdrom /media/cdrom

copy the files to whereever You want on the ODA's file system :-)


April 4, 2018

Enterprise Manager and the disadvantages of WLS' Dynamic Monitoring Service (lots of metricdump files)

Had an interesting problem this morning with a customers Windows Server where Enterprise Manager 12c is running: Disk C: - where the EM Software is installed - was full. By the way: Imho, oracle software should never ever be installed in C: ...

The Problem:

Reason for the full disk was Weblogic's Dynamic Monitoring Service (or a weak housekeeping tool ;-)).
Weblogic has a feature, called DMS, which is checking some domain metrics and saves them to a file in directory (DOMAIN_HOME/server/<ServerName>/logs/metrics) for each managed server. Each file is about 600 to 800k in size, which is not that much - except You have thousands of those files. Filename is, by the way, somewhat like metricdump*. The files are created per default in a 3 hour cycle.

The Solution:

For this customer's system, I decided to stop the Dynamic Monitoring Service for the AdminServer as well as for the EMGC_OMS1 managed server. To achieve this, search for the file dms_config.xml (DOMAIN_HOME/config/fmwconfig/servers/<ServerName>) and change the value of 'enabled' to "false"

  <dump intervalSeconds="10800" maxSizeMBytes="75" enabled="false"/>

Restart EM to activate the change. 
Another option could be, to change the value of intervalSeconds to a higher value - for example once a day (86'400 secs) or twice a day (43'200 secs). Or, in case you have a proper working housekeeping tool running each day, configure it that it deletes all files older than 'whatever-you-might-think'.


March 16, 2018

ODA X6-2M – Expanding Storage can be unsuccessful when impatient

In 'A Brief History of Time' (RIP Mr. Hawking), Chapter 2 is named 'Space and Time' – and this title fits perfect with a current problem, I was faced with, when expanding disk capacity in an ODA X6-2M.

Long story, told short

An ODA X6-2M, equipped with the standard disk configuration, ran out of space and my customer decided to add two NVMe's. So, he ordered two NVMe's – and, by the way - we were waiting for two weeks (!), until delivery. 

Next step - mounting the disks. According documentation, expanding disk storage is a quite easy job:
  • Put the disks in
  • Set the disks in online state (odaadmcli power disk on pd_02 and odaadmcli power disk on pd_03)
  • Expand storage (odaadmcli expand storage)

This results in my environment in a complete disaster:

  • Disks are already online when trying a 'power disk on',
  • 'expand storage' meant, the disks have already an ASM signature and aborted,
  • 'odaadmcli show disk' shows the disks, but als UNKNOWN and with the /dev/nmv* names of the existing NMVes, whilst the old ones had, all of a sudden, new names … (!)
  • The command to power off said that the disks are not online, but a subsequent remove of the disks resulted in a system crash …

In short: horror!! Opened a Service Request, tried this, tried that – and finally, after three weeks fighting with Oracle Support, I started a last try: Put the disks in, went to the coffee bar, returned about an hour later. Started to set the disks in online state (result: the disks are already online), and issued an 'odaadmcli expand storage' – expecting the same result as with every try before … but, surprisingly, the command returned no error, ASM started rebalancing and everything went fine J

Solution / Chapter 2 ... 'Space and Time'

You'll get the disk space, when You take Your time ...

Put the disks in, wait at least 15 minutes, power on the disks and issue the 'expand storage' command. Oracle Supports explaination of this behavior was (in my words): The oakd process needs some time to prepare the disks in a way that expand storage works properly …


ODA Xx – Space Waste When Using ACFS (instead of ASM) For Databases

Disclaimer: I will not discuss the necessity of an ACFS FS to store database files, nor compare ASM and ACFS or it's benefits. What to use / what fits best in Your environment is up to You, folks … ;-)

Pretty sure that this is for lots of people a well-known problem – but for all others:

When creating a database using ACFS as storage option, a FS of size 100GB is created. This 100GB is not a configurable value, by the way. Result is: When having lots of small databases, making use of ACFS wastes a lot of disk space, as every database's file system occupies 100GB.
Oracle Support's answer to that is: "In the future releases you may see the customized option to define the size of ACFS while creating the database". Nevertheless: It is possible to reduce that 100GB FS to an appropriate size. Here's how:  

Examples are based on OAK, used db release:

Create the database:

oracle@eoda03 ~]$ odacli create-database -m -n RCRACFS1 --no-cdb  --dbstorage ACFS -dh cce28d1b-01cc-4917-8237-38683d34f53e

… results in (from a FS perspective)

Filesystem                   Size  Used Avail Use% Mounted on
/dev/asm/datrcracfs1-262     100G  2.5G   98G   3% /u02/app/oracle/oradata/RCRACFS1

Reduce the filesystem size to 10GB:

[oracle@eoda03 ~]$ acfsutil size -90G /u02/app/oracle/oradata/RCRACFS1
acfsutil size: new file system size: 10737418240 (10240MB)

Check the filesystem size

[oracle@oda03 ~]$ df -h /u02/app/oracle/oradata/RCRACFS1
Filesystem                   Size  Used Avail Use% Mounted on
/dev/asm/datrcracfs1-262      20G  2.5G   18G  13% /u02/app/oracle/oradata/RCRACFS1

20G?? 100 minus 90 is 20? Possibly yes (you never know ;-)) – on the other hand and a better explanation: 20GB could be minimum FS for an ACFS file system.


Yes! It is that easy J


March 5, 2018

EXPDP using an External Password Store - facing a new 'release' of a well known performance issue

After a while without blogging, here a new blog post talking about a very well known performance issue:

export (exp as well as expdp) is usually slower when using an TCP based TNS-Alias instead of setting ORACLE_SID. Remember? ;-) 

In a little more detail:
An "expdb system/manager@db directory= ..." takes (usually) more time than an
"export ORACLE_SID=DB; expdp system/manager directory= ..."

But what if You have to use an external password store - a wallet - to avoid clearly readable passwords either in a file or at the command line? One part of the whole procedure is, to define the TNS alias in tnsnames.ora - and most of us define a TCP based alias. This is - imho - not the best way of connecting a local database - IPC or BEQ are way better for that.

So, I solved an expdp performance issue by using an Bequeath based TNS alias:

Created a new wallet:
mkstore -wrl /u01/app/oracle/wallet -create

Created an alias to connect to the DB:
mkstore -wrl /u01/app/oracle/wallet -createCredential db_system_beq.world system manager

Added a BEQ connect description to my tnsnames.ora:
    (ADDRESS =
          (PROTOCOL = BEQ)
          (PROGRAM = oracle)
          (ARGV0 = oracleDB)
        (SERVICE_NAME = DB)


Set the environment for my db and issued an expdp:
export ORACLE_SID=DB; expdb /@db_system_beq.world directory= ...


Job "SYSTEM"."SYS_EXPORT_FULL_01" successfully completed at Mon Mar 5 15:04:15 2018 elapsed 0 00:00:43 

Result when using a TCP based TNS alias:

Job "SYSTEM"."SYS_EXPORT_FULL_01" successfully completed at Mon Mar 5 14:58:03 2018 elapsed 0 00:01:31 

Try it - and post Your results as comment.


Copyright © Robert Crames' Oracle Database and Middleware Blog | Powered by Blogger
Design by SimpleWpThemes | Blogger Theme by NewBloggerThemes.com