What I realized at the onset of the pandemic

I thought that it would be the best thing ever to be able to work from home and never go into the office. In the beginning it was great as I loved to work from home anyway because I got more done and drivebys were not prevalent. What I realized is that the interaction with the team was really nice. To keep up with things and talk with people physically was more important than I thought. I also found out that I was perfectly OK without interaction while working and that I was more of an introvert than I thought. But now I did not get to travel to SQL Saturday’s and speak, I did not go to the User Group physically and catch up with the members. So while I loved being in my home-office and was perfectly content, I was not perfectly content. I had a side of me that wanted to interact and see the whites of peoples eyes and present in front of. In the end I wanted to be with the #SQLFamily more than I thought I would.

Health Ramifications

I don’t think I take care of myself as much as when I was in the office. I eat worse and I sit all day and find myself having sat for hours on end without drinking water or eating anything. I don’t think that I am in better health than before the pandemic. I weigh more and I have not developed good habits as I should. So I have to start thinking about long term and not short term in my health. I am grateful to have been shown this by the pandemic, I know I cannot keep doing what I have been doing and be OK. I am beginning to put together a plan to get more healthy and develop good habits around exercise, good office practices (taking breaks, getting up from the chair, standing for a bit) so that I can be more healthy and happy, less stress and a good outlet to the daily grind.

My Advice to others

Really it is about finding out who you are and what you want to be. To be of help to your colleagues you need to keep up with yourself and have something to offer. I have given all my time, effort and really everything to everyone else, and I love to do it because growing is very important in keeping your mental health. If you do not learn and grow, you stagnate which means that you start to feel like you don’t have anything to offer and if that is a pattern every day, then it will be really detrimental a month from now, because the frog doesn’t get boiled overnight, it takes a slow rise of temperature and the frog stays in the water until the heat is so much that he cannot get out of the water because of no strength and then he boils. Don’t let the temperature of your water slowly cook you to death, recognize right now that you are in that pot of water and you want to ensure that you get out on dry land to make a difference. Give a little and then give a little more, but remember to give to yourself at the same time. Mostly so that you can thrive, grow and learn the things that make you, you. Take care of yourself through this pandemic and remember that you are a great part of our #SQLFamily and we need you to be complete. Stay safe and see you out there.

The post How is the pandemic going for you? (T-SQL Tuesday #132) appeared first on DBAduck.

I set off to do some tests.  First I created a Mirrored database using the demo code from the VC presentation.

Now once the database is created on instance 1 I backed up the database and a log backup. Then restored it to the second instance with it’s log with no recovery. Once it was primed and ready, I established a mirror and saw the database was synchronized.  Now the trick is to use create the components to establish the Encryption Hierarchy.

Now that we have the MASTER KEY and the Certificate in place, you need to backup the certificate to a set of files and restore it to the second instance.

NOW CHANGE TO THE SECOND INSTANCE

Now that you have the Encryption Hierarchy established for both instances, let’s encrypt the database.

What will happen in the Mirror is that it will encrypt the database, even though you won’t be able to see it.  When it is fully encrypted, and you fail the database over in the Mirror, it will indicate that the database is encrypted. On the Principal you can see it with the query below.

The post SQL Server TDE on Mirror and Log Shipping appeared first on DBAduck.

Parameters

• Database Id
• Object ID
• Index Id
• Partition Id
• Level of interrogation (DEFAULT, LIMITED, DETAILED, SAMPLED, NULL = LIMITED).

The interesting thing is that when any of the first 4 parameters are NULL, the default is to evaluate ALL of the items in that parameter.  For example, if you specify NULL in the Database ID then it will evaluate ALL databases in the server. If Object ID is NULL then it will evaluate all objects.  So I knew all that, but here is what I did not realize, quoting from the documentation:

“passing values that are not valid to these functions may cause unintended results. For example, if the database or object name cannot be found because they do not exist or are spelled incorrectly, both functions will return NULL. The sys.dm_db_index_physical_stats function interprets NULL as a wildcard value specifying all databases or all objects.”

“Additionally, the OBJECT_ID function is processed before the sys.dm_db_index_physical_stats function is called and is therefore evaluated in the context of the current database, not the database specified in database_id. This behavior may cause the OBJECT_ID function to return a NULL value; or, if the object name exists in both the current database context and the specified database, an error message may be returned. The following examples demonstrate these unintended results.”

Now that is nice, but here is what it means. If you are specifying a database id for use in this function and the database id is not the “current” database, then if the OBJECT_ID() function is used, it will evaluate it in the “current” database and NOT the database that is represented by the database id in the statement. If the object does not exist in the database, then it will result in NULL and will then proceed to do an evaluation on all objects in the database represented by the database id.

The other caveat is that if in the current database there is an Object by that name that results in an object id being returned, when the function begins, it will not be able to find the object id returned and will actually error. Take a look at the examples below and notice that you will want to be in the database that you intend to use if you are specifying anything beyond the database id. Don’t get caught with NULL in the statement without you knowing about it.

[code lang=”SQL”]use master
GO
SELECT *
FROM sys.dm_db_index_physical_stats(DB_ID(‘AdventureWorks2012’), OBJECT_ID(‘Person.Person’), NULL, NULL, ‘LIMITED’)

— Results were for 190 rows
/*
** What happens here is that it evaluates OBJECT_ID(‘Person.Person’) to NULL
** because it does not exist in master as shown below.
*/

use master
GO
SELECT OBJECT_ID(‘Person.Person’)
— Result is NULL
GO
use AdventureWorks2012
GO
SELECT OBJECT_ID(‘Person.Person’)
— Result is 1765581328

/*
** Let’s create a table in master of the same name
** as in the AdventureWorks2012 database.
*/

use master
GO
CREATE SCHEMA Person AUTHORIZATION dbo
GO
CREATE TABLE Person.Person (id int)
GO
SELECT *
FROM sys.dm_db_index_physical_stats(DB_ID(‘AdventureWorks2012’), OBJECT_ID(‘Person.Person’), NULL, NULL, ‘LIMITED’)
GO
— You get the error below
/*
Msg 2501, Level 16, State 40, Line 3
Cannot find a table or object with the name ‘.StateProvinceCountryRegion’. Check the system catalog.
*/
[/code]

The post sys.dm_db_index_physical_stats Easter Egg appeared first on DBAduck.