IE11 - Changing encoding in browser throws Authentication Failed

For some of our eBusiness users who generate report in languages other then English, by default it used to open in UTF-8 or Western European, and there Chinese or Japanese characters used not be visible.

For IE8 they used to change encoding from View> Encoding > Japanese/Chinese etc.

But IE 11 onward it started failing with error Authentication Failed.

Solution:

Go to Tools > Internet Options

In General Tab open Settings.

In Website Data Settings > Temporary Internet Files > Check for newer versions of stored pages:

Change the setting to Never, and press OK.

And now encoding can be changed locally as many times as desired.

Oracle Grid Infrastructure Upgrade to 12C using OUI with additional patches (Cluster upgrade 11.2.0.3 to 12.1.0.2 - tricky approach)

In our recent cluster upgrade, we moved from 11.2.0.3 to 12.1.0.2.
The upgrade approach we chose was simple using OUI, but with some bugs we hit in available installable, we were asked to go for fixes as well as latest available patch-sets.

The approach should be to install software and then apply patches. Then start upgrade manually or using OUI. Or other way upgrade and apply patches.
But trying all this were appearing time taking and troublesome.

We kept the same approach for upgrade and path to upgrade is moved a little bit with couple of steps introduced in mid.

1. Run OUI with install and upgrade.
2. Hold it post install and do not press next to go to configure.
3. Apply patches from other window on recently installed software home.
4. Press next to let OUI go and do configuration.

With above approach the upgrade went pretty smooth in one go. Following are the detailed step for the same.


1. Verify grid with cluster verify utility.
./runcluvfy.sh stage -pre crsinst -upgrade -rolling -src_crshome /d00/app/11.2.0/grid -dest_crshome /d00/app/12.1.0/grid -dest_version 12.1.0.2.0 -fixup –verbose

In case of any issues this generates a fixup script. Running that from root solves the issue.

2. Keep on pressing next with your desired options, and at the window for batches, preferable divide task in batches.

3. In case of any issues shown in pre requisites check. Solve the same and move ahead.

4. Let the installation go and hold this when this pops up for running configuration scripts. (For me this appeared around 81% and in steps installation went successful and it is about to start the configuration script for Batch1 ).

5. Keeping the installtion window as it is, I logged in from other session. There I updated opatch to latest version available, created response file and also applied few patches as required.

$ unzip p6880880_121010_Linux-x86-64.zip -d <12C_ORACLE_HOME>

$ <12C_ORACLE_HOME>/OPatch/ocm/bin/emocmrsp -no_banner -output <Response File Name With Path>

$ <12C_ORACLE_HOME>/OPatch/opatch apply -oh <12C_ORACLE_HOME> -local <PATCH_PATH>/<patch_no> -ocmrf <Response File Name With Path>

6. Once done you can verify the patches with opatch lsinventory. And then you can go to the already open screen of OUI and press Yes there to move with upgrade. Later go with desired inputs as and when asked.

7. This will do execution of batch scripts and configuration on nodes one by one, and then Management DB creation. You will not be asked for any more inputs if everything goes smooth, until the below screen appears.

Thus upgrade completed quite fast as this saved time in applying patches as well, and it was smooth with OUI as it supposed to be.

RMAN : ORA-01861: literal does not match format string

The issue occurred for some of the databases around the month end.
The backup started failing with same message and even connecting to database or catalog, no rman command was working.

$rman target / catalog=<catalog details>

Recovery Manager: Release 10.2.0.4.0 - Production on Tue Dec 1 07:40:36 2015 

Copyright (c) 1982, 2007, Oracle. All rights reserved. 

connected to target database: ********
connected to recovery catalog database 

RMAN> resync catalog; 

starting full resync of recovery catalog 
RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
RMAN-00571: =========================================================== 
RMAN-03009: failure of resync command on default channel at 12/01/2015 07:40:55 
ORA-01861: literal does not match format string 

RMAN> 

Issue:

Taken the dump of controlfile with following commands.

SQL> Alter session set tracefile_identifier='dump'; 

SQL> alter session set events 'immediate trace name controlf level 9'; 

The dump showed something like following.

RECID #49661 Recno 1277 Record timestamp 11/30/15 12:45:55 piece #1 copy #1 pool 0 
Backup set key: stamp=897133568, count=46318 
V$RMAN_STATUS: recid=140735545929200, stamp=140735545929192 
Flags: 
Device: DISK 
Handle: *******
Media-Handle: <Handle Name>
Comment: 
Tag: ********
Completion time 11/31/15 01:37:53 


The point to notice here was the date i.e. 31 Nov. This is a bug for database versions 10.2.0.4 and 11.0.2.1 and oracle has patches for them.
But the problem here is existing malicious backup which are not allowing to proceed.

To resolve those following were the step taken.

Check the target database for following.

SQL> select recid, stamp, handle, set_stamp, set_count, piece# 
from v$backup_piece 
where recid in (<recId>);

This can be recid for handle name or anything  from above list to identify the backups taken on a malicious date.

Once we have the details. Take backup of controlfile before proceding futher.

SQL> alter database backup controlfile to '/tmp/backupcontrol.ct' 

SQL> exec sys.dbms_backup_restore.deleteBackupPiece(recid, stamp, 'handle',set_stamp, set_count, piece#); 

Note:- Need to run above for all backup pieces, and it will delete the entries from v$rman_status as well as backup piece from disk.

Now the rman can work without connecting catalog, but the catalog still throws the same error. Even resync catalog too fails with same error.

Later following commands were  run on target database.

NOTE:- you loose all earlier backup information after following activities.

SQL> EXECUTE DBMS_BACKUP_RESTORE.RESETCFILESECTION(19); #delete piece

PL/SQL procedure successfully completed.

SQL> EXECUTE DBMS_BACKUP_RESTORE.RESETCFILESECTION(13); #active piece

PL/SQL procedure successfully completed.

SQL>

Post the activity, there are two options.(you may try both in some cases).

1. Unregister database and register database in catalog database.

2. Connect catalog schema using sqlplus and run following.

SQL> update dbinc set high_do_recid =0 where db_name = '<your target's DB_NAME here>'; 
SQL> commit; 


Now connect to rman using target and catalog, and do a resync catalog.

$rman target / catalog=<catalog details>

RMAN> resync catalog;

Finally this came back to a state where backups can work with catalog using existing scripts.