I'm just a simple DBA on a complex production system

Writing about all things production. Especially Oracle databases.

Everyone Loves a Reorganization April 30, 2009

Filed under: musing — prodlife @ 1:46 am

At least VPs love them. So when our division’s VP retired and we got a brand new VP, we pretty much knew what to expect.

This reorg has been a good one. Several of my favorite co-workers and managers got amazing promotions. It is terrific to see good and capable people recognized and moved up the management chain. I’m happy to work in an organization that will be run by such a great team.

The DBA team was moved from being part of application production team to the infrastructure team. Now my team mates are the storage manager, the network manager and the monitoring manager. This is a big change, but its going to be great. I love the folks of the infrastructure team. Naturally, we worked together quite a bit in the past and leaving mutual finger-pointing aside, they are really really good at what they do and I’m very happy to be in their team. One of them even reads my blog :)

But even the best reorg is still a jolt. I find myself agonizing over all sort of stuff. The silliest thing I’m worried about is what to put in “rollback decision maker” field in my change requests. My last manager thought that rollback decisions should be made by the person doing the change. The manager before that insisted that he will be the one to make the decision. Both had a point. What is my new manager going to prefer? (I’ll find out in the CAB meeting tomorrow).

This is a good time to reflect on how much my work is shaped by the specific preferences of my direct manager. Some things are very constant – backups will be taken and tested, patches will be applied, production schema will be cloned for development.

But everything else is up for grabs – whether or not the formal change process should be followed, should we get involved in long-term projects, involvement in what other teams are doing, do we try new solutions or stick to what works, whether team members should know what is going on or be kept in the dark, whether team members are allowed to have opinions, etc.

I’m also fretting about bigger things. For example, I hope the new boss will not have problem with blogs, conferences and community involvement.

*******

If you are in the Netherlands on May 26, you should seriously consider going to DBA Symposium. For some reason, many of my favorite Oracle experts are Dutch, and three of them (Rob van Wijk, Frits hoogland and Toons Koppelaars) will be presenting there. Its got to be an amazing symposium.

 

Group By in Shell April 22, 2009

Filed under: Linux,scripts,tips — prodlife @ 6:35 pm

Storage manager dropped by my cube to say that redo log archives for one of our DBs grew from 40G to 200G in the last day. Running “du -Sh” few times showed that the files are no longer getting written as fast, so the issue is probably over. But what was it? And to start, when was it? Once I figure out when the issue occure, I may be able to find the offending DML in ASH.

So, I need to do something like:

select day,hour,sum(bytes)
from (ls -l)
group by day,hour
order by day,hour

I guess I could have used the output of “ls -l”  as an external table and actually run this query. But I’m actually trying to improve my shell scripting skills. There must be some way to do it!

I asked on Twitter, and Kris Rice (of SQLDeveloper fame) pointed me in the right direction – use AWK.

Here’s the result:

ls -l | sed ‘s/:/ /g’ | awk ‘{sizes[$7$8] += int($5)} END {for (hour in sizes)
{ printf(“At %s %d bytes were inserted\n”,hour,sizes[hour])}}’ | sort

I run ls. Use sed to seperate the time into fields (Laurent Schneider will kill me, because I’m mixing sed and awk, but I’m not it his level yet…). After the split, the fifth field contains the file size, the seventh contains the date and the eighth is the hour. So I  have an associative array called “sizes”, indexed on the date and hour, and each bucket contains the sum of the file sizes in this hour.

Then I loop on the array and print the results, and sorted them to make it more readable.

A long post for a short script, but I want to make sure I don’t forget it ;)

Anyway, the best part by far was everyone who tried to help my desperate call in Twitter/Facebook. It was unexpected and very very nice. About 5 people sent tips, ideas and even solutions! I only imagine that doing my work is more fun than doing their own work, but I appreciate the help a lot.

 

I’m Chen and I Read Minds April 21, 2009

Filed under: musing — prodlife @ 8:48 pm

I ran into this post by Seth Godin about super powers. Essentially, he claims that everyone has a superpower, something we are extremely good at. And he thinks we should let everyone know what it is. To quote:

“When you meet someone, you need to have a super power. If you don’t, you’re just another handshake. Don’t say, “Hi, I’m Don, I’m from Cleveland.” Instead, try, “Hi, I’m Don, I tell stories that spread.” It’s not about touting yourself or coming on too strong. It’s about making the introduction meaningful.”

I’ve been fascinated by superheros for most of my life, so this really resonated with me. I immediately knew what’s my super power – I can read minds.

I can sit at one of those meetings where the customer is annoyingly vague about his requirements and keeps waving his hands around as if it explains anything. I ask few questions, drilling down into specific requests he’s made and after the meeting, I tell my team: “The customer wants X. He forgot to ask for Y, but he’ll need this too. He’ll be very happy if we’ll throw in Z as well. He doesn’t need W, even though he asked for it, so we can skip it.”. I always get this right.

In the university this translated to the uncanny ability to accurately predict which topics will appear on the final exam, and which topics you can skip while preparing. This superpower also helps me stay married :)

Obviously my superpower is not something I can do for a living, but working in a team, it is nice to have someone who understands what the customer wants.Especially since the customer does not.

Other DBAs on the team have other powers. “Cut through red-tape”,”Work at 10 times normal speed” and “Make bugs disappear” come to mind, but perhaps my colleagues see their powers differently.

What we are missing is someone who’s superpower is fortune-telling. How much storage will this system require next year? What will happen if we add this application on this server? Will my design scale for the next three years? I’m sure those questions are easy if you just happen to have the right superpower or own a crystal ball.

I’m interested if my readers know what superpowers they have. I’d love to read about them in the comments :)

 

Got Lost Following NoCoug SQL Challenge? April 20, 2009

Filed under: nocoug,sql — prodlife @ 9:54 pm

So did I.

For the last few weeks there were links flying everywhere. Solutions, people commenting on solutions, people commenting on comments, and so on. I got completely lost on who said what to whom. And we are only a month and a half into the competition!

For our collective convenience, I present the definitive list of who said what to whom regarding the NoCoug SQL Challenge. Bravely stolen from Iggy Fernandez by yours truly.

Breaking news:

  1. More prizes! You remember that  the winner will receive six books by his choice from Apress catalog. Apress just donated six more eBooks for the runner ups. I guess they are also overwhelmed by all the great solutions that were sent.
  2. The end date for the competition was not published, but rumors are that it’ll probably happen at the end of June. So if you have a brilliant solution you did not send your results in yet (SQLchallenge@nocoug.org) , it is time to do so.
  3. Remember the “SQL vs. PL/SQL” debate? (If you don’t there are links below). Iggy asked a bunch of oracle gurus their opinion on the topic and publish an article about it on NoCoug’s Journal (I think we are the only Oracle User Group with a quarterly journal).  NoCoug members will get a copy in the mail, as usual. Non-Members can either register really fast or ask their friends if they can borrow a copy :)

Contest announcements:

  1. Official announcement: http://www.nocoug.org/SQLchallenge/FirstSQLchallenge.pdf
  2. Write-up on Chen Shapira’s blog: http://prodlife.wordpress.com/2009/03/31/first-international-nocoug-sql-challenge/

Oracle solutions:

  1. Rob van Wijk’s solution using the MODEL clause (Netherlands): http://rwijk.blogspot.com/2009/03/calculating-probabilities-with-n-throws.html
  2. Vadim Tropashko’s solution using Common Table Expressions (USA): http://vadimtropashko.wordpress.com/2009/03/25/variable-number-of-joins/
  3. Laurent Schneider’s solution using CONNECT BY and XMLQUERY (Switzerland): http://www.amazon.com/gp/blog/post/PLNKI2MYB0YCYAUL/#Mx1E6DR4VGI3O9Z
  4. Craig Martin’s solution using CONNECT BY and logarithms (USA): http://www.amazon.com/gp/blog/post/PLNKI2MYB0YCYAUL/#Mx26NK96OBG2FLQ
  5. Alberto Dell’Era’s two solutions using Fourier transforms (Italy): http://www.adellera.it/investigations/nocoug_challenge/index.html
  6. Fabien (Waldar) Contaminard’s solution using the multinomial distribution (France): http://www.waldar.org/blog/200904/nocougs-first-sql-challenge

Non-Oracle solutions:

  1. Postgres solution (Romania): http://hype-free.blogspot.com/2009/04/nocoug-sql-challenge.html

Commentaries:

  1. Comment on Alberto Dell’Era’s solution by Jonathan Lewis: http://jonathanlewis.wordpress.com/2009/04/15/model/
  2. Analysis of Alberto Dell’Era’s solution by Iggy Fernandez: http://prodlife.wordpress.com/2009/03/31/first-international-nocoug-sql-challenge/#comment-2772

Debate on the merits of SQL and PL/SQL

  1. Rob van Wijk: http://rwijk.blogspot.com/2009/03/choosing-between-sql-and-plsql.html
  2. Chen Shapira: http://prodlife.wordpress.com/2009/03/20/would-you-rather-maintain-sql-or-plsql/
  3. Laurent Schneider: http://laurentschneider.com/wordpress/2009/03/to-sql-or-to-plsql.html
  4. H.Tonguç Yýlmaz: http://tonguc.wordpress.com/2009/03/21/hot-discussion-sql-or-plsql/

Whew, quite a link collection. Now I’m obsessing whether or not I missed anyone!
If I did, let me know if the comments. I’ll keep editing this post with the latest info.

 

Shrinking Tables Once More April 13, 2009

Filed under: 11g,plsql,tips — prodlife @ 6:35 pm

Commenting on my post from last week, “an oracle dba” said:

“”shrink” would down the HWM of object, but may not for datafile. and it would invalidate the dependent plsql/trigger definitely.”

I did not believe that! Surely something as innocent as shrinking has no reason to invalidate the triggers. Maybe in 10g, but 11g has Fine Grained Dependencies, surely merely shrinking can’t invalidate a trigger in 11g!

So I tried it:

SQL> create table test2 (ID number, c_date date);

Table created.

SQL> create trigger trig1
  2  after insert on test
  3  referencing new as newrow
  4  for each row
  5  begin
  6  insert into test2 values (:newrow.id,sysdate);
  7  end trig1;
  8  /

Trigger created.

SQL> select object_name,object_type,status from user_objects where object_name='TRIG1';

OBJECT_NAME         OBJECT_TYPE          STATUS
-------------       -------------------  -------
TRIG1               TRIGGER             VALID

SQL> delete from test where mod(id,5)=0;

1000 rows deleted.

SQL> alter table test enable row movement ;

Table altered.

SQL>  alter table test shrink space cascade;

Table altered.

SQL> alter table test disable row movement ;

Table altered.

SQL> select object_name,object_type,status from user_objects where object_name='TRIG1';

OBJECT_NAME         OBJECT_TYPE          STATUS
-------------       -------------------  -------
TRIG1                TRIGGER             INVALID

Learn something new every day :)
Thanks “an oracle dba”!

 

Stand Back. I’m Going to Try Science. April 8, 2009

Filed under: musing — prodlife @ 2:57 am

So these days I’m working on a presentation about streams troubleshooting. I did a nice troubleshooting demo in OOW08, but this time I wanted something more theoretical.

I want to give my audience a feel of what Tanel Podel calls “Systematic Approach” and Jonathan Lewis calls “Scientific Method”.

Thinking about all this, reminded me of a lesson from my favorite book – “Zen and the Art of Motorcycle Maintenance”. In the book, the protagonist explains how to use the scientific method to troubleshoot his motorcycle.

The scientific method uses logic. And the book explains about two kinds of logic:

“Two kinds of logic are used, inductive and deductive. Inductive inferences start with observations of the machine and arrive at general conclusions. For example, if the cycle goes over a bump and the engine misfires, and then goes over another bump and the engine misfires, and then goes over another bump and the engine misfires, and then goes over a long smooth stretch of road and there is no misfiring, and then goes over a fourth bump and the engine misfires again, one can logically conclude that the misfiring is caused by the bumps. That is induction: reasoning from particular experiences to general truths.

Deductive inferences do the reverse. They start with general knowledge and predict a specific observation. For example, if, from reading the hierarchy of facts about the machine, the mechanic knows the horn of the cycle is powered exclusively by electricity from the battery, then he can logically infer that if the battery is dead the horn will not work. That is deduction.”

Sometimes I read people claiming that only one of these inferences counts as truly scientific. I don’t really see how you can work with just on of them. You need good dose of both just to create a reproducable test case of a problem.

Next comes the most perfect description of systematic troubleshooting. It is so good that I don’t see how anything else can be added to this or said after that. Just substitute Oracle for Nature, Database for Motorcycle, your current problem to the electricity system and your favorite v$ views for spark plugs…

Its going to be a quite a read, but its worth it. I also highlighted my favorite quotes :)
Now I just have to figure out how to put this into a presentation.

“For this you keep a lab notebook. Everything gets written down, formally, so that you know at all times where you are, where you’ve been, where you’re going and where you want to get. In scientific work and electronics technology this is necessary because otherwise the problems get so complex you get lost in them and confused and forget what you know and what you don’t know and have to give up. In cycle maintenance things are not that involved, but when confusion starts it’s a good idea to hold it down by making everything formal and exact. Sometimes just the act of writing down the problems straightens out your head as to what they really are.

The logical statements entered into the notebook are broken down into six categories: (1) statement of the problem, (2) hypotheses as to the cause of the problem, (3) experiments designed to test each hypothesis, (4) predicted results of the experiments, (5) observed results of the experiments and (6) conclusions from the results of the experiments. This is not different from the formal arrangement of many college and high-school lab notebooks but the purpose here is no longer just busywork. The purpose now is precise guidance of thoughts that will fail if they are not accurate.

The real purpose of scientific method is to make sure Nature hasn’t misled you into thinking you know something you don’t actually know. There’s not a mechanic or scientist or technician alive who hasn’t suffered from that one so much that he’s not instinctively on guard. That’s the main reason why so much scientific and mechanical information sounds so dull and so cautious. If you get careless or go romanticizing scientific information, giving it a flourish here and there, Nature will soon make a complete fool out of you. It does it often enough anyway even when you don’t give it opportunities. One must be extremely careful and rigidly logical when dealing with Nature: one logical slip and an entire scientific edifice comes tumbling down. One false deduction about the machine and you can get hung up indefinitely.

In Part One of formal scientific method, which is the statement of the problem, the main skill is in stating absolutely no more than you are positive you know. It is much better to enter a statement “Solve Problem: Why doesn’t cycle work?” which sounds dumb but is correct, than it is to enter a statement “Solve Problem: What is wrong with the electrical system?” when you don’t absolutely know the trouble is in the electrical system. What you should state is “Solve Problem: What is wrong with cycle?” and then state as the first entry of Part Two: “Hypothesis Number One: The trouble is in the electrical system.” You think of as many hypotheses as you can, then you design experiments to test them to see which are true and which are false.

….

Part Three, that part of formal scientific method called experimentation, is sometimes thought of by romantics as all of science itself because that’s the only part with much visual surface. They see lots of test tubes and bizarre equipment and people running around making discoveries. They do not see the experiment as part of a larger intellectual process and so they often confuse experiments with demonstrations, which look the same. A man conducting a gee-whiz science show with fifty thousand dollars’ worth of Frankenstein equipment is not doing anything scientific if he knows beforehand what the results of his efforts are going to be. A motorcycle mechanic, on the other hand, who honks the horn to see if the battery works is informally conducting a true scientific experiment. He is testing a hypothesis by putting the question to nature. The TV scientist who mutters sadly, “The experiment is a failure; we have failed to achieve what we had hoped for,” is suffering mainly from a bad scriptwriter. An experiment is never a failure solely because it fails to achieve predicted results. An experiment is a failure only when it also fails adequately to test the hypothesis in question, when the data it produces don’t prove anything one way or another.

Skill at this point consists of using experiments that test only the hypothesis in question, nothing less, nothing more. If the horn honks, and the mechanic concludes that the whole electrical system is working, he is in deep trouble. He has reached an illogical conclusion. The honking horn only tells him that the battery and horn are working. To design an experiment properly he has to think very rigidly in terms of what directly causes what. This you know from the hierarchy. The horn doesn’t make the cycle go. Neither does the battery, except in a very indirect way. The point at which the electrical system directly causes the engine to fire is at the spark plugs, and if you don’t test here, at the output of the electrical system, you will never really know whether the failure is electrical or not.

In the final category, conclusions, skill comes in stating no more than the experiment has proved. It hasn’t proved that when he fixes the electrical system the motorcycle will start. There may be other things wrong. But he does know that the motorcycle isn’t going to run until the electrical system is working and he sets up the next formal question: “Solve problem: what is wrong with the electrical system?”

He then sets up hypotheses for these and tests them. By asking the right questions and choosing the right tests and drawing the right conclusions the mechanic works his way down the echelons of the motorcycle hierarchy until he has found the exact specific cause or causes of the engine failure, and then he changes them so that they no longer cause the failure.

An untrained observer will see only physical labor and often get the idea that physical labor is mainly what the mechanic does. Actually the physical labor is the smallest and easiest part of what the mechanic does. By far the greatest part of his work is careful observation and precise thinking. That is why mechanics sometimes seem so taciturn and withdrawn when performing tests. They don’t like it when you talk to them because they are concentrating on mental images, hierarchies, and not really looking at you or the physical motorcycle at all. They are using the experiment as part of a program to expand their hierarchy of knowledge of the faulty motorcycle and compare it to the correct hierarchy in their mind. They are looking at underlying form.”

 

Unexpected Side Effect of Table Shrinking April 6, 2009

Filed under: maintenance,optimizer,performance,tips — prodlife @ 5:44 pm

Last year, I wrote a bit about table shrinking.  It generated quite a bit of discussion and both Freek d’Hooge and Venz warned about some of the side effects involved, especially when using “enable row movement”.

I just discovered another effect of row movement. As the name implies, after enabling row movement, rows get moved around. This can impact the clustering factor of your primary key.

If you had an index on a monotonously growing column (such as “create date”), the table and the index would be ordered in the same way. This results in a low clustering factor, and it means that the index is considered more favorably by the optimizer for some operations. I’m not a big expert on the optimizer, but I assume that if the index and table are ordered in the same way, and you need to scan a portion of the table, the index can be used to find the first row and then the table itself can be scanned. This method should be about twice faster than scanning the index and going to the table for each row to get extra columns that are not in the index. (Again, this is common sense only, I did not test or even deeply studied this).

Anyway, so you have this nicely ordered table, and a nicely ordered index to match, and you probably enjoy all kinds of performance benefits from this arrangement.

Now you enable row movement and shrink. Rows get moved around, and the order of rows in the table no longer matches the order of rows in the index. So you have a smaller table (less blocks) and a higher clustering factor. Maybe scanning portions of the table will be faster since the table is smaller and you read fewer blocks, but maybe it’ll take longer because the ordered changed and the index is less usefull now. In any case, this is something you should consider before deciding to shrink the table with row movement – it can have unexpected effect on your plans.

Here’s a small test I ran to verify:


SQL> create table test (id number);

Table created.

SQL> INSERT INTO test SELECT rownum FROM dual CONNECT BY LEVEL <= 10000;

10000 rows created.

SQL> commit;

Commit complete.

SQL> create index test_i on test (id);

Index created.

SQL> EXEC dbms_stats.gather_table_stats(ownname=>'SCOTT', tabname=>'TEST', estimate_percent=> null, cascade=> true, method_opt=>'FOR ALL COLUMNS SIZE 1');

PL/SQL procedure successfully completed.

SQL> select t.table_name,i.index_name,t.blocks,t.num_rows,i.clustering_factor from user_tables t, user_indexes i where t.table_name=i.table_name and i.index_name='TEST_I';

TABLE_NAME                     INDEX_NAME                         BLOCKS   NUM_ROWS CLUSTERING_FACTOR
------------------------------ ------------------------------ ---------- ---------- -----------------
TEST                           TEST_I                                 20      10000                16

SQL> delete from test where mod(id,2)=0;

5000 rows deleted.

SQL> commit;

Commit complete.

SQL> EXEC dbms_stats.gather_table_stats(ownname=>'SCOTT', tabname=>'TEST', estimate_percent=> null, cascade=> true, method_opt=>'FOR ALL COLUMNS SIZE 1');

PL/SQL procedure successfully completed.

SQL> select t.table_name,i.index_name,t.blocks,t.num_rows,i.clustering_factor from user_tables t, user_indexes i where t.table_name=i.table_name and i.index_name='TEST_I';

TABLE_NAME                     INDEX_NAME                         BLOCKS   NUM_ROWS CLUSTERING_FACTOR
------------------------------ ------------------------------ ---------- ---------- -----------------
TEST                           TEST_I                                 20       5000                16

SQL> alter table test enable row movement ;

Table altered.

SQL> alter table test shrink space cascade;

Table altered.

SQL> alter table test disable row movement ;

Table altered.

SQL> EXEC dbms_stats.gather_table_stats(ownname=>'SCOTT', tabname=>'TEST', estimate_percent=> null, cascade=> true, method_opt=>'FOR ALL COLUMNS SIZE 1');

PL/SQL procedure successfully completed.

TABLE_NAME                     INDEX_NAME                         BLOCKS   NUM_ROWS CLUSTERING_FACTOR
------------------------------ ------------------------------ ---------- ---------- -----------------
TEST                           TEST_I                                  8       5000                22

 

 
Follow

Get every new post delivered to your Inbox.

Join 48 other followers