Just a WAG... plan cache snapshot (dump) looks very much like the database
monitor output file. As you know, there is a wealth of information in there
about every SQL statement SQE executes, including actual parameter marker
values used for host variables and such. Perhaps that's what IBM means by
'security reasons'? I mean, somebody's seeing SQL statements and associated
values when he/she is not supposed to?
As with any WAG, I could be way off the mark there.
<rant of my own>
As for the rant... it really gets my blood boiling when shops that have no
problem hiring multiple DBAs for their Oracle & SQL Server databases will
not allow even a part-time DBA on the System i. What do they think, query
optimizer on i is just magically coming up with consistently good access
plans? I don't get it. IBM is partly to blame there as they still sell the
box with the assumption that all data access is done via RLA. In my
opinion, that notion is outdated. Most shops run at least some SQL and I
actually encounter shops that have standardized on SQL as the access method.
Nice thing about i is that you don't need a full-time DBA, but query
optimizer could use help from a human once in a while.
<rant off>
Elvis
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com
-----Original Message-----
Subject: Plan cache QQQOOOPLNC security implications?
All,
Now that we're finally on v5r4, I've been trying to take a look at various
query related improvements.
When I try to look at the current SQL Plan cache or show the SQL statements
that caused an index to be advised, I get a message about not being
authorized to the *PGM QSYS/QQQOOOPLNC.
Found an IBM technical document:
http://www-912.ibm.com/s_dir/slkbase.NSF/1ac66549a21402188625680b0002037e/8f
37dbd15277d11e8625711b005e95f8?OpenDocument
that says: "When using the SQL Plan Cache Snapshots option in iSeries
Navigator R540, the user requires authority to use program objects
QQQOOOPLNC
and QQQOOOPLAN in QSYS. The default is *PUBLIC *EXCLUDE for security
reasons."
Well hey, that's nice but what exactly are the "security reasons"?
I'm going to have a hard enough time convincing the security folks to change
an IBM supplied object in the first place, even with detailed info about the
security implications.
For that matter, I'm still trying to get Visual Explain to work....
<rant>
What happens when you developers don't have the authority to the tools
needed to analyze and tune SQL queries and your QSECOFRs don't know anything
about SQL or tuning....
Simple, the poorly performing System i gets replaced by an Oracle or SQL
server with a DBA.....
</rant>
Charles
midrange.com
