How do you schedule a job in SQL Server 2016? I've done this in 2005 but going through the tree in SSMS I don't see anything that resembles any type of scheduling that I am familiar with.
Searching finds me nothing for 2016. In older versions I see references to Jobs and Agent but I do not see any of those choices. Could I not have permission? Do they have new names? I also can't find the activity monitor which I found to be very useful (especially for terminating my processes during debugging sessions).
As it turns out I went through a similar situation and had to find a workaround.
It is actually quite simple. Just have a batch file created to run msserver from shell, then schedule to run that on OS.
Assuming you're running on Windows, use Task Scheduler to run a file that goes:
sqlcmd -S servename -d database_name -Q "Query or procedure here"
I don't know if the nature of the job and the permissions you have would make this not feasable, but nevertheless, maybe it will be of help.
Related
Hopefully this question is unique enough not to be a duplicate. I have a PowerShell script which does two things.
Inserts records into a SQL Server table
Writes text to a text file
For the purpose of this post, I have simplified the script. On my computer, the script is located at C:\Temp\ssis.ps1. Following is the contents of the script.
DTEXEC.EXE /F "C:\Temp\ssisjob.dtsx"
$date = Get-Date
Write-Output "This PowerShell script file was last run on $date" >> C:\Temp\test.txt
When I manually run this PowerShell script, records are inserted into the SQL Server table, and a line of text is written to the test.txt file. If I schedule this script to run using Windows Task Scheduler, a new line of text is written to the text file, but the records are not inserted into the SQL Server table. This tells me that Windows Task Scheduler is able to run the PowerShell script. However, for some unknown reason, Windows Task Scheduler seems to not want to run the SSIS job (DTEXEC.EXE) part of the script. Event Viewer confirms there is an issue with the SSIS job. I am running Microsoft SQL Server 2014, Developer Version.
In my task, on the Actions tab, the Add arguments field has the following reference: C:\Temp\ssis.ps1. Task Scheduler is configured to run with the highest privileges.
I have tried all of the following Execution Policies in PowerShell. Regardless of the Execution Policy I select, my experience does not change.
Bypass
Unrestricted
RemoteSigned
The History tab in Task Scheduler has information events, but no error events.
I do not have the permission to view the SQL Server logs (this is a production server).
I have been debugging this issue for a few weeks, and I have read numerous posts here on Stack Overflow, yet I still cannot seem to find the answer, so hopefully I have done my due diligence before making a new post here. I could add some additional observations, but I do not want my post here to get extensively long. If anyone has any hints or tips or insight that might lead me down the right path, it would be greatly appreciated.
Here is the solution I came up with. Instead of exporting the file to Excel, I exported to a flat file (txt file). Also, using Nick McDermaids excellent recommendations, instead of using PowerShell in Task Scheduler, I started the dtexec.exe file in Task Scheduler.
Task Sheduler Actions Tab
Keep the action as Start a program
In Program/script, type dtexec.exe
In Add arguments, type /f "C:\path\to\example.dtsx
Leave the Start In box empty
I have a Requirement where i have to run a SQL Script in SQL server on a weekly basis .Result of this script has to be mailed.I want to automate this process.I don't want to go with SSIS Jobs. I have searched i have found few options like Creating a Windows Scheduler task to invoke a SQLCMD.Can Someone Assist on how to create Scheduler task to invoke SQLCMD
Your best bet would be to create a Console Application which executes the SQL Command and performs the email.
You can then use setup a task under Task Scheduler to use the Start a program option and run it on the schedule you prefer.
sqlcmd is just a command line tool. Put your SQL in a script file, and call it from the tool with right DB server and credentials. We can help you to figure how to make it work if you have a specific problem, but you should make your own tries before and tell us what goes wrong.
You will easily find examples on how to run a script :
http://msdn.microsoft.com/en-us/library/ms170572.aspx
More details on parameters :
http://msdn.microsoft.com/en-us/library/ms162773.aspx
example :
sqlcmd -S myServer\instanceName -i C:\myScript.sql -o C:\EmpAdds.txt
For task scheduler, it's easy to use but beyond SO scope, and it depends heavily of your version of windows, so (again), try yourself first.
Please note that you can also use SQL Server Agent to schedule your jobs.
This has been driving me crazy. I have tried all suggestions and no go.
This absolutely does not work. The files are all still there.
The job runs successfully, but the files do not delete.
I recently ran into the same problem, and it was due to folder permissions. Easy enough to check:
Check the properties of a recent bak or trn file, security, and find out who the owner is.
Now check the properties of the backup FOLDER, security and see if the FILE owner from step 1 has enough effective permissions to delete files. The account might only have enough to create and modify, but not to remove files.
The peculiar part is that the plan always ran "successfully", even though it failed miserably. This is why teachers shouldn't let students grade their own tests. (grin).
What account is this running under? Domain Admin, service, etc?
I've always found it easier to create a batch job and use windows scheduler to clean up .bak files over x number of weeks. Can you look at the job history and see if the task failed / succeed, may be worth looking at the event viewer on the server as well.
The only solution I could find was to take the SQL that was generated from the cleanup task, and run that in an SP instead, 'cause guess what??? The SQL that this plan generates, runs perfectly!!!!!
This is the code I am using to run and it works.
ALTER PROCEDURE spUtility_delete_OldBackups
AS
DECLARE #date varchar(28)
SET #date = CONVERT(varchar(28),DATEADD(DAY, -5,GETDATE()))
EXECUTE master.dbo.xp_delete_file 0, 'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\EEIDW\', 'bak', #date,1
EXECUTE master.dbo.xp_delete_file 0,'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\EEIDW\','diff', #date,1
EXECUTE master.dbo.xp_delete_file 0,'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\EEIDW\','trn', #date,1
I have a similar job that runs with no problems, what account does SQLServerAgent run under, these maintenance plans execute as SQLServerAgent, if the security context that SQLServerAgent runs under does not have adequate permissions, this job will fail, there should be some job history that will tell you more though.
We are in the process of migrating from SQL 2000 to SQL 2005. We have hundreds of DTS pacakges, that the development team is reluctant to redevelop using SSIS.
When migrating these packages to SSIS, I am faced with a problem - many of these packages read from Excel files.
Given that my production Box is 64 bit, I am forced to use CmdExec sub-system to call the 32 bit runtime to execute these packages.
My question here is : What are the security risks involved with using CmdExec subsystem to schedule these SSIS packages as SQL agent jobs?
Thanks,
Raj
Whatever account running the job will potentially have access to run commands from the command line - so you need to think about how it will be running and what permissions the account will have.
For example, if a user could create a job that would run under the context of your sqlagent and your sql agent was overpriviledged (rights to change security), she could grant herself elevated privs or hurt your machine.
SQL 2008 introduced a switch for DTExec that allows you to run the packages in 32 bit mode using the native SQL Agent task for SSIS. On the execution tab of the job step properties there is a check box for 32 bit, which translates to the "/X86" switch when looking at the command line view.
If you are stuck using SQL 2005 then the CMDEXEC option is the only one I know of.
xp_cmdshell is the biggest security risk in SQL Server because it allows a compromised SQL Server box to elevate the attack to the host operating system itself, and from there to the entire network.
The typical vector of attack is web site HTTP form -> SQL injection -> xp_cmdshell -> take over SQL hosting machine -> take over domain. If xp_cmdshell is shut down then the attacker has to find other means to elevate its attack from SQL to the host.
Other scenarios exists, like insider users using it to elevate privileges, or using the cmdshell for other purposes, eg. steal a database. All are based on the fact that xp_cmdshell allows arbitrary commands to be executed and on the host, and in some cases the commands executed also inherit the SQL Server service account privileges.
There are other commands and extend procedures that can be used by an attacker if xp_cmdshell is blocked, but they far less known. Using the xp_cmdshell vector is in every SQL injection cheat sheet and forum discussion, so is known by everyone and their grand ma.
I have a program that runs osql.exe from microsoft sql server tools directory and runs a script.
The problem is that on computers that don't have an installation of sql server, this tool is missing. So my question is whether or not is possible to run it as a standalone( along with any dll that may be required ) meaning that run them from Process.Start from a local directory of the application.
Yes, you can. Just copy the binary and off you go.
Why are you spawning osql?
I've written simple programs to execute scripts using SMO - mostly insired by this post.
EDIT
The jist of the post is to use SQL Server Management Objects (SMO). Server.ConnectionContext.ExecuteNonQuery parses SQL with GO statements in it.