A customer who is using an Exadata X8M-2 with multiple VMs had Smokescreen deployed in their company recently and they reported an issue that one of the Smokescreen decoy servers in their DC was seeing traffic from one of the Exadata VMs on a certain port. That was rather confusing as that port was the database listener port on that VM and why would a VM with Oracle RAC deployed try to access any random IP on the listener port. Also it was happening only for this VM. Nothing for so many other VMs.
We were just looking at the things and my colleague said that he had seen this IP somewhere and he started looking through the emails. In a minute, we found the issue as he found this IP mentioned in one of the emails. This was the VIP of this VM from where the traffic was reported to be originating. While reserving IPs for Smokescreen decoy servers, someone made the mess and re-used the IP that was already used for one of the VIPs of this RAC system !
So there is a new toy in the market for database geeks : Oracle has released database 12c. Every social platform is abuzz with the 12c activity. So thought that I should also complete the ritual
In this post Aman has already summed up many important links.
Maria Colgan has posted some useful links here.
And here is a link to a slidedeck about Upgrading and Migrating to 12c.
Happy 12c’ing !
Today I was checking OTN forums and came across a thread. OP’s concern was:
One of the db i am supporting has about 3.3 Terabytes capacity and the application is using only 1 huge tablespace with one big file.
the system is linux 4 , 32 bit.
oracle version is 10.2.0.4
Is there a limit of space for a tablespace when you consider insert/delete/query performance?
Single datafile of 3.3 TB 🙂
Kudos to the designer 😉
Today I was upgrading 10gR1 to 10gR2 (10.2.0.1) on Linux x86. The upgrade went almost fine (except that I had to install one package and change few kernel parameters) but while running DBUA to upgrade databases, it gave an error:
Could not get database version from the Oracle Server component. The CEP file rdbmsup.sql does not provide the version directive
Start of root element expected. Upgrade Configuration file
'C:\Oracle10g2\cfgtoollogs\dbua\test\upgrade5\upgrade.xml' is not a valid XML file.
I searched in the metalink and found that this all happens due to customized glogin.sql file which was there in my case also. And removing that customization made DBUA rock 🙂
You might want to check here, here and here.