ORA-01159: file is not from same database as previous files - wrong database id

SQL> @E:\yoonus.sql
ORACLE instance started.
Total System Global Area 1358954496 bytes
Fixed Size                  2077456 bytes
Variable Size             687869168 bytes
Database Buffers          654311424 bytes
Redo Buffers               14696448 bytes
CREATE CONTROLFILE REUSE DATABASE "GEP" NORESETLOGS  ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01159: file is not from same database as previous files - wrong database id
ORA-01517: log member: 'E:\ORACLE\GEP\ORIGLOGA\LOG_G11M1.DBF'


SOLUTION:

Change the control file value from :( if you are using newly installed system's log file change as follows)

CREATE CONTROLFILE REUSE DATABASE "GEP" NORESETLOGS  ARCHIVELOG  to

CREATE CONTROLFILE REUSE SET DATABASE "GEP" RESETLOGS  ARCHIVELOG


SQL> @E:\yoonus.sql
ORACLE instance started.
Total System Global Area 1358954496 bytes
Fixed Size                  2077456 bytes
Variable Size             687869168 bytes
Database Buffers          654311424 bytes
Redo Buffers               14696448 bytes
Control file created.

SQL>

Thanks
Yoonus

ORA-01166: file number 255 is larger than MAXDATAFILES (254)

SQL> @E:\yoonus.sql
ORACLE instance started.
Total System Global Area 1358954496 bytes
Fixed Size                  2077456 bytes
Variable Size             687869168 bytes
Database Buffers          654311424 bytes
Redo Buffers               14696448 bytes
CREATE CONTROLFILE REUSE DATABASE "GEP" NORESETLOGS  ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01166: file number 255 is larger than MAXDATAFILES (254)
ORA-01110: data file 255: 'X:\GEPDB1010\SR3.DATA226'

Solution:

Edit the control file and increase the number of MAXDATAFILE VALUES



STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "GEP" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 255
    MAXLOGMEMBERS 3
    MAXDATAFILES 254 increase to more than your data files count
    MAXINSTANCES 50
    MAXLOGHISTORY 1168
LOGFILE
  GROUP 1 (
    'E:\ORACLE\GEP\ORIGLOGA\LOG_G11M1.DBF',
    'E:\ORACLE\GEP\MIRRLOGA\LOG_G11M2.DBF'
  ) SIZE 50M,
  GROUP 2 (
    'E:\ORACLE\GEP\ORIGLOGB\LOG_G12M1.DBF',
    'E:\ORACLE\GEP\MIRRLOGB\LOG_G12M2.DBF'

Thanks
Yoonus

Unlimit the failed login attempts in ORACLE, SAPSR3: ORA-28000: the account is locked

ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;

Symptom

You cannot log on to the Oracle database and the program returns the message:

ORA-28000: the account is locked

Other Terms

Reason and Prerequisites

ORA-28000 is usually triggered because someone has previously attempted to log on several times using an incorrect password, which causes the logon to fail and returns ORA-01017. The number of allowed logon attempts is defined by the resource FAILED_LOGIN_ATTEMPTS in the profile. You can determine the current value of this parameter using the following query:

SELECT LIMIT FROM DBA_PROFILES
WHERE
  PROFILE = 'DEFAULT' AND
  RESOURCE_NAME = 'FAILED_LOGIN_ATTEMPTS';

Until Oracle 10.1, this parameter had the default value UNLIMITED, so that no ORA-28000 messages would normally occur. As of Oracle 10.2, this standard value has been set to 10.

A further option in the case of a locked user is an explicit lock as follows:

ALTER USER <username> ACCOUNT LOCK;

Solution

To prevent ORA-28000 errors, and avoid similar problems in future, be aware of the following:

• If you use Oracle 9i or earlier, do not manually restrict the authorizations of the default profile (also refer to Note 700548 (16)).

• If FAILED_LOGIN_ATTEMPTS is not set to UNLIMITED, you can adjust it as follows:
  
  ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;

           This is also possible for Oracle 10. 1 and earlier and Oracle 10.2 and later.

• If a user is already locked, you can unlock it as follows:
  
  ALTER USER <username> ACCOUNT UNLOCK;

           If the ORA-28000 error occurred due to a large number of failed logon attempts, you must check why these logon attempts were unsuccessful and returned the ORA-01017 error. The cause is often an incorrect configuration of the OPS$ mechanism. In this case, refer to Note 400241.

  Thanks Yoonus