sorted by: recent | see : popular

Content Tagged with group + oracle

This week, database blogs seemed to talk about conforming to stereotypes as well as breaking them.

Fulfilling the stereotype of Microsoft software being unsecure, Microsoft released a very important SQL Server update that Aaron Bertrand notes patches “four elevation of privilege vulnerabilities.” That’s right, not one, not two, but four!!! At least there is a patch now……go forth and patch! Usually it is MySQL that throws ambiguous warnings or errors which are not an accurate representation of the actual error, but Bertrand also notes that there is A Little Management Studio Oops.

Contrary to stereotype, Microsoft is giving away content with NO DRM! Kalen Delaney asks, Did You Know the History of SQL Server? and shares a link to a chapter from a book on SQL Server 2000 in the Inside SQL Server series.

The PSS SQL Escalation Services team has fought many times about SQL Server I/O Bottleneck, I don’t have one, YES YOU DO! The team gives some reminders about how to interpet averages properly.

Allen White asks about Tools for the Reluctant DBA — that is, a programmer or administrator so good at databases that they were promoted to DBA, but may not actually want the job. Check out the comments and add your own.

Tibor Karaszi shares his stored procedure to find physical index details. Now you can use one stored procedure does what a stored procedure plus 3-4 tables ordinarily does.

But wait! There are some more updates!

(more…)

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?

Welcome to the 89^th edition of Log Buffer, the weekly review of database blogs.

Welcome, welcome everyone.

In writing this week’s Log Buffer, I’ve had a chance to sit down and read some excellent posts on all sorts of platforms. The depth and breadth of what’s available to house and retrieve data is astonishing.

Many of you who have read my posts will know that I’m a fan of vegetables. They are something most of us don’t eat enough of. Come on DBAs! I think we need to make a collective effort to get healthy. We need you to keep all these systems alive. I say this because I have a new found appreciation for the work we do day in and day out.

Six months ago my wife and I said hello to our baby girl for the first time. I don’t say this to elicit any type of congratulations, but to illustrate something entirely different. If you have ever been to a hospital for any reason — to celebrate, to hope, or to say goodbye — you know the sheer complexity of the vast numbers of systems that need to interact. Daily, these systems save lives and help bring new ones to this world. I saw first-hand how the work I do on a everyday keeps the wheels turning.

Some of our customers run systems used by hospitals and I saw them in action. In a simple world, treating people can be done without technology, but this is an issue of scale, and our involvement directly affects the sheer masses of people whose lives are better because of our behind-the-scenes support. It’s true here, and it’s true for the most serious, most mission-critical systems, to the least critical and most trivial systems. The work done by DBAs from all platforms should be recognized for what it is.

I’m proud of what I do for a living and happy that I get to work in an industry filled with so many savvy folks. Oracle, Microsoft, MySQL, Postgres, IBM, and countless other organizations, and the people involved in them have together created an industry filled with opportunities and challenges, and above all, they have together elevated our ability to communicate and share. It’s in this spirit that Log Buffer was created, so let us proceed!

Since I’m an Oracle guy, we’ll let Oracle go first this time.

(more…)