Search

OakieTags

Who's online

There are currently 0 users and 20 guests online.

Recent comments

SQL

Where do my trace files go? V$DIAG_INFO

Where do oracle trace files go? I don’t know why this piece of info will not stick in my head, I seem to have to look it up 3 or 4 times a year.

If only I had an easy way to find out. There is a very easy way to find out – and that piece of info won’t stay in my head either. So this really is a blog post just for stupid, forgetful me.

V$DIAG_INFO has been available since oracle V11. All the trace files go into the Automatic Diagnostic Repository (ADR) by default.

PL/SQL bug with DBMS_RANDOM?

I think I’ve found an (admittedly obscure) bug with DBMS_RANDOM, group functions, PL/SQL and/or SQL.

Have a look and see if you also think this is odd – or have I missed the totally obvious?

(This is all on 12.1.0.2)

{Update – my conclusion is, and thanks to Joel and Sayan for their comments, that this is not a “bug”. Oracle do not promise us how PL/SQL functions are executed due to the way SQL can be re-written by the parser. I think most of us stumbling over something like this would treat it as a bug though. You have to look at the column projection, again see the comments, to see how Oracle is deciding to get the columns derived by a naked call to DBMS_RANDOM.VALUE (by naked I mean no inclusion of parameters passed in and, significantly, no reference to columns). It’s just the way it is}

The Hitchhiker’s Guide to the EXPLAIN PLAN Part 40: Why is it so hard to get SQL performance right the first time?

In the August 2015 issue of the NoCOUG Journal, we asked Stéphane Faroult why it is so hard to get SQL performance right the first time. His answer implies that SQL itself and the way it is taught are the problems.(read more)

SQL and the Art of Problem Solving

What would you do if you were lost in a labyrinth of underground caves? In the dark. With no food. Mark Twain tells the story of how Tom Sawyer and Becky Thatcher got separated from their picnic group and got lost in a labyrinth of underground caves. What’s that got to do with problem solving? I think that the first rule of problem solving is “If at first you don’t succeed, try, try, again.” Of course, there’s more to problem solving than determination. In his 1945 book “Solve It!”, one of the 20th century’s most notable mathematicians, George Polya, said: “If you cannot solve the proposed problem try to find first some related problem. Could you imagine a more accessible related problem? A more general problem? A more special problem?

SQL for Beginners : Videos and Articles

love-sqlI’ve been saying for some time I should do some more entry level content, but it’s been kind-of hard to motivate myself. I mostly write about things I’m learning or actively using, so going back and writing entry level content is not something that usually springs to mind.

Recently I’ve got involved in a number of “grumpy old man” conversations about the lack of SQL knowledge out there. That, combined with a few people at work getting re-skilled, prompted me to get off my ass and give it a go. It’s actually quite difficult trying to get yourself into the head-space of someone who is coming fresh to the subject. You don’t want to pitch it too low and sound patronizing, but then pitching it too high makes you sounds like an elitist dick.

The Hitchhiker’s Guide to the EXPLAIN PLAN Part 39: Unfriending the optimizer statistics

We can’t help attaching meaning to optimizer statistics. After all, they represent our data, don’t they? So we refresh them as frequently as possible and use the largest sample sizes that we can use. Recently, for the first time in my life, I encountered a group of DBAs who understood that statistics do not have any intrinsic meaning; that they are nothing more than a collection of numbers that influence the generation of query plans. In the case of these DBAs, they found that the strategy that worked best for their applications was to treat the optimizer statistics just as they would treat program code. Statistics were checked into the source code repository just as program code was checked into the source code repository.(read more)

[Oracle] Insights into SQL hints - Embedded global and local hints and how to use them

Introduction

The idea for this blog post started a few weeks ago when i had to troubleshoot some Oracle database / SQL performance issues at client site. The SQL itself included several views and so placing hints (for testing purpose) into the views was not possible, especially as the views were used widely and not only by the SQL with the performance issue. In consequence this blog post is about the difference between embedded global and local hints and how to use them.

 

STANDARD date considerations in Oracle SQL and PL/SQL

Most of us know that the Oracle DATE datatype has upper and lower limits. From the Oracle 11g Database Concepts manual:

Oracle Database can store dates in the Julian era, ranging from January 1, 4712 BCE through December 31, 9999 CE (Common Era, or ‘AD’). Unless BCE (‘BC’ in the format mask) is specifically used, CE date entries are the default.

I never believe 100% anything I read, so I’ll try that. I’ll set my session to show dates with the AD/BC indicator and step back in time:

The Hitchhiker’s Guide to the EXPLAIN PLAN Part 38: Shakespeare’s advice for database upgrades

Previous installment: POISED: A problem-solving method First installment: DON’T PANIC
“ Those friends thou hast, and their adoption tried, Grapple them unto thy soul with hoops of steel; But do not dull thy palm with entertainment Of each new-hatch’d, unfledg’d comrade.”
—some of the advice of Polonius, counselor to King Claudius, to his son Laertes who is leaving for France in Act 1, Scene 3 of The Tragedy of Hamlet, Prince of Denmark by William Shakespeare...(read more)

The Hitchhiker’s Guide to the EXPLAIN PLAN Part 37: POISED: A problem-solving method

P.O.I.S.E.D. is the acronym I invented for the performance tuning method described by Chris Lawson in The Art and Science of Oracle Performance Tuning; it stands for Problem, Observation, Interpretation, Solution, Execution, and Documentation. The Observation and Interpretation phases feed each other. The Interpretation phase concludes with a determination of root cause. If we are investigating poor performance a single SQL statement, the tool of choice for the observation phase is SQLT for all but the simplest cases.(read more)