A few tips, as you dive into SQL

In previous posts, I proclaimed "Everything is SQL" (link)
And I re-called which tools you could use to explore the SQL from your database: SQL Developer and SQLcl (or whichever other SQL-client you prefer). (links...)
Now for some tips...

Tip1: Stay Current, and skilled.
Get familiar with your tools and Stay Current: Check the download-sites and keep up with the latest version. You are going to live in the SQL-environment, hence you may as well keep up with current versions. 
For SQL Developer you should probably explore the Web-Version as well.
For SQLcl, the most important item for me is to keep my $SQLPATH correct, or modify it for the task/client at hand. When I do demos or presentations, I often use a special, Clean, version of my sql-scripts.

Tip2: Collect and Save your scripts.
Collect and manage (github) your own set of tool-scripts and familiarise yourself with them. In my case, I have my own scripts for day-to-day examinations, and for troubleshooting. I can quickly clone my private set form github onto just about any machine I get to work on (if not, I have a zipfile, and at times I use old fashioned uuencode to circumvent filters ...)


Tip3: Explore scripts from others. 
There is a lot if useful stuff out there, and you should read some of it just for Inspiration. In the end, you will suffer the "not invented by me" syndrome, but it really helps to see what others did. I use the available tools from Oracle and others. 
Oracle provides AWR, ASH, (or statspack for Standard Edition).
Carlos Sierra maintains sqldb360. 
And for the high-tech folks, there is also the toolset from Tanel Poder. 
This topic merits a whole article by itself, but you can start by exploring the material from Tanel Poder and Carlos Sierra. Links...


Tip4: Always establish “Where You Are”.
Make sure that you are “looking at the problem” and not at some random database(-clone) running in a container on some developer-box. Many ppl seem to logon to the wrong DB (e.g. pre-prod instead of prod). Make sure you are looking at the correct database or instance.
Sounds trivial, but it is one of the most occurring "mistakes" I come across. You have to check and Double Check that you are Actually looking at the right database, and that the supposed problem you see really is the problem the cstmr is having issues with.

Similar when you get mailed a Statspack or AWR report: double + triple check that is was from the correct database, and that the problem-you-want did occur at the time-interval of the report.

The other classic is to run some disastrous stmnt in Production while you were assuming you were just connected to some Dev-copy.
Sorry to hammer on about this, but it has happened too often...
For this reason, my most used, and most valuable scripts are the ones called pr.sql (to set the prompt) and a number of varieties on it. I tend to customise it for the environment I look at. Possibly merits a separate blogpost (future link)

So far the first set of Tips..
next post probably about pr.sql or some of the ready-to-use scripts out there.