Rants

Oracle and jhermiz

Derrick Leggett — Wed, 04 May 2005 04:31:00 GMT

This has been a test of absolutely nothing.

I do believe this might be the most ridiculously stupid blog post I ever make. :)

SOX Auditing Companies SUCK!!!!

Derrick Leggett — Wed, 27 Oct 2004 04:18:00 GMT

Just gotta rant for a second. (I know it's hard to believe.) There are only a few approved SOX auditing companies out there currently. The law is so broad in scope, yet undefined, that auditing companies really have no idea what they are auditing for. We have internal auditors talking to D&T; and one of the biggest problems we face is the vagueness of responses received back. None of the auditors really agree with each other on what needs to be done. Passing and/or failing an audit will not be determined by the security of the companies data. It will be determined by your auditors interpretation of their auditing companies interpretation of a law the courts haven't yet interpreted.

That should give anyone truly concerned about productive process and data security a really bad headache!

Long live stupid laws......job security for IT people that couldn't keep a real job.

Why do all these SOX auditing companies have IT consulting divisions???? HMMMMMMMMM

SARBANES-OXLEY SUCKS

Derrick Leggett — Tue, 29 Jun 2004 01:23:00 GMT

We are currently putting processes in place to comply with the Deloitte & Touche interpretation of Sarbanes-Oxley for our internal audit department, and for certification of compliance with Deloitte & Touche. As a DBA, I normally don't complain about processes and have introduced many at my company; however, today I read the proposed functions the DBA would have in my organization if they pass the version currently being considered.

Database Administrator: The DBA will insure the integrity and performance of the database environment. The DBA will not have access to security functions. The DBA will not have access to the physical servers. The DBA will not be able to view production data.

?????? Do these people have any clue about reality? I can't view production data. My developers can't view production data, neither can anyone who is considered a developer. So we have nobody able to view the data, who can fix a bug should it occur. I can't have access to the physical server. Now this is a problem since I currently manage ALL the 27 SQL Servers we have including patches and critical updates. I can't have access to security either, so everytime I set up a new user, or need to add a user to an existing NT Group I need to forward the change control to the NT Security group. I can then do my job. That's fine with me.....less work.

In addition, all fixes need to go through a full SDLC including emergency bug fixes. Think about this before you say it sounds reasonable. This means I not only have to provide a dev/test/staging/prod environment for releases. I need to have the ability to clone production quickly to produce test/staging environments for the bug fixes as well. This will mean buying space for an entire new environment that can be quickly cloned with SnapView for testing of fixes seperately from the normal process. While this environment is being build, and everyone on earth is taking time to test the bug fix, the users are just screwed. I understand we need controls, but this is going WAAAAAAAAAY overboard.

The thing that bothers me the most about this is the incredibly stupid and inept people dictating these processes. We have non-technical people giving us their interpretation of the law as it regards technical matters. Notice it's an interpretation that will benefit ONLY THEM!!!!! That is where the real conflict of interest resides, not in the off chance that some developer could copy someone's phone number down and call them on the phone at night. The head of our internal auditor department said that we must “think like criminals” and think that our developers are. I believe the criminal is the one who slantingly interprets the law solely for the purpose of creating jobs for themselves to the point it erodes shareholder value by limiting the service levels provided by IT/IS departments. That is criminal.

Favorite words used: 8 (complain, reality, WAAAAAAAAAY, overboard, stupid, inept, screwed, Touche) --I just love that word.

Mean level (1-10): 4 (If you are an idiotic auditor completely out of touch with reality, I'm sure you'll find this somewhat mean.)

Education level (1-10): -2 (You really can't learn anything from these people. You are dumber after you sit in their presence.)

Entertainment level (1-10): 5 (Don't worry. Your turn is coming.)

If you're going to lie, can you at least make it believable.

Derrick Leggett — Sun, 25 Apr 2004 20:46:00 GMT

On one of the forums at SQLTeam.com, a “development manager“ claims they have found a database engine that supports the following:

1. Zero or near zero administration

2. One physical file for the database

3. Simple recovery procedures

4. Physical file protection while at rest and in transit

5. Acceptable performance

6. Scaleability

7. Small footprint

8. SQL engine that typically eliminates the need for a DBA.

9. SQL engine with one app supporting 50,000 connections to the database

10. The database is large (in the tetrabytes). --ummmm, okey-dokey. What's a tetrabyte? Will it catch falling blocks and rearrange them in mid-air also?

11. The database has an overall performance of around 30 times faster than engines such as MSSQL and Oracle. --WOW!!!!!!

12. The best of all is that many of these SQL engines run on Linux, Unix, VMS and Windows platforms, giving clients a choice. --blah,blah,blah

If anyone has ran across a database platform that supports the above “features”, please let me know ASAP. I would like to start using it immediately. (grin)

BTW, this "mistress of lies" works for www.eduadmin.com. Please feel free to visit the website and see screens of the wonderful application this intense development house creates requiring the magnificent database described above. She states she has been developing for over 30 years. What a wealth of incredibly useful lore.

Does this look like a terabyte size, high performance, super-duper, high-security database system to you? I think we can cry wolf on this one. If you do find any databases that meet the above specifications though, please let me know. I look forward to the hundreds of responses from vendors. (cough, cough)

Stupid people shouldn't lie. They are too stupid to make it coherent and believable.

Favorite words used: 8 (stupid, lie, coherent, super-duper, blah, WOW, okey-dokey, lore)

Mean level (1-10): 10 (Stupid people should be branded on their foreheads.)

Education level (1-10): 1 (It's possible someone learned something from this. The thousands of replies from vendors could exponentially increase level.)

Entertainment level (1-10): 6 (This is mildly entertaining if you have had to repeatedly endure those Dilbert moments at work.)

Respectfully and lovingly yours,

The MeanOldDBA

A table with a mind of it's own.

Derrick Leggett — Thu, 15 Apr 2004 03:04:00 GMT

I ran across something today I have never encountered in SQL Server 2000; and thought I would share it with the poor souls unfortunate enough to read my blog. We had a process at work that was taking several hours to run (mainly because the stored procedures are written like crap), and about 5 days ago just stopped working. It would just run for 3-5 hours and then stop, producing an error saying it was locked by another process.

There were absolutely no other processes running on this server to “lock” the process, including the process it said was locking it. I set up a profiler, turned on Performance Monitor, ran integrity checks, recompiled the stored procedure, reindexed the table, and hoped it would go away. IT DIDN'T. How incredibly vain and stupid of me to think it would. :)

I tried everything I could think of to solve the problem and accomplished minus 5 things. The SQL Server developer rewrote a copy of the proc to use a copy of the table he created and it ran in under 15 minutes. Sooooo, I figured I would drop the table, recreate it, and test the procedure. When I went to drop the table, it wouldn't drop. The drop ran for 30 minutes and was the ONLY process running consistently during that time. The only way I could get the table to drop was to restart the SQL Server and drop it. Earlier in the week, I got the process to start working by restarting SQL Server also.

On my last badly frayed nerve, I recreated the table and tested the procedure again. The process now runs consistently around 15-20 minutes. Before it laid over and died it was taking around 1.5-2.0 hours with nothing unusual showing up in profiler except the millions of reads the inefficient code produces.

Any great ideas? Beats me!!!!!!!!!!!!!

Now onto the task of rewriting the stored procedure. It was written by an analytics group. Why is it these people never analyze their code and realize it's a horrible, smelly, disgusting pile of

e eeh eeeeh eeeeeh

effffffffff

ish ish iiiish iiiiiiiiish iiiiiiiiiiiii

iii

The power of bold...and other useless ramblings

Derrick Leggett — Wed, 07 Apr 2004 05:15:00 GMT

I recently posted a blog on SQLTeam forgetting to unbold my title. I always bold the title for emphasis, but that day I managed to bold pretty much the whole aggregated blog page, which Tara Duggan was more than happy to point out. :) I tried to weasel out of it, but since Graz had already gone in and fixed it, there wasn't any room left in the tunnel to crawl under his feet. Anytime you use a tag that needs to be closed, <b>CLOSE IT!!!!</b> Wise advice from the Graz Oracle.

But then life is full of these kinds of things when you're in our line of work. I recently brought a third-party imaging software under our management at work. When I got it, the objects had a couple different owners. The third-party vendors (i.e. end-users) and end-users really didn't know how that happened. The images weren't stored in the right directories and nobody really knew how that happened. The application would only show certain years and nobody really knew why that was happening. None of the migrations which had been conducted by IT (don't they work on routers) and vendors (aren't they end-users) had worked and nobody knew how that really happened. The developer in charge of the product told me the wrong database so we pointed the application to a database they hadn't been using in 1.5 years and nobody knew how that really happened.

As long as I work at this company nobody will ever touch this database again unless I am watching them with an axe in my hand to instill fear and remind them that they shall not break anything. :)

One of the DBA's primary functions consists of insuring that everything which touches, breathes on, or approaches the databases is a known. It is not something we have to guess about, wondering if the affected area will work tomorrow. We are the gatekeepers and organizers against chaos. If we aren't allowed to do that it's time to get out the old dusty tie, clean it off, and head down the road. Or at least that's how I see it in this rant.

BTW, this is a useful script if you ever have to change the owners of objects after end-users (that would be anyone who shouldn't touch your database) mess them up.

CREATE PROCEDURE sp_change_owner_all

--Name:   sp_change_owner_all
--
--Purpose:  Change the owner of all objects in a database owned by a given user to another.
--
--Type:   Utility
--
--Format:  EXEC sp_change_owner_all 'derrick','dbo'
--
--Example_1: EXEC sp_change_owner_all 'derrick','dbo' --Changes owner from common to dbo.
--
--Author:   Date:  Type:  Description:
--Derrick Leggett 02/01/2002 Created  Changes all objects to use a specific owner.
--Derrick Leggett 04/01/2003 Modified Changed to only change specified owner to new owner.
--

@txt_old_name VARCHAR(55),
@txt_new_name VARCHAR(55)

DECLARE @objects TABLE(
int_id INT PRIMARY KEY IDENTITY(1,1),
txt_name VARCHAR(255))

INSERT @objects(
txt_name)

SELECT so.name
FROM sysobjects so INNER JOIN sysusers su ON so.uid = su.uid
WHERE
su.name = @txt_old_name
AND type IN ('P','U','V')

DECLARE
@int_counter INT,
@int_max INT,
@txt_object VARCHAR(256),
@txt_sql VARCHAR(2500)

SELECT
@int_counter = (SELECT MIN(int_id) FROM @objects),
@int_max = (SELECT MAX(int_id) FROM @objects)

WHILE @int_counter <= @int_max
BEGIN

SELECT @txt_object = (SELECT txt_name FROM @objects WHERE int_id = @int_counter)

SELECT @txt_sql = 'sp_changeobjectowner ''' + @txt_old_name + '.' + @txt_object + ''',''' + @txt_new_name + ''''

PRINT @txt_sql
EXEC(@txt_sql)

SELECT @int_counter = @int_counter + 1
END
GO

Favorite words used: 7 (weasel, crawl, vendor, end-user, axe, fear, chaos)

Mean level (1-10): 3 (Tara was mean, but she has a kewl blog so who cares. Graz was gracious enough to not delete my blogs so who's complaining.)

Education level (1-10): 3 (Transact-SQL for Dummies and SQL Server Administration for Dummies would be way more educational than this.)

Entertainment level (1-10): 6 (I have to be able to laugh at myself. The need arises so often.)

Vendors....We shall slay them and take their precious.

Derrick Leggett — Fri, 02 Apr 2004 03:43:00 GMT

Does anyone else have problems with lying, cheating, stealing vendors promising the world and delivering nothing???

We've been dealing with E&& for several months now and I can't say I've ever been more disappointed in a vendor that hires sales staff who know absolutely nothing about how the product REALLY WORKS.

We have 30 databases, with the production instances currently on the EMC SAN. The hardware and technical support have been great, but we want to expand our product to include backup, development, reporting, and staging. We decide to purchase ERM (SQL Server replication manager) and SnapView (to clone LUNs). We draw a diagram of the environment, draw process documents, and detail all daily processes that will be involved based on what they tell us. They approve it and agree that the software solution will work exactly as we understand, so we buy it.

Now, here's where the evil sales people bash us over the head and run away laughing maniacally. They never bothered to tell us that ERM will not support more than one database on a LUN (which equates to a drive letter on a server), even though our drawings all had it designed that way.. They didn't think this was important, even though they approved our environment having multiple databases on one LUN.

WE HAVE 30 DATABASES ON OUR PRODUCTION SERVER IDIOTS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Let me see.

That's one LUN for logs. COUNT 1 STUPID. (Because our log files are on RAID 1+0 instead of RAID 5 like data, they have to be on seperate LUNs.)

That's one LUN for data. COUNT 1 STUPID.

That's multiplied by 30 databases. THAT'S 60 STUPID.

That's multiplied by 4 environments. THAT'S 240 STUPID.

So, we're supposed to manage 240 LUNS. DID THIS NEVER OCCUR TO ANYONE???????????????????

Oh, and we're on Windows 2000 Advanced Server. They're not sure if we can even see that many drive letters now. AND, even if we can, they don't know if their product will work with it. If they do get it to work though, guess what....the Clariion CX-400 won't support that many LUNs either.

VENDORS SUCK. VENDORS LIE. VENDORS ARE STUPID. VENDORS ARE IDIOTS. VENDORS MUST BE END-USERS.

Favorite words used: 2 (stupid, suck, lie, end-user, idiot, evil, bash, stinking, filthy)

Mean level (1-10): 7 (It's late. I just got done working. I'm grouchy. If you want a real blog, see http://weblogs.sqlteam.com/tarad.)

Education level (1-10): 9 (Never, ever, ever, ever, ever trust a third-party vendor until you hold the product in your hands and know it works.)

Entertainment level (1-10): 4 (E&& is laughing. They think this is funny. They have my precious. I must slay them and take my precious.)