March 25, 2014 at 4:01 am
Manic Star (3/24/2014)
LSAdvantage (3/21/2014)
I have chuckled about this several times already today! This is great!Manic Star (3/21/2014)
I accidentally scrambled production data in an effort to scramble DEV data once.As if I don't have enough shame from my other post, a loooong time ago when I was green, I bulk copied some data from production to move to dev, then truncated the table on dev. You guessed it....I truncated production instead! Thankfully I had just bulk copied the data so I just bulk copied it back. I truly felt all the blood rush to my feet when that happened.
Yep, i walked into boss's office right after i realized what happened, and he was actually pretty cool about helping me recover from the error.
Lesson learned, always double-check your connection and use transactions even for 'routine stupid stuff'.
I use the connection colour option in SSMS. See 'Use custom color' and set up registered servers using the desired colours. I tend to give red to production, yellow(ish) to UAT etc and green to development instances. It works like traffic lights in that I don't remember checking most of the times when it wasn't an issue but I do notice the colour a lot of times when I need to be sure.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 26, 2014 at 9:05 am
Gary Varga (3/25/2014)
I use the connection colour option in SSMS. See 'Use custom color' and set up registered servers using the desired colours. I tend to give red to production, yellow(ish) to UAT etc and green to development instances. It works like traffic lights in that I don't remember checking most of the times when it wasn't an issue but I do notice the colour a lot of times when I need to be sure.
I think this works well for some people, but for others your muscle memory takes over and the colors blur into the background because you see them so often.
March 26, 2014 at 9:27 am
Steve Jones - SSC Editor (3/26/2014)
Gary Varga (3/25/2014)
I use the connection colour option in SSMS. See 'Use custom color' and set up registered servers using the desired colours. I tend to give red to production, yellow(ish) to UAT etc and green to development instances. It works like traffic lights in that I don't remember checking most of the times when it wasn't an issue but I do notice the colour a lot of times when I need to be sure.
I think this works well for some people, but for others your muscle memory takes over and the colors blur into the background because you see them so often.
For application, user, or service accounts, we can limit operations using role based security. The problem with sysadmin, is that it always has full privilege. However, running ad-hoc DML or DDL operations should not be part of a DBA's daily routine. Something that would be useful, not specific to SSMS but rather a feature of the provider libraries, is a ReadOnly connection option. In the SSMS 'Connect To Server' dialog, the DBA could toggle on or off the ReadOnly option depending on wether they are just managing backups and monitoring that day, or wether they are about to do something like run a deployment script.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 26, 2014 at 11:31 am
Steve Jones - SSC Editor (3/26/2014)
Gary Varga (3/25/2014)
I use the connection colour option in SSMS. See 'Use custom color' and set up registered servers using the desired colours. I tend to give red to production, yellow(ish) to UAT etc and green to development instances. It works like traffic lights in that I don't remember checking most of the times when it wasn't an issue but I do notice the colour a lot of times when I need to be sure.
I think this works well for some people, but for others your muscle memory takes over and the colors blur into the background because you see them so often.
This is something EVERY dev should do as we rarely should be on production instances and I have found it is under these rare circumstances that the red comes up like a neon sign. I can imagine for DBAs it will be a kaleidoscope of colours 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 26, 2014 at 11:59 am
I can imagine for DBAs it will be a kaleidoscope of colours 😉
I always wanted to use kaleidoscope in a sentence. "I just hit F5 with focus on the wrong monitor and now my vision is a kaleidoscope of 'rows affected' and red connection color screens".
March 27, 2014 at 1:38 pm
I use the connection colour option in SSMS. See 'Use custom color' and set up registered servers using the desired colours. I tend to give red to production, yellow(ish) to UAT etc and green to development instances. It works like traffic lights in that I don't remember checking most of the times when it wasn't an issue but I do notice the colour a lot of times when I need to be sure.
And what happens if the user is color blind? We had a wonderful report that used red/yellow/green to identify issues....the end user happened to be color blind and couldn't tell a difference.
-SQLBill
March 28, 2014 at 3:57 am
SQLBill (3/27/2014)
I use the connection colour option in SSMS. See 'Use custom color' and set up registered servers using the desired colours. I tend to give red to production, yellow(ish) to UAT etc and green to development instances. It works like traffic lights in that I don't remember checking most of the times when it wasn't an issue but I do notice the colour a lot of times when I need to be sure.
And what happens if the user is color blind? We had a wonderful report that used red/yellow/green to identify issues....the end user happened to be color blind and couldn't tell a difference.
-SQLBill
Good point. Most solutions (if not all) will not cater for everyone. Steve (Jones) already highlighted that a DBA who works on production machines a lot will see red bars too often to be warned by it.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 16, 2014 at 9:30 am
Eric M Russell (3/26/2014)
Steve Jones - SSC Editor (3/26/2014)
Gary Varga (3/25/2014)
I use the connection colour option in SSMS. See 'Use custom color' and set up registered servers using the desired colours. I tend to give red to production, yellow(ish) to UAT etc and green to development instances. It works like traffic lights in that I don't remember checking most of the times when it wasn't an issue but I do notice the colour a lot of times when I need to be sure.
I think this works well for some people, but for others your muscle memory takes over and the colors blur into the background because you see them so often.
For application, user, or service accounts, we can limit operations using role based security. The problem with sysadmin, is that it always has full privilege. However, running ad-hoc DML or DDL operations should not be part of a DBA's daily routine. Something that would be useful, not specific to SSMS but rather a feature of the provider libraries, is a ReadOnly connection option. In the SSMS 'Connect To Server' dialog, the DBA could toggle on or off the ReadOnly option depending on wether they are just managing backups and monitoring that day, or wether they are about to do something like run a deployment script.
I just discovered that, starting with SQL Server 2012 Native Client, we now have the connection property ApplicationIntent = ReadOnly.
However, when I specify that option in the "Additional Connection Parameters" tab of the "Connect to Server" dialog in SSMS, it appears to have no effect, I can still update tables. It would be useful to place a connection in read-only mode without logging in under a special read-only account.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 2, 2018 at 6:51 am
Reminds me of a T-shirt I saw a while back:
"Bad decisions make good stories"
...
-- FORTRAN manual for Xerox Computers --
February 5, 2018 at 10:06 am
Many years ago (mid 90's) I was involved as both lead DBA and developer in a migration from an old ISAM database to a relational DB (Oracle at the time). We had been diligently working for over a year on code changes and testing when we came to go-live day. Everything was going great on day one when all of sudden at late morning people all over the office started calling with panic in their voices. NOTHING IS WORKING!! We can't enter orders, invoices - everything is down. My IT colleagues and management panicked and were ready to pull the plug and go back to the old system. I felt the sinking feeling that Steve and others describe, but I knew if we went back at this point it would kill confidence and could mean weeks of more long days. Normally I'm a pretty mild-mannered guy, but I told everyone, in no uncertain terms, to go away and hunkered down. Within 20 minutes I found that we had forgotten to turn off a batch job on the old system that purged various tables and rebuilt them from the old ISAM DB. I turned that job off, rebuilt as much as I could, and we were up and running with just a small amount of transactional data lost. The system ran very well for years after that, and everyone was quite happy with the outcome.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply