August 31, 2007 | Comments: (0)
An interesting debate sprung up the other day. I was called over to a developer's desk to help with an issue and as he sat there typing different solutions, I found myself getting more and more antsy. The problem was he can't type. He pecks at the keys like a princess trying to pick diamonds out of a pile of manure. It just drives me crazy to see people who can't type.
So the debate arose, should everyone in IT take it upon themselves to learn to type? I mean, it IS the way you make your living. Working on a computer for a living and not learning to type is like becoming a surgeon and refusing to learn to sew people up, or becoming a math teacher and refusing to learn your times tables, or becoming a plumber and refusing to learn how to use a wrench, or... ok, you get the idea.
And as a programmer, pretty much the only tool you have for doing your job is the keyboard. So not learning to use it at all is like being a race car driver and refusing to touch the wheel. Or a ditch digger who can't work a shovel. OK, OK, I'll stop.
Seriously though, I type very well. I can clock myself somewhere in the 90s. And while I don't expect everyone to type as well as I do, I would fully expect someone who works at the keyboard every day to at least have a basic knowledge of where the keys are. This particular guy that started this whole thing types stored procedures several hundred lines long. He does it all the time. And he's constantly having to look at his keyboard and then at the screen... keyboard-screen-keyboard-screen-keyboard-screen, etc. It's maddening. Personally, it gives me a headache to do that.
So whatever you do in IT... don't be a pecker... be a typer.
Posted by Sean McCown on August 31, 2007 08:40 AM
August 24, 2007 | Comments: (0)
It's no wonder that so many vendors are always trying to come up with a decent realtime monitoring tool. The MS tool Perfmon is good, but for monitoring a lot of counters, it can get kinda thick. The trouble is, for all the technology out there, and all the companies throwing dev dollars at this problem, there's still nothing that works as well as Perfmon. What can I say, it's just a great tool. And despite its problems with large counter sets, it's still my tool of choice. What am I going to do, use Spotlight? I don't think so.
That's really the reason why the tool is so successful at what it does though. It doesn't try to be more than it is, and it doesn't try to throw tons of those fancy pac-man graphics (or whatever game you kids are playing these days) at you. It just draws simple lines. Because of this it keeps a very small footprint on the server and just does its job. I like that. It may not be the prettiest tool out there, but it's the most reliable I've seen. And it's fairly versitile as well. You can save to different file formats, and replay scenarios, etc. You can even save to a database and do whatever you like with it after that. But Perfmon as a realtime tool just can't be beat. And anything that does as good of a job is probably similar enough that you might as well use Perfmon to begin with.
To show you what I mean, here's a screenshot of a Perfmon session from my production environment. You can see that there's no way you could ever read this, but in a case like this, you wouldn't even try. What I do when I'm looking at this server is switch it over to log mode and just look at the raw numbers. It would be nice if you could highlight some of them or color them, etc, but that would make Perfmon fatter and it wouldn't be as successful as it is. So I don't really mind the lack of functionality if it'll work every time.
I think another driving force behind all the other realtime monitoring tools is lack of education. These days nobody wants to open a book and learn what a lot of these counters mean, and how they work together. So a lot of the other tools spend a lot of time and energy trying to interpret the raw data for you. Yeah, it can be useful sometimes, but how do I know that you've interpreted it correctly, or that it's what I actually want to see. Thresholds are another advantage to the 3rd party tools. You can set alarms to go off, and bells to chime, and colors to change, etc whenever a counter gets outside your parameters. And again, that's dandy, but it slows down the tool, and quite often creates a bigger load on the server than it can handle sometimes. Especially if it's already under heavy load... I mean, you're looking at it for a reason, right? And that reason is usually performance related. So if you're having problems with server performance, then why would you add more load to it and expect to be able to do anything except cause a bigger bottleneck? This is where a lot of the 3rd party tools loose me. And it's like none of them test their software on really busy systems. If they did, they would see what they do to the systems and either fix their product, or scrap it altogether. But that's not what happens. So they either test and they don't care, or they don't care so they don't test. Or maybe they just want their tool to be used on systems that aren't suffering from severe performance problems. Maybe they're only for moderate problems. Well, how do you know what kind of problems you're having until you get in there, and why would you switch tools for the different types of issues? You need to find a tool that works all the time in every scenario so you can keep your settings, etc. You also don't have to worry about learning how to do things differently in different tools. So you guys come back to Perfmon. MS is doing some pretty cool things with it these days in Vista, and I would imagine in Server'08 too.
Posted by Sean McCown on August 24, 2007 12:13 PM
August 13, 2007 | Comments: (0)
OK, well, the response to my last Access post was a lot more than expected. There are some pretty good comments in there. Some of you made some very good points, both for and against my post. And for the first time in a long time I actually got on and approved comments so everyone could see them.
What I think is great though, is that a lot of you came out against my post, and ended up proving my point for me. I love it when that happens. Rather than dwell on those things though, I thought I'd just kinda explain why I wrote that to begin with.
I'm a professional DBA. It's what I do. That means that I deal with data all day. I backup and restore DBs, I develop DR plans, I spec sizing and performance for new servers, I troubleshoot indexing and performance issues, I recover corrupt data (as best I can), and everything else that goes along with being a production/dev DBA. In my group we do it all. I've been doing this for over 10yrs. And while I realize that there are plenty of you out there who have been in IT longer than I, a lot of you haven't been doing high-end DBs as long as I have.
So I'm looking back at some issues I've had over the past, and it hits me... a LOT of the issues I've been called in on have been due to end users pretending to be DBAs. The issues have been everything from 'we didn't put PKs/FKs on our tables and now we've got thousands of ghosted records' to 'I accidently updated all the records in my table and now we're completely screwed cause I didn't back it up.'
The issues are so varied there's no way I could recount them here, but those of you who support Access know what I'm talking about.
There are simple design principles that end users just don't know. And there's no reason for them to know them either. They're not DBAs. So why then do they want to develop their own apps? I get that it's quicker to use a tool like Access and keep the IT guys out of it. Yeah, sometimes things get over-engineered, but if you leave it in the hands of your end users then things will get under-engineered with almost no thought put behind it.
There's a reason we have DBAs. They know what they're doing. Well, they're supposed to anyway. And for every user that tells me that his Access solution is good enough, I always end up asking them a series of questions that makes them think otherwise. I've always felt that any data worth storing is worth protecting. It's clearly data you want, so why wouldn't you do what it takes to protect it? InfoWorld Daily just last week had an article on the true cost of data breach. So what cost would it be to you to have your employees be able to not just steal your data, but also the entire DB and application?
A couple of the comments to the last post said that I was wrong because there are tons of fortune 500 companies using Access all over the place. Do you think that makes one bit of difference to me? Do you think I really care what those companies are doing? Big companies can take chances with their data the same as everyone else... it doesn't make it right.
Even MS agrees with me. Look at how they're starting to treat SQL Server. In the old days, SQL shipped fully open. You could do whatever you wanted right out of the box. Now they're starting to shut things down more. With Yukon, you can't just install the DB and have it operational. You have to specifically turn on external connections. You also can't use openrowset or cmdshell right out of the box anymore either. The theory is that if you specifically turn something on, you're aware of its presence and are more likely to secure it and manage it properly. That's a method that's worked with Oracle for years.
I've always said that the general population of Oracle DBAs knows far more about Oracle than SQL Server DBAs know about SQL Server. That's because SQL has always been so incredibly easy out of the box that pretty much anyone could get a working DB up in just a day or 2. That's just not true with Oracle. It's becoming more true as Oracle's trying to become more user-friendly though.
So anyway, why do you think MS is putting all this effort into locking down SQL and making you jump through more hoops to open up functionality in SQL? Do you think it's because they're idiots, or because they've gone through their support records and saw where the bulk of their issues were and decided to start protecting us from ourselves? After all, any data loss we suffer in their product instantly becomes part of the reputation of that product whether it's their fault or not. So why wouldn't they follow this same reasoning with Access? Why give users another avenue to create a data store that's ill-conceived and basically unmanaged? From my perspective it just doesn't make sense. Like I said earlier, there's no such thing as trivial data. You either need it or you don't.
Most of you guys seem to treasure Access for its GUI abilities. Almost all of you agree with me on its merits as an actual DB. So why not pressure MS into making it a front-end dev utility? Have its functionality added to Visual Studio or the like and be done with it? I'd probably have a lot fewer problems with Access if it were just a dev environment and didn't put your data at such risk. Or if people used it the way they should and just connected to server-side DBs instead of using it to store data. That's the problem, isn't it? People have been given a pistol without a safety, and they insist on looking down the barrel.
Remember, in DBs, just because you can doesn't mean you should. MS even took object-level restore away from us in SQL 7 because of integrity issues. They wanted to protect us from ourselves. A position they're finally reconsidering. MS isn't stupid. They've got a lot of smart people working for them. And they know how to manage data. So with the way they manage SQL and the way they manage Access, I can only conclude that they're saying anything in Access isn't data worth keeping.
Let's face it, as a company, there's just no reason to give your users the ability to walk off with your entire DB and application. Why even take the chance? And there's no reason to let amateurs create DBs and apps. You're just asking for trouble. Look at it this way, it goes back to a lot of my previous posts where I talk about the lack of respect for DBAs and data in general. You'd never find one of these companies letting some random guy in IT file their taxes with some off the shelf home or small business tax software, would you? Of course not. They take their taxes too seriously. And you'd never find a company letting some random secretary file their numbers with Wall Street, would you? Absolutely not. There's too much at stake. How about making sales deals? Could I just make a sales deal with someone for my company? I mean, why spin up a project for it, or go through the channels and get a sales guy involved? They'll just complicate things and a month later we'll still be waiting. I can make the deal in just a couple days. I'll even go through a day of sales training if it makes you feel better. No wait, here's a better idea. I'll go through a day of training, and then I'll go negotiate our health plan. Maybe I'll choose where our 401K will be invested instead.
All of those suggestions are ludicrous and no company on the planet would even consider any of them because every one of those things takes a highly skilled professional to do properly. Someone who knows that field inside and out and knows the pitfalls. But data... hell anyone can do that. Let's let the dept secretary run an Access DB on her workstation. She can build it and maintain it too. What's a foreign key? Oh, that's not important. What am I going to do if someone updates all the data a table and there are no log backups? Just never you mind. And how often should we back it up? I'm sure someone else will be in charge of that. What about data theft? Oh, that's just an old wives' tale. Is this data already being stored somewhere else? Who knows? What about integration with other systems? Will other people find this useful? Now you're just talking crazy. It's really like being your own lawyer. An end user who writes his own application in Access has a fool for a DBA. At least if you went with the client/server model you'd have to study up some more and you stand a little bit better chance at success.
Now, that's not to say that Access doesn't fulfill a purpose right now. From all the comments I've seen, almost every one of you values it as a front end tool. It's just that MS should make it a front end tool and leave it at that. They should take steps to phase out the DB portion of the product. But that's just my humble opinion. A lot of you were getting very upset at the mere mention of doing away with Access. I don't know why though. It's not like MS is going to do it just because I said it. I could see it now. The Access team sitting around going, oh man, now I've gotta find a new job. Sean said we should get rid of Access. Oh well, I liked the tool and this job, but what can I do... Sean said it has to go.
I'm gonna go off on one last diatribe and I promise to keep it short. Every enterprise data modeling class I've ever seen taught by a college has been taught with Access. Seriously guys, what the hell? While I've seen modeling classes taught in other DBs, they're usually a section in a line of courses for that specific product. But for general and enterprise modeling classes, they're always in Access. I'm not even going to touch that one.
Posted by Sean McCown on August 13, 2007 02:06 PM
August 08, 2007 | Comments: (0)
I've taken a pretty good look at Office 2007 and the new Access, and the one thing that goes through my head is the same thing that goes through every time I see Access... when is MS finally going to just get rid of this thing? What real purpose does it really serve anymore? For tiny shops, you still have to buy it, and MS has other solutions that are just as easy and completely free.
You can get SQL Server Express for free, as well as Visual Studio Express. And Visual Studio 2005 comes with lots of templates and wizards so creating whatever code you need should be fairly easy. I just think that continuing to support Access is fairly useless and it's time for it to die.
Not only has Access run its course, but using SQL2K5 Express/VS05 is actually smarter. Not only are they free (and you still have to buy Access), but it's a much smarter upgrade path. I seriously doubt that any of the small businesses out there dream of staying exactly where they are, and never want to grow at all. And as a business owner, you need to look into the future and consider things that will put your company in a good position on down the line. Well, making the decision to stay away from Access is a good business decision. Not only will you not have to buy Access (my solution is free), but when your business grows, the upgrade path from SQL2K5 Express to Workgroup or Standard is super easy. In fact, you have but to attach the DB files to the new system and your application works as before. You don't have an upgrade path with Access... it doesn't exist. When you out-grow Access, you have to convert to SQL Server (or other RDBMS) and then upgrade your front-end code to match. It's a huge pain and sometimes you can't match things up perfectly and have you re-architect. The IT world is full of stories of Access to SQL conversions.
SQL files also don't get corrupted like Access files do. You put an access file on your server, and pretty soon you'll need to fix corruption on it. Let's face it, Access is an out-dated, small-minded way to do things. If everyone did business in Access, you'd have huge file server farms acting as DB servers.
SQL is also much easier to manage. With Access, you can have the files anywhere on your workstation, or the server. You don't know where to start looking, and if you have a DB you don't use for a while, and you forget where the file is, what do you do? It's almost impossible to find it if you don't know where it is. Someone can also come along and delete your DB right out from under you and you'll have nothing. Or someone could just move it for you and not tell you where it is. There a quite a few things that can happen to an Access DB. With SQL however, you just don't have that problem. The DB is in SQL Server and it stays there. As long as the service is running nobody can delete your files, and if they do, you probably have a backup. Also, you can't forget where your data is stored on SQL. You just connect to the server, and the DB is right there. You don't have to maintain a shortcut to all of your DB files and keep up with where they are. Managing a lot of Access DBs is just ridiculous when you compare it to how easy it is to manage SQL DBs.
Access also doesn't have the same facilities as SQL for scheduling jobs, managing security, BI, reporting, etc. You just get far more out of SQL than you ever could out of Access... and did I mention Access isn't free and SQL is?
Anyway, join with me and lets all kill Access.
Posted by Sean McCown on August 8, 2007 06:35 AM
August 06, 2007 | Comments: (0)
You know, it never fails. You go on vacation, or just take a couple days off and you come back to hundreds if not thousands of emails. And of course it takes you a while to go through them all and you never know which ones are the important ones until you see them. This is when the problem starts. Here you are being forced to go through all these emails, and 40% of them are Reply Alls from actual issues.
Sure, you need to know an issue happened. And it even helps to know the root cause of it. What I'm talking about here is all the useless chatter that comes after...
"Thanks for your help."
"Oh sure, my pleasure. Let me know if there's anything else I can do for you."
"I will. Thanks again for your help."
"You're welcome."
Come on people, is all this chatter really necessary for Reply All? Do the rest of us really have to hear this? What's your goal here... is it to thank the guy, or to let everyone see you being as polite as you can? And remember, while you're being polite to that one guy, you're being pretty rude to everyone else.
Coming back from a couple days off is bad enough, but what about those of us who do on-call support? When I get pulled out of bed and resolve the issue, I typically want to go back to bed and not hear another word until there's another problem. Instead, what I get is another hour of pleasantries. Because remember, being on call means that you have to look at your email every time it goes off. Seriously people, is it really necessary?
I tend to be pretty militant in my guarding of the silence. I personally don't reply all to simple issues, nor do I reply all once the issue is closed. And I usually make it pretty clear to people who do that it's not acceptable behavior. For those who have never had to do after hours support, they just don't get it. I've even gone so far as to call someone every time he hit reply all for something stupid. The confusion on the other end of the line is usually priceless.
"Why did you call me?"
"Well there's an issue. You just sent me an email."
"No, I was just telling him thanks for helping me."
"Then why did you include me and get me out of bed for it."
"I was just being polite."
"To whom? Because I have to get up every time email goes off, so I figured there was another problem since you got me and everyone else on support up."
"I didn't realize you had to get up."
"You complain when we don't answer issues in the middle of the night, so how did you figure that happened if we're not getting up when email goes off?"
"Well, again, I was just being polite."
"OK, well do you call a meeting with everyone in the office just to thank someone for their help in person?"
...etc.
You guys get the point. It's actually a pretty gross breach of support etiquette to reply all for things that have no business going to everyone. Like I said above, it's the same as calling a meeting with everyone in the dept just to carry on a simple conversation with the guy who sits next to you.
I've actually worked in places where everyone in the group got upset if they didn't hear every last word no matter how insignificant. I can remember being called into the boss's office to be asked why I refuse to include everyone on emails. And when I explained that I just don't like to bother everyone with every word I say, I got a lecture on what it means to be a team player. It's funny sometimes the limited focus some people have.
I've also been on the front end of building a support organization where nobody was used to having to take these things into consideration. And what I've found is that people don't even think about things like this. What's worse is even when they're getting woken up for no reason, it still never crosses their minds to limit the email traffic.
The answer is simple courtesy. Even if you don't have a support staff responsible for answering every email that comes across, it's just simple courtesy to not force everyone to listen to your chatter. Hey, email all you want to whomever you want. Just don't make me listen to it.
I put this on the same level as going to a meeting and leaving your phone riger on high on your desk, and going home for the evening with your source code checked out.
Posted by Sean McCown on August 6, 2007 10:22 AM
August 02, 2007 | Comments: (0)
OK, I had a different blog planned today, but I just got my PASS newsletter and got inflamed again. I hope I don't have to go over this again, but I'll do it as many times as I have to.
DBA = A single DBA.
DBAs = More than one DBA.
DBA's = An object owned by a DBA. The DBA's idea.
DBAs' = An object owned by more than one DBA. The DBAs' toolkit.
It's not that I expect the ordinary person to know these rules necessarily, but I would expect the Professional Association for SQL Server to know how to pluralize DBA.
Posted by Sean McCown on August 2, 2007 07:38 AM
TOP STORIES
Microsoft's post-Yahoo optionsNet neutrality bill introduced
MS adds $3 million to Big Easy
AMD's Java improvement efforts
Leopard at 6 months
Intel still investing in WiMax
Yahoo tests aggregated search
Developers vs designers
Sun defends JavaFX Script
Botnet spams 60B a day
ADDITIONAL RESOURCES
- Application Security: Threats and How to Counter Them
- Why Linux Threats Mean Business
- Virtualization: A Step by Step Approach to Success
- Virtual Test Lab Automation: Manage development infrastructure
- Improve Resource Utilization and Lower Operating Costs
- Protect Your Data with SSL
