You can see the curriculum at this link PowerShell for DBAs Fundamentals | DBADuck Training School. The class is scheduled to be delivered live and the recordings will be available to you for a year as part of the class. The enrollment link is live and will allow you to enroll, but make sure you use the discount link below.

BLACK FRIDAY special. For 2 weeks there is a coupon BLACKFRIDAY that will get you $2000.00 off the regular price of $2,995.00. Don’t miss out on this deal before the end of this year. If you have any questions you can feel free to use the Contact link.

The post PowerShell for SQL Server DBAs Course is Finally Here! 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.

Event Information

Monday, March 6th at 8:00 AM Mountain Time (click the link for your time)

I am excited to get this started, so I hope you will join me for the first of my Office Hours.

The post PowerShell for DBAs Office Hours appeared first on DBAduck.

What? Huge News!

How is this done?

According to the documentation page, you simply would put #NOSQLPS in the first line of the SQL Agent PowerShell Job Step as in the image below, and when the job runs, it will NOT load the SQLPS module. This starts in SQL Server 2019, so it has not been back ported to previous versions of SQL Server.

If you want to test this, you can put the #NOSQLPS in the top of the step and then on the second line put ‘Get-Module’ without the quotes and then run the job. When you look at the job output, you will see nothing. If you remove the #NOSQLPS from the job step and put Get-Module in the line, run the job and then look at the output, you will see the SQLPS module be returned.

Hopefully you found this useful.

The post SQL Server Agent PowerShell Job Step with #NOSQLPS appeared first on DBAduck.

First you would have a SAN LUN configured for iSCSI which would have a IQN like iqn.1991-05.com.microsoft:winsan-winsql1-target. This is a unique identifier for the iSCSI resource and this is what you would connect to for the drive.  To make this connection you would use the iSCSI module that has the commands you will see.  Below is the example of the connection.

# On Client Computer 
$TargetPortal1 = "10.1.1.1" 
$TargetPortal2 = "10.1.2.1" 
$ISCSIIP1 = "10.1.1.2" 
$ISCSIIP2 = "10.1.2.2" 
New-IscsiTargetPortal -TargetPortalAddress $TargetPortal1 -InitiatorPortalAddress $ISCSIIP1  
New-IscsiTargetPortal -TargetPortalAddress $TargetPortal2 -InitiatorPortalAddress $ISCSIIP2 

Figure 1.1 – The same as New Discovery Portal in iscsicpl

Start-Sleep -seconds 2

Connect-IscsiTarget -NodeAddress "iqn.1991-05.com.microsoft:winsan-winsql1-target" 
	-IsPersistent $true -IsMultipathEnabled $true -TargetPortalAddress $TargetPortal1 
	-InitiatorPortalAddress $ISCSIIP1

Connect-IscsiTarget -NodeAddress "iqn.1991-05.com.microsoft:winsan-winsql1-target" 
	-IsPersistent $true -IsMultipathEnabled $true -TargetPortalAddress $TargetPortal2 
	-InitiatorPortalAddress $ISCSIIP2

Figure 1.2 – Connecting with MultiPath IO using 2 different Targets and Initiators

Now you have a drive attached, at least in iSCSI.  This drive will be a raw drive and using Get-Disk  will show them. This cmdlet is in the Storage  module in PowerShell.

Figure 1.3 – Get-Disk in action. Showing the newly attached drive

The next task is to online and configure the new drive so that you can use it. You need to initialize the disk, then create a partition of type GPT and finally format the volume with 64KB blocks for use with SQL Server.

Initialize-Disk -Number 1 -PartitionStyle GPT # Data

New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter E 

Figure 1.4 – Initialize-Disk and New-Partition to make the drive accessible

Get-Volume -DriveLetter E | 
         Format-Volume -FileSystemLabel DATA -AllocationUnitSize (64KB) -FileSystem NTFS `
                -ShortFileNameSupport $false

Figure 1.5 – Get-Volume and Format-Volume to finish setting up the drive

This concludes this part of the creation of a drive from the iSCSI side of the house.  The entire piece of code is available here.

Happy PowerShelling. Onward in the quest to become a SQL PowerShell DBA.

The post Connecting iSCSI LUNs with PowerShell appeared first on DBAduck.

I have heard many times from many people that it is not worth learning PowerShell as a DBA.  I have been using PowerShell since v1.0 and have found it to be amazingly rewarding. I will illustrate why this is the case in this entry and hopefully some of it will resonate with you and you will find some worth in learning at least a little PowerShell for your DBA job.

First, PowerShell was built to manage Windows Servers and soon manage some part of Linux servers as DotNet Core comes into play.  Back in the day, if you were a DBA and wanted to manage SQL Servers, you used a lot of SMO (Shared Management Objects) and that meant programming in C# or pseudo C# in PowerShell. Creating objects, managing properties, etc.. That was not for everyone I know. I have a developer background and an IT background so managing servers and Active Directory and building programs to do things was part of my world a long time ago.  But what I found was that there were not a lot of tools in the marketplace for doing things against SQL Server with PowerShell then so it was not widely adopted by DBAs.

In the SQL Server 2008 days, Microsoft wrote some PowerShell Snapins that would give us access to some cmdlets (Commands) in PowerShell to manage some things and introduced a PowerShell Provider for SQL Server that turned your SQL Server into a series of Paths (SQLSERVER:\sql\servername\instancename) and that was pretty powerful, at least to a guy like me, looking to automate many repetitive tasks. With those cmdlets and the provider there began to be a way to now use PowerShell to get at SQL Server without writing .NET code. It certainly did not cover the breadth of the product like Exchange had done with their cmdlets, but it was a start of some love. This is where the dawn of becoming a PowerShell DBA began.

Now Why Investigate

For a DBA there are many times you want to know information about your server, and there is plenty of TSQL to get that information. You need to know the DMVs or the system tables to get at that information and for a fairly new DBA, that can be a real challenge. Here is where the paradigm begins. In SMO there are objects (methods, properties) that encapsulate the properties of the objects in SQL Server into a class (Object Oriented term). These classes represent the objects by having the appropriate methods and properties to act on those objects.  Let me illustrate.

We all know that there is a Database object in SQL Server and there are many TSQL commands that we can use to find out information such as…

SELECT * FROM sys.databases

SELECT * FROM sys.database_files

and many more….

It is a common practice to create a set of TSQL scripts and take them with you as you go. That is one of the values of longevity in the industry is what you have created and built up.  There is no argument from me for this mentality. This is where you parallel with the PowerShell mentality in that you can reuse the scripts later on and not have to remember or rebuild them on the fly. But is there a better way? Maybe, but at least there is “another” way.

Enter PowerShell

PowerShell in and of itself is a mechanism to do many things. I advocate DBAs learn it because of the way you can change your job by using Automation, Scripting and Information Gathering that is much different than running TSQL Scripts and copy-pasting them into documents or tables. (or even Excel)  I will take you through a couple of scenarios to give you a flavor of an additional tool (not advocating replacing SSMS or any other tool with PowerShell, only making you more efficient) with examples.

Say I want to have a list of databases with their name and recovery model.

TSQL

SELECT name, recovery_model FROM sys.databases;

PowerShell

Get-SqlDatabase –ServerInstance servername  | Select Name, RecoveryModel | Format-Table * –AutoSize

We won’t really go into how you get to be able to run these commands, just to compare the commands. They are not much different than each other, one is run in SSMS or sqlcmd and one is run in PowerShell console or ISE or another tool that will execute PowerShell.  The results are pretty similar as well.

Now that doesn’t look too scary. You get the same results.  Here is how you would get it with the provider.

Notice that I used a Path-Like structure to get to the Databases in the Provider.  I used the –Force parameter to ensure that I got the System Databases. Now that seems the same, other than the tool. So you ask the question, why do I do it?  Why do I learn PowerShell to be able to get the same information?  Here is the answer.

Objects are the answer

In TSQL you get results in a Grid or Text, you copy and paste or you just look at it and read it. You just get some text back either in PowerShell or TSQL or so it seems.  In PowerShell everything is an object and they all have (potentially) methods and properties.  Let me illustrate something that is an interesting part of PowerShell and objects.

Say I want to change the recovery model to Full on my DBA database.  in TSQL I could do it in a couple of ways and it would look something like this.

ALTER DATABASE databasename SET RECOVERY FULL

Let’s take a look at how you do it with PowerShell and why it would be valuable to get this tool in your toolbelt.

What you see is the retrieving of the Database object in an SMO object (the provider always returns an SMO object) and there is a Property called RecoveryModel that tells me which recovery mode it is. To set it, the property is read/write so I can change it with the words “FULL”, “SIMPLE” or “BULKLOGGED” and then I use the method Alter() as above.  The methods have the double parenthesis () after the method name and I could have inserted ($true) in the parenthesis to do a WITH ROLLBACK IMMEDIATE like I would do if I were changing a property that required full access.  Now that looks like it may not be very advantageous, but imagine the next scenario.

I create a function to change my recovery model.  I can use parameters for my SQL Server instance and the database and the RecoveryModel.  Now I have a tool that does not require SSMS to be installed and allows me to call a function to change my recovery model.  Once this is written and saved (and even put in a module for easy loading), and loaded into my environment, I can use it pretty easily for any database on any server.

Like I said before, this is contrived and works because I have SMO loaded, which is not hard to do, but this entry is all about why, not how to get things loaded.  I have a SQL PowerShell Stairway at SqlServerCentral.com that you can go and read to help you get that part worked out.  Not hard but not the reason for this post.

Join me in the quest to become a PowerShell DBA. Stay tuned for more on this site and join me in a class soon.

The post Why Become a PowerShell DBA appeared first on DBAduck.

SQLSkills Training

Event 1 for this month revolving around PowerShell is May 8-10 at SQLskills.com training in Chicago. I am teaching the first class of the Immersion event on PowerShell for the DBA. You can see the details in the link on the class.

I am super humbled and excited to teach this class for SQLskills and at the time of this writing there are 3 seats left after we opened more seats for the class. Please join me for a great event.

We will be going over how to get started with PowerShell and then dive right in and learn why a DBA should learn PowerShell and why you would ever want to become a PowerShell DBA. There are so many reasons and so much value, I cannot contain it all in this type of post. But we will be having a grand time drinking from a firehose and learning while we do. 🙂

I hope you will join me for this iteration, or plan on another iteration another time. I love PowerShell and look forward to meeting all of you who are going to be there.

PASS Virtual PowerShell Chapter Meeting

Event 2 for this month will be on Wednesday, May 17th at 12:00 PM Eastern Time I will be presenting to the group on Gathering Data for Trending using PowerShell.  You can RSVP here . I will be covering a great topic that I spend a lot of time thinking about. There is a lot of data in SQL Server and a lot of Meta-Data that can tell some great stories about your servers and what the behavior looks like.  Ever since working at Microsoft with the Community Research team on Newsgroup Behaviors, I have been hooked on looking at things in SQL Server as far as behaviors go, not just about features and such.  So I have created some data gathering scripts to get data and put it into tables with snapshots in time and looking at the information in a different light to see if I can derive how things are working in SQL Server.  Join me for a great time and register for the webinar here.

SQL Intersection

Event 3 will be a PreCon at SQLIntersection on May 20th in Orlando at the Disney Swan Hotel.  If you are going to be there, I hope you will join me and if you are thinking about going, please register and join me there.  It is my well-liked PreCon that takes you from 0-60 in using PowerShell as a DBA and a professional that wants to manage SQL Server from a command line instead of clicking your way through everything.  I will be teaching how to leverage the shell as well as balancing the use between SSMS and PowerShell to gain another tool in your toolbelt.

This will be a great month focused on PowerShell.

The post PowerShell month in May with DBAduck appeared first on DBAduck.

You can visit the site to see the full lineup of sessions and workshops. I’m going to be presenting four, count them 4 sessions on SQL Server topics and 2 Workshops on PowerShell in SQL:

Be Friendly to SQL Server with TSQL Best Practices
TSQL is a necessity when interacting with SQL Server so knowing can be half the battle. Performance is always good as the database starts to grow, but building in resilience when you begin is a greater advantage than refactoring. I will go over 5 key things to know when you write TSQL, use DataTypes and/or variables in comparisons and you will also learn about the procedure cache and how to avoid pitfalls there. This is a beginners session but the concepts in this session are a great foundation to begin with. If you are looking for a solid foundation to build on and need the basics to start, this session is definitely for you.

SQL Server Filestream Implementation and Management
Filestream was introduced in SQL 2008 and has been a part of the engine since then. The reasons to use Filestream over BLOB has been talked about in many different ways and for many different reasons. I will take you through how to get SQL Server configured to use Filestream, what that means and how to implement a column that is of Filestream type. I will also go over where the files live and how to stream them outside of the SQL engine instead of pulling them through the engine. Join me for an in depth discussion on this technology. We will also touch on FileTables which was new in SQL 2012.

Managing Availability Groups with PowerShell
Today Availability Groups are all the rage. Being a PowerShell guy I prefer to manage things with PowerShell. The SQL team has granted us a great toolset in the SQLPS/SqlServer module that allows you to fully manage Availability Groups simply. Join me for a fun filled hour of PowerShell and Availability Groups, you won’t look at them the same way after we are finished.

SQL Server on Server Core with PowerShell
Ever wondered what the craze of Server Core is all about? There is a lot of power in Core and with it comes the admin challenge of NO GUI. But there are settings that you want to change in the OS, how do you do that? This session will take you through some of the challenges that are not really challenges when you know. We will use the builtin method of making some changes and also use PowerShell and commandline tools to get you where you want to be with Core. I built a 6 node cluster on Server Core and created it with PowerShell (Cluster and all) and it runs very nicely with a little footprint in RAM for the effort.

WORKSHOP ON TUESDAY, OCTOBER 25, 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.

WORKSHOP ON SATURDAY, OCTOBER 29, 2016

PowerShell for the DBA from 60-120 in a Day
This is the next installment of becoming a PowerShell DBA. Now that you have been introduced to PowerShell and have an idea of what you can do, we take it to the next level and start you thinking about tool building and using PowerShell to actually manage instances. We take a look at modules you can use every day and then we talk about building your own modules. PowerShell is becoming more prevalent in the world of DBAs but still has not come to a level that I would like to see in our careers of working smarter not harder. We will be looking at practical items that you can use PowerShell to enhance because DBA work can contain a mass amount of clicking around if you only use Management Studio. We will take the challenge to remove as many clicks as possible from your daily management of databases and database servers. We cover Database Maintenance, monitoring and data gathering. We talk about managing SQL Server instances with PowerShell and last but not least, we will see how to use it to manage Jobs and SQL Server Agent. Join me in the quest to become an effective PowerShell DBA.

Join me in the quest to become a PowerShell DBA.

Hope to see you there!

The post Join me at SQL Intersections in October 2016 appeared first on DBAduck.

Starting Out with PowerShell

Be Friendly to SQL Server

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