OS authentication - using sqlldr but dealing with different schemas [message #112673] |
Mon, 28 March 2005 11:58 |
malayalite
Messages: 5 Registered: March 2005 Location: Canada
|
Junior Member |
|
|
Here's my problem,
we went to get rid of username/passwords sitting around in plain text korn shell, perl and sql files so we're using OS authentication.
Our database has several schemas so when we execute an sql script that refers to schema A its just a matter of
<code>sqlplus -S / script1.sql</code>
and then modifying the code to alter session to schema A, so
script1.sql
<code>
bla bla
alter session set current_schema = schemaA;
bla bla
</code>
how do I apply this same principle to my sqlldr statements? is there anyway to alter session if I calling the sqlldr statement from a ksh file? for example if I change the following :
<code>sqlldr userid=schemaA/schemaApassword control=schemaA.ctl</code>
into
<code>sqlldr userid=/ control=schemaA.ctl</code>
how do I ensure that sqlldr logs in to schema A and not schema B or C?
thanks for the help guys!
Logan
|
|
|
|
Re: OS authentication - using sqlldr but dealing with different schemas [message #587848 is a reply to message #587834] |
Wed, 19 June 2013 00:18 |
|
Michel Cadot
Messages: 68693 Registered: March 2007 Location: Nanterre, France, http://...
|
Senior Member Account Moderator |
|
|
No this is the wrong answer.
- Never ever use SYS (or SYSDBA) but for maintenance purpose (startup, shutdown, backup, recover)
- SYS/SYSDBA is special
- SYS/SYSDBA is Oracle proprietary (try to open a SR/TAR starting with "i did that with SYS/SYSDBA" and you'll see the immediate answer)
- SYS/SYSDBA does not act like any other user
- When you use SYS/SYSDBA Oracle deactivates some code path and activates others
- Whatever you do with SYS/SYSDBA will neither validate nor invalidate the same thing with any other user.
NEVER EVER use SYS/SYSDBA for anything that can be done by another user.
Use SYS/SYSDBA ONLY for something that can't be done by someone else.
Use Secure External Password Store for this.
Regards
Michel
|
|
|