Internal error has occurred. Check the log files for details when logging into database control

Problem Description
After login to 11g database control/ Enterprise Manage DBConsole "Internal Error has occurred. Check the log file for details." is received but the database and other pages can be accessed normally.

Cause of the Problem
The error appears because the url accessed is not correct one.

Solution of the Problem
Once we hit above error let's look at our Url. We will see something like.
"https://192.168.100.101:1158/em/console"

In general the format would look like following:

http://{hostname}:{port}/em/console
https://{hostname}:{port}/em/console

This URL always generates this error.

The URL that should be used is:-

http://{hostname}:{port}/em
or,
https://{hostname}:{port}/em

Note that there is no '/console' at the end.

In our case, just type "https://192.168.100.101:1158/em/" url in our browser.
We will see the error is not appeared anymore.

java.lang.Exception: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

Problem Description
After login to Oracle database dbconsole/ Enterprise Manager it shows following error message.
java.lang.Exception: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Database version is 11.2.0.1 and it is RAC database. We face the same error whenever we try to do some operation in database control from enterprise manager for example RMAN backup settings.

Cause of the Problem
The problem happened due to the corruption of SSL certificate or emkey. Due to corruption Database Console is unable to connect to its agent and verify the credentials.

Solution of the Problem
The solution of this problem is to resecure the DB Console.

Steps are:
1) emctl stop dbconsole
2) emctl unsecure dbconsole
3) emctl secure dbconsole
4) emctl status dbconsole
5) emctl start dbconsole

Whenever it asks you "Please enter repository password:" type the password of SYSMAN user.

Following is the output from my system.
[oracle@DC-DB-01 ~]$ emctl stop dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
https://DC-DB-01:1158/em/console/aboutApplication
Stopping Oracle Enterprise Manager 11g Database Control ...
... Stopped.

[oracle@DC-DB-01 ~]$ emctl unsecure dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
https://DC-DB-01:1158/em/console/aboutApplication
Configuring DBConsole for HTTP... Done.
DBCONSOLE already stopped... Done.
Agent is already stopped... Done.
Unsecuring dbconsole... Started.
DBConsole is now unsecured... Done.
Unsecuring dbconsole... Sucessful.

[oracle@DC-DB-01 ~]$ emctl secure dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
http://DC-DB-01:1158/em/console/aboutApplication
Please enter repository password:
DBCONSOLE already stopped... Done.
Agent is already stopped... Done.
Securing dbconsole... Started.
Securing dbconsole... Sucessful.

[oracle@DC-DB-01 ~]$ emctl status dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
https://DC-DB-01:1158/em/console/aboutApplication
Oracle Enterprise Manager 11g is not running.

[oracle@DC-DB-01 ~]$ emctl start dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
https://DC-DB-01:1158/em/console/aboutApplication
Starting Oracle Enterprise Manager 11g Database Control .... started.
------------------------------------------------------------------
Logs are generated in directory /u01/app/oracle/product/11.2.0/dbhome_1/dc-db-01_bddipdc/sysman/log

Now again login to Enterprise Manager and you will see the errors are gone.

Performing Switchover in Physical Standby Database

In a Data Guard environment Switchover means to change primary database role to standby role and standby to primary role. Before we performing switchover we need to remember the following points.

1) Verify the standby database that will become the new primary database is operating in ARCHIVELOG mode.

2) Ensure both primary and standby database contain temporary files.

3) Ensure that all but one RAC instance on the standby databases in a Real Application Clusters configuration are shut down. Though only one RAC instance of the standby database is open during the switchover, all other standby database instances will automatically undergo a transition to their new role correctly when they are opened.

4) Data Guard provides the V$DATAGUARD_STATS view that can be used to check the time it will take to perform a role transition if all available redo data is applied to the standby database. For example:

SQL> COLUMN NAME FORMAT A20
SQL> COLUMN VALUE FORMAT A25
SQL> COLUMN TIME_COMPUTED FORMAT A24
SQL> SELECT * FROM V$DATAGUARD_STATS;

5) In case to switchover to physical standby database, verify the primary database instance is open and the standby database instance is mounted.

Once you check above five points it is now time to perform switchover operation. Following is the step by step procedure.

Step 01: Verify that it is possible to perform a switchover.
On the current primary database, query the SWITCHOVER_STATUS column of the V$DATABASE view to verify it is ready for switchover operation.

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
1 row selected

The status "TO STANDBY" indicates that it is possible to switch the primary database to the standby role.

If the value in the SWITCHOVER_STATUS column is SESSIONS ACTIVE then using following query you can identify and terminate active user or SQL sessions that might prevent a switchover from being processed.

select SID, PROCESS, PROGRAM
from v$session where type = 'USER' and
SID <> (select DISTINCT SID from v$mystat);

After killing session if the SWITCHOVER_STATUS column still displays SESSIONS ACTIVE, you can successfully perform a switchover by appending the WITH SESSION SHUTDOWN clause to the ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY statement.
Alternatively, you can issue:
SQL> alter system set aq_tm_processes=0;
SQL> alter system set job_queue_processes=0;

If the TO STANDBY or SESSIONS ACTIVE value is not displayed in the SWITCHOVER_STATUS column, then verify the Data Guard configuration is functioning correctly (for example, verify all LOG_ARCHIVE_DEST_n parameter values are specified correctly).

Step 02: Initiate the switchover on the primary database.

The second step is to change the primary database to physical standby database role. To do that issue following command on primary database.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
or,
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
After this statement completes, the primary database is converted into a standby database. The current control file is backed up to the current SQL session trace file before the switchover. This makes it possible to reconstruct a current control file, if necessary.

Step 03: Shut down and restart the former primary instance.

Shut down the former primary instance, mount it.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
At this point in the switchover process, both databases are configured as standby databases.

Step 04: Verify the switchover status in the V$DATABASE view.

After you change the primary database to the physical standby role and the switchover notification is received by the standby databases in the configuration, you should verify if the switchover notification was processed by the target standby database by querying the SWITCHOVER_STATUS column of the V$DATABASE view on the target standby database.

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected

If the value in the SWITCHOVER_STATUS column is SESSIONS ACTIVE then run the following two statements.
SQL> alter system set aq_tm_processes=0;
SQL> alter system set job_queue_processes=0;

In this case you can append the WITH SESSION SHUTDOWN clause to the switchover statement.

Step 05: Switch the target physical standby database role to the primary role.
Switch a physical standby database from the standby role to the primary role when the standby database instance is either mounted in Redo Apply mode.
Issue the following SQL statement on the physical standby database that you want to change to the primary role:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Step 06: Finish the transition of the standby database to the primary role.

If the physical standby database has not been opened in read-only mode since the last time it was started, issue the SQL ALTER DATABASE OPEN statement to open the new primary database:

SQL> ALTER DATABASE OPEN;

If the physical standby database has been opened in read-only mode since the last time it was started, you must shut down the target standby database and restart it:

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

Step 07: Restart log apply services on the standby databases.
In the new standby database issue the following command to apply redo log.

SQL> alter database recover managed standby database disconnect from session;

Step 08: Begin sending redo data to the standby databases.

Issue the following statement on the new primary database:

SQL> ALTER SYSTEM SWITCH LOGFILE;

ORA-1093 During Switchover or Close of Standby Database

Problem Description
This problem usually occurs in Oracle database 10.1.0.2 to 10.2.0.3. However, this problem also exist in 11gR1 and 11gR2 database and the reason is different. During switchover from Primary to Physical Standby database ORA-1093 error occurs.

SQL> alter database commit to switchover to physical standby;
alter database commit to switchover to physical standby;
*
ERROR at line 1:
ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected

In case of 10g database you will see switchover status as Session Active.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
SESSIONS ACTIVE

In case of 11g database you will see switchover status as TO STANDBY

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO STANDBY

In case of 10g checking v$session will show the following:

SQL> select SID, PROCESS, PROGRAM
  from v$session where type = 'USER' and 
  SID <> (select DISTINCT SID from v$mystat);

SID       PROCESS    PROGRAM
--------- ---------------- ------------------------------------------------
1078    622624         racgimon@koalav1 (TNS V1-V3)
1079    622624         racgimon@koalav1 (TNS V1-V3)
1080    622624         racgimon@koalav1 (TNS V1-V3)
1086    622624         racgimon@koalav1 (TNS V1-V3)

In case of 11g you might notice some Program related to Oracle clusterware.

Cause of the Problem
This error can also occur when any standby database registered with the Oracle Clusterware is being closed.

1) ALTER DATABASE CLOSE
2) Running RECOVER MANAGED STANDBY DATABASE on a standby that was previously opened in READ ONLY mode

Oracle Clusterware uses the RAC Global Instance Monitor (racgimon) to monitor instance availability on each node. In order to close any database, all sessions must be disconnected.

Solution of the Problem
If the error occurs during switchover in a Data Guard environment, simply re-run the switchover command with the additional clause WITH SESSION SHUTDOWN.

SQL> alter database commit to switchover to {new database role} WITH SESSION SHUTDOWN;

Otherwise stop racgimon using the following command in the database ORACLE_HOME on a single node:

% racgimon stopd {db_name}

Re-issue the original command that failed.

Starting in Oracle11g Release 1 and up, the racgimon sessions will be ignored on a standby during close.

Microworkers - A scam company

Today, I want to tell you a very important message about Microworkers. Those who are using Microworkers beware about it. They are simply scam company. But it might not sound good to everyone. They are only scam to the people who earn good amount of money from it. I have bad experience with them. They are suppose to pay money on every Thursday. But for more than 2+ weeks they did not pay money. And after 3+ weeks I see my account become disabled. They simply said,

"This account has been terminated and cannot be activated again.
PROXY
"

Here goes the screenshot,

which is their very generic message and they don't have any answer about it. Their support is also horrible.

1. I contacted them saying that I never used proxy and why you disabled my account.
2. Though they were suppose to answer support mail within 5 days but it is 2 weeks passed they never replied.
3. Then I threaten them saying if you don't enable my account I will take necessary steps to fight with them as I never used PROXY.
4. At this point they replied my email and sent me the following email from info@microworkers.com saying the following on Tue, Sep 27, 2011 at 9:26 PM

subject Re: Microworkers made fraud while disabling account
"Please provide a copy of the driver license and your phone number so that we can verify your account."

5. I replied them with my driving license as well as my valid phone number.

6. Since then I did not get any reply. I contacted again and again and no reply from them.

Why they are scam?

1. I had campaigns running on Microworkers.com and I invested money in it. I have also $80 in my workers account. They took away all money from me.

2. Even if you notice Paypal is not allowed in Microworkers because they are simply illegal company and Paypal does not allow any illegal company.

3. Every week at Thursday they were suppose to pay me money. But for more than 2+ weeks they did not pay money and whenever my money was a good amount then they disabled my account.

4. Even if you browse their website they only mentioned about email. No physically address as well as about us is mentioned which means they are likely to scam.