mess up (seriously) and Oracle DBA
Wednesday, July 7, 2010
Pokemon Black And White Birthday Invitations
Reading the book "Oracle Database 11g 
Implementations" publisher Packt Publishing written by April C. Sims, makes an excellent summary of situations or activities that Oracle DBA happen if they could make us a hard day or our boss or the boss's boss. Be cautious, focusing on what is done and in some cases to double-check what you are going to run and on which server is only part of the performance to make your job more if it bears the title "DBA" . Seriously, some people have the wrong idea about what a DBA, but that's a topic for another entry. These are the points A. Sims is well to mention.
Avoid using rm-rf *.*
at any time and for whatever reason, try to be specific
Avoid using rm-rf *.*
at any time and for whatever reason, try to be specific
- rm *. log or *. lis or *. trc: it is more likely to support the board and make better use rmdir . It would be even better if you rename the whole directory and then you let one or two days. assume that all files in a directory that you see belong to a single database is an omen of disaster, these files can be created anywhere in the filesystem to which Oracle has write access. Modify access to productive instance at SQL * Plus is not a rule and usually not given directly to the developers unless a person take over that responsibility as the head development.
- is good to use Unix tool
- fuser against a file to determine whether or not to be used before executing commands
- rm or mv . Another way is to force a checkpoint and check the timestamp before disposal. If the file is active, the timestamp is updated. Add ORACLE_SID and prompt the user to SQL. This will prevent disaster to visually inspect the prompt before running a script as you think it's a production server. Use a extended at Unix prompt that contains the hostname, username and ORACLE_SID which will add more tracks visual you make sure you know exactly what you want to modify.
- Copy and paste directly into SQL * Plus or other command-line tool can cause it to execute the wrong code. Best copy and paste into a text editor. Czech thus exactly what is in the buffer copy / paste. Type the word
- production in the command line window after you finish using it. This will prevent accidental disasters when switching between windows if you run something wrong. Fail only because there is no command called production.
- Good recovery scenarios run in a different server production. In addition to testing at the operating system restoration. The site where will the disaster recovery should be on a different server to have real permutation capabilities. sure know how to use all the tools at Oracle from the command line and use the vi editor
- Unix in case you do not count on anything more at your disposal. Preferably
- change the colors of environments and applications, windows or command line tools like Putty that are connected to productive environments which are connected to non-production environments and to increase the size of the largest history saved possible. Unix has a history capture tool called script.
- Warn that you will make a change ... case. Say it aloud can give time for someone to stop or at least confirm that your gonna do that. scripts log file rotation can cause havoc if you named the online redo logs to log
- extension. It would be safer to use the extension
- rdo. unknown An outside consultant will not necessarily give the best advice. Be cautious until you are sure of your expertise and skill. If possible, ask you to work under him so you know what that is doing. Use the number 8 on any type of script in the ORACLE_SID
- or what you are going to support to run something, it can wreak havoc when run as the wildcard character * is above the 8-it's easy typing mistakes and accidentally.
- You always an exhaustive review on the performance of the server operating system, specifically that do not run out of disk space. Be careful when using the 'reuse' when you add or modify a database file. The command overrides the current datafile destroying any information. Be wary
- scripts generated by third-party tools instructions can be powerful. A script can recreate a deleted object first which can be disastrous if that was not backed up information.
- You are responsible for the backups. It is advisable to delegate in any way.
- sure to investigate the use of resources by users who have special access in production. These users can easily take over CPU or I / O that are necessary for OLTP applications.
- the Unix root account is not for everyday use and especially for dedicated tasks for Oracle. Investigates the use of sudo
- to track activities approved root.
- This is the most important tip to avoid carrying the leg-in case of doubt it is best to do nothing that you can not undo, reverse or fix.
- the list mentioned good practices that should not be forgotten in the daily tasks of a DBA. The consequences of committing a serious error in a production database can range from a reprimand to losing a job or getting into legal trouble.
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment