Stupid check for proper instance

Stupid check for proper instance

When you are bouncing between instances as an Oracle DBA, what is a quick way to determine what instance you are in? You certainly don't want to drop tables, tablespaces, etc. in the wrong instance. I've found these simple queries an easy way to quickly determine what instance you are working on.

Many times I am bouncing in and out of a variety of Oracle instances. A quick and dirty trick I have used (as a user with DBA role) is to check the instance name using one of these two select commands: 

 
select * from v$instance;

or

select * from v$database;
It's saved my posterior quite a few times in that I was about to mangle tables, data, etc. This tip has been used on Oracle 8.x and 7.3.4.

Reader Feedback

Jon H. writes: Agreed, this is a good way to determine which instance you (a DBA) are in. What I find to be better is:

select name from v$database;

This saves the hassle of looking through all the fields to recognise which database you are in. For other users, like developers and programmers who do not have DBA privileges, they can use:

select * from global_name;

These are tips I use on a daily basis and they have prevented some disasters from happening.

Niranjan writes: Why do you need to display all the other column data with * ? It would be better to get instance_name from v$instance or name from v$database.

DeniseC. writes: Why "select

    Requires Free Membership to View

    Login

    By submitting your registration information to SearchOracle.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchOracle.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

*"? We have cases where the development and production instances have the same SID; the only difference is that we have development in noarchivelog mode and production in archivelog mode. So the 'select *' from v$database is best for this situation. (P.S. I did not name the SIDs the same -- I inherited the databases!)

RobertG. writes: Why not just use 'show parameter db_name' ?

AndrewR. writes: Yes, "quick and dirty" is right. I prefer to run a little script at each connect that changes the SQL> prompt so that the SID evidence is always at hand. The script is as follows: 

set termout off 
set time on col new_prompt new_value
new_prompt_value SELECT user||':'||substr(global_name,1,instr(global_name||'.','.',1)-1) 
new_prompt 
FROM global_name ; 
set sqlprompt '&new_prompt_value> ' 
set termout on

It should be noted that I acquired this script off a newsletter similar to this -- or it might even have been this one. I have been using it for quite a while.

For More Information

  • Feedback: E-mail the editor with your thoughts about this tip.
  • More tips: Hundreds of free Oracle tips and scripts.
  • Tip contest: Have an Oracle tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize -- submit your tip today!
  • Ask the Experts: Our SQL, database design, Oracle, SQL Server, DB2, metadata, and data warehousing gurus are waiting to answer your toughest questions.
  • Forums: Ask your technical Oracle questions--or help out your peers by answering them--in our active forums.
  • Best Web Links: Oracle tips, tutorials, and scripts from around the Web.

This was first published in August 2002

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top