Beware of a new default when installing Oracle 11g! This default can raise its ugly head and bite you in the ass! It just happened to me.
The default has to do with enforcing a password expiration when creating a user. I don’t know about you but we generally have applications (Oracle based as well as SQL Server) which rely on user logins specific for that application. These applications also have configurations in which you specify the user login, sometimes in several locations. Users and application managers come and go and along with them the knowledge of application configurations and where they are. Consequently, we do not change application passwords! As soon as you do, applications break and it could take hours or even days to get them working again.
With this in mind, you might seriously think about changing the Oracle 11g default policy as one of your steps immediately after installation. I did not change the policy as I was unaware of it. I had several user logins become disabled duet to expiring passwords. These also included SYSTEM and DBSNMP! Talk about a real PITA!
Here’s how you can change the password policy:
ALTER PROFILE DEFAULT LIMIT
Oh! And by-the-way, if the password does expire, you cannot unexpire it. You are forced to supply a new password even if it is the same as the old one. Unfortunately in my case, the application was installed by a third party and they were not sure of the password.
I recently installed GRID Control and while “playing around” with it, I discovered the fantastic capability to build a job once and deploy over many targets. I thought this is very cool after experiencing so many problems with Dbconsole.
I found you can create a Job with minimal effort and deploy it to various targets with minimal effort. Database backups fit this mold exceptionally well. In my shop, all of our backups are rather routine and all share common properties: complete backup, daily at 6PM. All of our databases are small enough for complete backups rather than incremental.
Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
I recently ran into this problem and because I could not find much relevant information to resolve it, I decide to write up my resolution process. I am not sure of all the reasons one can encounter a “604” error and this process addresses a problem with corrupted blocks.
My Alert log contained an entry, just prior to the “604”, which indicated I had corrupt data blocks in my SYSTEM01.DBF data file.
Corrupt block relative dba: 0x00400037 (file 1, block 55) Fractured block found during buffer read Data in bad block: type: 0 format: 0 rdba: 0x00000000 last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x00001501 check value in block header: 0x0 block checksum disabled Reread of rdba: 0x00400037 (file 1, block 55) found same corrupted data Tue Sep 09 13:27:59 2008 Errors in file d:\oracle\product\10.2.0\admin\fmax\udump\fmax_ora_668.trc: ORA-00604: error occurred at recursive SQL level 2 ORA-01578: ORACLE data block corrupted (file # 1, block # 55) ORA-01110: data file 1: ‘E:\ORADATA\FMAX\ORADATA\FMAX\SYSTEM01.DBF’
At first I ‘googled” a search for the 604 error text and found meaningful information but no clear way of resolving it. Several suggestions referred to using the ‘START MOUNT’ followed with a ‘RECOVER DATABASE’. I tried that and the database did go through recovery but still would not start. After thinking about it a few minutes, I recalled using RMAN to recover corrupted blocks on an already running database. So, I said to myself: ‘Self, why not use RMAN again’? I knew the database would not open bu RMAN should be able to run against a ‘mounted’ database. I then issued the START MOUNT command in SQLPLUS, brought up another command window (this is a Windoze environment) and ran through the RMAN recover corrupt blocks process
RMAN> connect target connected to target database: FMAX (DBID=1458847106) RMAN> backup check logical validate database; Starting backup at 08-AUG-08 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=245 devtype=DISK channel ORA_DISK_1: starting compressed full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00005 name=E:\ORADATA\FMAX\ORADATA\FMAX\FMAX_DATA.DBF input datafile fno=00001 name=E:\ORADATA\FMAX\ORADATA\FMAX\SYSTEM01.DBF input datafile fno=00003 name=E:\ORADATA\FMAX\ORADATA\FMAX\SYSAUX01.DBF input datafile fno=00006 name=E:\ORADATA\FMAX\ORADATA\FMAX\TOOLS01.DBF input datafile fno=00002 name=E:\ORADATA\FMAX\ORADATA\FMAX\UNDOTBS01.DBF input datafile fno=00004 name=E:\ORADATA\FMAX\ORADATA\FMAX\USERS01.DBF channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25 Finished backup at 08-AUG-08 RMAN> BLOCKRECOVER CORRUPTION LIST; Starting blockrecover at 08-AUG-08 using channel ORA_DISK_1 starting media recovery media recovery complete, elapsed time: 00:00:00 Finished blockrecover at 08-AUG-08 RMAN>
After completing the RMAN recovery, I then issued an ALTER DATABASE OPEN and the database opened just fine. I just hope this little bit of information may help any one else who encounters a similar problem.
eHarmony’s Vice President of Technology, Mark Douglas, cites SQL Server’s row locking mechanics as the biggest detractor. It appears this� was a major roadblock to scaling their application enough to accommodate their fast growth.� Find out more from the entire article here…
eHarmony spurns Microsoft, finds match with Oracle 10g
As announced some time ago, official Oracle Documentation is being indexed by Google as we speak.
will be a great help to Oracle newbies who otherwise would not have
been exposed to the doc unless they thought to become OTN members.