I’ve had a few folks ask me a similar question about the AWR Warehouse, occuring numerous times this week.
“How can I limit what the user of the AWR Warehouse can view in the AWR Warehouse?”
“How can I add source databases to the AWR Warehouse without DBA privileges?”
This topic bridges into the area of confusion of use of the EM12c environment, (which I consistently promote for use by DBAs, Developers and all of IT) and then the AWR Warehouse, which shares it’s user interface as part of cloud control, that currently is a DBA’s deep analysis and research tool.
The request to limit privileges to add source databases, limit view access to targets, but also bind values, full SQL statements, and advanced performance data impacts the purpose of the AWR Warehouse. I fully understand the security requirements for AWR Warehouse access as stated in Oracle’s support documentation:
“You can add and remove source databases provided you have access to the database target and to database credentials with execute privileges on the sys.dbms_swrf_internal package and the DBA role.”
Why is this important?
The first reasoning would be for space considerations. AWR data with long term retention could add up to a considerable disk space if just any database was added without careful planning to ensure the right database information is retained for the right databases. The power of the Automatic Workload Repository, (AWR) is that its always on, but always on means its always growing and this is best left to a DBA resource to ensure that allocation of space is used wisely.
Second, when discussing limiting view of data in the AWR Warehouse– When investigating an issue with any SQL execution, there are many factors to take into consideration. One of the most significant and commonly important information to answering why a performance issue has occurred, requires me to look into differences in the amount of data resulting in the where clause and objects vs. the data provided to the optimizer.
If we take the following, simple where clause into consideration:
where a.col1=b.col2 and a.col2=:b1 and b.col7=:b2;
When the optimizer uses data provided to it from statistics, histograms and any dynamic sampling, there is going to be a number of choices that can be made from the following information provided.
- Hash join on table a and b to address the join or perform nested loop if…
- Column a.col2 is unique, making the join quite small or…
- Adding b.col7 to a.col2 to the join will make it so unique that a nested loop is sufficient.
Now, what if the optimizer decided to perform a nested loop when 16 million+ rows were returned?
To the untrained eye, some may assume that the optimizer had made a poor choice or that there was a bug and would walk away. More often, if you have the data provided by the values passed to the bind variables, along with the data provided to the optimizer, assumptions would fall away and a very different story would present itself.
This is why Oracle requires DBA privileges to add a source database to the AWR Warehouse and to work with the data provided as part of the AWR Warehouse. This feature provides an abundance of data that is most useful to the professional that knows how to work with the Automatic Workload Repository. This professional, to have the access required to perform this type of analysis and research should be the database administrator, so the requirement for the AWR Warehouse now makes perfect sense.
Now to return to the query, adding in the values for the bind variables, a new picture develops to research:
where a.col1=b.col2 and a.col2=6002 and b.col7='YES';
We now can verify the statistics data behind the values for both a.col2 and b.col7 and accurately diagnose where the optimizer may have been mislead due to incorrect data provided to the Cost Based Optimizer.
This may be a simple explanation behind why I believe in the DBA privilege policy was chosen for source database additions and view options to the AWR Warehouse, but hopefully it sheds a bit of light onto the topic.