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
    FAILED_LOGIN_ATTEMPTS 10
    PASSWORD_LIFE_TIME UNLIMITED;

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 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.

If you want to quickly and easily build the backups for a dozen or more databases, you can try this process. I’m sure you will find it simple and effective. The basic steps involved are:

1. Build a Job “template” and save it in the Job Library
2. Choose between submitting the Job for scheduling against multiple targets or submitting the Job for each target. This process submits the Job for each target. I chose this method because I believe it gives me more flexibility to accommodate future changes for individual target requirements. You can try both methods to see which best suits your needs.

To start, bring up Oracle Grid Control and then choose the Jobs tab at the top. My screen is shown below. Now click on Job Library tab of that screen.

You should now be in the Job Library. Follow the numbered sequences on the next image below to create a new Library Job

Fill in General information about the Job

Key or paste in your RMAN script into the Parameters screen. I use a very generic script which uses all of the defaults I had previously established in Backup Settings for the target. A copy of my RMAN script is available here for cut & paste.

run {
backup device type disk database;
backup device type disk archivelog all not backed up delete all input;
delete noprompt obsolete device type disk;
}

After entering the script you’ll go on to specifying the Schedule. We won’t worry about the Credentials tab until we deploy to a target.

Set up your Schedule. Because we are deploying to individual targets, you will be able to change this later per target. In my case, all the targets have the same schedule so I can set it here and not worry about it when I deploy.

Deploy your new Job by selecting it from the list and then clicking the Submit button.

Now you will see another Job creation screen with the General settings. However, this one is now in the Jobs category and not the Job Library. You may notice, the Job name has been filled in with the name from your Job Library along with a suffix (most likely .1).  This is the time to add a Target or Targets.

Select one or more from the Targets List. I chose to use one target for each deployment. However, you can deploy one Job to multiple targets at the same time. My preference is to run the deployment for each target thereby creating a Job for each.

We’re back to the General information screen of the Job creation. At this time I also change the suffix for the Job name to match the Instance name of my target.

The Credentials screen gives you the opportunity to choose which credentials you want to use. In my case I am using the preferred credentials which I had already set up for each target.

The final Job scheduled to run every day at 6PM according to the time of the target ( you could have targets in differing time-zones).

If you chose, as I did, to deploy to individual targets, you would now return to the Job Library, select your job, and click submit. This would be repeated for each target.

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: 0×00400037 (file 1, block 55) Fractured block found during buffer read Data in bad block: type: 0 format: 0 rdba: 0×00000000 last change scn: 0×0000.00000000 seq: 0×0 flg: 0×00 spare1: 0×0 spare2: 0×0 spare3: 0×0 consistency value in tail: 0×00001501 check value in block header: 0×0 block checksum disabled Reread of rdba: 0×00400037 (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 spurns Microsoft, finds match with Oracle 10g

This
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.