I ran into an interesting problem recently when attempting to publish an MS Access application with Citrix XenApp. The application pulled data from an Oracle database, so an ODBC connection was created on the Citrix server. What we found was that when a non-privileged user tried to run the application, the connection failed. When the Citrix server admin ran it, however, it worked. Furthermore, as long as the admin was logged in, anybody else could run the application successfully; when he logged out, the users’ connections broke again.

Since Access is not my area of expertise, we finally contacted Microsoft tech support after trying a few suggestions we dug up in our own research. The support analyst clued us in to the following solution, which I pulled from an Oracle Primavera setup document.

From what I’ve seen on different support forums, this seems to be a pretty standard setup task when running Oracle on Windows over Citrix.

If using an Oracle database platform, confirm [that] the Create Global Objects Windows Security Policy is set up on the Terminal Servers and add the domain Users or Groups of the end-users who will be accessing the published application. If the local security policy is not setup, the following steps can be used to add the policy:

1. Click Start, Programs, Administrative Tools, and then click Local Security Policy.
2. Expand Local Policies, and then click User Rights Assignments.
3. In the right pane, double-click Create Global Objects.
4. In the Local Security Policy Setting dialogbox, click Add.
5. In the Select Users or Group dialog box, select the user group that these end users are a part of, click Add, and then click OK.
6. Click OK.

If using an Oracle database platform, the Oracle client software also requires that you give the Authenticated User Group, Read and Execute privilege to the Oracle Home Directory and ALL its sub directories and files on the Terminal Servers.

Read on…

VMSTAT is a tool on Unix type plaforms that provides an impressive amount of resource information, but is formatted in such a way that it can be difficult to read much less determine when the snapshot occurred if looking at historic snapshots. Here is an example

[root@new-host ~]# vmstat 2
procs ———–memory———- —swap– —–io—- –system– —–cpu——
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 1916352 39376 906944 0 0 186 39 1024 1139 1 2 93 4 0
1 0 0 1916352 39384 906968 0 0 0 76 1015 1203 0 2 95 4 0
0 0 0 1916260 39392 906976 0 0 0 58 1014 1118 0 2 98 0 0

Through some simple Unix scripting commands, you can get more user-friendly information from this tool.

The vmstat_tool.sh script below works for most Linux versions:

#!/bin/sh
#vmstat_tool.sh
#vmstat parser script. Makes the information easily readable.

#Ensure that the number of loops and delay parameters
#were passed to this script
if [ $# -ne 2 ]
then
echo “Usage: $0 ”
exit
fi

export LPCNT=$1
export DLAY=$2

c=0

while [ "$c" -lt $LPCNT ]
do
date
vmstat | tail -n 1 | awk ‘{printf(“%d processes are waiting\n%d processes are blocked\n%d virtual memory used, %d idle memory, %d buffer memory, %d cache memory\n%d memory swapped in from disk, %d memory swapped out to disk\n%d blocks per second written\n%d blocks per second read\n%d interrupts per second\n%d context switches per second\nCPU usage: %d%% (user, non-kernel), %d%% (system, kernel), %d%% idle, %d%% wait\n\n”,$1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16)}’

sleep $DLAY
c=$((c+1))
done

Sample Output (Single Loop):

Sat Feb 18 11:15:48 PST 2012
1 processes are waiting
0 processes are blocked
0 virtual memory used, 1990308 idle memory, 32964 buffer memory, 843564 cache memory
0 memory swapped in from disk, 0 memory swapped out to disk
928 blocks per second written
75 blocks per second read
1062 interrupts per second
1128 context switches per second
CPU usage: 4% (user, non-kernel), 2% (system, kernel), 77% idle, 17% wait

As you can see. the output is much more readable than the regular vmstat output.

Should you need to do more than just a cursory examination of the VMSTAT output, you can use these scripts to generate an output file for examination with the following method:

nohup vmstat_tool.sh 288 300 > ./vmstat.log &

In the above example, you are using the native nohup command to run the vmstat_tool.sh script to loop every 5 minutes (300 seconds) for 24 hours (288 5-minute loops). The output will to the vmstat.log script in the local directory and will run in the background by using ‘&’ at the end of the command. Examining the output is a simple matter of using the native cat and grep commands in the following manner:

cat ./vmstat.log | grep “processes are waiting” | more

Sample Output:

0 processes are waiting 0 processes are blocked
0 processes are waiting 0 processes are blocked
0 processes are waiting 0 processes are blocked
0 processes are waiting 0 processes are blocked
0 processes are waiting 0 processes are blocked
0 processes are waiting 0 processes are blocked
0 processes are waiting 0 processes are blocked
0 processes are waiting 0 processes are blocked

You can now see the output of the first line of the VMSTAT tool scrolled one screen at a time. If you see a line that has some abnormal values, you can then use the vi utility to zero in on that particular value and get the timestamp from it.

How it Works

It should work with 10gR2-11gR2 without changes. The first time is run, it will attempt to identify the Grid Infrastructure / CRS home and the version that is being used (CRS/HAS must be up for it to gather)- it takes that information and writes the info to a crsstat.env located in the same location as the script. It only gathers the information the first time, so if you upgrade the Oracle software you will want to remove the crsstat.env and allow the script to re-gather the information.

The output of the script assumes a term width of 132 and attempts to highlight possible issues, by showing in RED those resources with a target of ONLINE and a state of OFFLINE. You can also pass in “search criteria” as the first and only parameter.

Also of note, per Oracle support document 1086563.1, the “State Details” output in 11gR2 could show incorrect information, such as, “Instance Shutdown” even though it is up and running correctly.

Under the covers, the script is utilizing the “crs_stat -t” in 10gR2/11gR1 and “crsctl status resource -t” and then awks their output to create the tabular format. It has been used on AIX and Linux (SuSE, Red Hat, Oracle).

How to Install

Pre-requisite to Installation:

1. CRS/HAS must be running
2. The location of the crsstat script must be writable by the user that will run the installation (either root or your oracle user)

Installation Location:

Generally, it is practical to put the crsstat script in the /usr/local/bin directory, so everyone will have access (in most users path). Make sure the crsstat.env file can be created in the /usr/local/bin directory the first time the script is run. If it is preferred to put it an alternate location, choose a location that is accessible by your Unix users that should be able to list the CRS or HAS resources (i.e. in their PATH).

Installation Process:

1) Copy the installation script from this link http://blog.enkitec.com/wp-content/uploads/2012/04/crsstat.v1.2.1.zip
2) Do a “cp crsstat.v1.2.1.zip /usr/local/bin/”
3) As root run the crsstat and a “crsstat.env” file is created:

# cd /usr/local/bin
# unzip crsstat.v1.2.1.zip
# chmod 755 crsstat
# ./crsstat

Output like example below…

# chmod 644 crsstat.env

4) Verify that the crsstat.env file has two entries like the following:
GRID_HOME=/u01/app/oracle/product/11.2.0/grid
GRID_VER=11.2

Example Usage

Basic Usage (note that the dbfs filesystem is offline when it should be online, thus it is highlight in red):

$ crsstat

Resource Name                            Resource Type  Target       State        Node            State Details
---------------------------------------- -------------- ------------ ------------ --------------- --------------
ora.DATA.dg                              diskgroup      ONLINE       ONLINE       tstdb01
ora.DATA.dg                              diskgroup      ONLINE       ONLINE       tstdb02
ora.LISTENER.lsnr                        Listener       ONLINE       ONLINE       tstdb01
ora.LISTENER.lsnr                        Listener       ONLINE       ONLINE       tstdb02
ora.LISTENER_SCAN1.lsnr                  SCAN Listener  ONLINE       ONLINE       tstdb02
ora.LISTENER_SCAN2.lsnr                  SCAN Listener  ONLINE       ONLINE       tstdb01
ora.LISTENER_SCAN3.lsnr                  SCAN Listener  ONLINE       ONLINE       tstdb01
ora.RECO.dg                              diskgroup      ONLINE       ONLINE       tstdb01
ora.RECO.dg                              diskgroup      ONLINE       ONLINE       tstdb02
ora.SYSTEM.dg                            diskgroup      ONLINE       ONLINE       tstdb01
ora.SYSTEM.dg                            diskgroup      ONLINE       ONLINE       tstdb02
ora.asm                                  ASM            ONLINE       ONLINE       tstdb01
ora.asm                                  ASM            ONLINE       ONLINE       tstdb02
ora.cvu                                  cvu            ONLINE       ONLINE       tstdb01
ora.dbfs.db                              database       ONLINE       ONLINE       tstdb01         Open
ora.dbfs.db                              database       ONLINE       ONLINE       tstdb02         Open
ora.dbfs.filesystem                                     ONLINE       OFFLINE
ora.dbfs.filesystem                                     ONLINE       OFFLINE
ora.demo.db                              database       ONLINE       ONLINE       tstdb01         Open
ora.demo.db                              database       ONLINE       ONLINE       tstdb02         Open
ora.demo.workshop.svc                    service        ONLINE       ONLINE       tstdb01
ora.demo.workshop.svc                    service        ONLINE       ONLINE       tstdb02
ora.tstdb01.vip                          Cluster VIP    ONLINE       ONLINE       tstdb01
ora.tstdb02.vip                          Cluster VIP    ONLINE       ONLINE       tstdb02
ora.net1.network                         Network (VIP)  ONLINE       ONLINE       tstdb01
ora.net1.network                         Network (VIP)  ONLINE       ONLINE       tstdb02
ora.ons                                  Ora Notif Svc  ONLINE       ONLINE       tstdb01
ora.ons                                  Ora Notif Svc  ONLINE       ONLINE       tstdb02
ora.registry.acfs                        registry       ONLINE       ONLINE       tstdb01
ora.registry.acfs                        registry       ONLINE       ONLINE       tstdb02
ora.scan1.vip                            SCAN VIP       ONLINE       ONLINE       tstdb02
ora.scan2.vip                            SCAN VIP       ONLINE       ONLINE       tstdb01
ora.scan3.vip                            SCAN VIP       ONLINE       ONLINE       tstdb01
ora.test.db                              database       OFFLINE      OFFLINE
ora.test.db                              database       OFFLINE      OFFLINE

A couple of examples using the search key:

$ crsstat service

Resource Name                            Resource Type  Target       State        Node            State Details
---------------------------------------- -------------- ------------ ------------ --------------- --------------
ora.demo.workshop.svc                    service        ONLINE       ONLINE       tstdb01
ora.demo.workshop.svc                    service        ONLINE       ONLINE       tstdb02

$ crsstat demo

Resource Name                            Resource Type  Target       State        Node            State Details
---------------------------------------- -------------- ------------ ------------ --------------- --------------
ora.demo.db                              database       ONLINE       ONLINE       enkdb01         Open
ora.demo.db                              database       ONLINE       ONLINE       enkdb02         Open
ora.demo.workshop.svc                    service        ONLINE       ONLINE       enkdb01
ora.demo.workshop.svc                    service        ONLINE       ONLINE       enkdb02

Another example, as sometimes when there are many databases it is useful to pipe the output to grep:

$ crsstat database | grep -i offline

ora.test.db                              database       OFFLINE      OFFLINE
ora.test.db                              database       OFFLINE      OFFLINE

Let’s revisit a use case I alluded to in my earlier blog entry: incorporating LDAP data into a query. Suppose your task is to code a custom authorization scheme for an enterprise application reporting system. You want row access to be determined by a user’s group memberships in the company’s Active Directory server. If a user is assigned to “the Company A group” in Active Directory, he gets to see Company A’s data. You can configure that kind of restriction at a database level using Oracle’s Virtual Private Database feature. Configuring VPD is beyond the scope of this blog entry, but ultimately you will be associating a table to a portion of a SQL WHERE clause that gets appended to every query written against that table. You can find more documentation on VPD on the OTN site. In this case, let’s assume you know that another team has written a PL/SQL database package to query data from Active Directory, and you want to make use of that code. The only problem is that all the functions in that package return collections of various types, and you need to be able to access that information from the WHERE clause you are building with VPD. This is where table functions come in handy.

Let’s begin by setting up our example schema. We’ll be looking at client sales data. First, let’s set up our clients.

CREATE TABLE clients (
  client_id NUMBER,
  client_name VARCHAR2(50));
 
INSERT INTO clients VALUES (100, 'Timco Industries');
INSERT INTO clients VALUES (200, 'Moneybros');
INSERT INTO clients VALUES (300, 'The Monacle Corporation');
INSERT INTO clients VALUES (400, 'Schmapple');

We also need application users who will be logging in to view the report data. We’ll assume each application user is uniquely linked to a user in Active Directory via the external_id column.

CREATE TABLE users (
  sequence_number NUMBER,
  user_name VARCHAR2(20),
  external_id VARCHAR2(20),
  first_name VARCHAR2(30),
  last_name VARCHAR2(30));
 
INSERT INTO users VALUES (1, 'JACKA', 'jaugusti', 'Jack', 'Augustine');
INSERT INTO users VALUES (2, 'KENKI', 'kkidd', 'Ken', 'Kidd');
INSERT INTO users VALUES (3, 'BRIAH', 'bhill', 'Brian', 'Hill');
INSERT INTO users VALUES (4, 'KEOVO', 'kvongkas', 'Keo', 'Vongkaseum');

Finally, we need a data table on which to report.

CREATE TABLE quarterly_sales_data (
  sequence_number NUMBER,
  client_id NUMBER,
  sales_year NUMBER,
  sales_quarter NUMBER,
  sales_amount NUMBER);
 
INSERT INTO quarterly_sales_data VALUES (1, 100, 2011, 1, 20000);
INSERT INTO quarterly_sales_data VALUES (2, 100, 2011, 2, 17500);
INSERT INTO quarterly_sales_data VALUES (3, 100, 2011, 3, 33000);
INSERT INTO quarterly_sales_data VALUES (4, 200, 2011, 1, 4500);
INSERT INTO quarterly_sales_data VALUES (5, 200, 2011, 2, 7000);
INSERT INTO quarterly_sales_data VALUES (6, 200, 2011, 3, 6300);
INSERT INTO quarterly_sales_data VALUES (7, 300, 2011, 1, 11100);
INSERT INTO quarterly_sales_data VALUES (8, 300, 2011, 2, 12800);
INSERT INTO quarterly_sales_data VALUES (9, 300, 2011, 3, 14000);
INSERT INTO quarterly_sales_data VALUES (10, 400, 2011, 1, 55600);
INSERT INTO quarterly_sales_data VALUES (11, 400, 2011, 2, 80000);
INSERT INTO quarterly_sales_data VALUES (12, 400, 2011, 3, 78500);

Our basic report query will look something like this:

SELECT client_name, sales_year, sales_quarter, sales_amount
  FROM quarterly_sales_data NATURAL JOIN clients;

Our Active Directory groups will be TIMCO_GRP, MONEYBROS_GRP, MONACLE_GRP, and SCHMAPPLE_GRP. If a user belongs to one or more of these groups, he has permission to view the respective client’s data.

Now we need a function that returns data from Active Directory. Just to keep it simple we will create a package that hardcodes the group memberships and returns them as collections of various types. We will then look at how table functions can be used to transform each one of those collections into an aggregate result set. (NOTE: querying LDAP directories from PL/SQL is not too difficult, and might serve as the basis for a future blog entry.)

Here’s our function. We’ve placed it in a package called LDAP_UTIL.

CREATE OR REPLACE PACKAGE ldap_util AS
 
  TYPE ldap_entry_typ IS RECORD (
    cn VARCHAR2(30),
    description VARCHAR2(1000),
    distinguished_name VARCHAR2(200),
    name VARCHAR2(30),
    samaccountname VARCHAR2(30));
 
  TYPE ldap_groups_nt IS TABLE OF ldap_entry_typ;
  TYPE ldap_groups_aa IS TABLE OF ldap_entry_typ INDEX BY PLS_INTEGER;
  TYPE ldap_groups_va IS VARRAY(100) of ldap_entry_typ;
 
  FUNCTION get_user_groups_nt (p_user VARCHAR2) RETURN ldap_groups_nt;
  FUNCTION get_user_groups_aa (p_user VARCHAR2) RETURN ldap_groups_aa;
  FUNCTION get_user_groups_va (p_user VARCHAR2) RETURN ldap_groups_va;
 
END ldap_util;
/
SHOW ERRORS
 
CREATE OR REPLACE PACKAGE BODY ldap_util AS
 
  FUNCTION get_user_groups_nt (p_user VARCHAR2) RETURN ldap_groups_nt IS
    l_groups ldap_groups_nt := ldap_groups_nt();
  BEGIN
    CASE p_user
      WHEN 'jaugusti' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'TIMCO_GRP';
        l_groups(1).description := 'Employees working on the Timco Industries account.';
        l_groups(1).distinguished_name := 'CN=TIMCO_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'TIMCO_GRP';
        l_groups(1).samaccountname := 'TIMCO_GRP';
 
      WHEN 'kkidd' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'MONEYBROS_GRP';
        l_groups(1).description := 'Employees working on the Moneybros account.';
        l_groups(1).distinguished_name := 'CN=MONEYBROS_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'MONEYBROS_GRP';
        l_groups(1).samaccountname := 'MONEYBROS_GRP';
 
      WHEN 'bhill' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'TIMCO_GRP';
        l_groups(1).description := 'Employees working on the Timco Industries account.';
        l_groups(1).distinguished_name := 'CN=TIMCO_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'TIMCO_GRP';
        l_groups(1).samaccountname := 'TIMCO_GRP';
 
        l_groups.extend;
        l_groups(2).cn := 'MONACLE_GRP';
        l_groups(2).description := 'Employees working on the Monacle Corporation account.';
        l_groups(2).distinguished_name := 'CN=MONACLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(2).name := 'MONACLE_GRP';
        l_groups(2).samaccountname := 'MONACLE_GRP';
 
      WHEN 'kvongkas' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'MONEYBROS_GRP';
        l_groups(1).description := 'Employees working on the Moneybros account.';
        l_groups(1).distinguished_name := 'CN=MONEYBROS_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'MONEYBROS_GRP';
        l_groups(1).samaccountname := 'MONEYBROS_GRP';
 
        l_groups.extend;
        l_groups(2).cn := 'MONACLE_GRP';
        l_groups(2).description := 'Employees working on the Monacle Corporation account.';
        l_groups(2).distinguished_name := 'CN=MONACLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(2).name := 'MONACLE_GRP';
        l_groups(2).samaccountname := 'MONACLE_GRP';
 
        l_groups.extend;
        l_groups(3).cn := 'SCHMAPPLE_GRP';
        l_groups(3).description := 'Employees working on the Schmapple account.';
        l_groups(3).distinguished_name := 'CN=SCHMAPPLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(3).name := 'SCHMAPPLE_GRP';
        l_groups(3).samaccountname := 'SCHMAPPLE_GRP';
 
    END CASE;
    RETURN l_groups;
  END get_user_groups_nt;
 
  FUNCTION get_user_groups_aa (p_user VARCHAR2) RETURN ldap_groups_aa IS
    l_groups ldap_groups_aa;
  BEGIN
    CASE p_user
      WHEN 'jaugusti' THEN
 
        l_groups(1).cn := 'TIMCO_GRP';
        l_groups(1).description := 'Employees working on the Timco Industries account.';
        l_groups(1).distinguished_name := 'CN=TIMCO_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'TIMCO_GRP';
        l_groups(1).samaccountname := 'TIMCO_GRP';
 
      WHEN 'kkidd' THEN
 
        l_groups(1).cn := 'MONEYBROS_GRP';
        l_groups(1).description := 'Employees working on the Moneybros account.';
        l_groups(1).distinguished_name := 'CN=MONEYBROS_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'MONEYBROS_GRP';
        l_groups(1).samaccountname := 'MONEYBROS_GRP';
 
      WHEN 'bhill' THEN
 
        l_groups(1).cn := 'TIMCO_GRP';
        l_groups(1).description := 'Employees working on the Timco Industries account.';
        l_groups(1).distinguished_name := 'CN=TIMCO_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'TIMCO_GRP';
        l_groups(1).samaccountname := 'TIMCO_GRP';
 
        l_groups(2).cn := 'MONACLE_GRP';
        l_groups(2).description := 'Employees working on the Monacle Corporation account.';
        l_groups(2).distinguished_name := 'CN=MONACLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(2).name := 'MONACLE_GRP';
        l_groups(2).samaccountname := 'MONACLE_GRP';
 
      WHEN 'kvongkas' THEN
 
        l_groups(1).cn := 'MONEYBROS_GRP';
        l_groups(1).description := 'Employees working on the Moneybros account.';
        l_groups(1).distinguished_name := 'CN=MONEYBROS_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'MONEYBROS_GRP';
        l_groups(1).samaccountname := 'MONEYBROS_GRP';
 
        l_groups(2).cn := 'MONACLE_GRP';
        l_groups(2).description := 'Employees working on the Monacle Corporation account.';
        l_groups(2).distinguished_name := 'CN=MONACLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(2).name := 'MONACLE_GRP';
        l_groups(2).samaccountname := 'MONACLE_GRP';
 
        l_groups(3).cn := 'SCHMAPPLE_GRP';
        l_groups(3).description := 'Employees working on the Schmapple account.';
        l_groups(3).distinguished_name := 'CN=SCHMAPPLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(3).name := 'SCHMAPPLE_GRP';
        l_groups(3).samaccountname := 'SCHMAPPLE_GRP';
 
    END CASE;
    RETURN l_groups;
  END get_user_groups_aa;
 
  FUNCTION get_user_groups_va (p_user VARCHAR2) RETURN ldap_groups_va IS
    l_groups ldap_groups_va := ldap_groups_va();
  BEGIN
    CASE p_user
      WHEN 'jaugusti' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'TIMCO_GRP';
        l_groups(1).description := 'Employees working on the Timco Industries account.';
        l_groups(1).distinguished_name := 'CN=TIMCO_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'TIMCO_GRP';
        l_groups(1).samaccountname := 'TIMCO_GRP';
 
      WHEN 'kkidd' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'MONEYBROS_GRP';
        l_groups(1).description := 'Employees working on the Moneybros account.';
        l_groups(1).distinguished_name := 'CN=MONEYBROS_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'MONEYBROS_GRP';
        l_groups(1).samaccountname := 'MONEYBROS_GRP';
 
      WHEN 'bhill' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'TIMCO_GRP';
        l_groups(1).description := 'Employees working on the Timco Industries account.';
        l_groups(1).distinguished_name := 'CN=TIMCO_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'TIMCO_GRP';
        l_groups(1).samaccountname := 'TIMCO_GRP';
 
        l_groups.extend;
        l_groups(2).cn := 'MONACLE_GRP';
        l_groups(2).description := 'Employees working on the Monacle Corporation account.';
        l_groups(2).distinguished_name := 'CN=MONACLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(2).name := 'MONACLE_GRP';
        l_groups(2).samaccountname := 'MONACLE_GRP';
 
      WHEN 'kvongkas' THEN
 
        l_groups.extend;
        l_groups(1).cn := 'MONEYBROS_GRP';
        l_groups(1).description := 'Employees working on the Moneybros account.';
        l_groups(1).distinguished_name := 'CN=MONEYBROS_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(1).name := 'MONEYBROS_GRP';
        l_groups(1).samaccountname := 'MONEYBROS_GRP';
 
        l_groups.extend;
        l_groups(2).cn := 'MONACLE_GRP';
        l_groups(2).description := 'Employees working on the Monacle Corporation account.';
        l_groups(2).distinguished_name := 'CN=MONACLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(2).name := 'MONACLE_GRP';
        l_groups(2).samaccountname := 'MONACLE_GRP';
 
        l_groups.extend;
        l_groups(3).cn := 'SCHMAPPLE_GRP';
        l_groups(3).description := 'Employees working on the Schmapple account.';
        l_groups(3).distinguished_name := 'CN=SCHMAPPLE_GRP,OU=Global Groups,DC=acme,DC=com';
        l_groups(3).name := 'SCHMAPPLE_GRP';
        l_groups(3).samaccountname := 'SCHMAPPLE_GRP';
 
    END CASE;
    RETURN l_groups;
  END get_user_groups_va;
 
END ldap_util;
/
SHOW ERRORS

As you can see, LDAP_UTIL has three functions that return the three kinds of collections in PL/SQL: nested tables, associative arrays, and varrays.

  FUNCTION get_user_groups_nt (p_user VARCHAR2) RETURN ldap_groups_nt;
  FUNCTION get_user_groups_aa (p_user VARCHAR2) RETURN ldap_groups_aa;
  FUNCTION get_user_groups_va (p_user VARCHAR2) RETURN ldap_groups_va;

The collections consist of a group of records representing “group” data from Active Directory.

  TYPE ldap_entry_typ IS RECORD (
    cn VARCHAR2(30),
    description VARCHAR2(1000),
    distinguished_name VARCHAR2(200),
    name VARCHAR2(30),
    samaccountname VARCHAR2(30));

The p_user parameter would be the user’s network id, corresponding to the sAMAccountName attribute in Active Directory; since we’re hardcoding group data this is not important to us at the moment. The point is you pass in a username and you get a collection of groups.

Using the same technique we demonstrated in part one, we now create a wrapper package of pipelined functions to transform the collection data into something we can query – an aggregate result set.

CREATE OR REPLACE PACKAGE ldap_util_pipelined AS
 
  FUNCTION get_user_groups_nt (p_user VARCHAR2) RETURN ldap_util.ldap_groups_nt PIPELINED;
  FUNCTION get_user_groups_aa (p_user VARCHAR2) RETURN ldap_util.ldap_groups_nt PIPELINED;
  FUNCTION get_user_groups_va (p_user VARCHAR2) RETURN ldap_util.ldap_groups_va PIPELINED;
 
END ldap_util_pipelined;
/
SHOW ERRORS
 
CREATE OR REPLACE PACKAGE BODY ldap_util_pipelined AS
 
  FUNCTION get_user_groups_nt (p_user VARCHAR2) 
  RETURN ldap_util.ldap_groups_nt PIPELINED IS
    l_groups ldap_util.ldap_groups_nt;
  BEGIN
    l_groups := ldap_util.get_user_groups_nt(p_user);
    FOR i IN 1 .. l_groups.count LOOP
      PIPE ROW (l_groups(i));
    END LOOP;
    RETURN;
  END get_user_groups_nt;
 
  FUNCTION get_user_groups_aa (p_user VARCHAR2) 
  RETURN ldap_util.ldap_groups_nt PIPELINED IS
    l_groups ldap_util.ldap_groups_aa;
  BEGIN
    l_groups := ldap_util.get_user_groups_aa(p_user);
    FOR i IN 1 .. l_groups.count LOOP
      PIPE ROW (l_groups(i));
    END LOOP;
    RETURN;
  END get_user_groups_aa;
 
  FUNCTION get_user_groups_va (p_user VARCHAR2) 
  RETURN ldap_util.ldap_groups_va PIPELINED IS
    l_groups ldap_util.ldap_groups_va;
  BEGIN
    l_groups := ldap_util.get_user_groups_va(p_user);
    FOR i IN 1 .. l_groups.count LOOP
      PIPE ROW (l_groups(i));
    END LOOP;
    RETURN;
  END get_user_groups_va;
 
END ldap_util_pipelined;
/
SHOW ERRORS

Note the return types of the three functions in ldap_util_pipelined.

  FUNCTION get_user_groups_nt (p_user VARCHAR2) RETURN ldap_util.ldap_groups_nt PIPELINED;
  FUNCTION get_user_groups_aa (p_user VARCHAR2) RETURN ldap_util.ldap_groups_nt PIPELINED;
  FUNCTION get_user_groups_va (p_user VARCHAR2) RETURN ldap_util.ldap_groups_va PIPELINED;

The first two return a nested table collection, while the third returns a VARRAY. These two collections can be pipelined because they correspond to native SQL datatypes in Oracle; not so for associative arrays. In order to pipeline the associative array returned from ldap_util.get_user_groups_aa, we need to map that collection to one of the other types. Here, we map it to a nested table. The iterative logic is the same, though, as the other two functions.

Now we can verify that our approach worked by issuing some simple queries, supported by the SQL “TABLE” construct.

SQL> select * from table(ldap_util_pipelined.get_user_groups_nt('jaugusti'));
 
CN        DESCRIPTION                                        DISTINGUISHED_NAME                            NAME      SAMACCOUN
--------- -------------------------------------------------- --------------------------------------------- --------- ---------
TIMCO_GRP Employees working on the Timco Industries account. CN=TIMCO_GRP,OU=Global Groups,DC=acme,DC=com  TIMCO_GRP TIMCO_GRP

As you can see, the individual attributes of the record structure form the columns of our new table, and we can reference those columns directly, if we wish.

SQL> select cn from table(ldap_util_pipelined.get_user_groups_nt('kvongkas'));
 
CN
---------------
MONEYBROS_GRP
MONACLE_GRP
SCHMAPPLE_GRP

All that’s left for us at this point is to construct a WHERE clause condition to use with Oracle’s Virtual Private Database feature to limit data returned from queries against the table QUARTERLY_SALES_DATA. That condition could look something like this, assuming that our application connects to the database as the logged in user.

client_id IN (SELECT CASE cn
                       WHEN 'TIMCO_GRP' THEN 100
                       WHEN 'MONEYBROS_GRP' THEN 200
                       WHEN 'MONACLE_GRP' THEN 300
                       WHEN 'SCHMAPPLE_GRP' THEN 400
                     END
                FROM TABLE(ldap_util_pipelined.get_user_groups_nt(USER)))

Here the mapping between AD group name and client ID is hardcoded in the CASE expression. A more flexible way would be to create a mapping table. Also, this is probably not a case study in writing a well performing VPD clause, but the real point here is that using SQL table functions and PL/SQL pipelined functions, we can translate data retrieved from an API, LDAP directory, or web service into table-like structures that we can query, join, and otherwise manipulate just like real tables.

Tweet

Making the assumption that you are using RMAN, you have already configured your backups to run a weekly full on each database to tape once per week, incrementals daily, and a reasonable amount of archivelogs being generated daily to the Fast Recovery Area, we can proceed to estimate your immediate needs.

If you are running Oracle and you are using RMAN, you can get the sizing numbers you need for your tape requirements somewhat easily if you are already taking backups to your Fast Recovery Area. There are a number of different views that can provide information about your backups, but I have found the most beneficial information can be gathered from the views used here. The helpful script that follows can be run to collect data on all the different types of backups you are currently running and the sizes (this script allows you to feed a list of SIDs):

#!/bin/bash

. /home/oracle/.bash_profile

ORAENV_ASK=NO

for DB in `echo “$DB_LIST”`; do
export ORACLE_SID=$DB
. oraenv $DB >/dev/null

echo “Database: $DB”

sqlplus -s \/ as sysdba<<EOF
set serveroutput on
set linesize 150
set pagesize 300

select ctime “Date”,

decode(backup_type, ‘L’, ‘Archive Log’, ‘D’, ‘Full’, ‘Incremental’) backup_type,bsize “Size GB” from (select trunc(bp.completion_time) ctime, backup_type, round(sum(bp.bytes/1024/1024/1024),2) bsize

from v\$backup_set bs,

v\$backup_piece bp where bs.set_stamp = bp.set_stamp and bs.set_count  = bp.set_count and bp.status = ‘A’ group by trunc(bp.completion_time), backup_type) order by 1, 2;

exit;
EOF
done

You can then look at the history of your current backups and right-size your tape requirements.

You might also check how many archive logs you are generating in a week under full production load:

col gbytes form 999,999.99

select sum(blocks*block_size)/1024/1024/1024 gbytes

from v$archived_log

where next_time > sysdate-8;

Some things to consider when you decide on your tape solution:

The type of tape drives

Encryption needs

The amount of compression

The number of tape drives

The type of backup software (OSB vs Netbackup vs Tivoli)

Your vaulting schedule (number of available media slots)

How fast can your channel send the data to the tape drives

Assuming you already have a tape SAN and you are not given enough money in your budget or enough lead time to get the gear in place before an audit, you might consider looking at what you have now in place and checking to see if you are doing too many backups, you have tuned your backups incorrectly, or if you have a number of backups that would benefit from VTL or dedup technologies in order to free space on your existing tape infrastructure.

Tweet

CREATE OR REPLACE PACKAGE example AS
 
     TYPE nested_table_typ IS TABLE OF VARCHAR2(100);
 
     FUNCTION get_nested_table_data RETURN nested_table_typ PIPELINED;
 
END example;
/
 
CREATE OR REPLACE PACKAGE BODY example AS
 
     FUNCTION get_nested_table_data RETURN nested_table_typ PIPELINED IS
     BEGIN
          PIPE ROW ('one');
          PIPE ROW ('two');
          PIPE ROW ('three');
          RETURN;
     END get_nested_table_data;
 
END example;
/

The package function example.get_nested_table_data returns a PL/SQL collection — in this case, a nested table. The PIPELINED directive instructs the function to return data to the calling query as rows are populated by the PIPE ROW command. That way, you don’t need to wait for the function to finish before you get results from your query.

The function can be invoked from the SELECT clause of a query in the usual way, and will return a valid result.

SELECT example.get_nested_table_data FROM dual;
 
GET_NESTED_TABLE_DATA
-------------------------------
SCHEMA.SYS_PLSQL_166672_9_1(one,two,three)

This is possible because nested tables and VARRAYs are supported as native types in SQL. The other type of PL/SQL collection, associative arrays, are not. Therefore you cannot use an associative array as the return type of a pipelined table function. However, it’s pretty trivial to create a wrapper function that translates an associative array into a nested table. You wouldn’t necessarily take this approach in your own code, but it comes in handy when you’re transforming data coming from a third party package or function.

But what if you need the contents of the collection presented as a table, with one record per entry in the collection? This is where the TABLE operator comes in handy.

SELECT column_value FROM TABLE(example.get_nested_table_data);
 
COLUMN_VALUE
-------------------
one
two
three

The TABLE operator casts a collection type as an aggregated result set, meaning it allows you to query it as if it were a table.

Why would you need to do this?

One reason might be because you want to query or join data retrieved from a web service, or from an LDAP server. Another reason might be to simplify a complex query with lots of unions, case statements, and subqueries by fetching, manipulating, and combining your data inside a PL/SQL function. You can leverage the ease and maintainability of building your collection in a procedural manner, while still having access to the collection data from SQL. There is some overhead associated with that approach, though, so you’ll want to be careful about applying it in performance-critical situations. Still, though, it’s worth considering when the complexity of SQL constructs gets out of hand.

Tweet

SELECT * FROM RECYCLEBIN;

Dropped tables and any associated objects such as indexes, constraints, nested tables, are not removed when the table is dropped and still occupy space in the tablespace where they originated. They continue to count against user space quotas, until specifically purged from the recyclebin either manually or by the database because of tablespace space constraints.

When you drop a tablespace including its contents, the objects in the tablespace are NOT placed in the recycle bin AND the database purges any entries in the recycle bin for objects located in that tablespace.

When you drop a user, any objects belonging to the user are not placed in the recycle bin and any objects in the recycle bin are purged that belong to that user.

When you drop a cluster, its member tables are not placed in the recycle bin and any former member tables in the recycle bin are purged that belong to that cluster.

When you drop a type, any dependent objects such as subtypes are not placed in the recycle bin and any former dependent objects in the recycle bin are purged.

Recyclebin Settings
In 10g release 1, recyclebin was enabled by default and there was only an undocumented parameter to disable it. This parameter was _recyclebin which defaulted to a value of TRUE. The recyclebin initialization parameter was introduced in 10g release 2 and had a default setting of ‘on’. It was a dynamic parameter and could be enabled or disabled with either an ‘alter session’ or an ‘alter system’ command. Oracle 11g release 1 made no changes to the basic feature, except to add the ‘deferred’ option to the ‘alter session’ command to allow subsequent, but not the current, session to be affected. Release 2 remained unchanged from release 1.
To find out if the recyclebin is enabled, except for 10g release 1, you can execute ‘show parameter recyclebin’ from a SQL prompt as a user with sysdba privileges.
Sample output:

SQL> show parameter recyclebin
 
NAME                                 TYPE                             VALUE
------------------------------------ -------------------------------- ------------------------------
recyclebin                           string                           on

I would recommend keeping the recyclebin enabled at all times, except during an upgrade, to add an extra layer of recovery options to the existing environment.

Using Recyclebin

Once recyclebin is enabled, you don’t have to give much thought to its use. Every time a ‘drop table’ command is executed, the table and its associated objects (indexes, constraints, nested tables) are placed in the recyclebin and renamed with a system-generated naming standard. Because objects age out of the recyclebin based on demands for space, it is always a good idea to back up a table with an export or a create table as select (CTAS) option before dropping it. This is especially true for dropping very large tables which may not fit in the recyclebin.

In the event that you do not want a table to be preserved in the recyclebin, the addition of the ‘purge’ option at the end of the ‘drop table’ statement ensures that the recyclebin bin is bypassed and the table as well as the associated objects are dropped from the database.

Purging the recyclebin can be performed at both the user and system level. As stated earlier, each named account in the database will automatically have a recyclebin assigned to it. A user can simply execute the ‘purge recyclebin’ command to purge their individual recyclebin. Users with the sysdba privilege can purse the entire recyclebin with the ‘purge dba_recyclebin’ command. Be careful, though, as this command also purges the users’ individual recyclebins as well. Purging the entire reyclebin should be reserved for upgrade situations, or unless otherwise directed by Oracle Support.

You can also perform selective purges of the recyclebin. For example ‘purge tablespace tmpdata’ only purges those objects in the recyclebin belonging to the tmpdata tablespace. Also, ‘purge tablespace tmpdata user jon’ will purge only those objects in the recyclebin belonging to the tmpdata tablespace owned by the named user jon. You can also purge individual tables from the recyclebin with the command ‘purge table
’. The table name in this command can be either the system-generated recyclebin name or the original name of the table.

To recover a table from the recyclebin, you need to know if it is available. Use the following query to get this information:

select owner, object_name, original_name, droptime
from dba_recyclebin
where owner = ‘CMN’;
 
OWNER                          OBJECT_NAME                    ORIGINAL_NAME                    DROPTIME
------------------------------ ------------------------------ -------------------------------- -------------------
CMN                            BIN$o5lg4yWjH3ngRAAUT0rhuQ==$0 CMN_BASE_CONTACT                 2011-05-18:23:12:42
CMN                            BIN$o5lg4yWiH3ngRAAUT0rhuQ==$0 CMN_BASE_CONTACT_PK              2011-05-18:23:12:42
CMN                            BIN$o5icV6rtByXgRAAUT0rhuQ==$0 CMN_BASE_CONTACT                 2011-05-18:22:51:07
CMN                            BIN$o5icV6rfByXgRAAUT0rhuQ==$0 CMN_BASE_CONTACT                 2011-05-18:22:17:45
CMN                            BIN$o5lg4yWvH3ngRAAUT0rhuQ==$0 CMN_BASE_CONTACT                 2011-05-18:23:15:11
CMN                            BIN$o5icV6rgByXgRAAUT0rhuQ==$0 EXECUTE_TABLE                    2011-05-18:22:49:58
CMN                            BIN$o5mU5fo6KF/gRAAUT0rhuQ==$0 EXECUTE_TABLE                    2011-05-18:23:30:15
CMN                            BIN$o5icV6ruByXgRAAUT0rhuQ==$0 EXECUTE_TABLE                    2011-05-18:22:53:23
CMN                            BIN$o5mU5foqKF/gRAAUT0rhuQ==$0 CMN_BASE_CONTACT                 2011-05-18:23:27:15
CMN                            BIN$o5mU5fo5KF/gRAAUT0rhuQ==$0 CMN_BASE_CONTACT                 2011-05-18:23:30:08
CMN                            BIN$o5mU5fo4KF/gRAAUT0rhuQ==$0 CMN_BASE_CONTACT_PK              2011-05-18:23:30:08
CMN                            BIN$o5mU5fpGKF/gRAAUT0rhuQ==$0 CMN_BASE_CONTACT                 2011-05-18:23:32:02
CMN                            BIN$o5mU5fpHKF/gRAAUT0rhuQ==$0 EXECUTE_TABLE                    2011-05-18:23:32:02

NOTE – The owner clause in this query was only given to limit the size of the output.

From this output, you can see which tables are present in the recyclebin and when they were dropped. As you can see, there can be several versions of the same table in the recyclebin.

This brings us to the purpose of the recyclebin – recovering an accidentally dropped table. What you may or may not know is that the recyclebin tables can be queried like normal tables. You can query the recyclebin copies of the table until you find the one that contains the data you are interested in…

select count(*)
from cmn."BIN$o5mU5fpGKF/gRAAUT0rhuQ==$0";
 
  COUNT(*)
----------
        89

Note that it is important to use both the owner identifier (CMN) and double-quotation marks because of the special characters in the recyclebin table name.
Once the table you want to recover has been identified, there are a few different methods by which you can recover the table or the individual data. The ‘flashback table
to before drop’ command will recover the latest copy of the table in the recyclebin. You can also specify the ‘rename to ’ at the end of the command to recover the table to a different table name. In the case where there are several copies of the table in the recyclebin and you are not interested in the latest copy, you can do a simple create table as select (CTAS) operation using the recyclebin table name, not the original name. Remember to use double-quotation marks around the recyclebin table name due to the special characters. You should also be able to recover select rows from the recyclebin table using the same method.

Summary
In situations where the code we deploy is beyond our control, this feature may prove invaluable. It is one of those features that you can set and forget, but are very thankful when it is available and you need it.

By default, crontab runs scripts in the user’s home directory, as specified in /etc/passwd. For user “Tim” with home directory /home/tim, a sample crontab might look something like the following:

0 0 * * * runme.sh

Every night at midnight, cron will try to run the file /home/tim/runme.sh. However, if runme.sh is actually in a sub-directory under ~tim, you will need to tell cron how to reach the file. One option would be to qualify the path in crontab, like so:

0 0 * * * ~/bin/runme.sh

Now cron can find the file. However, if the script makes references to other files inside of /bin in a path-relative way, those references will be broken.

#!/bin/bash
#runme.sh
./runthis.sh      # can't find this file when running under cron
./runthat.sh      # can't find this file when running under cron

That’s because to cron ./ is not the directory in which the script is running, but rather whatever is defined as the base directory; in the default case, the user’s home directory.

It is possible to specify the base directory in the crontab file itself by defining the special variable HOME.

HOME=/home/tim/bin
0 0 * * * runme.sh

However, you may not always have control over how your crontab is configured. Perhaps a system administrator is in charge of all the schedules on your server. Or you may organize your scripts in several different directories.

An easy solution is to start your bash scripts with the following command:

cd $(dirname $0)

The program dirname returns the directory portion of the fully qualified path name sent to it. The $0 argument in this context is name of the running script. Basically, this code ensures that the current working directory is the same as the directory in which your script is running. That way all your path-relative references are correct whether running manually or through a scheduler.

Tweet