Pass Summit 2016 and Old School MSSQL DBA Skills

I’ll be attending my very first Pass Summit next week and I’m really psyched!  Delphix is a major sponsor at the event, so I’ll get to be at the booth and will be rocking some amazing new Delphix attire, (thank you to my boss for understanding that a goth girl has to keep up appearances and letting me order my own Delphix ware.)

Its an amazing event and for those of you who are my Oracle peeps, wondering what Summit is, think Oracle Open World for the Microsoft SQL Server expert folks.

I was a strong proponent of immersing in different database and technology platforms early on.  You never know when the knowledge you gain in an area that you never thought would be useful ends up saving the day.

Just Goin to Take a Look

Yesterday this philosophy came into play again.  A couple of folks were having some challenges with a testing scenario of a new MSSQL environment and asked for other Delphix experts for assistance via Slack.  I am known for multi-tasking, so I thought, while I was doing some research and building out content, I would just have the shared session going in the background while I continued to work.  As soon as I logged into the web session, the guys welcomed me and said, “Maybe Kellyn knows what’s causing this error…”

Me- “Whoops, guess I gotta pay attention…”

SQL Server, for the broader database world, has always been, unlike Oracle, multi-tenant.  This translates to a historical architecture that has a server level login AND a user database level username.  The Login ID, (login name) is linked to a userID, (and such a user name) in the (aka schema) user database.  Oracle is starting to migrate to similar architecture with Database version 12c, moving more away from schemas within a database and towards multi-tenant, where the pluggable database, (PDB) serves as the schema.

I didn’t recognize the initial error that arose from the clone process, but that’s not uncommon, as error messages can change with versions and with proprietary code.  I also have worked very little to none on MSSQL 2014.  When the guys clicked in Management Studio on the target user database and were told they didn’t have access, it wasn’t lost on anyone to look at the login and user mapping to show the login didn’t have a mapping to a username for this particular user database. What was challenging them, was that when they tried to add the mapping, (username) for the login to the database, it stated the username already existed and failed.

Old School, New Fixes

This is where “old school” MSSQL knowledge came into play.  Most of my database knowledge for SQL Server is from versions 6.5 through 2008.  Along with a lot of recovery and migrations, I also performed a process very similar to the option in Oracle to plug or unplug a PDB, in MSSQL terminology referred to as “attach and detach” of a MSSQL database.  You could then easily move the database to another SQL Server, but you very often would have what is called “orphaned users.”  This is where the login ID’s weren’t connected to the user names in the database and needed to be resynchronized correctly.  To perform this task, you could dynamically create a script to pull the logins if they didn’t already exist, run it against the “target” SQL Server and then create one that ran a procedure to synchronize the logins and user names.

Use  <user_dbname>
go
exec sp_change_users_login 'Update_One','<loginname>','<username>'
go

For the problem that was experienced above, it was simply the delphix user that wasn’t linked post restoration due to some privileges and we once we ran this command against the target database all was good again.

This wasn’t the long term solution, but pointed to where the break was in the clone design and that can now be addressed, but it shows that experience, no matter how benign having it may seem, can come in handy later on in our careers.

I am looking forward to learning a bunch of NEW and AWESOME MSSQL knowledge to take back to Delphix at Pass Summit this next week, as well as meeting up with some great folks from the SQL Family.

See you next week in Seattle!