Hi there! I am cross-training as an application DBA. One thing I am learning is that classes and reading are no substitution for hands on experience. I am lucky to have a team of really good DBAs that are supporting me and helping me to learn. I ask them what I think are pretty basic questions all day and they are tolerating me like a fairly well behaved puppy for now. I'm hoping to get some good feedback from you all on best practices on how to do things in addition to what I am learning from them. I have a really great mentor, but I like to hear how many people do things. So here is my first question. As the application DBA, the developers send me sql scripts that they have tested in dev and stage and ask me to run them against production schemas. Do you log in as your id with superpowers, the sysdba role, or the schema owner to run the sql? Do you run from Toad or as a script (@c:\script) and do you spool your logs and if so how long do you keep them? Do you request your developers to preface the objects in their scripts with the schema name? Do you have a change control process that you go through? Thanks in advance!
~DanceRat
Do you log in as your id with superpowers, the sysdba role, or the schema owner to run the sql?
You can not run the script by logging in as schema owner unless that schema user has appropriate privileges. You can login as superpower user and just set the current_schema=
Do you run from Toad or as a script (@c:\script) and do you spool your logs and if so how long do you keep them?
It is upto every individual. You can run through toad or sqlplus as well. You definately have to spool the logs. Retention period depends on request/criticality. You can make ur own folder to keep the logs
Do you request your developers to preface the objects in their scripts with the schema name?
Depends on the organization env. Generally developers repface the objects with schema name.
Do you have a change control process that you go through?
Sure...it has to be there.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Bookmarks