Additional space required is more than max allowed space for these datafiles - During 12c Upgrades

I was upgrading a 11gR2 database to 12.1.0.2, and faced following error during upgrade using DBUA:

Upgrade Storage Check  

 Disk space usage summary  
/opt/app/testdb/oradata01/ has enough space. 
Required space is 0 MB , available space is 380732 MB.  

Details: Space usage summary  Space usage reason: Upgrade  

Tablespace Name: SYSTEM 
Additional space required: 0MB Datafile: /opt/app/testdb/oradata01/testdb/system_01.dbf Auto Extensible: No  

Tablespace Name: SYSAUX 
Additional space required: 0MB Datafile: /opt/app/testdb/oradata01/testdb/sysaux_01.dbf Auto Extensible: No  

Tablespace Name: UNDO 
Additional space required: 0MB Datafile: /opt/app/testdb/oradata01/testdb/undo_01.dbf Auto Extensible: Yes  

Tablespace Name: TEMP 
Additional space required: 0MB Datafile: /opt/app/testdb/oradata01/testdb/temp_01.dbf Auto Extensible: Yes  

Disk space usage summary  
/opt/app/testdb/oradata01/ has enough space. 
Required space is 0 MB , available space is 380732 MB.  

Additional space required is more than max allowed space for these datafiles  

Tablespace Name: 
TEMP Datafile: /opt/app/testdb/oradata01/testdb/temp_01.dbf 
Additional space required: 0 MB 
Maximum allowed space on datafile: -27647 MB  

This is because the maximum value of the datafile is being shown with a lower value than required and the solution for this error is to increase the maxsize limit (MaxBytes) to a value greater than the datafile size.

Example :
alter database tempfile '/opt/app/testdb/oradata01/testdb/temp_01.dbf' autoextend on next 10M maxsize 32767M; 

And then reprocess the DBUA:

Hope this resolves your issue!!

ORA-38784 + ORA-01153 + ORA-16000 : During restore point creation/Deletion on Standby Database

Create or Remove Restore Point on Active Dataguard Standby databases

It is required to stop the managed recovery on the standby, otherwise the following error will happen:

SQL> create restore point restore_point_2017 guarantee flashback database
*
ERROR at line 1:
ORA-38784: Cannot create restore point 'restore_point_2017'.
ORA-01153: an incompatible media recovery is active

SQL> alter database recover managed standby database cancel;
SQL> create restore point ;



To drop the restore point on standby7 database which is running in Active Dataguard, database shutdown is required

We get below error when we try to drop the restore point in read only mode


SQL> DROP RESTORE POINT restore_point_2017;
DROP RESTORE POINT restore_point_2017
*
ERROR at line 1:
ORA-16000: database open for read-only access


Check the restore Point Name

SELECT NAME,SCN, TIME,DATABASE_INCARNATION#,GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE FROM GV$RESTORE_POINT;

NAME                        SCN TIME                                     DATABASE_INCARNATION# GUA STORAGE_SIZE
-------------------- ---------- ---------------------------------------- --------------------- --- ------------
restore_point_2017          1.4933E+13 17-Jan-17 11.33.52.000000000 PM                              2 YES   2.4934E+11


sqlplus / as sysdba
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> 
SQL> startup mount
ORACLE instance started.

Database mounted.
SQL> DROP RESTORE POINT restore_point_2017;

Restore point dropped.

SET LINESIZE 200
SET PAGESIZE 200
COL NAME FORMAT A20
COL TIME FORMAT A40
SET TRIMS ON
SELECT NAME,SCN, TIME,DATABASE_INCARNATION#,GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE FROM GV$RESTORE_POINT;

no rows selected

SQL> alter database open read only;

Database altered.

Restart the Managed Recovery
SQL> alter database recover managed standby database using current logfile disconnect; 

ORA-01516: nonexistent log file, data file, or temporary file - Oracle while resizing tempfile

Got below error while resizing the tempfile. 

Error:

sql> alter database tempfile '/user/app/db_home1/data3/db_home1/temp1.dbf' resize 12001m;

alter database tempfile '/user/app/db_home1/data3/db_home1/temp1.dbf' resize 12001m
*
ERROR at line 1:
ORA-01516: nonexistent log file, data file, or temporary file "/user/app/db_home1/data3/db_home1/temp1.dbf"

Fix: 

sql> alter tablespace temp shrink tempfile '/user/app/db_home1/data3/db_home1/temp1.dbf' keep 12G;

Tablespace altered.

ORA-00600: internal error code, arguments: [13013], Table/Index row count mismatch ; SQL error 600 occurred when updating duplicate row in table.

My Oracle 11.2.0.4 database started reporting Ora-600 errors

Upon checking the alert log and Oracle Support (Doc ID 1438920.1) , 

Turns out the Index was corrupted.. Ran the Analyze table command to analyze the problem table

SQL> analyze table APP_USER.ENTRY_HIT VALIDATE STRUCTURE CASCADE;

analyze table APP_USER.ENTRY_HIT VALIDATE STRUCTURE CASCADE

*

ERROR at line 1:

ORA-01499: table/index cross reference failure - see trace file

Trace file shows below

Table/Index row count mismatch

table 384001 : index 384028, 0

Index root = tsn: 7 rdba: 0x02400a5a

The error says the indexes are still bad.

If you run the query through SQL*PLUS it will ask for a rdba number. Enter the value from error message '0x02400a5a' (no quotes). This will return a file number and a block number.

SQL> SELECT dbms_utility.data_block_address_file(

  2           to_number(trim(leading '0' from

  3  replace('&&rdba','0x','')),'XXXXXXXX')

  4         ) AS rfile#,

  5         dbms_utility.data_block_address_block(

         to_number(trim(leading '0' from

  6    7  replace('&&rdba','0x','')),'XXXXXXXX')

  8         ) AS block#

  9  FROM dual;

Enter value for rdba: 0x02400a5a

old   3: replace('&&rdba','0x','')),'XXXXXXXX')

new   3: replace('0x02400a5a','0x','')),'XXXXXXXX')

old   7: replace('&&rdba','0x','')),'XXXXXXXX')

new   7: replace('0x02400a5a','0x','')),'XXXXXXXX')

    RFILE#     BLOCK#

---------- ----------

         9       2650

Next run the following query:

select owner, segment_name, segment_type 

from  dba_segments 

where header_file = <rfile#>

  and header_block = <block#>;

This will give you the offending index to be dropped and recreated.

ORA-00245: control file backup failed; target is likely on a local file system

Error : ORA-00245: control file backup failed; target is likely on a local file system

Cause : the control file is saved on local file system., in case of RAC databases the control file snapshot should be saved on the shared location.

Solution : Make change in RMAN to point the control file snapshot to be saved under shared location

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DB4_ORADATA/snapcf_db4.f';

ORA-00234,ORA-17503,ORA-15045

RMAN> SHOW SNAPSHOT CONTROLFILE NAME; 

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of show command at 09/07/2016 08:41:04
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of full resync command on default channel at 09/07/2016 08:41:04
ORA-00234: error in identifying or opening snapshot or copy control file
ORA-00202: control file: '+DB4_ORADATA'
ORA-17503: ksfdopn:2 Failed to open file +DB4_ORADATA
ORA-15045: ASM file name '+DB4_ORADATA' is not in reference form

Everything I run on the catalog database gives me the above error

Solution :

Make the change as sys user

SQL> EXECUTE SYS.DBMS_BACKUP_RESTORE.CFILESETSNAPSHOTNAME ('+DB4_ORADATA/snapcf_db4.f');

PL/SQL procedure successfully completed.

this resolved the rman issue.. 

"E575: viminfo: Illegal starting char in line:" while opening a file on Linux

Error:
E575: viminfo: Illegal starting char in line: 2015-04-03 12:35:01:64263:1428089701:1428089701:0:ok
E575: viminfo: Illegal starting char in line: 2015-04-03 12:36:01:44948:cronmon.ksh starting as pid 44948 with threshold of 120 seconds.

Reason : 
viminfo file got corrupted

Solution :
viminfo file is present in the user home location, as its hidden file it starts with .viminfo. The solution for this error is deleting this .viminfo file or rename it. This file will get generated again once you open a file.