Nice Teeth

Some of the commentary about the recent Amazon "Cloud" has focused on the reliability of cloud offerings, and their aggressively high availability Service Level Agreements (SLA).  Just for reference, the Microsoft Azure SLA is 99.9%, and  Amazon’s availability SLA happens to be 99.95%

Didn't see that one coming

The interesting thing about an SLA is that it doesn't make the service, or its servers, more reliable, it just specifies penalties and/or contract options for when the services become unreliable unavailable.  To go with their aggressive promises, the SLA usually provides creative definitions for “available” to help ensure the SLA is met, e.g., if the service drops half your connections, it’s still available, and you’re Simply Out of Luck

If a company actually uses its data to make money, the SLA doesn't fund the enterprise while the service is unavailable.  And the SLA typically doesn’t cover service degradation, just the creatively defined “availability.”  It also doesn’t manage or repair your tarnished reputation with your customers or your business.

Want to bet your reputation, and that of your organization on the cloud?  It’s probably a good bet, since you’re likely not getting 99.9% uptime from your own servers.  But be prepared when that .1% kicks your reputation in the teeth.

Passing the Word

So, I had this long running trace going through profiler last night (don't worry, it was just a DEV thing) and when I came in this morning, profiler had ended the trace with the following Trace Error:

-- 'Ӈ耇' was found in the text of this event.

-- The text has been replaced with this comment for security reasons.

At first, I feared a Chinese Injection Attack, but after a little digging around, I was able to reproduce it by running a trace, then stopping the traced SQL Service while profiler was still running the trace.  It's apparently a built in error code.

I thought I had seen similar behavior in the past around queries that include the word "PASSWORD" in them, so I started playing around to see if I remembered correctly.  It turns out my recollection wasn't perfect.

When you run a security statement that might contain a login's password, SQL Profiler will remove the TextData from the event.

Here are a few such statements where TextData is stripped:

sp_password

CREATE LOGIN

ALTER LOGIN

Of course, before rediscovering this, I had already run a statement using the word "PASSWORD" and profiler happily displayed my query text.  I thought I'd share, not because of the query is so profound, but because I wrote it simply for the joy of writing it.

CREATE DATABASE PASSWORD;

go

USE PASSWORD;

go

CREATE SCHEMA PASSWORD;

go

CREATE TABLE PASSWORD.PASSWORD (PASSWORD SYSNAME);

go

INSERT PASSWORD.PASSWORD.PASSWORD (PASSWORD) VALUES ('PASSWORD');

go

CREATE INDEX PASSWORD ON PASSWORD.PASSWORD.PASSWORD (PASSWORD);

go

SELECT  PASSWORD.PASSWORD.PASSWORD.PASSWORD

FROM    PASSWORD.PASSWORD.PASSWORD WITH(INDEX(PASSWORD))

WHERE   PASSWORD.PASSWORD.PASSWORD.PASSWORD = PASSWORD.PASSWORD.PASSWORD.PASSWORD;

go

DROP TABLE PASSWORD.PASSWORD;

go

DROP SCHEMA PASSWORD;

GO

USE TEMPDB;

go

DROP DATABASE PASSWORD;

GO

It's also amazingly blue because nearly every word is reserved.  If you'd like to play with it, it should run for you on any system that doesn't already have a database named "PASSWORD"

I hope you also find such light-hearted simple ways to enjoy the tools you work with.