Scheduling with the SQL Server Agent

A few practical examples on setting up policies. This time, we PowerShell it.

It is possible to use the SQL Server Agent to execute PowerShell scripts. If you've worked with the SQL Server Agent to run jobs on your server, you already know that whenever you define a job step, you have to define a job step "type." In SQL Server 2008 and newer, when you create a new job step and click on the Type drop down, you see what's in Fig. 1.

New Job Step dialog
Figure 1. Creating a new job step. (Click image to view larger version.)

The most frequently used step types are T-SQL and the SQL Server Integration Services Package; however, you can see now that we have the PowerShell type. Selecting this tells the SQL Agent to invoke the SQLPS environment to run whatever commands are entered in the job step.

It's an inside job...
Figure 2. Job step creation; like the Powershell code? (Click image to view larger version.)

Fig. 2 simply shows the Job Step dialog box with some sample PS code. One thing to be very cognizant of: When creating a PowerShell job step, there is only one security context available, which is the "SQL Server Agent Service Account." That means that if you intend to execute PowerShell scripts/commands from SQL Agent Job steps, the service account that the SQL Server Agent is running as must have appropriate permissions. This includes access to the folder where the scripts actually live, as well as any output directories. This also means that the you have to set the signing and restriction permissions on the SQL Server itself (as discussed earlier in this series). Once all of that is done, getting the SQL Server Agent Job setup to run your script is just like creating any other SQL Agent Job.

There's one other "gotcha" to keep in mind: Every time a SQL Agent Job step executes PowerShell code, it opens it own SQLPS.exe process. This process alone consumes about 20MB of memory (not counting any work it's doing). If you have a server executing quite a few PowerShell job steps, this could get ugly.

Be sure to keep tabs on how many PowerShell job steps are running on a server; try to avoid running too many of these types of jobs on very busy production servers. In fact, since the primary use for PowerShell for most DBAs is administrative in nature, try to use an "Admin" server for your PowerShell jobs. This will help logically separate the workload as well as prevent SQLPS.exe processes from using precious memory on your production SQL Servers.

That's it; you can use many of the scripts and commands discussed in this series to create jobs to help you manage your servers, gather information, and keep you informed on your environment.

About the Author

Joshua Jones is co-author of A Developer's Guide to Data Modeling for SQL Server: Covering SQL Server 2005 and 2008 (Addison-Wesley Professional, 2008) and is a principal with Denver-based Consortio Services LLC.

Featured

  • Ransomware: What It Means for Your Database Servers

    Ransomware affects databases in very specific ways. Joey describes the mechanics of a SQL Server ransomware attack, what DBAs can do to protect their systems, and what security measures they should be advocating for.

  • Windows Admin Center vs. Hyper-V Manager: What's Better for Managing VMs?

    Microsoft's preferred interface for Windows Server is Windows Admin Center, but can it really replace Hyper-V Manager for managing virtual machines? Brien compares the two management tools.

  • Microsoft Offers More Help on Windows Server 2008 Upgrades

    Microsoft this week published additional help resources for organizations stuck on Windows Server 2008, which fell out of support on Jan. 14.

  • Microsoft Ups Its Carbon Reduction Goals

    Microsoft on Thursday announced a corporatewide carbon reduction effort that aims to make the company "carbon negative" by 2030.

comments powered by Disqus

Office 365 Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.