• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 409
  • Last Modified:

DBA goes to vacation

I will be out of office for two weeks for vacation. As DBA, what things should I left to my substitute:

- Documentation that includes as much as possible:
Servers with Oracle - O/S users and password
schemas and instances
 scripts to be executed
 backups
 plans of disaster recovery
 exports or imports of dmp

Should I inform System and Sys passwords?
I think this point is sensible. I read once that only the DBA (and the boss) should know the System or Sys password.
Even if I left a Oracle user with DBA grants to my substitute, he/she could change System and Sys passwords.

What is used to do in this kind of cases?
0
miyahira
Asked:
miyahira
2 Solutions
 
slightwv (䄆 Netminder) Commented:
What do you do on a daily/weekly basis as 'normal' tasks.

They should be able to do those.  Like the ones you mentioned: check backups, alert logs, status, etc...

They don't need passwords unless they are needed to do those jobs.  In an emergency the need the ability to connect 'as sysdba' which is SYS.
0
 
slightwv (䄆 Netminder) Commented:
They will also need to know how to contact Support and open an SR.
0
 
miyahiraAuthor Commented:
If it is needed to create users and schemas, or grant privileges to another Oracle users... then substitue would need to use a DBA user...
0
Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

 
slightwv (䄆 Netminder) Commented:
If you don't have scripts that will create users and grant privs then they need the privs to do it.

What is the question then?
0
 
miyahiraAuthor Commented:
Probably I'm wrong, but I understand in this way:

In the script I can have this commands:

***** Start *****
create tablespace HDV
 datafile 'D:\oradata\prod\OPEXT\DATAFILES_DATA\HDV.ORA' size 1g
 autoextend on NEXT 100M maxsize UNLIMITED;

create tablespace HDV_BLOB
 datafile 'D:\oradata\prod\OPEXT\DATAFILES_DATA\HDV_BLOB.ORA' size 3G
 autoextend on NEXT 100M maxsize UNLIMITED;

create tablespace HDV_IDX
 datafile 'D:\oradata\prod\OPEXT\DATAFILES_IDX\HDV_IDX.ORA' size 500M
 autoextend on NEXT 100M maxsize UNLIMITED;

CREATE TEMPORARY TABLESPACE hdvtmp
      TEMPFILE 'D:\oradata\prod\OPEXT\tempfiles\hdvtmp.ora' SIZE 100M
      autoextend on NEXT 10M maxsize UNLIMITED;
     
CREATE USER HDVERM2010
  IDENTIFIED BY xxxxxx
  DEFAULT TABLESPACE hdv
  TEMPORARY TABLESPACE hdvtmp
  PROFILE DEFAULT
  ACCOUNT UNLOCK;

  GRANT resource TO HDVERM2010;
  GRANT CREATE SESSION TO HDVERM2010;
  GRANT CONNECT TO HDVERM2010;
  ALTER USER HDVERM2010 DEFAULT ROLE ALL;
  GRANT UNLIMITED TABLESPACE TO HDVERM2010;
***** Finish *****

I need to connect to Oracle as a DBA user to be able to run the script.
0
 
slightwv (䄆 Netminder) Commented:
You create tablespaces and temp tablespaces on a daily basis and for each user?

I'm not sure create tablespace can be granted,
the online docs can confirm.

Most of the others can be granted to some user.

Either connect as DBA or grant the necessary privs to issue the commands.

Also, you do realize that connect and create session are the same.
0
 
ontechCommented:
Try to provide remote assistance while on vacations. If you can provide remote assistance then password need not revealed to him/her.
For remote assistance you can use
1. LogMeIn
2. TeamViewer.
0
 
mrjoltcolaCommented:
>>Also, you do realize that connect and create session are the same.

Only since 10.2

Prior to that the CONNECT role included a list of other privileges.

If you have old scripts that depended on CONNECT role, you should probably review them.



>>Should I inform System and Sys passwords?

If your substitute is expected to fulfill the role of DBA, give them the DBA passwords. There is no point having a backup DBA if they are not trusted.


>>Even if I left a Oracle user with DBA grants to my substitute, he/she could change System and Sys passwords.

So what? You'll know when you get back, and you fix it.

This is about trust. If you are so suspicious of the person and worried that he will change passwords, then the real question is, Why don't you trust the backup DBA? Therein lies the answer.

Assuming the backup guy is new, or the only person available, but not really qualified, create a junior DBA user for him to use, and seal the SYS/SYSTEM passwords in an envelope, give the envelope to a trusted third party, and have the agreement that in an emergency the envelope shall be opened for the backup DBA only after proper justification. Or just direct him to call you in the case he needs the passwords, so you are assured of being in the loop; but then that isn't really a vacation, is it?
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now