Feed aggregator
UKOUG Tech and EBS Conference, Day 0
Today’s the first full day of the UKOUG Technology & EBS Conference in Birmingham, UK, and I’m currently getting my presentations ready for later on today. This year we’ve again got a stand in the main exhibition hall, where we’ll be running demos of OBIEE, Warehouse Builder and the rest of the Oracle BI technology stack. Yesterday though was all about getting up to Birmingham, getting the stand set up and then off in the evening for the second annual ACE Director meal.

The evening was organized by Debra Lilly and myself, with Todd from the OTN team kindly bringing along the credit card and passing along messages from Vikki, Lillian, Justin and the team back from HQ. We had an excellent turnout with 25 ACEs and ACE Directors from around the world, including such names as Steven Feuerstein, Bryn Llewellyn, and Mogens Norgaard, and it was a great chance to catch up with people such as Marco, Dimitri, Dan Morgan, Tim and others that I tend to see only at other conferences around the world.

Today’s a busy day for me, with the following two sessions running later today:
- “Oracle BI EE and Essbase Integration Step-by-Step”, Monday 14:45 – 15:45, presented by myself and Venkat Janakiraman
- “Oracle Warehouse Builder 11gR2 New Features”, Monday 16:15 – 17:00, presented by myself
We’ve also got a fun demo running on the stand (Stand 50) where we’re using OBIEE as part of a football management simulation, where you can pretend to be an investor looking to put money into any of the Premier League teams and seeing, through the use of analytics, writeback and the dashboard where this money would be put to best use. I’m trying to persuade Chris to rig the numbers so that Arsenal always get relegated and Spurs win the league, but I think at least the latter is a bit beyond the powers of Oracle BI – perhaps we need to deploy Essbase in the background. Anyway, if you’re at the conference then be sure to pop by stand 50 if you get a moment, otherwise hopefully I’ll see a few people at the various conference sessions.
UKOUG 2009 – a
OBIEE Software Configuration Management Part 1 : Initial Deployment from DEV to PROD
I’m currently sitting in speaker ready room at the UKOUG Technology & EBS Conference up in Birmingham, and the team are on the stand now ready to meet people at the exhibition. I’ve got an hour or so free now this morning, and so I thought it’d be a good opportunity to blog about one of the sessions we’re delivering later this week at the conference.
The session I’m thinking about is our OBIEE Masterclass that’s running for two hours on the last day of the conference. In previous years we’ve covered the basics of OBIEE development together with performance tuning tips for the BI Server and the underlying Oracle database, and as we’re still waiting for the 11g release to come out, we thought we’d devote this year’s session to some of the perennial questions that come up on the forums, on our blog and when we work with customers. We’re therefore spending half of the masterclass on OBIEE data modeling questions, specifically how do we model normalized data sources, single-table sources and un-conformed star schemas, whilst the second half of the session is being devoted to software configuration management for OBIEE projects.
Software Configuration Management is a topic that seems to come up on most projects, with customers at least wanting to version control their project and have a means to promote code between development, test and production environments. Now there’s not really a defined, standard way to do this with OBIEE projects, and certainly on this blog we’ve talked about various ways to do this, and others have added to the debate with alternatives and suggestions on how to do things better. We’ve also had a utility released, the “Content Accelerator Framework”, that some people have talked about as being a good tool for promoting changes between environments, and now that OBIEE projects are getting more mature and more “enterprise” we’ve also had requests for tips on code branching, code merging and other common software configuration management (SCM) techniques.
So this seemed to me a good area to cover in our OBIEE masterclass. As we’ve got a fair few experts on OBIEE within the company, including people like Venkat J, Adrian Ward, Borkur Steingrimsson and Christian Berg, we had a fair bit of internal debate on what works, what doesn’t work and what’s practical within a project. If you’re interested, I’ve uploaded the resulting slides here and over the next few blog posts, I’ll go through what we came up with, starting in this post with tips on the initial deployment of a project.
To get back to basics though, if you’re working with OBIEE on a project, there are a number of SCM tasks that you’ll want to carry out:
- We’ll want to set up separate development (DEV), production (PROD), and perhaps test (TST) and user acceptance testing (UAT) environments
- We’ll then want to be able to promote OBIEE metadata and configuration files between these environments
- You’ll want to be able to promote individual reports between environments, and create them for users to use
- You’ll typically want to version your project, so that you can identify releases and refer back to previous versions of the project
- You may want to branch the code, or work concurrently on separate but linked projects, and then merge the code back into a single code stream
Within an OBIEE system (disregarding the BI Apps or the underlying data warehouse for the time being), there are a number of project elements that you’ll want to include in this process, including:
- The BI Server repository file (the “RPD” file)
- The BI Presentation Server web catalog (the “webcat”)
- various configuration files (the BI server .INI files, instanceconfig.xml etc)
- various other artifact files (used for setting up writeback, for example), and
- various web files (CSS etc) if you’ve customized the dashboard UI
For the purposes of this posting, we’ll assume you’ve just got DEV and PROD environments (if you have TEST, UAT etc as well, the process is very similar with additional steps in between when you promote code from one environment to the other). For now though we’ll assume you have just a DEV environment, which is where the developers edit and develop the RPD together with a set of shared reports and dashboards; and PROD environment, where the RPD is “read-only” but users create their own reports in their own web catalog folders.

The first thing to bear in mind here, is that you should generally try and have a single BI Server per physical/virtual server, which you may end up clustering with other single BI Servers on other single physical/virtual servers. There are a few workarounds where you can set up a single BI Server with multiple RPDs attached, or indeed install multiple BI Server instances on the same physical/virtual servers, but this is not recommended as OBIEE 10g isn’t really designed for this and you hit issues around files, configuration settings and so on being inadvertently shared amongst all environments. If you want to set up multiple BI Servers on the same box, use VMWare or another such virtualization product to create OS containers and work from there. I have heard that support for multiple BI Servers on the same OS environment is coming in the 11g release, but for now it’s not recommended.
So once you’ve got DEV and TEST environments set up, and you’ve developed your initial system in the DEV environment, how do you go about making use of the PROD environment? For us, you can generally divide up code promotion into two stages:
- The initial deployment of the project from DEV to PROD
- Subsequent updates of PROD from DEV, for example new releases of the project
This initial release typically involves copying the whole project, including the RPD, the web catalog, the supporting web, configuration and artifact files, from the DEV environment to the PROD one, and we don’t have to worry about merging, overwriting or preserving what’s currently in PROD (as there won’t be anything there yet). The second and subsequent migration require a bit more thought though as you’ll typically want to preserve what’s already in production.
Doing the initial DEV to PROD code promotion is therefore a fairly straightforward process, as there aren’t really any decision points, more a series of steps to remember, as shown in the flowchart below:

Starting from the beginning, the typical steps you’d want to perform in this initial migration are:
1. Create a temporary directory somewhere on the DEV server, into which we’ll put all the files to migrate. Shut down the BI Server if the RPD you want to migrate is running online,

and then copy the development RPD to this temporary folder.

2. Next, start the Catalog Manager utility and connect to the web catalog either online or offline. Select (click on) the Shared folder, and then from the application menu select File > Archive. Archive the shared web catalog folder to a file in the temporary directory you created earlier, and then repeat this for the Users directory if there are reports in there that you want to migrate. Don’t archive the whole web catalog, or the System folder, as the production web catalog will get corrupted if you try and copy the system folder from another catalog into it (you’ll not be able to connect to any dashboards or to Answers).

3. Now gather up the various configuration, artifact and other files that you need to copy from this environment to the production one. This list isn’t exhaustive, but you’d typically want to gather up the following files and copy them into the temporary directory on the development server.
$ORACLEBI/server/config/*.*
$ORACLEBIDATA/web/config/instanceconfig.xml
$ORACLEBIDATA/web/config/xdo.cfg
$ORACLEBI/web/javahost/config/config.xml
$ORACLEBI/xmlp/XMLP/Users
$ORACLEBI/xmlp/XMLP/Reports
plus any files that you’ve used to customize the dashboard UI, set up writeback and so on. Once you’ve done this, zip up the temporary directory ready for transferring to the production server.

4. Now copy this ZIP file from the DEV to the TEST server, unzip the file, and copy the files to the correct location on the production server, including the RPD that contains the BI Server repository. Watch out for files like NQSCONFIG.INI and instanceconfig.xml that reference machine names in the files, as you’ll need to update these to reflect the naming in the production environment.
5. It’s generally good practice to do any new project development into a fresh, blank RPD and web catalog, and so if the production server is still pointing towards the Sample Sales or Paint web catalog, you’ll want to create a new one into which you’ll copy the development webcat items in a moment. The safest way to create a new web catalog, with all permissions, folders and so on on created correctly, is to create a new folder in the web catalog folder ($ORACLEBIDATA/web/catalog), reference it in the instanceconfig.xml file and then stop and start the BI Presentation Server. When the Presentation Server starts and finds its pointing to a blank directory, it’ll automatically create all the folders and system items we need, ready for the migration will then do from the development environment.

6. Now it’s time to start the Catalog Manager tool and unarchive the Users and Shared webcat directories from the development environment. You can choose to keep timestamps and permissions, the latter becomes relevant if you’ve set up a security system in development that you want to copy across to production.

7. The RPD that you copied across in step 5 will contain database passwords (and connection details) that may not be relevant in the production environment. If your DBA allows it, you can open up the RPD file and edit the connection pool settings to reflect the production settings.

There are various techniques around to do this in a scripted way, one of my colleagues has defined the database password as a variable and then updated this via an init block and a text file, another technique is this one by Venkat where he uses an undocumented command line interface to the BI Administration tool to set the database password.
8. Now that all of the files are in place, and you’ve copied the RPD over, set the database password(s) and migrated the web catalog entries, one step you’ll want to consider is to make the production RPD file read-only. This stops inadvertent changes to the RPD in production, though if this is inevitable (for quick fixes etc) you can always make it read-write and apply subsequent changes using the Merge feature recently introduced into the BI Administration tool. If you can though, make the production RPD read-only.

It’s worth taking a copy of the first production RPD at this stage, which we’ll call the “baseline RPD”, as we’ll need this later on if we apply subsequent RPD changes using the three-way merge feature in the BI Administration tool. Take this copy and place it somewhere safe, and we’ll use it at a later date when we start doing incremental updates to the production environment.
9. Now, in order to pick up all the changes you’ve introduced with the migrated files, stop and then restart the BI Server, BI Presentation Server, Javahost and BI Scheduler services, and the BI Cluster Controller if you’re using clustering.
10. You’re now ready to use your system in production. Users can now create new reports in production (within their own User folders, if you ware maintaining the Shared webcat folder in development and plan to overwrite it with each subsequent release), or developers can create reports in the development environment if they are dependent on updates they are making to the RPD, which will be put into production as part of a co-ordinated release.
So that’s how we promote the initial release of the project into production. What about subsequent releases, where we have updates to the RPD to promote and potentially some more shared reports and dashboards? Well, we’ll cover this in the next instalment of the series.
Site Upgrade
I spent some time upgrading the web site over the weekend. I'm now running the latest versions of Joomla and all of the components and modules. The look and feel has changed considerably and I even took the time to make up a logo for my company, ERP Associates.
PeopleSoft Corner Blog and the forum are where they've always been. Hopefully all of your old shortcuts still work. Your old username/password combination should work if you're a registered user.
I do encourage you to register if you haven't already done so. Registration makes it easier to post messages on the forum or leave comments. You'll also get access to the members only area of the web site, and you'll be able to use the social networking features when they start rolling out in the near future.
If you do find a problem, have a suggestion about something that could be better or see something you like, please let me know. You can use the "Contact Us" on the main menu, or leave a comment on this post.
BPEL Partnerlinks thoughts
Well at first thought the answer is simple: there is no one-to-one relationship between a partnerlink and invokes of that partnerlink. So you can introduce as many invokes on a certain partnerlink as you want.
However at second thought there are a few considerations. I'll give a few that I came up with:
- Invokes preferably are done in seperate scopes. That is: I prefer to do so. That provides the possibility to catch exceptions on that scope specifically. Variables are kept local as much as possible. Escpecially when the documents they hold can be large. At least you should think about the scope of variables. So if the invoke's input and output variabables are locally declared then they cannot be reused amongst invokes.
- If the input and output variables of the invokes are local and thus not shared, you need to build them up from scratch. This can introduce extra assign steps that might be avoided when declare the variables in a larger spanning scope. Extra assign activities with copy steps cost time. A little perhaps, but still they do. Shared variables are stored to dehydration store over and over again.
- A shared partnerlink has thus shared MCF (managed connection factory)-properties. And possibly other adapter-related properties. Normally you probably want that. So in most cases it is advisable to share partnerlinks escpecially on adapters. Then you have to configure them only once. However in some cases you might (for instance with queues) use other parameters. Maybe you have two EBS-instances and a process calling the same procedure but on seperate instances. Then you need to split them up of course.
- Be aware of transactions. The database adapter normally uses connection-pooled datasources. Database sessions are shared amongst instances. You might expect (but I won't rely on it!) that if you share a database-adapter-partnerlink (invoke it multiple times) in a synchronous process, that every invoke would use the same database-session. So for instance your application context settings, package variables, etc. are shared. Although I would check on run-time, you can use that for performance purposes. In a synchronous process you may rely on the fact that this occurs in the same database-transaction. However, if you use different partnerlinks for in fact the same Pl/Sql procedure/function call, the chance is large that you get another database-session. BPEL might need to rely on XA-transaction mechanisms. I don't think this is functionally a big problem. But might cause issues on processes with high performance requirements.
- Maintenance: having multple partnerlinks for the same database procedure or even the same purpose introduces extra maintenance cost and a higher risk. I would not expect that a BPEL-project would have multiple partnerlinks for the same purpose. So in a Change Request or Test-Issue I tend to solve/change the first partnerlink and forget about possible others. And why should I be different from fellow developers? A good developer is a lazy one...
Input and Output variables are based on the message-definitions of the partnerlinks-wsdl's. So changing one partnerlink might change the message definitions. If you reuse your partnerlinks, changing them will effect all the related variables.
UKOUG 2009 – “Oh Dear; Marco has a brand new Flip”
Got me one. No idea if is useful or if it will add anything to the experience, but instead of shooting pictures, I will have a go at it.
Roel Hartman stated the following while being “shot”.
Couldn’t agree more, by the way…
Twitter Weekly Updates for 2009-11-29
Twitter Weekly Updates for 2009-11-22
Twitter Weekly Updates for 2009-11-15
Twitter Weekly Updates for 2009-11-08
Using EMC Clones and IBM ESS FlashCopy to Backup your Database
Twitter Weekly Updates for 2009-11-01
Twitter Weekly Updates for 2009-10-25
Twitter Weekly Updates for 2009-10-18
UNDO Brain Damage
So I dropped her a line and offered her some space here.
I won't take (all) the credit, but she has since started her own blog, DBA Kevlar.
Automatic Undo can be one of those areas that make you go "hmmmm..." I am fully aware that the documentation that came with Oracle 9i new features for DBA's when Automatic Undo was introduced clearly claimed, "You won't receive another ORA-01555 again!" yet Oracle hasn't quite lived up to that promise in either 9i or 10g and I haven't had the chance to prove otherwise in 11g.
I had the opportunity to revisit my old friend, "ORA-01555" when one of our environments began to page a fellow DBA with the issue the other day. I became intrigued, as I often am by any database oddity and when I queried the amount of undo the process was consuming, it didn't add up with the amount of undo that was being consumed. In our environment, it is not uncommon for 800GB or more of undo to be utilized, but it became quickly apparent something was amiss when looking at the query below vs. the amount of undo allocation of 1.2TB that had been recently allocated by the DBA on call:
select distinctTOTAL GB used from the query above: 45GB
vs.sid, vs.osuser,
vs.process,
vs.sql_id,
round((vu.undoblks*32768) / (1024*1024*1024)) GB,
vu.tuned_undoretention
from v$undostat vu, v$session vs
where vu.maxqueryid in vs.sql_id
group by
vs.sid,
vs.osuser,
vs.process,
vs.sql_id,
vu.undoblks,
vu.tuned_undoretention
order by vs.sid
The first aspect I chose to take into consideration is the "tuned undo retention", as many folks forget that the Oracle parameter UNDO_RETENTION can be over-ridden by the SMON if a process requires blocks from the undo to stay unexpired over the set retention period. I have found in my experience, that if there is a rollback issue with an existing process, inspecting the TUNED_UNDO_RETENTION is an important area to start as a DBA.
After verifying that there were over 7000 different maxquerid's in v$undostat, but that only 20% of them were returning when we were looking at active sessions, I queried to find out what queries have undo blocks set with expirations greater than the set time, (currently 43200 seconds) that were also not in active sessions.
select distinctOne SQL_ID came up as the offender with the majority of undo blocks retained over the retention period and not in active sessions: 1zuumhmqc93zj
vu.maxqueryid,
vu.maxquerylen,
vu.tuned_undoretention
from
v$undostat vu,
v$session vs
where vu.tuned_undoretention > 43200
and vu.maxqueryid not in vs.sql_id
group by
vu.maxqueryid,
vu.maxquerylen,
vu.tuned_undoretention;
The maxqueryid we are looking for isn't active, but if we searched historical SQL, then we found our statement:
select sql_textWhy would a select statement create undo blocks and how could it be using undo if it isn't a current running process and yet showing active undo blocks???
from DBA_HIST_SQLTEXT
where sql_id = '1zuumhmqc93aj';
select col1
from prod.Tbl1
where cnt = 1
If the query is not active - what could it be?
Answer: PREVIOUS
select vs.sidWe now have the SID currently running that is the cause, why worry about the SQL anymore? It's not the current SQL, but a previous sql_id in an active undo process in v$undostat, so at this point, we need to focus on the SID.
from v$undostat vu, v$session vs
where vu.max_queryid=’1zuumhmqc93aj’
and vu.maxqueryid = vs.prev_sql_id;
SID
---
817
So what transpired here?
Upon inspecting SID 817, it was found to be a background session for Oracle two weeks back where someone had issued a kill session command on a poorly coded process! Oracle decided that the select, which was a full scan on a 59GB table, used a cursor into a for loop, was going to take just over two weeks to rollback the killed session! The process to rollback was so sublime, that it hadn't come up as a red flag on any monitoring script or tool, including OEM!
Since no actual data block changes had been performed, it was perfectly safe to stop the rollback and execute a session kill. To free the undo vs. allowing the kill command to continue, we selected the OS Session from V$SESSION for SID 817, proceeded to kill the process at the OS level and issued a reset on the undo tablespace to clear the remaining undo blocks that were active and/or unexpired:
beginBy resetting the undo, we were able to free up the undo that had been tuned to be retained and were able to disregard the rollback on a select statement that had been killed.
reset_undo_stat();
end;
Once we reset the undo, we promptly informed the developer that he/she was never to attempt to use a 59GB non-partitioned table without indexes for a cursor ever, ever again!! :)
Moral of this story
If you have significant undo retained by non-active, non-transactional processes, you should inspect them carefully to verify that they are valid utilization of your undo tablespace. If not, you could receive ORA-01555, snapshot too old errors on transactions that would normally complete successfully, causing incomplete transactions, more rollback occurrence and users asking you why their processes didn't finish.
BIO
Kellyn Pedersen is a Performance Tuning and Operations Database Administration Specialist with 10 years of DBA experience in Oracle, SQL Server and MySQL. She is a Database Administrator and Developer at I-Behavior in Louisville, CO, is busy writing articles, sharing tips on her own blog, DBA Kevlar, and will be presenting at RMOUG 2010 in Denver, CO.
She lives in Westminster, CO with her husband and children - who are wonderfully willing to put up with her strange fascination with Oracle's Cost Based Optimizer.
[ kellyn dot pedersen at gmail | Twitter | LinkedIn ]
Teaching APEX
I'm a bit nervous for multiple reasons.
1. I've never had a problem (well, not in my 30's anyway) getting up and speaking in front of people. My style is light on slides and heavy on winging it. I can do that because I don't often give talks on things I don't know intimately. Don't get me wrong, I have a basic outline to follow, but I have never liked lectures and tried to avoid them at all costs.
2. Leaving the family. The last time I was away from my family for more than a day was 3 years ago, when I moved down to Tampa. Before that, it was 2002 when I went to OOW. I was homesick both times. Homesickness...is a strange thing for me. I grew up as an only child and moved 8 times...so I was always the new kid with no friends. I went to college 2000 miles away from home (CO --> FL). It wasn't until I had a family did I first experience the phenomenon.
3. I have to get on a plane. Yes, it's irrational...I know this. You are far more likely to die on the roads (in the US anyway). Again, this has something to do with the family thing. A feeling of mortality? I don't know. I've probably flown 100 times in my life, I used to love flying...the people watching in the terminal, the feeling of takeoff, landing...
In fact, when I was at UF, I rode this plane countless times...without fear. (And I swear there was duct tape on the propellors...)

I've just been out of the habit of flying. No more Peter Pan Invincibility syndrome for me I guess.
I know lots of you travel quite frequently and are non-plussed by it. I will be thinking of all the people that I know that travel on a regular basis. It might require a beer or 3 to get on board this "first" time.
4. Almost forgot, I get to meet OracleNude. That could be scary too. :)
I guess this post should have been titled, A Fear of Flying, would have been more appropriate.
0×1A
0×1A, better know as the end of file character.
Now also known as the cause of me waisting several hours on analyzing a 500MB raw trace file trying to figure out why the tkprof report did not seemed to be correct.
Still wondering why the application I was tracing had an EOF character in the value of a varchar2 type bind variable.
Cardinality


