You will be ended up in not using Oracle stages, as simple as that. You would still able to acheive all the functionality through stored procedures are script and it been called via Datastage, but by this you ultimately loose the efficiency of High speed capacity of Datastage.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
zzgani wrote:But my client is adament on not to give these select privileges on dba tables to ETL user account as they are against the Sox compliance .
I'm sorry, but that is just so wrong and shows a poor understanding of what 'Sox compliance' means. Without those privs you are SOL. So, it's ok for the ETL user to delete production data but not to select from dba views?
The work around is to talk to the DBAs behind the client's back.
-craig
"You can never have too many knives" -- Logan Nine Fingers
Where, in the SOX legislation, does it say that you can't have SELECT privilege to SYS tables?!!
It is IMPOSSIBLE to do damage with only SELECT privilege.
It is also impossible to use the Oracle Enterprise stage without SELECT privilege to these tables, because it (the stage) needs to check the metadata at runtime, so that the design is "idiot-proofed" - a laudable aim, surely?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
zzgani wrote:But my client is adament on not to give these select privileges on dba tables to ETL user account as they are against the Sox compliance .
I'm sorry, but that is just so wrong and shows a poor understanding of what 'Sox compliance' means. Without those privs you are SOL. So, it's ok for the ETL user to delete production data but not to select from dba views?
The work around is to talk to the DBAs behind the client's back.
Hi chulett,
Just to give you some background on this ,we are dealing with Oracle ERP and Siebel as our source systems. I'm not an expert on Sarbanes-Oxley,but the Sarbanes-Oxley act requires that companies monitor and secure financial and other systems, such as ERP, CRM, and SCM, which monitor corporate data.
Currently we require the select privileges on these Oracle ERP and Siebel databases as they are our sources. Since these databases are constantly audited for any unwarrented /undue privileges, the DBA has raised his concern.
So I think it is not completely out of context to mention about Sox compliance here.But the pertinent question is giving select privileges on certain set of sys tables is really a matter of concern.
Probably with Ray's words I can go back and try to convince the DBA that SELECT privileges would not do any damage .
zzgani wrote:Since these databases are constantly audited for any unwarrented /undue privileges, the DBA has raised his concern.
I have been there. I was questioned DataStage's privilige to go directly to my source systems. Just a select to the tables that were to be transformed. They wanted DataStage to call a stored proc., get the data, transform it and call a stored proc. to load. Wierd huh !!!
Sometimes DBA's can be that pushy. But as you mentioned 'undue privilege' is concerning the DBA. Well this is not undue privilige. The stage needs access to these tables to function.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
Infact its responsible for the DBA to maintain all the previlages in an ERP system. Its obvious that ERP will be used my many other system than its own. And those system which deals with DML operation in the system will certainly require permission to certain level. Its impossible to get details of a partition table with out getting access to DBA_TAB_PARTITIONS or USER_TAB_PARTITIONS.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
Not when using the system tables is "hard-wired" into the stage! Presumably because this is the most reliable way.
In any case, it's documented as being required.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
It's odd because they are giving you access to the most sensitive tables - the customer and financial data tables - and are kicking up a stink about irrelevant system tables that have no private information in them. I think you could publish most system tables to the entire world without breaking SOX compliance.
Its a valid point given by Vincent, with which you can speak to DBA. If access is given to core functional tables, there is no point in restricting the system tables. After all, those are for supporting the business.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
.
.
