BOBJ on Oracle Best Practices - Schema vs New DB

[Former Member]

Hi all,

My company is installing Business Objects 4.1 as part of an overall (new) SAP project.  I am the Oracle DB for the project and new to the SAP/Business Objects world.

My question is how do most people separate the different pieces of the overall Business Objects install on the database level?  I was thinking we would have one database with different schemas for Audit, CMS, BODS and Information Steward.  I've heard from our integrator that some companies will have a separate database for each. 

Not knowing the system that well, adding separate databases seems unnecessary.  Where I would have some additional hoops to jump through if a restore was needed for just one of the schemas, it seems better then adding the additional DBs.

Hopefully this makes sense.

Thanks.

[Former Member · Accepted solution]

Hi Michael,

I agree with Mani's suggestion as recommended approach. However, It would depend from org to org.

and if insisted to continue with one database then you would have to scale ORA DB accordingly considering trnsactional nature of each service highlighted (CMS, AUDIT, BODS)

Since, these are transactional you would need to customize database while setup (DB buffer, Undo segments, Shared pool)

I'm assuming you would be using 11g R2 on Linux Operating system(mostly preferred). Hence,

how is Oracle DB deployed(single instance architecture or RAC) on which you would create DB schemas for above services?

In either of the above case you should setup db user for BODS and CMS to conect to the ORA database in "Dedicated server connection" mode and not in "Shared server connection" mode. Hence, no latency provided the Server platform are in the same network or on same server. Audit could connect in "Shared server conection" mode.

In ORA RAC deployment i don't forsee any issues as your transactions could be benefited by "Streams" feature incase of ORA instance failure.

Starting in Oracle 11g Release you may be benefited from automatic PGA memory management can be implemented using

• PGA_AGGREGATE_TARGET initialization parameter for PGA

• MEMORY_TARGET initialization parameter combined total memory for SGA & PGA

I may go on and on. Hope i was able to put some light here. Please refer for more information regarding BODS that might also assist you.

Regards,

Sandeep

[Former Member]

Thank-you very much for the replies.  Your insights are very helpful.  My initial thought was to use separate schemas and those schemas would have their own tablespaces.  Of course I'm going to talk with the integrator.  For recovery purposes has anyone used Table Space Point In Time Recovery method in regards to BOBJ?

[former_member182521]

Hi Michael,

Having different DBs for each independent application with in BusinessObjects would be ideal. Let me explain why. If you are planning to have all the application databases with in a single database with different schema for each, what will you do if there is an issue BODS job which requires a DB reset. Your entire BI application space will be affected and the impact will be high in terms of number of users impacted. This is the reason why it is always recommended independent DB's for each BusinessObjects product.

In our implementations we always recommend something like this

Database 1 -> Schema 1 -> CMS (BO)

Database 1 -> Schema 2 -> Audit (BO)

Database 2 -> Schema 1 -> Central Repository (BODS)

Database 2 -> Schema 2 -> local Repositories (BODS)

Database 3 -> Schema 1 -> Information Steward

Regards

Mani

[Former Member]

Different schemas are the best option.