Why does my Weblogic Server takes a Long Time to Start?
On Linux or Solaris operating systems, this behavior is very common. Especially in new installations.
There is more information about this behavior in “Doc ID 1574979.1“.
The solution to this problem is very simple.
Just edit the java.security file that is inside the $$JAVA_HOME/jre/lib/security/
Find the line with the content “securerandom.source=file:/dev/urandom” and replace with “securerandom.source=file:/dev/./urandom”.
If do you prefer, just run the command:
sed -i ‘s/securerandom.source=file:\/dev\/urandom/securerandom.source=file:\/dev\/.\/urandom/g’ $JAVA_HOME/jre/lib/security/java.security
Are you receiving old notifications from OEM? Like 2 or 3 days past, mostly already solved or after a blackout?
Yeah, this is annoying, specially when getting floods and floods of notifications.
Ok, so here go a very good tip: You can set grace period for notifications! 🙂
Easy easy, do this way:
emctl set property -name oracle.sysman.core.notification.grace_period -value [provide value in minutes]
The oracle.sysman.core.notification.grace_period OMS parameter has been introduced in 12c and allows the user to configure the grace period within which the notification should be sent. The value is set in minutes.
emctl set property -name oracle.sysman.core.notification.grace_period -value 1440
With this, OMS sends only those notifications which have been raised in the past 1440 mins (last 24 hours) and ignores all the notifications for events / incidents created prior to this time period.
After this, you’ll need to start OMS:
emctl start oms
The oracle.sysman.core.notification.grace_period parameter applies to all the Notification methods, but if the requirement is to specify the grace period for a particular notification method only, you can use the below parameters accordingly:
oracle.sysman.core.notification.grace_period_connector: For Connectors
oracle.sysman.core.notification.grace_period_email: For email notifications
oracle.sysman.core.notification.grace_period_oscmd: For OS Command notifications
oracle.sysman.core.notification.grace_period_plsql: For PLSQL notifications
oracle.sysman.core.notification.grace_period_snmp: For SNMP Trap notifications
oracle.sysman.core.notification.grace_period_ticket: For ticketing tools
This is weel described as per MOS: 12c Cloud control: How to Prevent OMS from Sending out Old Notifications for Events / Incidents Occurred in the Past? (Doc ID 1605351.1)
This days I found this in a client’s 12c Database when trying to create a Materialized View:
ORA-00600: internal error code, arguments: [qkswcWithQbcRefdByMain4]
A perfect match to MOS ORA-00600 [qkswcWithQbcRefdByMain4] when Create MV “WITH” clause (Doc ID 2232872.1).
The root cause is documented on BUG 22867413 – ORA-600 CALLING DBMS_ADVISOR.TUNE_MVIEW.
The given solution is to apply Patch 22867413.
After applying patch, issue solved. 🙂
As DBAs we are always being recommended by Oracle and also recommending to clients to update their databases, but we have to be aware about new features and their effects. This is the case of Adaptive Query Optimization and in this particular case on SQL Plan Directives.
SQL Plan Directives are one of the functionalities that compose the Adaptive Query Optimization in Oracle Database 12c. The basic idea is pretty interesting: The SQL Optimizer keeps reviewing bad (“suboptimal”, as they like to say) plans, tipically incorrect cardinality estimations and generates SQL plan directives, like for missing histograms or extended statistics.
In my case, just after the upgrade to 12c (made on Jan 27th), the CPU usage increased for the same report always ran in the database:
Ok, how to check it?
After discover your new 12c targets you are facing target status down for MGMT targets, similar to image below?
And checking on server all looks to be ok, right?
Ok, now it’s everyone upgrading to 12c, right? Thanks God, this version was released in 2013!
But there is some things to be aware when planning an upgrade, specially regarding old applications and legacy. But pay attention! Not all of the requirements are necessary inside database. It’s the case os JDBC version requirement.
The database 12c documentation explicit mentions that JDBC versions 11.1.x and below are not supported anymore. It doesn’t mean that they don’t work, it’s only unsupported and you’ll have no assistance from MOS if you need. It’s better to avoid, right?
Anyway, if you check the JDBC support matrix, if you are in version 11.2 or below you are not supported since August/2015. So the Database 12c is helping you, that don’t have patching policy, to keep on right way. Thanks to Database 12c!
If this is your situation, I highly recommend you to upgrade the directly to JDBC version 7, the last available by now. See JDBC matrix version as:
But test! Test in you dev/test/QA environments before upgrading in Production environment!
Why? Because JDBC also have his compatibility matrix. JDBC 7, for example, demands your JDK to be at least in version 7 (released in 2011!). So, it’s needed to be at least in JDK version 6, as you can see below.
(Click in the image to access the link)
Some interesting links for you:
Verifying a JDBC Client Installation
What are the various supported Oracle database version vs JDBC compliant versions vs JDK version supported?
Checking the Oracle JDBC Driver Version on a Weblogic Server (by Cristóbal Soto)
Reset the AdminServer Password in WebLogic 11g and 12c:
mv data data-old
java weblogic.security.utils.AdminAccount weblogic .
Restart the AdminServer.
If the weblogic has the file boot.properties in $DOMAIN_HOME/servers/AdminServer/security/, should be adjusted the credentials of user and password, before restart the AdminServer.
OBS: Check the post on decrypt datasource password, which can also be used to decrypt the credentials of boot.properties file, avoiding making the above procedure, if this file exists.
That’s all for today.