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.

You add a new SQL Server authentication login with Server Manager and you forget to uncheck the boxes for User must change password, Enforce password, and Enforce Expiration. Being this is an application user for which you don’t want to enforce password restrictions and which uses ODBC, therefore never seeing a login dialog, they never get an opportunity to change the password. Consequently the login can’t be used as is.

Ok, you realize your mistake too late. The login has been created. It has been associated with one or more databases and/or schemas. Permissions have been granted, etc., etc., etc. How do you fix it? Guess what? If you try to just want to uncheck the “User must change” check box, you can’t! It is greyed out.

This conundrum perplexed me to no end when first encountered. Searching the internet turned up several solutions like this one:
ALTER LOGIN test_must_change WITH PASSWORD = ‘newpass’,
      CHECK_POLICY = OFF,
      CHECK_EXPIRATION = OFF;

Guess what happens (you have three choices and the first two don’t count). You get this error message
Msg 15128, Level 16, State 1, Line 1
The CHECK_POLICY and CHECK_EXPIRATION options cannot be turned OFF when MUST_CHANGE is ON.

If you try to user Server Manager and just uncheck the ‘Enforce password policy’ or ‘Enforce password expiration’ boxes, you get this

THE FIX

You MUST change the password first and it must be done without changing the other password policy options. You CAN change the password to be the same as the existing one. However, you do it, you still must effect a change on the password an then change the policy options as a separate step. If you choose to use the Server Manager wizard, when you change the password, the ‘User must change password’ check box will become available and you can then uncheck it (do not uncheck the other policy check boxes if they already were). You can then save the change, open the wizard again, uncheck the other policy restrictions, and save it again.

If you decide to use a query, you can use code similar to this
USE Master
GO
ALTER LOGIN test_must_change WITH PASSWORD = ‘samepassword’
GO
ALTER LOGIN test_must_change WITH
      CHECK_POLICY = OFF,
      CHECK_EXPIRATION = OFF;

eHarmony spurns Microsoft, finds match with Oracle 10g