Pythian Group

One of the most frequently needed functionality in the MySQL Proxy is the need to know which server you are on. This is not given, on purpose, by the proxy, because the proxy is supposed to be transparent. It is not supposed to matter which back-end server you are on.

However, for testing purposes we often want to know which back-end server we’re on. Thus I developed functionality for SHOW PROXY BACKEND [INDEX ADDRESS OTHER].

SHOW PROXY BACKEND INDEX — gives the index of the server you’re on (backend_ndx, ie 1)

SHOW PROXY BACKEND ADDRESS — gives the address of the server you’re on (ie, foo.bar.com:3306)

SHOW PROXY BACKEND OTHER — gives the address of all the other servers except those you’re not on, in multiline format.

Note that I was pretty lazy and the commands are case-sensitive. But I figured that since this is supposed to be used mostly in testing circumstances, it did not really matter.

The code is on the MySQL Forge Wiki at http://forge.mysql.com/tools/tool.php?id=139

Interestingly enough, this script is actually being used in production — a site has a primary and failover server, and wants to check that when the primary server is in use, there are no connections on the failover. I wrote that check as well, but as the logic is somewhat particular, I am not sure it would be useful to many. The logic is:

1. Run SHOW PROXY BACKEND INDEX.
2. if it fails, I can’t connect to the proxy, log an error, exit.
3. if it !=1, I’m on the failover server, log a warning, exit.
4. if it =1, I’m on the primary server.
5. Run SHOW PROXY BACKEND OTHER.
6. if it is empty, either I can’t connect to the proxy or there are no failovers defined, log a warning, exit
7. For each OTHER address, connect to them and find what that connection’s host looks like (sometimes it looks like foo.bar.com:4325, other times it looks like 1.2.3.4:4573). Get the value of “my host” by stripping off the port.
8. Connect to the OTHER address again, killing off connections from “my host” except for the “system user” and a few other special accounts (replication slave being one of them). Log each kill with the thread number and a warning.
9. If there are no connections to be killed, log OK.

Let me know if you’d like to see that…it’s a shell script, and it requires the mysql client and bintools like grep and cut.

Recently, while answering a question, I came across what appeared to be a change to the rules for licensing Oracle Standard Edition — a change that appears to be subtle on the surface, but one that could have significant and surprising repercussions.

It was with considerable fanfare that Oracle announced, several years ago, the last major change to the licensing rules for Standard Edition — that multi-core processors would be counted as a single CPU for the purposes of licensing Standard Edition products. (For Enterprise Edition, Oracle continued to count each core as a separate “processor”, but then provided price discounts, presumably in recognition that a 2- 4- or 8-core CPU rarely provides equivalent performance to an equivalent number of single-core processors running at the same clock rate).

The revised licensing rule went like this (I have highlighted the relevant text in bold):

Processor: shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on a processor basis may be accessed by your internal users (including agents and contractors) and by your third party users. For the purpose of counting the number of processors which require licensing for a Sun UltraSPARC T1 processor with 4, 6 or 8 cores at 1.0 gigahertz or 8 cores at 1.2 gigahertz for only those servers specified on the Sun Server Table which can be accessed at http://oracle.com/contracts , “n” cores shall be determined by multiplying the total number of cores by a factor of .25. For the purposes of counting the number of processors which require licensing for AMD and Intel multicore chips, “n” cores shall be determined by multiplying the total number of cores by a factor of .50. For the purposes of counting the number of processors which require licensing for all hardware platforms not otherwise specified in this section, a multicore chip with “n” cores shall be determined by multiplying “n” cores by a factor of .75. All cores on all multicore chips for each licensed program for each factor listed below are to be aggregated before multiplying by the appropriate factor and all fractions of a number are to be rounded up to the next whole number. When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to a socket.

This is exactly the definition you will find today today in Oracle’s online store, for example here.1 In fact, being lazy and not having access to a two-year-old copy of the OLSA, that is exactly where I got the text above.

Now, that little bit of bold text was a pretty big deal. As I understood it, and everybody I could find seemed to agree, this affected both the licensing cost and the eligibility rules. These 23 simple words now meant that Oracle Standard Edition was limited to computers with a maximum capacity of four (4) CPU sockets, not four processor cores. Although multi-core processors were — at the time, several years ago — relatively new, at least in the “commodity hardware” space, we all new that Intel and AMD had near-term plans for 4-core and eventually event 6- and 8-core processors. Suddenly, we could build an Oracle database server with 16 processors (cores) and 16GB of RAM or more, for less than $200,000. (Prior to this change, you would pay $640,000 — list price — just for the Enterprise Edition database licenses.)

But now, it seems, all of this is changing again, only this time, not for the better.

So what exactly has changed? (more…)

Fedora 9 was released on the 13th. I waited a whole three days to make sure I wasn’t going to be the beta-tester. Then I tried out the live release, and finally decided to upgrade my main workstation to Fedora 9 today. To be sure I wouldn’t mess stuff up, I used the DVD installer to upgrade.

The upgrade finished fine, but when I rebooted, XChat would not run.

[14:15:53]$ xchat
xchat: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory

What did rpm have to say about this?

[14:26:31]$ rpm -q xchat
xchat-2.8.4-11.fc8.i386

[14:26:39]$

Hmm . . .  looks like the package did not get upgraded. Wondering how many others did not get upgraded, I did a quick check:

[14:26:39]$ rpm -qa | grep fc8|wc -l
139

Wow! 139 packages still carry the fc8 tag! Next I checked if the updates repository has the updates:

[root@rajlin ~]# yum update
...

...
Transaction Summary
===================================================================
Install     18 Package(s)
Update     148 Package(s)
Remove       0 Package(s)

While I didn’t check all the packages in the list, XChat is definitely there:

xchat                   i386       1:2.8.4-15.fc9   fedora            1.3 M

So did Fedora just push out a release with old packages just to stay on schedule, and is actually releasing packages now hoping nobody would notice? (more…)

The 97th edition of Log Buffer, the weekly review of database blogs, has been published on Brian “Krow” Aker’s Idle Thoughts.

We have Jeff Smith and Ward Pond standing by for two upcoming editions. And if you’d like to contribute, make yourself known in the DBA community-at-large (and have some fun in the process), you too can do Log Buffer! Read the homepage and send me, the Log Buffer coordinator, an email.

And now, Brian Aker’s Log Buffer #97.

Log Buffer #97 is unaccountably delayed, but have no fear — it will appear before too long.

Stay tuned.

I decided to reprise my commentary on Oracle RAC and the gv$ views after reading Patrick’s comments on my previous post. It is always encouraging to know that someone is kind enough to read your work and provide insightful feedback - many thanks to him!

I can use a script now to find the locks in a RAC environment, but until this point I couldn’t have told you how the script actually works. Frankly, the documentation that I found on Metalink is dry and boring for such an important (and sometimes entertaining) subject as locks.

There are two questions that I wanted to answer here: Can you use the gv$ views with a non-RAC environment? What do the WHERE clauses in a good block-checking script do?

First, can you use the gv$ views to check for locks when you have a single-instance, non-RAC database? The reason this question is prevalent in my mind is that we just completed an 11.5.9 application clone (with RAC enabled on the source environment but not on the target) for a customer who has been busy purging data from the new environment. When a performance issue arose, one of the first things that we did was to see if there were any locks. We employed the same script that had been developed to tell us if there were locks on our RAC-enabled instances — and the script returned no records. At the time, I thought that perhaps the gv$ views would not be populated in a non-RAC database. I tested this by executing the following SQL statements on the non-RAC database:

select sid, id1, id2 from v$lock minus select sid, id1, id2 from gv$lock;

select sid, serial# from v$session minus select sid, serial# from gv$session;

(more…)

The highlight today of probably every Linux-related mailing list and IRC channel was the announcement of CVE-2008-0166, affecting OpenSSL libraries on Debian-based Linux distributions, including the popular Ubuntu.

According to the Debian Security Advisory, a change made to Debian’s OpenSSL package makes its random number generator predictable. Obviously this is less than desirable in a random number generator used for things like, say, all of your SSH keys.

The vulnerability has been present since September of 2006, and Debian strongly suggests throwing your old keys out completely:

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch.

Debian has now disabled public key authentication on their project servers until further notice, and are generating new keys for those servers and new certificates for db.debian.org.

So all you Debian and Ubuntu folks out there will probably want to do the same for your own keys and certificates. Note that this patch was never used by the upstream OpenSSL team nor by other distros like Fedora or RHEL (or CentOS), so they are not affected.

As some of you probably already noticed, there was a thread on AskTom discussing the scalability tests I did back in 2007. You are welcome to read the entire thread, but in a nutshell, Tom Kyte claimed that my tests did not reflect how one would use the result cache in the real world.

Of course, the important question is whether I tested a feature in a way it was never designed to be used, or whether someone is just trying to make an excuse for poor scalability results by defining “real world” in a way that makes my tests inappropriate.

What do you do, then, you first see a new feature? You read about it in the documentation, and then you test it in order to compare what you have read with what you have in reality.

Open the Performance Tuning Guide and go to 7.3.1.4 Result Cache Concepts:

When these queries and functions are executed repeatedly, the results are retrieved directly from the cache memory. This results in a faster response time. The cached results stored become invalid when data in the dependent database objects is modified. The use of the result cache is a database-wide decision.

All it says is that you have to have repeatedly-executed functions and queries to get faster response time. It says nothing about what kind of queries or functions. It also suggests that the result cache should be used database-wide or shouldn’t be used at all (which is perfectly sound according to Jonathan Lewis’s Rules for Hinting).

Now skip up to 7.3.2.7 Use of Result Cache:

OLTP applications can benefit significantly from the use of the result cache. The benefits highly depend on the application. Consider the use of the PL/SQL function result cache and the SQL query result cache when evaluating whether your application can benefit from the result cache.

It clearly says that result cache is perfectly appropriate for OLTP applications. They leave a backdoor with the words, “depend on the application” but, yet again, they say nothing about what kind of OLTP applications.

(more…)

Karun Dutt and I managed to get DBD::Oracle 1.21 to install on a 64-bit Linux OS against the Oracle 11 full client. Here’s what we did.

As root, we downloaded DBD::Oracle from CPAN.

# perl -MCPAN -eshell
cpan> get DBD::Oracle
...

We replaced the distribution makefile with: http://svn.perl.org/modules/dbd-oracle/trunk/Makefile.PL (this is the latest Makefile.PL).

# cd /root/.cpan/build/DBD-Oracle-1.21
# export ORACLE_HOME=<actual value of Oracle Home>
# export ORACLE_SID=<actual value of ORACLE_SID>
# export ORACLE_USERID=<a working ORACLE_USERID>
# export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME
# perl Makefile.PL
...
# make
...
# make test
...
# make install
...

It works!

Contemporary software engineering models include many loosely-defined layers. Database developers might help with other layers, but for the most part a database administrator’s domain is the persistence layer.

• Presentation


• Application


• Business Logic


• Persistence (also called Storage)

The Daily WTF has an article on The Mythical Business Layer makes the case for not separating the business layer and the application layer:

A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.

It almost goes without saying that business logic changes frequently and in unpredictable ways. The solution to this problem is not a cleverly coded business layer. Unfortunately, it’s much more boring than that. Accommodating change can only be accomplished through careful analysis and thorough testing.

I will call this merged business/application layer the “functional layer.”

The serious scaling requirements posed by most applications these days call for partitioning, clustering, sharding or some other term for “dividing up the data so it does not become the bottleneck”. Enter the “architecture layer”.

“Wait a minute,” I hear you asking. “Isn’t that just the persistence layer?”

Yes and no. To me, there’s a difference between the storage and the architecture of said storage. The database schema for storing a user profile is a persistence layer issue. Figuring out which database instance to go to is an architecture layer issue.

This is an important distinction for me. Many folks are coding the architecture layer directly into the functional layer. A “save_profile()” API function might call an ORM to deal with the persistence, or it will have MySQL (or other database) connection handling and queries. However, the database will grow, and at some point you will find yourself wanting to split the data [more].

This type of information, like the presentation layer, needs to be separate. Why should the application care whether save_profile(’Sheeri’,'hair color’,'blonde’) accesses database1 or database2? More importantly, why should there be major code changes to the functional layer if the architecture changes? Just like no functionality has changed when you change your website color from blue to red, there is no functionality change when you go from splitting data between 2 database servers to splitting among 3, or 10.

For me, the persistence layer is about how the data is stored. Which, explicitly and for the record, I also believe should be separate from the functional layer — if you store hair color and eye color in one table or 2, the functionality of the application has not changed; all that’s needed is a change in how that data is stored and retrieved.

The architecture layer is all about where the data is stored. Early forms of the architecture layer are configuration files, though most would not call that a “layer”. Database administrators should be able to change the architecture of the database system without requiring mucking about in the application’s functional code.

Thoughts?

Thanks to Paul for announcing the founding of Pythian Europe. Paul finished his blog by inviting me to tell you the story about “how we met Pythian”. Here it is.

As I get older, I am starting to see some symbolic links connecting significant moments of my life. I realize now that the link to Pythian started 20 years ago in Prague in the year 1988. Let me share with you the trip. Although in Soviet Union, Mikhail Gorbachev began to moderate the totalitarian regime by introducing Perestrojka, the government of Czechoslovakia was still ruling with an iron hand.

I worked as a VMS administrator on a Czechoslovak clone of the VAX computer and, by the way, I became an expert in backup/restore, an expertise I had to exercise several times per week due to frequent crashes of our 29MB disks (also a East European clone). Besides administering VAX/VMS systems, I had to write hundreds of lines of Assembler, Fortran, and C code, just to handle inserts, updates, and queries for records in a few data files.

One day a colleague of mine brought me a tape, which he had smuggled from Vienna (there was an embargo on US software imports). On the back of the tape was written, “Oracle V4 for VAX/VMS.” Oracle V4 was released in 1984, the year I knew better as the title of the famous George Orwell novel. Out of curiosity I installed it after hours.

The “Readme1st” said to run one script with a strange extension — “.SQL”. Some program called UFI logged in as scott/tiger into a “database” and did SELECT * FROM EMP, DEPT WHERE EMP.DEPTNO=DEPT.DEPTNO AND DNAME = 'SALES', and then increased the salaries of all salesmen by 10% by one simple UPDATE command.

I was so fascinated that I spent the whole night playing with SQL, as I did on many evenings over the next two years. Once, after returning from a political demonstration in Old Town Square, I escaped back into my SQL world. Despite tanks running the crowds down and the imprisonment of the dissident Vaclav Havel, I perceived strongly that regime change was as inevitable as the victory of SQL.

(more…)

You might have already seen the blog update on Steven Chan’s site. TXK AutoConfig and Templates Rollup Patch S (6372396) was released on May 5th.

This patch differs from traditional TXK autoconfig template patch releases in that the ATG team decided to include some other important TXK patches also with this release. One of these is TXK Advanced Utilities Rollup Patch C (5011249).

This Advanced Utilities patch brings some import scripts that can be used to implement advanced topologies. The important benefit here is that these scripts can be run from command line. For complete details, refer to Metalink note 277574.1, Running Configuration Wizards from the Command Line in Oracle Applications 11i.

As a side effect of this generous inclusion of import updates, the patch size has increased from 16mb (RUP R) to 65mb (RUP S).

This Rollup Patch has also brought in some new Context variables. These new XML tags in Rollup Patch S are:

1. s_jdbc_connect_descriptor_generation: The value of this variable determines whether the jdbc connect descriptor is regenerated and whether the value of the context variable s_apps_jdbc_connect_descriptor is updated. Acceptable values for this context variable are true (the default) or false. Set this value to false when using a custom apps jdbc connect descriptor
2. s_apcprestart: This variable is used to specify the complete path of the script to be executed before the Apache service is started.
3. s_ccmmaxsyspathlen: (Windows-specific) This context variable is used for setting the maximum length of the Windows System Path.

(more…)

Beware this parameter can prevent your database from starting. Indeed it can prevent your instance from starting!

There are two dynamic views v$system_fix_control and v$session_fix_control which were introduced in 10.2 and control whether fixes for bugs in the optimizer can be turned on or off. This can also be controlled using the _fix_control initialization parameter.

If the parameter _fix_control is set incorrectly i.e. with invalid bug ids then, when starting the database, you may get the following error

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Wed May 7 10:55:43 2008

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup nomount
ORA-00940: invalid ALTER command

There are no error messages in the alert log and the instance has refused to start.

And look at that helpful error message. No doubt behind the scenes it doing some sort of ALTER command but still …

If you get this error then check the pfile or spfile and see if there is some spurious _fix_control setting. This is especially valid for the upgrading of Oracle. I came across this error upgrading 10.2.0.2.0 to 10.2.0.3.0.

Also beware if setting this parameter in a running database. You can prevent further logins if you get it wrong or indeed try to unset it. Do not do

ALTER SYSTEM SET "_fix_control" = '';

This will require a bounce to fix. Once, of course, the parameter has been removed from the initialization files.

The moral of the story is be very careful with undocumented parameters when upgrading!

This is the 96th edition of the weekly review of database blogs, Log Buffer.

Let’s start this one in SQL Server Land, with a question from Dennis Gobo — should SQL Server have the CREATE [OR REPLACE] PROCEDURE syntax? There are, he writes, advantages: “When scripting out a database you don’t have to generate if exists…..drop statements,” and disadvantages: “I can overwrite a proc without even knowing it.” Of course, the commenters have opinions of their own, and the piece becomes a straw poll for the desirability of that syntax as a feature.

Aaron Bertrand has one too: when was my database/table last accessed? Writes Aaron, “SQL Server does not track this information for you. SELECT triggers still do not exist. Third party tools are expensive and can incur unexpected overhead. And people continue to be reluctant or unable to constrain table access via stored procedures, which could otherwise perform simple logging.” He looks at 2008’s built-in auditing, and for those who can’t wait for that, illustrates a workaround for 2005.

Linchi Shea explores something else from 2008, Page Compression, focusing on how the number of processors affects the rebuilding a table with page compression.

Jamie Thomson, the SSIS Junkie writes that he has made a submission to Connect on the matter of absolute and relative paths in SSIS. “. . . I have always agreed that stipulating the use of absolute paths within SSIS was the right thing to do (and indeed I have championed it) however of late I have changed my mind. Support for relative paths would greatly simplify package deployment and package management . . . What do you think? Should SSIS support relative paths?” So far, it looks like a shoo-in.

Brian Knight also explains another little quirk, SSIS Case Sensitivity: “The case sensitivity can in some cases create behavior that is not expected and may give you bad results if you’re not careful.  . . . One such example is with the Lookup Transform, where comparisons against the cache are case sensitive. If you do not expect this, you may have a miss in a match that is actually a hit.”

In the MySQL ’sphere this week, there is plenty of talk about the openness or otherwise of MySQL. (more…)

It is with great pride that I am able to announce that Pythian is making a large investment in Europe. As of this month, Pythian Europe s.r.o. is fully operational and we have headquartered the company in beautiful Prague. Additional offices are planned in Paris and Malta by the end of the summer.

Pythian Europe is launching with an elite, full-fledged team and I would like to introduce the founders:

On the left is Lukas Vysusil, who joins us from Oracle where he served for 6 years in a variety of roles, including Oracle Applications DBA, DBA Team Lead, Manager of the Configuration Queue for Oracle OnDemand outsourcing services, and also Senior Technology Consultant. He brings a wealth of experience in team leadership, troubleshooting, Oracle Apps, the pressure cooker of consulting in the enterprise database and applications technology space and formal configuration and change management processes to Pythian and will serve as Service Delivery Manager.

On the right is Jan Polnicky, who joins us from Oracle where he served for 6 years in a wide variety of roles. You’ll have to check his linkedin profile for the entire list, but suffice it to say he started out as a developer for Online Services, quickly took on a leadership role in that team, moved to OnDemand where he became a services team lead, then got promoted to EMEA queue manager for configurations, and then got promoted to OnDemand Services EMEA Manager - Release Management where he led a team of up to 15 engineers across geographies (UK, ES, CZ, EG + USA & APAC indirects) doing general Oracle Database & Apps management, tons of preventative maintenance and supervised a number of Oracle Applications upgrade projects. In his spare time, Jan is working on his Ph.D., I kid you not. Jan will serve as a peer to Lukas as Service Delivery Manager.

You may think that’s enough.

You may be thinking, OK, with these guys and the teams they will soon be leading now Pythian has added so much expertise and horsepower in Europe they’ll stand pat for a while.

But oh no. Not me. That was not enough!

To lead these guys, on the centre, we have also added Peter Simecka as Vice President, Pythian Europe. Peter joins us from, you might have guessed it, Oracle Corporation where he started out in 1994. Even before joining Oracle, he had substantial expertise on Oracle/UNIX, dating back to Oracle 4 (I first worked on Oracle 5, but 6 was already out by then). Over his career at Oracle, Peter has led teams as large as 60 engineers, served as Product Support Manager for five years, served as Customer Support Manager for four years, and then built and led the Oracle OnDemand Outsourcing centre in Prague for four years. To say that he brings a wealth of leadership experience, customer support and liaison experience, and outsourced services design, development and delivery experience is a woeful understatement. I am hoping and planning to learn a lot from him.

It’s funny because the way I presented these guys, it makes it seem like I selected each of them individually, but that’s not how it happened at all. I’ll leave that story for another day, or maybe Peter will want to tell it.

So, what are we planning to do with this ambitious operation in Europe? Stay tuned.

After our last post about installing Oracle 11g on Ubuntu 7.10 (November, 6th), and considering Ubuntu 8.04 LTS was released on April 21st, I spent some time reviewing and putting together this new HOWTO for the installation.

Please note: I’ve used the x86 server version of Ubuntu 8.04, but the same steps should work without any problems for the Desktop version. Also notice that this whole procedure can easily take over six hours to complete, so don’t complain I didn’t warn you!

So, let’s get started, shall we?

Get the Ubuntu Linux 8.04 Hardy Heron (x86, 32-bit) image here, burn it, and install on any box you like. The only remark on the installation is that you should ask the installer to install an OpenSSH server at the end of the installation, since we’ll perform all the steps on this procedure remotely.

I’m not sure about the minimum requirements for the server, as, the last time I checked, running Oracle on Ubuntu is not officially supported by Oracle. In case you’re wondering, however, I’m using an x86 Pentium-like machine with 512M of RAM.

Download Oracle 11g for Linux (x86, 32-bit).

(more…)

In this post and some upcoming posts, I’m going to write more about Oracle application servers, a subject we have addressed too little on the Pythian blog.

In this post, I am addressing how to bounce a whole application server, including all tiers and databases from one location. The reason being, I have a request from a client to have the application server be bounced automatically during the weekend to release swaps and to address memory leaks. The application server on this client includes one Mid tier, one Infra tier, and one database (a metarepository database) in three different Oracle homes on two boxes.

As you know, for application server, tiers should be stopped and started up in a specific order. On startup, the sequence is like: database –> listener –> Infra tier –> Mid tier.

For shutdown, the sequence is vice versa. It is not safe to shutdown the database or Infra tier before making sure that the Mid tier is totally done.

So, in order to address client’s request, the basic plan was to have a script to shutdown Mid tier, then handshake with a tscript on the Infra tier to let it know that it is safe to shutdown the Infra tier. We would use the same approach for the Infra shutdown script and database shutdown script.

Is there a simpler way?

opmnctl, the main tool for startup/shutdown of application server components, is able to bounce the whole farm. However, first time you try to run opmnctl status @farm, you may just see the status of AS component only for single box rather than for the whole farm. Why?

(more…)

According to the wikipedia page,

“The rack is a medieval torture . . . which induces excruciating pain as the victim’s joints slowly dislocate.”

Per the Oracle website,

“Oracle RAC is a cluster database with a shared cache architecture that overcomes the limitations of traditional shared-nothing and shared-disk approaches to provide highly scalable and available database solutions for all your business applications.”

Which is more painful, you might ask? I cannot say for certain, as I have never been subjected to the torture of a medieval rack, but I have experienced some pain at the hands of the Oracle RAC. My first encounter was about five months ago when I first became an “official” DBA. Being eager to jump into solving problems in my new job (as that’s what most DBAs do, solve problems), I relished the chance to get my hands dirty and work on a “real” DBA task — a database lock.

Even though I had never been officially titled a DBA before, I was somewhat familiar with the concepts as I have been working around them for years (and still chose to join their ranks, if that tells you anything). Theoretically, I knew exactly what a database lock was, but I had no clue how to practically diagnose or kill one off.

Checking with a few knowledgeable co-workers, I was directed to a set of common database diagnostic scripts affectionately known as the “Pythian Kit”. (more…)

Next Thursday, May 8, the New England SQL Server Users Group will have a special meeting, featuring Craig Freedman from the SQL Server development team. Craig is The Man when it comes to query optimizer internals, and wrote an incredibly detailed chapter on the topic for “Inside SQL Server 2005: Query Tuning and Optimization”.

At the meeting next week, Craig will discuss some of what he talked about in the chapter, including the basics of how the query processor works and what iterators are. He’ll cover the various operators you’ll commonly see in query plans, and describe how they actually work internally.

This should be a great meeting, and we expect it to be very well attended. In order to help us figure out food and drink, in addition to securing enough chairs for the meeting room, we need you to RSVP if you’re planning to attend. In order to RSVP, sign up for our mailing list. I will send out an e-mail next Tuesday, and you can RSVP by replying to it. Only attendees who RSVP will be eligible for our prize draw at the end of the night, so make sure to sign up for our list by Monday in order to guarantee that you don’t get left out.

We would like to thank Red Gate Software, who made a very generous donation to the group that allowed us to have this special meeting. Red Gate makes some of my favorite SQL Server tools and provides a huge amount of community support in the SQL Server and .NET space, and we hope that you will give their products a try.

The 95th edition of Log Buffer, the weekly review of database blogs, has been published by Mark Schoonover on his Mark’s IT Blog.

We can look forward to LB#98 Jeff Smith’s Jeff’s SQL Server Blog on May 23rd. There’s always plenty of room for more editors, so don’t waste another minute — send an email to me, the Log Buffer coordinator, and get started!

Without further ado, here is Mark Schoonover’s Log Buffer #95.