Voice of the DBA

Category: Editorial

  • Real Time Dangers

    There can be tremendous volatility in short term data.

    There seems to be a quest to move closer and closer to real time decision making. Gather data, analyze it, and make decisions instantly, preferably with the help oif expert systems. That makes some sense, and as shown in the article, it can allow analysts to respond to events very quickly, performing verification, fraud checks, or just about anything you can think of.

    It’s a good goal, and it can definitely help many companies make more informed decisions at any point in time. However there are problems as well. Sometimes short term data can fundamentally distort the picture of reality. Some of our large stock market meltdowns are the result of automated systems, perhaps not so much expert systems, as very quick reacting systems that might overvalue the last few pieces of data and make decisions that are less than optimal.

    We cannot program systems to handle every situation, nor can we even give enough guidance to inexperienced humans that might be involved in the workflow. Instead we ought to recognize that short term data might not represent longer trends and ensure that we have people looking over the data across a longer timeline before any important decisions are made.

    Too often it seems we build systems, assuming that more data, delivered quicker, is the way to prevent poor business decisions. We might easily overwhelm other systems, or people with too much data, delivered too quickly, or used to inform decisions too quickly. Real time systems can provide many benefits, but their use should be tempered with this saying I have long believed: computers give us the power to make mistakes quicker than ever before.

    Steve Jones

    The Voice of the DBA Podcasts

  • Going Green in Software Development

    We use a little solar power at the ranch, making us a touch more "green"

    I am very interested in a better use of the electricity we use on this planet. I think energy production from non-fossil fuel sources will be important in the future, and I’m regularly examining the energy usage at my ranch, calculating the cost of wind, solar, and other energy production technologies to see if any of them are a good investment. I believe that our future will both require and consume more electrical energy. That’s fine, but I think that we ought to be looking to be more efficient in how we use energy, which will require an effort to build and use more efficient devices.

    Many authors write articles and speak about techniques that you can use to build more efficient applications. The most popular sessions given by speakers and requested by attendees are those that deal with improving performance. Writing better code, troubleshooting issues, and increasing the efficiency of our systems are under our control seem to be the priorities for most IT workers that I know. Every time we build something a little better, it’s a great win for the author.

    Intel published an interesting article that talks about the impact that writing better code might have on energy usage in applications. Computers use different amounts of energy under different loads. More intensive computations use more power than the idle thread that occupies the CPU during low usage periods. I don’t know how much power I’m using at my house for computing, but I plan on measuring it, especially after reading this post from someone that calculated his power consumption.

    Power is becoming a more of an issue for many data centers. The cost is rising and becoming a significant percentage of the total expense of operation. While data professionals tend to work on server systems, which share the load from many clients and might not have much idle time, there still could be room for improvement. Writing better, more efficient code that requires less reads, less CPU cycles, can end up reducing the cost of operation. Maybe that’s a reason to ask for a little larger training budget and learn how to write better, non-RBAR code (as Jeff Moden would say).

    Whether better code could save a significant amount of electricity is hard to know, but in most cases, it doesn’t take any more time or effort to write more efficient code than poor code: if you know how. You probably have plenty of reasons to learn to write better code, but here’s one more. Writing better code might help you feel a little more green.

    Steve Jones

    The Voice of the DBA Podcasts

  • ETL

    The phases of ETL

    Today we have an editorial that was originally published on Aug 31, 2006 as Steve is traveling at DevConnections.

    I’ve followed the development, release, and subsequent news on SQL Server 2005 for over two years now. It’s been an interesting journey and I’ve had the chance to see some evolutions in the product over time as well as observe the reaction to different subsystems.

    At the Colorado Code Camp, where I got roped into speaking, I was asked what I thought was the part of SQL Server 2005 that had the most impact. I’m not a heavy user of the product, but since I gather, edit, and follow the news I answered that Integration Services was one of the most written about, blogged about, newsworthy systems. It seemed more people were really excited about SSIS than anything else, despite the fact that I think the Service Broker and other technologies are “cooler” to me.

    So when I saw some people knocking SSIS, as well as this blog post by Jamie Thomson, I decided this would make a good poll.

    Is SSIS a professional data integration tool?

    I’m not a BI guy, and not deep into the ETL world like many of you out there. However it does seem to me that while it may not offer all the features of tools costing thousands of dollars, it does a great deal of the things I need in a professional ETL tool.

    Most of us don’t deal with terabyte databases. We don’t roll up data from 30 separate applications into one humongous data warehouse and then spin off a dozen cubes for different departments.

    I’ve done some of that on a smaller scale and I thought DTS was up to the task most of the time. Sure the error handling wasn’t great and there were times we had to restart things and do some manual cleanup or script editing, but it worked very well for most of my needs. From what I’ve seen of SSIS, it’s more robust and does an even better job of being a professional tool I can use.

    As to whether it’s professional enough or enterprise ready, I’d like to know what you think.

  • Laptop Boy Scouts

    Are you prepared for remote work?

    This editorial was originally published on Jan 10, 2007. Steve is at DevConnections, so it is being republished. 

    So class, for today’s protection mechanism you’ll need: a mouse, a loop of wire, a lock, a key, and a link. Sounds like MaGyver, huh? This article on hot spot security gives you some software hints and covers most of the items I listed above. The exception is the loop of wire.

    If you’re working for some time at a place, especially a place that’s traffic’d well, you might want to lock your computer to the desk or table. It will discourage iJacking or the chance that someone will walk by, grab your laptop and run. This is more likely in a cafe or Starbucks than an airport, but you never know.

    The advice is good and it makes sense that most of the discovery and openness of Windows is rapidly becoming a liability. Even out here in the country, where I live and my nearest neighbor is nearly 1/4 mile away, I have keys on our wireless routers. I know it’s not the best security, and I did get some complaints about making everyone have a key until a neighbor’s router showed up on our computers. Makes you realize just how far away someone could be and reach your system.

    As handy as all the capabilities are in wireless networking, as with anything else, they need to be secured and they should be turned off by default. Use them when you need them, but the rest of the time, try to be a bit more secure and limit access to your system.