Oracle DB prerequisites for installing OWB?

Question

Hi,
I am planning to install OWB for a prototype project for a client.
But I wanted to make sure that whatever I do now can be repeated at the time of the actual project too. For other things, I see no problem, but installation remains one.
I need to install Oracle 10g first and then OWB in case of the prototype. But later I will find Oracle DB already in place and just OWB has to be installed.
Is someone aware of the steps required to set up Oracle DB if it has to support OWB later on. Can someone please suggest me the proper way to set up Oracle DB first and then OWB?
I am concerned because in the I have seen OWB installations failing when they were done at an existing Oracle DB setup. (may be some Init parameters were required to be set before OWB is installed)
Also, is anyone aware of some typical problems that we face while working on Red Hat linux?
thanks
Goga

Answer 1

Hi Ron,
Good questions..You have a number of options here and it depends how you want to manage your repository in terms of different environments (dev, test, training etc). In terms of users I would recommend creating a repository owner (in effect the DBA of the repository) and then create additional users for each person in your team. These other users can then connect to the repository and create new projects, design objects and deploy objects as required. By creating new users you can create a security layer within the system to prevent certain team members from deploying objects to specific database instances.
There are a number of options for managing versioning within OWB. There is a demo viewlet on the OWB website that explains the basic concepts, although it relates to OWB 10gR1.
http://www.oracle.com/technology/products/warehouse/htdocs/OTN_viewlet.html
Version management in OWB
With OWB 10gR2 a few things have changed. However, the simplest configuration is to have one design repository and multiple target instances, each with their own OWB repository installation. For the Target schemas, the installation of the OWB repository is used simply to run the control centre as this is required to manage and record the deployment of objects into the various target schemas. You can then create different configurations in your design repository to control the different characteristics of each target instance (use of tablespaces, enabling/disabling parallel features etc).
The flaw with this simple approach is that you have no version control within the design repository. If you make changes to the design repository objects after you have deployed them to a specific schema there is no ability to recreate the target schema if something happens because the design repository has been updated. Therefore, depending on how you want to manage you target schemas in relation to the design repository you may want to create multiple design repositories to support each target schema (dev, test, qa, training, prod etc). Then to update a schema you would export your project from the design repository and import it into the target repository and then deploy the new design to the required schema. This type of approach does provide additional levels security allowing you greater control over access to each target schema.
I thought there was some documentation being developed by the product management team but I have not seen it yet. I hope this helps, if not ping me again.
Keith