Quick one today!
Having message below in your 22.214.171.124 on AIX like this?
WARNING: Heavy swapping observed on system in last 5 mins.
pct of memory swapped in [31.28%] pct of memory swapped out [3.81%].
Please make sure there is no memory pressure and the SGA and PGA are configured correctly.
Look at DBRM trace file for more details.
Stand down, this issue is caused by unpublished Bug 11801934, mentioned in MOS False Swap Warning Messages Printed To Alert.log On AIX (Doc ID 1508575.1).
Basically happens because the v$osstat does not reflect proper stats for the swap space paging.
So, stay calm and see you next week!
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?
Have you ever killed a session in database and the session doesn’t disappear? Or yet, you killed the SPID of the session in OS and the session still running in database, but now you cannot see the SPID?
Very weird, but it happens. First of all, let us point some interesting items:
Facing this error? Let me guess: Ports 03, 05, 06, 08, 09 and 12 are alerting? You have a Quarter Rack? Have recently installed Exadata plugin to version 126.96.36.199 or higher?
This is probably related to Bug 15937297 : EM 12C HAS ERRORS CABLE IS PRESENT ON PORT ‘N’ BUT IT IS POLLING FOR PEER PORT. The full message might be like “Cable is present on Port 6 but it is polling for peer port. This could happen when the peer port is unplugged/disabled“.
In fact, the bug was closed as not a bug. 🙂
As part of the 188.8.131.52 Exadata plugin, the IB switch ports are now checked for non-terminated cables. So these errors ‘polling for peer port’ are the expected behavior. Once ‘polling for peer port’ is an enhanced feature of the 184.108.40.206 plugin, this explains why you most likely did not see these errors until you upgraded the OMS to 220.127.116.11 and then updated the plugins.
In Quarter Racks, the following ports 3, 5, 6, 8, 9 and 12 are usually cabled ahead of time, but not terminated. In some racks port 32 may also be unterminated. Checking for incident in OEM you might see something like this image:
Having this error from cell alerthistory.log? Don’t panic!
Take a look in MOS: Exadata Storage Cell reports error RS-7445 [Serv MS Leaking Memory] (Doc ID 1954357.1). It’s related to Bug – RS-7445 [SERV MS LEAKING MEMORY].
The issue is a memory leak in the Java executable and affects systems running with JDK 7u51 or later versions. This is relevant for all versions in Release 11.2 to 12.1.
What happens is that MS process is consuming high memory (up to 2GB). Normally MS use around 1GB but because of the bug the memory allocated can grow upt to 2GB. You can check it as per example below:
[root@exaserver ~]# ps -feal|grep java
0 S root 16493 14737 0 80 0 - 15317 pipe_w 18:34 pts/0 00:00:00 grep java
0 S root 22310 27043 2 80 0 - 267080 futex_ 18:15 ? 00:00:27 /usr/java/default/bin/java -Xms256m -Xmx512m -XX:-UseLargePages -Djava.library.path=/opt/oracle/cell/cellsrv/lib -Ddisable.checkForUpdate=true -jar /opt/oracle/cell/oc4j/ms/j2ee/home/oc4j.jar -out /opt/oracle/cell/cellsrv/deploy/log/ms.lst -err /opt/oracle/cell/cellsrv/deploy/log/ms.err
Note that: 267080 * 4096 = 1143MB (1GB). If your number is higher than this, it indicates the presence of the bug.
I was asked to make a conversion from T-SQL (MSSQL) Procedure to PL/PGSQL. Regarding how boring is this task, the follow link helped me:
I highly recommend it. The site has a commercial solution to convert all database, but some code can be converted online for free. 🙂
The conversion not fixed at all, but make a good part of the work… And all help is helpful…
See the first part of this post here: HANGANALIZE Part 1.
This post is just complement with a little kludge I liked…
First, let’s remmember that the hanganalyze is used when you are if some hanging in your environment, of course.
But what if you are having difficult to access the database, even with ‘/ as sysdba’?
You can create a ‘preliminary connection’ without create a session, like this:
sqlplus -prelim / as sysdba
This ‘feature’ is available since Oracle 10g, and it basically skips a session creation part (which could block) when logging on as SYSDBA.