First, here is the link to the Feedback Item that is out there for voting to get Microsoft to fix this issue. There has already been an issue fixed with the msdb proc to activate dbmail in a Contained AG ([dbo].[sp_sysmail_activate]).

What is the Issue?

The issue is that within a Contained AG the master and msdb are actually named AGNAME_master and AGNAME_msdb which in the procedures mentioned use the following code which uses the original msdb database instead of the AGNAME_msdb database.

-- sp_RunMailQuery is used to run a query result into the mail message
SET @mailDbName = db_name() -- which will return msdb instead of AGNAME_msdb

The fix is to have this code instead so that it uses the real database name since it is in a contained availability group which makes the AGNAME_msdb look like msdb when connected to the AG Listener. See below.

-- Note: we cannot use DB_NAME() here since this SP could be running in the context
    -- of a contained AG: in that case, we really want to fetch the physical name of the DB
    SELECT @mailDbName = physical_database_name FROM sys.databases WHERE database_id = DB_ID()
    SET @mailDbId   = DB_ID()

Notice how the database name instead of just being DB_NAME() it is using the physical_database_name that is in sys.databases for this DB_ID()? This is the fix. You can make the fix yourself until Microsoft gets to it in the feedback item.

If you have not applied the latest SQL 2022 CU to your servers and you run a Contained Availability Group, then you should look to update your server so that you have the most up to date fixes in SQL Server. So far this fix is not in a CU, but the previous one for dbo.sp_sysmail_activate has been fixed in one of the CUs previously.

The post Contained Availability Groups using DbMail Query appeared first on DBAduck.

I read the feedback and understand the comments made. Based on the feedback I am adding a Part 2 for both presentations. Add PowerShell to your DBA Toolbox! and SQL Server 2022 Contained Availability Groups. I am going to be completing the presentations on Twitch.tv/dbaduck on November 27th at 3:00 PM MDT.

The presentations are linked here.

I will be covering a more deep level of PowerShell for DBAs to complete the more basic side of PowerShell that I presented. If you have any questions that are related please post them to https://pollgab.com/room/dbaduck so that I can address them as part of the broadcast. I would love it if you wanted to attend live to ask the questions in the chat window.

As I said before, I thank you all for your feedback and your attendance and this is why feedback is so important. None of it was brutal but sincere and to the point. I appreciate the opportunity to resolve feedback that I received. I hope to see you there.

The post PASS Data Community Summit Presentations part 2 appeared first on DBAduck.

This post will assist you in configuring this solution when you add it to your SQL Servers. Jobs are created with this solution. You download it at the link above.

• Backup Jobs for System and User databases
• Database Integrity jobs for System and User Databases
• Cleanup jobs for Command Log and Output Files

I recommended creating a database to use for this solution or even installing it into an existing DBA function database. I usually create a DBA database and use it for this purpose and others as well. With this new database, you configure the Database in the header of the maintenance solution SQL file, whether to create jobs, retention time and backup directory for the jobs.

USE [master] -- Specify the database in which the objects will be created.

SET NOCOUNT ON

DECLARE @CreateJobs nvarchar(max)          = 'Y'         -- Specify whether jobs should be created.
DECLARE @BackupDirectory nvarchar(max)     = NULL        -- Specify the backup root directory. If no directory is specified, the default backup directory is used.
DECLARE @CleanupTime int                   = NULL        -- Time in hours, after which backup files are deleted. If no time is specified, then no backup files are deleted.
DECLARE @OutputFileDirectory nvarchar(max) = NULL        -- Specify the output file directory. If no directory is specified, then the SQL Server error log directory is used.
DECLARE @LogToTable nvarchar(max)          = 'Y'         -- Log commands to a table.

Parameters to Fill Out

Pay close attention to the highlighted lines:
The database name you created is put in the USE statement and the following items are created in that database:

• CommandLog table
• Stored Procedures that are in the solution

I use the DBA database here, which keeps it out of System databases and in an isolated place.

The @CreateJobs variable specifies whether or not the create the jobs. If you already have it installed, turning that off is easy, you just change it to an ‘N’ and it will merely update the code so that you have the latest version.

Next is @BackupDirectory which is where you specify the database backup location you want to use for the backups. If you do not specify this one, then the default is used. The default location is in the Database Settings tab of the Server Properties in SSMS.

Next is @CleanupTime and it is specified in hours. If you want to clean up the backup files after 1 week, you specify 168 as the hours for cleanup time. This number is put in all the Backup jobs that are created.

Last but not least, is the @OutputFileDirectory which specifies the folder for the output files that are on each step in the Ola jobs. If not specified, it will default to the LOG directory specified in the startup of SQL Server. The SQL Server Errorlogs are kept in that folder. I usually leave the parameter to be NULL to leave the output files there.

The @LogToTable parameter is configured as ‘Y’ because this is going to be put in the jobs as well to ensure that the work that is done in this solution is logged in the dbo.CommandLog table in the specified database.

In the code block below, the data is filled out so you can see what it looks like and the jobs get created with these settings as their defaults. The stored procedures are created in the specified database as well.

USE [DBA] -- Specify the database in which the objects will be created.

SET NOCOUNT ON

DECLARE @CreateJobs nvarchar(max)          = 'Y'         -- Specify whether jobs should be created.
DECLARE @BackupDirectory nvarchar(max)     = '\\server\share'    -- Specify the backup root directory. If no directory is specified, the default backup directory is used.
DECLARE @CleanupTime int                   = 168        -- Time in hours, after which backup files are deleted. If no time is specified, then no backup files are deleted.
DECLARE @OutputFileDirectory nvarchar(max) = NULL        -- Specify the output file directory. If no directory is specified, then the SQL Server error log directory is used.
DECLARE @LogToTable nvarchar(max)          = 'Y'         -- Log commands to a table.

Conclusion

It is important to remember that this solution creates jobs that have a structure and at https:.//ola.hallengren.com the documentation has a full complement of examples of how to configure these jobs with parameters. The items that you need to ensure are configured include @LogToTable = ‘Y’ and @Compress = ‘Y’ so that you get it logged to the table and the database backups are compressed. If you omit the @Compress parameter then it will rely on the server setting to compress backups by default. Never rely on a setting that can be changed with or without your knowledge.

This part was not meant to be 100% comprehensive, but to ensure that you have information of how to install the jobs and solution, other parts are going to go into more depth so that you can see how to use it in the real world.

The post Ola Hallengren Maintenance part 1 appeared first on DBAduck.

This year, you can save $50 on attending by using my last name (MILLER) as the promo code, AND if you register by January 31st, you may be eligible for free hardware as well – a Microsoft Band 2, a Surface 3, or an XBox One.

You can visit the site to see the full lineup of sessions and workshops. I’m going to be presenting two 200-level sessions on PowerShell and Encryption and a Workshop on PowerShell:

SQL Server Encryption
Have you ever wanted to know how Transparent Database Encryption (TDE) works or how you set it up? What about encrypting your backups? This session will go over all the steps and caveats that go with this technology. TDE allows you to have your database encrypted on disk and the same Encryption Hierarchy allows you to back up your database and have it encrypt the contents in the backup file. We will discuss the Encryption Hierarchy which is used for encryption in SQL Server and take you through keeping your secrets safe. Master the concepts of SQL Server Encryption when you are done with this session.

SMO Internals for High Performance Automation using PowerShell
In today’s fast paced world, automation is becoming a necessity and not a luxury. PowerShell is a powerful tool that allows you to leverage Windows objects and coupled with SMO you have the power to connect to SQL Server objects. This is all great, but not understanding how SMO works, you could find that your automations are not as fast as you would hope, when accessing SQL Server. This session will take you beneath the surface and demonstrate the secret sauce that will help you get the most out of your SQL Server automation scripts and have them perform. Understanding is the key here and we will get you there in this session. Let’s take your automation to infinity and beyond.

WORKSHOP ON MONDAY, APRIL 18, 2016

PowerShell for the DBA from 0-60 in a Day
Think of how many servers or instances you maintain. Putting tools in your toolbox becomes a critical part of your life as a DBA. How many clicks can be reused? We will be taking you from 0–60 and everywhere in between with how PowerShell fits into a DBA’s day in the life. We will go from getting PowerShell connected to SQL Server to walking away with a toolbox starter kit that will help you get automated and allow you to focus on harder problems than modifying database options or getting information from SQL Server and storing it away for later analysis. The toolbox alone will make it well worth your attendance.

Join me in the quest to become a PowerShell DBA.

Hope to see you there!

The post Join me at SQL Intersections for a great lineup this year! appeared first on DBAduck.

Starting Out with PowerShell

Be Friendly to SQL Server

The post Utah Code Camp 2015 Presentations appeared first on DBAduck.

I like this topic because I think about it all the time.  I have learned so much from others and I am trying each year to ensure that I give back by speaking at SQL Saturday’s across the country.  No one pays for my trips (most of the time) but it is the least I can do for those that have helped me in my career.

Giving back is so much more than just speaking or giving a gift, it is about helping someone replace you in the Community. Mentoring, speaking, teaching and leading.  I lead my SQL Server User Group locally with another awesome guy and I speak at local events thanks to another great guy. In our town we have Utah Geek Events run by Pat Wright who keeps us full of opportunities to give back. I just cannot get enough.

So this year will be full of speaking, leading the group and attending the other User Group locally

to ensure that I am available. Not for love given to me but to ensure that if I have experience that someone needs, that I am there to share with no strings, no ego and no agenda. That is how I will give back this year.

I hope to blog more and get more articles written and to support just a little bit more than last year so that people looking to learn will have yet another place to go to get some help. Thanks to all those that have helped me along the way, most of you know who you are and the list would be way too long to list here and I would for sure leave someone out and I would never do that to my #SQLFamily.

Happy Holidays and see you around.

The post T-SQL Tuesday #61–Giving Back appeared first on DBAduck.