Tag: administration

  • Finding a Balance

    lego USB
    Are devices like this a problem?

    This editorial was originally published on Nov 19, 2007. It is being republished as Steve is on vacation.

    When I started in IT things were much simpler. We had smaller data sets, but hardware was larger. There just wasn’t a good way to transfer large amounts of data on 3 1/2″ floppy drives. I remember CDs coming into being and CD writers became a concern, but since few people had them and we knew who they were, it wasn’t a big problem. The zip drives created a cause for concern briefly with their 100MB capacity, but again, they were somewhat bulky and easy to spot.

    However with the growing sizes of flash drives, storage in cell phones, and the monstrous capacity of iPods and other music players, it seems that data has little chance of being contained by IT within the walls of the organization.

    I saw an interesting discussion about managing all these technology devices and the problems that come with so much storage being in reach for so many people.

    So we’re data people, we get beat up to ensure our SOX procedures work well, and we’re in the trenches. With that in mind, the poll this week is…

    Does it make sense to ban personal storage devices?

    I know it’s not practical to actually try and prevent the iPods and other devices from coming into the building. You for sure cannot take away all the cell phones from people. But does it make sense to prevent these devices from connecting to your network? Ban USB and Bluetooth; don’t purchase rewriteable drives except for admins who can be monitored. Some other ideas?

    That might not even work. Recently a report surfaced about some executives in Korea that stole nearly $2billion worth of trade secrets with USB drives and taking them to a new company.

    Think about the past experiences we”ve had. Suppose you”d locked down floppy drives and CD burners a decade ago. All of a sudden MP3 players appear and get mounted as removable drives. It”s a new twist you hadn”t considered, so you shut down all the serial, parallel, and USB ports. You get a new laptop and realize Bluetooth is now available and works just as well and your controls have been circumvented again. What do you do now? It’s a tough balance to strike. Are you trying to be a control freak and make it an hostile work environment or do you trust your employees and deal with the occasional problems that come with them?

    I’m not sure what the best solution is, but I’d venture to guess that banning the technologies won”t work. Someone will always come up with a new way to get around your controls, and more importantly, you won”t be as vigilant if the controls “appear” to work.

    I’d adopt the Counterpane approach to security, which is what security expert Bruce Schneier believes in. Assume you”ll get compromised and attacked and put systems in place to detect and respond to issues rather than trying to prevent all attacks.

    Steve Jones


    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available atsqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). We’ve upped the quality a little on the Quicktime files, so if it’s better from your side, let us know. Comments are definitely appreciated and wanted, and you can get feeds from there.

    The RSS Feed:  or now on iTunes! 

  • Separate Accounts

    Separated Strawberry
    Is separation that much of a hassle? I don’t think so.

    Many years ago I worked in a small company that only had about 5 or 6 servers. We had one system administrator whose job it was to manage all the servers. One day our sysadmin was on vacation when there was a problem with the Exchange server. One of the other developers worked on the system and ended up fixing it, but changed the service account password while doing so. The next day I walked into the office to find a group of people stymied as to what was wrong with the development server and version control system. Everyone claimed they hadn’t changed anything on that server, and they were right. However our admin used the same domain account for all servers, including my SQL Servers. I changed the SQL service account that day.

    One of the recommendations that I learned a long time ago, and one that I make regularly, is that every SQL Server instance should have a separate security account. In that case, I had separate accounts created for each database instance, and for each SQL Agent instance. We used long, random passwords that were never stored, and if we needed to access a password, we just changed it. That kind of flexibility and separation prevented any crosstalk issues between services, and it allowed us to easily alter permissions or passwords for one service without affecting any others.

    The other day I saw someone recommending a single service account for all SQL Servers. Someone else recommended a single account for each version of SQL Server, using separate accounts where it’s really needed. That’s a better recommendation, but I still prefer completely separate accounts. I know that some security groups don’t like that, but is it that big a problem? This Friday I wanted to ask you about your experiences.

    Do you find separate accounts for each instance (or Agent) to be a security or administrative issue?

    I’m not sure why this is unwieldy. Service accounts rarely change, and you could easily script changes to a group of accounts with PowerShell or some other tool. Once I set a service account, the only thing I might ever do later is alter the permissions to add access to a folder. When that happens, I definitely want to have separate accounts for each instance.

    Let us know this Friday how you feel and what works for you.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Copy Cat Poll

    copy cat shirt
    How many copies of data do you need in our organization?

    One of the interesting facts I saw a few years ago talked about storage in enterprise environments. There was research that showed many enterprise applications had 6 or 7 copies of their large databases inside the organization. In addition to the production copy, there were many other copies in use, resulting in an explosion of growth. That wasn’t surprising, and it was one of the drivers for implementing compression in many databases.

    While the cost of storage is constantly coming down, it’s still expensive for enterprise class hardware, especially in a large SAN device. Today I wanted to ask those of you that work on real world systems to make a quick count of your own system, and let us know. I can’t decide if 6 copies of a production database is high, or low.

    How many copies, on average, of your production databases are in your company?

    I suppose you could count backups as a copy, since it’s disk space usage and you have to pay for it. If you count backups, let us know, but I’m thinking just about the test systems, development systems, HA or DR systems that might receive copies of the data. Some of those secondary systems might be in use for other purposes, such as reporting from readable secondaries in an AlwaysOn scenario. Whether they are or not, they are still copies of your database.

    I used to think that four or five copies would be a lot, but with the advances in technology that allow different DR options, and the cheap local storage available on today’s desktops and laptops, I wonder if seven or eight copies might be more accurate.

    Take a count today; you might surprise yourself with the results.

    Steve Jones

    If you are looking to reduce the cost of storing all those copies of your data, take a look at SQL Storage Compress, Virtual Restore, or SQL Backup Pro from Red Gate Software.


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The DBA Database

    database
    Having a database to store DBA type data can be very helpful for a busy administrator.

    Do you have a DBA database on all your instances? I’ve always kept a small database on all instances, usually standardized with a set of tables and procedures that I used to monitor and track activity on the instance. By keeping this fairly standard, I could script and deploy it during all new installs as well as easily aggregate information from all instances on a central server, usually in a slightly larger version of my DBA database.

    It’s nice to see more and more DBAs using this same technique in their environments. Over the last few years I’ve seen lots of articles and blog posts that recommend building a DBA database and populating it with DBA-stuff. That DBA-stuff can be anything from tracking backup sizes, to storing performance metrics, to keeping trace data. I’ve seen some neat implementations with Service Broker that use the DBA database as a repository for a queue to which they can send messages. Based on those message, they can have the instance  perform some action.

    There are any number of standards or corporate reasons not to include extra databases, but none of them really make sense. The DBA database, and any administrative tasks that use this database essentially act as a proxy for the DBA. Almost every piece of data stored in this database is data that the DBA would query or use on a regular basis. Keeping it inside a database set aside for this purpose allows the DBA to act more efficiently.

    If you haven’t built a DBA database, I’d encourage you to do so on all your instances. Secure it so only sysadmins can access it, but use it to capture and store information about the ongoing health of your SQL Server.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.