It’s probably a bit big to be a blog post so I’ve put it on a tab at the top, and at this link:

http://peoplesofttipster.com/sql-developer/

To reduce the likelihood of developers accidentally deleting some data that they shouldn’t it would be quite normal to remove their access to the environment altogether. However if they need access for troubleshooting purposes then (at least on projects I’ve seen) it’s quite normal for developers to be told “OK, you can have access, but be careful not to do anything destructive”. Occasionally – as with everything – things can go wrong. Either someone forgets which environment they’re in, or does something with unintended consequences. An alternative to the “just be careful” approach would be to create an entirely read-only user profile (i.e. one that has display only privileges to every component system-wide).

A read-only user profile is shown in screenshot below, where no fields are editable and the save button is inactivated:

Also, on Run Control pages the ‘Run’ button is inactive. It’s going to be pretty difficult to alter data in this environment.

Here’s how to do it quickly and easily …

1. Create User Profile

First, craft your perfect ‘read/write’ user profile. I’ll call this ‘DMD’. Now clone it using the ‘Copy User Profile’ functionality in the PIA. This creates a new user profile (in my case ‘DMD_R’) with the same Roles, and this is the one we’re going to turn read-only.

2. Create new Read-Only Permission Lists

First create the Permission Lists by cloning those that are currently against the User Profile:

INSERT INTO PSCLASSDEFN
(CLASSID, VERSION, CLASSDEFNDESC, TIMEOUTMINUTES, DEFAULTBPM,
STARTAPPSERVER, ALLOWPSWDEMAIL, LASTUPDDTTM, LASTUPDOPRID)
(SELECT CLASSID || '_R'
      , VERSION
      , CLASSDEFNDESC
      , TIMEOUTMINUTES
      , DEFAULTBPM
      , STARTAPPSERVER
      , ALLOWPSWDEMAIL
      , SYSDATE
      , 'DMD'
   FROM PSCLASSDEFN
  WHERE CLASSID IN (
      SELECT DISTINCT CLASSID
        FROM PSROLECLASS
       WHERE ROLENAME IN (
           SELECT ROLENAME
             FROM PSROLEUSER
            WHERE ROLEUSER = 'DMD_R')))

Don’t forget to add the sign-on times:

INSERT INTO PSAUTHSIGNON (CLASSID, DAYOFWEEK, STARTTIME, ENDTIME)
SELECT CLASSID || '_R'
     , DAYOFWEEK
     , STARTTIME
     , ENDTIME
  FROM PSAUTHSIGNON
 WHERE CLASSID IN (
     SELECT DISTINCT CLASSID
       FROM PSROLECLASS
      WHERE ROLENAME IN (
          SELECT ROLENAME
            FROM PSROLEUSER
           WHERE ROLEUSER = 'DMD_R'))

We add the pages to the new permission lists, but set Display Only to 1:

INSERT INTO PSAUTHITEM (CLASSID, MENUNAME, BARNAME, BARITEMNAME, PNLITEMNAME, DISPLAYONLY, AUTHORIZEDACTIONS)
(SELECT CLASSID || '_R'
      , MENUNAME
      , BARNAME
      , BARITEMNAME
      , PNLITEMNAME
      , 1 DISPLAYONLY
      , AUTHORIZEDACTIONS
   FROM PSAUTHITEM
  WHERE CLASSID IN (
      SELECT DISTINCT CLASSID
        FROM PSROLECLASS
       WHERE ROLENAME IN (
           SELECT ROLENAME
             FROM PSROLEUSER
            WHERE ROLEUSER = 'DMD_R')))

4. Create the new Read-Only Roles

INSERT INTO PSROLEDEFN
(ROLENAME, VERSION, ROLETYPE, DESCR, QRYNAME, ROLESTATUS, RECNAME, FIELDNAME, PC_EVENT_TYPE, QRYNAME_SEC, PC_FUNCTION_NAME, ROLE_PCODE_RULE_ON, ROLE_QUERY_RULE_ON, LDAP_RULE_ON, ALLOWNOTIFY, ALLOWLOOKUP, LASTUPDDTTM, LASTUPDOPRID, DESCRLONG)
(SELECT SUBSTR(ROLENAME, 1,28) || '_R'
      , VERSION
      , ROLETYPE
      , DESCR
      , QRYNAME
      , ROLESTATUS
      , RECNAME
      , FIELDNAME
      , PC_EVENT_TYPE
      , QRYNAME_SEC
      , PC_FUNCTION_NAME
      , ROLE_PCODE_RULE_ON
      , ROLE_QUERY_RULE_ON
      , LDAP_RULE_ON
      , ALLOWNOTIFY
      , ALLOWLOOKUP
      , SYSDATE
      , 'DMD'
      , DESCRLONG
   FROM PSROLEDEFN
  WHERE ROLENAME IN (
      SELECT DISTINCT ROLENAME
        FROM PSROLEUSER
       WHERE ROLEUSER = 'DMD_R'))

5. Add the read only permission lists to the read only roles

INSERT INTO PSROLECLASS(ROLENAME, CLASSID)
(SELECT SUBSTR(ROLENAME, 1,28) || '_R'
      , CLASSID || '_R'
   FROM PSROLECLASS
  WHERE ROLENAME IN (
      SELECT DISTINCT ROLENAME
        FROM PSROLEUSER
       WHERE ROLEUSER = 'DMD_R'))

6. Update the user profile with the new read only rolenames

UPDATE PSROLEUSER
   SET ROLENAME = SUBSTR(ROLENAME, 1,28) || '_R'
 WHERE ROLEUSER = 'DMD_R'

And that’s it, although you may well also need to perform the following:

• Run Portal Security Sync (to sync security up).
• Bounce the App Server and clear cache (my App Server didn’t pick up the signon times from the cloned permission lists until I did this).
• Run SJT_OPR_CLS (Refresh the Security Join Table that contains the Operator and Classid data)
• Close and reopen your Web Browser and clear it’s local cache.

a) how you haven’t found out about it before

b) how much time it’ll save in the future

This is related to taking only a portion of a string using Oracle SQL, and in particular the right hand side of a string.  In other programming languages I’ve been spoilt with the RIGHT(x,num_chars) command, which we don’t have in Oracle.

In the past I’ve made do using something like:

SUBSTR(<character_field>,length(<character_field>)-4,4)

if I wanted to take the 4 right-most characters from a string.  This gets cumbersome pretty quickly when you have multiple substrings etc.

Today – to my delight – I discovered that you can include negative numbers and Oracle will count back from the right hand side.  So this will take the 4 right-most characters from a string:

SUBSTR(<character_field>,-4)

Widely known tip

Most techies who’ve looked under the covers will be aware of PSPCMPROG. It’s the underlying table where PeopleCode is storeed. This isn’t immediately useful however as the actual code itself is stored in the PROGTXT field in binary so it’s not easily accessible. This isn’t an insurmountable issue however as there are a couple of routines to decode the field (an SQR and a Java version, both by David L Price). I’ve not used either method personally, but a colleague has used the SQR version with great success.

For me, this field isn’t quite the most useful on PSPCMPROG. You may have noticed that if you update the PeopleCode on a record, the record properties aren’t updated to reflect the change – I guess because the record definition itself hasn’t changed (although strangely Component and Page PeopleCode do update the timestamp on the corresponding Component/Page definition – so there’s a bit of an inconsistency there). So how do you check when and by whom a piece of Record PeopleCode was last updated? If you check the LASTUPDDTTM and LASTUPDOPRID fields on the PSPCMPROG record via SQL then it’s all recorded there. This snippet of knowledge has saved me (or at least expedited troubleshooting by showing me the correct person to ask about the change) innumerable times.

Lesser known tip

I’ve not really had much reason to look at the PSPCMNAME record in the past, however a colleague and I checked it recently and discovered the RECNAME and REFNAME fields. Every time you create some PeopleCode your code is parsed and a line inserted into PSPCMNAME for every reference to a Tools object. I assume that this is the record searched when using ‘Find Definition References’ within App Designer. However, now we know the SQL table behind this we can therefore query this table to quickly find out objects affected by code in a specified project, for example.

Both the company I currently work for and my previous employer had utilities to export project details to file, printing out settings and details from Tools objects to speed-up the documentation process (and we know how much techies love documenting!). Now we can add to that utility any objects that are affected but which aren’t included in the project.

http://www.roughsea.com/vids/SQL_Best_Practices.html

Stephane clearly knows his topic, but also possesses a wonderful dry wit. His comical example of the developer’s shopping algorithm and the “DBA doing the parameter dance” to tune it had me chuckling away and has made sure that the point won’t be forgotten.

It’s a view where the data is defined via a SQL statement, but the resulting dataset is actually stored in the database (which can then be indexed, analysed etc). Depending upon the parameters chosen Oracle can keep the data in your view in sync with that in the tables upon which it is based. They were originally designed for replication (i.e. holding local copies of remote tables) but they’ve been adapted for performance tuning and reporting use.

When you have a large SQL query, a portion of which could be ‘pre-calculated’, it may well be possible to extract this and use it in a materialized view. This hugely benefits query performance, particularly if you can get some or all of the more complex work done in advance (and run only once too, rather than repeatedly in a nested subquery). It’s preferable to creating a table to do the same as Materialized Views can be updated when the data they are built from alters.

The syntax is as follows:

CREATE MATERIALIZED VIEW <view_name>
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
AS (<Sql Query Goes Here>)

Now you’ve seen the considerable upside, it’s only fair I point out that there are two (fairly minor) potential downsides to Materialized views:

1) As it writes the dataset to the database it does use extra disk space, the increase in query performance should more than offset this negative.

2) If the master table performance receives a lot of inserts, performance may suffer due to the overhead of also inserting into the Materialized View.

This is – as far as I know – an Oracle-only function, however I believe Indexed views in SQL Server are similar to so non-Oracle sites aren’t excluded from this performance improving goodness.

There’s a whole lot more to Materialized Views than the high-level view given here, but a quick Google shows plenty of resources to sate those hungry for more detail.

This cache (or to use the correct term the ‘Shared Pool’) is all very useful, but what if you’re trying to tune a piece of SQL? You want to get a ‘natural’ idea of how long it’ll take to run, not the artificially quick result you’ll get if it’s in the shared pool. (Execution Time is of course not the only measure to consider when tuning, examining the execution plan is critically important.)

We need to flush any mentions of our SQL from the shared pool. DBAs can clear it by issuing the ‘ALTER SYSTEM FLUSH SHARED_POOL’ command, but us un-privileged developers don’t have that luxury (and neither would we want to clear the entire cache).

Instead, re-calculating the statistics on a table means that “all shared SQL areas that contain statements referencing the analyzed schema object are flushed from the shared pool”.

A fuller (and slightly more expertly worded) explanation is available here:

http://download-west.oracle.com/docs/cd/B12037_01/server.101/b10743/memory.htm

Most SQL snippets use multiple joins to the table, I’ve seen one before that used connect_by_prior, but this one is the smallest script yet.

Thanks Jim!

Edit:

this slightly more succinct version may be even better.
select distinct rtrim(reverse
         (sys_connect_by_path(reverse
         (portal_label), ' > ')), ' > ') path
  from psprsmdefn
 where portal_name = 'EMPLOYEE'
   and portal_prntobjname = 'PORTAL_ROOT_OBJECT'
 start with portal_uri_seg2 = :1
connect by prior
         portal_prntobjname = portal_objname

The usual way to return the job row (this could be any table, I’m just picking job as a common example) that’s effective for each Employee at a specific date is probably something similar to this:

SELECT emplid, empl_rcd, effdt, effseq
  FROM ps_job j
 WHERE j.effdt =
    (SELECT MAX (j1.effdt)
       FROM ps_job j1
      WHERE j1.emplid = j.emplid
        AND j1.empl_rcd = j.empl_rcd
        AND j1.effdt <= '10/AUG/2007')
   AND j.effseq =
    (SELECT MAX (j2.effseq)
       FROM ps_job j2
      WHERE j2.emplid = j.emplid
        AND j2.empl_rcd = j.empl_rcd
        AND j2.effdt = j.effdt)

Execution Cost = 3010, time = 1 sec.

SELECT emplid, empl_rcd, effdt, effseq
  FROM (
SELECT emplid, empl_rcd, effdt, effseq,
  RANK () OVER
       (PARTITION BY emplid, empl_rcd
            ORDER BY effdt DESC
                   , effseq DESC) rnk
           FROM ps_job
          WHERE effdt <= '10/AUG/2007') j
 WHERE rnk = 1

Execution Cost = 665, time = 78 msecs.

Not only is the code shorter and easier, the database execution cost is less than a quarter of the ‘standard’ method and the execution time is less than a tenth.

Explain plans and costs are obviously variable depending upon your environment, the tables and indexes and the volume of data; however it should be clear from the example above that there are sometimes quicker ways than the ‘standard’ method.

Analytic Functions are extensions to Oracle SQL that enable common tasks to be accomplished faster than using large blocks of SQL or PL/SQL. They are apparently ‘under review by the ANSI SQL committee for inclusion in the SQL specification’, although whether this will ever happen or not is anyones guess.

The LAG function solves (at least for those of us on Oracle) the oft-encountered issue of retrieving data from a prior row.

The standard way for dealing with this is either to have multiple ’self-joins’ to the same table, or to just use a blank space and populate those fields needing prior row data in a subsequent piece of SQL.

The example below shows how to code SQL to resolve an issue most of us have faced at least once in our careers … you’re pulling back all the employees in JOB who’ve changed departments, but we also want to know which department they’ve come from.
i.e. | EMPLID | EFFDT | NEW_DEPT | OLD_DEPT |

SELECT *
FROM (SELECT j.emplid, j.effdt, j.deptid, LAG (j.deptid, 1, NULL) OVER (PARTITION BY j.emplid, j.empl_rcd ORDER BY j.effdt, j.effseq) old_deptid
FROM ps_job j) j1
WHERE j1.deptid <> j1.old_deptid

The above SQL has an inline view with some columns from the job record, plus the LAG function which provides us with the Deptid from the prior row. The main select just chooses those rows where the current Deptid is different from the previous Deptid.

The LAG function works as follows:

LAG (j.deptid, 1, NULL) OVER (PARTITION BY j.emplid, j.empl_rcd ORDER BY j.effdt, j.effseq)

The first field (j.deptid) is the field that you want the previous value of. The 1 is how many rows to step back, and the NULL is what value is to be used when there is no prior row. The ‘Partition By’ fields are what divides the data into ‘result sets’, in this case we only want it to look back through the job rows for one person at a time, if there are no more rows for that emplid and we encounter data for the next emplid then stop and treat them as a new result set, don’t treat it as a Deptid change. The ‘order by’ fields just tell the function how to sort the rows before searching through them.

The LEAD function only differs from LAG in that it searches for the next row, rather than the previous one.

Quick to write and quick to run …