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?

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…)

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.

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.

I have already blogged about this keynote at http://www.pythian.com/blogs/948/liveblogging-who-is-the-dick-on-my-site.

If you are interested in actually seeing the video, the 286 Mb .wmv file can be downloaded at http://technocation.org/videos/original/mysqlconf2008/2008_04_17_panelDick.wmv and played through your browser by clicking the “play” link at http://tinyurl.com/55c5ps. This is not to be missed!

Here is the question that was posted on OTN Forum Grid Control Extensibility (not the topic of the forum!) yesterday:

I recently moved south to Bangalore and I am working for a large software integrator. My project team is working on a JEE application project that uses test driven development methodologies. We are planning to use a host of new breed technologies such as Enterprise 2.0, Ajax, Drools, JDO, Hibernate,and mashups. Are you able to point me to online and offline resources/trainings that can help our team get up to speed with these latest technologies.

All the help that group members can provide in this regard is much appreciated.

My first reaction was — how stupid one should be to post such absolutely irrelevant question in that forum? I do see from time to time some questions that are about Grid Control but not about Extensibility and, assuming I have a minute, I might suggest to ask it in the neighboring forum instead. However, this time it seemed absurd to choose this place.

I was even more surprised that someone actually tried to provide a sensible response, I was thinking to blog about it to re-iterate the point that Tom Kyte expressed recently but I couldn’t find the thread anymore. I thought it was moved by a wise admin to a more appropriate place. I did a quick search on OTN forums and found it in… well, many other OTN forums. So it seems that it was simply deleted from Extensibility forum.

Google showed that OTN forums are not the only one appearance of this request. Is this an absolute stupidity or an example of plain scam?

Well, I just needed that rant.

At the 2008 MySQL Conference and Expo, The Pythian Group gave away EXPLAIN cheatsheets. They were very nice, printed in full color and laminated to ensure you can spill your coffee* on it and it will survive.

For those not at the conference, or those that want to make more, the file is downloadable as a 136Kb PDF at explain-diagram.pdf

* or tea, for those of us in the civilized world.

Today I ran into an 11i E-Business Suite instance which is using Apache/JServ to do forms load-balancing. In fact, it’s my first customer to implement and successfully use Apache/JServ for load-balancing. Here is quick sketch of the instance architecture:

                  Users
                    | 11i URL:
                    | http://appsrv1.pythian.com:8000/
                    |
             ----------------
             |   appsrv1    |
             | apache/jserv |
             |  formservlet |
             ----------------
            /                \
           /                  \
----------------             ----------------
|   appsrv2    |             |   appsrv3    |
| apache/jserv |             | apache/jserv |
|  formservlet |             |  formservlet |
----------------             ----------------

            -------------------
            |    dbsrv01      |
            | CM/RepSrv       |
            |  Database       |
            -------------------

Almost all the customers that I have worked on till now, with a requirement for multiple middletier, have implemented load balancing using hardware load-balancers like Cisco Content Switch or F5 Big-IP.

This customer is running forms in servlet mode, a prerequisite for using Jserv to do load-balancing. If somebody wants to do forms load-balancing in socket mode and opts not to use any hardware LBRs, then the only option is a Metrics server.

Here is brief overview on how forms load-balancing happens in above architecture. (more…)

In a despicable business practice, I received a message from a PR Firm representing Ingres. Now, I even wrote about the controversy that seems to have swept the open source community; but even my writings were not completely factually correct — I wrote that even if online backups were closed it was not necessarily the worst thing in the world. The actual parts of the online backup that are not open source and free are compression and encryption — that is all.

So really, we are talking about a very small part of backup. The last I saw most people used their own compressing (ie, | gzip -c) and encryption for backups. And honestly, I would rather use tried and true compression and encryption than something new that MySQL comes up with, so I do not even see most people wanting compression nor encryption.

But that’s besides the point. If Ingres thinks they can win customers over by swooping in when a controversy is happening, they are way more evil than I would ever have guessed. It’s not good business practice to do this kind of thing — it is cold, calculated, uncalled for, and just plain wrong.

As for my comments — firstly, MySQL did not make any particular “announcement”, and secondly, MySQL is already losing “feedback and contributions on its products from a large group of users in the community” because it does not have an easy way to get community patches committed to the source tree.

There is so much else that bothered me about the e-mail I received, so I will just copy it here for full context for readers:

Subject:  Ingres' Thoughts on Today's MySQL Announcement and What it Means for the Open Source Community

From:  Lindsey Pappas

Date:  Apr 15, 2008 5:33 PM

Hi Sheeri,

 Did you see MySQL ’s announcement on new features in MySQL Enterprise version of its product? This is interesting news for the open source community, as it appears that MySQL is moving away from true open source towards a proprietary model by not providing the same features in its community version. Ingres is a a leading provider of open source database management software and support services and views the news as the loss of a true competitor in the open source space.  By doing this, MySQL will lose feedback and contributions on its products from a large group of users in the community. Costs will go up and quality will go down.

 Ingres is a believer in the true open source of its products.  I can put you in touch with an executive at Ingres to hear thoughts on the news and what MySQL’s announcement means for the future of the open source community, including comment on:

·         The benefits of open source solutions that are identical between community and enterprise, functionality should not differ between products, cost or version.

·         The importance of an online backup component for mission critical applications.

·         In a community where everyone benefits from the valuable contributions and feedback on new developments and innovations from other players, MySQL’s move away from open source is a loss for the open source community.

Please let me know if you’d like to connect in the next day or so to discuss MySQL’s announcement and where the open source community is headed.

Thanks,

Lindsey

Lindsey Pappas
Atomic Public Relations
8 California Street
San Francisco, CA 94111
(415) 402-0230
lindsey@atomicpr.com