Archive | SAN RSS feed for this section

POLL: Which SAN vendor have you had the best “SQL” experience with?

First and foremost, I want to see a totally anonymous poll that shows which vendor is the most loved by the SQL community. At the same time, if you would be kind enough to carry on a dialogue through the comments then I believe everyone would benefit. Choosing or replacing a SAN vendor requires getting past all the marketing fluff and down to the stuff that really matters. I hope that I can start a little momentum in that direction with this poll. Benchmarks and reviews are great if you have links to share. I want to know your bad experiences as well as the days when you were glad you chose a certain vendor.


Here are a few links to add to the discussion. If you have additional links feel free to add them.


Comments { 0 } Posted on June 7, 2012 in SAN, SQLServer, SQLServerPedia Syndication

T-SQL Tuesday #028 – Jack of All Trades, Master of None?

This is my first time to participate in the T-SQL Tuesday so take it easy on me. I really do come in peace.

It’s funny to me that this is one of the key things that drove me into the SQL world. I blogged about this last year explaining how I “Cheated on SQL Server”. Things have kept going uphill from that point and there are no regrets, but I don’t guess I will ever go from Jack blogger to Master blogger. Sounds like I should be in a guild or something.

Seeing Argenis Fernandez (Blog | Twitter) post on Leaving DBA-Land it resonates with how I feel about the leaving the SysAdmin world. I’m not sure if you ever really leave it all behind. I find myself needing to know more than ever about storage (like SANs) and how it pertains to SQL. I find myself needing to learn more about networking and the bandwidth that matters when you are discussing how SQL talks to its friends (or enemies).

I hate code by the way, never will I specialize in writing code. I will leave that to other Jacks and Masters because I really don’t want anything to do with it. Some people’s minds just don’t work as well when it comes to that. I’ll just stick with beating you in the 40-yard dash (based off my high school time of course). I tend to gravitate towards the Database Administrator side of things with Performance and Standards. It’s kind of cool to be dogmatic about at least one thing in your career, so master the “art of saying NO” to those developers who want too much access, that way you can sleep at 2am.

What is wild is that while we are always talking about specialization, the DBA certifications are trending more towards the developer (at least they were in 2008). Crap…I don’t want to be a developer. Anyway, hope you have fun getting just a little bit closer to being a Master or Jack of some trade so that you can pay the bills.

Comments { 1 } Posted on March 13, 2012 in Blogging, Networking, SAN, SQL General, SQLServer, SQLServerPedia Syndication, Tech

Where’s the page file when you need one?

I’m not sure how I missed this one given that I do quite a bit of reading online about best practices. My intentions were noble. I wanted to give my SQL Server the perfect environment so that it could flourish and thrive.  I wanted to allow the latest and greatest Microsoft OS (Windows Server 2008 R2) to shine on its pretty new C: drive. What I learned in my attempts at greatness is that I dropped my guard. I didn’t have the iron-clad check list that I thought I had. So now, it’s back to the drawing board to come up with my ideal checklist and installation guide for the Operating System and SQL Server 2008 (post date TBD). And if you are really curious about my fatal mistake that cost me a day and a half before I gave up trying to bring the server back up read on.

For the 3rd time, I’ve had a Dell R900 with SQL Server 2008 and Windows Server 2008 R2 start dropping iSCSI drives. When you believe you’ve properly laid out your separation of duties for SQL (E:\SQLData, F:\SQLLogs, T:\TempDB, and X:\SQLBackup) one would hope there wouldn’t be more problems. But for some reason, these ingredients mixed together have caused me quite the headache. I’m not giving up on Windows Server 2008 R2 just yet, as I’m trying to learn from my mistakes and kick this problem’s tail. There are two crucial mistakes I made this time which caused me more downtime and gave me more work to do in order to get back to an operational state. I listed four drive specifications above that I have used for everything but the OS, SQL Install files and Shared Features, and OS Paging File(s). I have had a practice of doing the following:

  • The OS on the C: drive.
  • The SQL Binaries on the D:\ drive (minus the shared resources that have to go on the C: drive).
  • Remove the paging file from the C: Drive, and place a paging file 1.5 times the RAM on the D: drive.

Maybe some seasoned veteran is reading this and laughing at me, and I’m sure I deserve that after the blunder I made. Because I didn’t have a page file of any size on the C: drive, I was unable to analyze the .dmp file to find out what exactly was causing Windows to go into a reboot cycle. I had lost one of the iSCSI connections so SQL was dead because it kind of needs that Tempdb thing. So I panicked and rebooted, but this time the Logs drive didn’t come up. So I started having deja vu from my previous experience with Windows Server 2008 R2, iSCSI, and SQL Server 2008 only to remember something in my mind thinking that a patch might have caused this since I had been running fine for a few days. So I uninstall the patch that was put on earlier that day (slight possibility that it was SP1 but I don’t believe so), and it goes to reboot. Now we are in an endless cycle of reboots, and there’s no turning back. Oh, but let’s count the positives that came out of this. I now have a few future posts in the works (when I can find the time with two young children) ranging from the Microsoft Disaster Recovery Toolset, Operating System Installation Guide and Checklist, a SQL Server Installation Guide and Checklist to recovery options when you have hit a wall.

Let’s get back to the biggest lesson learned here. You really do need a paging file on your boot volume. Coming from the Windows side of things the best document I could find was a technet post by CC Hameed it suggests RAM + 1MB for a complete dump. For something specific to Windows Server 2008 R2 you can look at at these Memory Dump Options.  You can also learn how to generate a dump file in Windows Server 2008.

From a SQL Server side, that’s probably not realistic. And you’ve got to look at what your physical resources are as well. I would point you to a great article by Buck Woody (blog|twitter) entitled “The Windows Page File and SQL Server”. I hope to write a follow-up post with an example of this process from one of my servers.

So the takeaway from today is not to end up with the inability to diagnose your problem by not having a paging file on your boot drive. How you determine to size that paging file is going to be up to you and your system. Use the resources I’ve listed and please include new ones that you find.  Feel free to add any experiences that you have had that you can’t believe you made or gotchas that others can learn from.

Comments { 2 } Posted on March 1, 2011 in SAN, SQL, SQLServerPedia Syndication, Windows Server

Jumbo Packets

In the past few months, we’ve gradually been implementing a new SAN solution from Dell that uses iSCSI. We are kind of learning as we go and there are always bumps in the road. I’d noticed we had some I/O issues on our main production SQL Server but nothing seemed to add up and I couldn’t find where the problem could be outside of tuning indexes or putting data files on a different drive. We are on SQL Server 2000 but we are moving towards 2005 and I’m sure that might have helped me troubleshoot the problem. I came across something the other day about Jumbo packets. As I read more and figured out where to check things I figured out I might have been onto something. Brent Ozar passed me this link that helps check on the packet size. I looked at the iSCSI connection(NIC card –> Configure –> Advanced) and noticed that the Jumbo Mtu was set to 1500. I asked more questions of our admin and everything else along the pipe had been raised to 9000, but somehow the card got missed. Once I set this to 9000 I saw that I had far fewer I/O problems. They are still there due to poor indexes and disk contention but they are better than they were. Just thought I’d pass this along in case anyone else had a similar issue with iSCSI.

Comments { 1 } Posted on February 26, 2009 in General, SAN, SQL Server 2000

Warning: Unknown: open(/home/content/44/3656244/tmp/sess_dcsuuoumenkmhbuhbbstgjcs26, O_RDWR) failed: No such file or directory (2) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct () in Unknown on line 0