In OEM 12c Enterprise Manager, you can change both the body and the subject of email alerts through the web-based EM console.
Once logged in, you should see menu options in the top right corner like "Setup" and "Help" with down arrows indicating a drop-down menu.
Click "Setup" -> "Notifications" -> "Customize Email Formats..."
From here, you can select the type of email that is being sent (Metric Alerts, Job Status Changes, etc.), the format (Long or Short), and you can also customize the subject and body of the email by clicking "Customize". A sample email based on your changes will be shown below the "Customize" button.
When customizing an email format, you can add plain text in both the subject and body, and you can also use the predefined labels and attributes (links to these are on this same page) to include dynamic information based on the type of alert and other status values.
Once you save this, your email notifications from OEM 12c should reflect whatever changes you made.
In addition, if you go to "Setup" -> "Notifications" -> "Notification Methods", you can change the name that appears as the sender of the email (e.g., "OEM 12c Administrator") as well as the email address that the alert appears to be sent from. This also allows you to use rules and filtering on the email alerts by filtering on the "FROM:" email address and sender name.
Let's say you created the database with the below parameters:
NLS_COMP=LINGUISTIC
NLS_SORT=BINARY_CI
And by create, I really mean create, from scratch. A DBCA custom database, or running CREATE DATABASE
and dictionary scripts manually.
If this happened, these will be your database level NLS properties:
SQL> select * from nls_database_parameters
where parameter in ('NLS_COMP', 'NLS_SORT')
order by parameter;
PARAMETER VALUE
---------- ----------
NLS_COMP LINGUISTIC
NLS_SORT BINARY_CI
(By default here you should see BINARY
and BINARY
, and to be honest, I can not remember a single case where the database had different values - except the one I have just created in my sandbox.)
Given the above, you will get the same execution plan as in your question. You can restart the instance, or set NLS_COMP
and NLS_SORT
at session or system (instance) level to the same values, it will not 'fix' the execution plan.
To modify the above setting, it is technically possible (but do not ever do this in a real database) to update these values manually (re-running the dictionary scripts will not update this):
SQL> update props$ set value$ = 'BINARY' where name in ('NLS_COMP', 'NLS_SORT');
2 rows updated.
SQL> commit;
Commit complete.
After this (and a shutdown + startup), the same query used the fixed index without any implicit NLSSORT
calls in the filter.
Revert the changes:
SQL> update props$ set value$ = 'BINARY_CI' where name in ('NLS_SORT');
1 row updated.
SQL> update props$ set value$ = 'LINGUISTIC' where name in ('NLS_COMP');
1 row updated.
SQL> commit;
Shutdown, startup, explain, dbms_xplan.display, and it is wrong again.
Another (troublesome, but at least supported) option would be recreating the database with the default (BINARY
, BINARY
) values.
Best Answer
You can get invalid views with a procedure like this:
You can run such procedure once a week triggered by Scheduler Job