I have a small database for a school project and I need to create a Database Maintenance Plan with the following requirements:
it has to manually (through scripting and not user interface)
it must reorganize data and indexes
it must validate database integrity
it must be run automatically everyday at 19:00
well, I have absolutely no idea on how to do this
Can someone help me out, please?
I found some commands to create backups and reorganize indexes but I can't find a way to run them periodically.
Thanks
Chiapa
If you want to create a maintenance plan, see the follwing page:
Use the Maintenance Plan Wizard
Otherwise, you can just create a SQL agent job with various steps in it that run the T-SQL commands that you want, such as backup database and DBCC commands and create a schedule for it.
If you cannot use the maintenance plan wizard, you can use commands similar to those detailed in the following page to create the jobs:
Create a Maintenance Plan
If you can't create agent jobs (for reasons such as you are using a version of SQL server that doesn't support them (SQL Express etc) then you can use OSQL commands that are fired by Windows task scheduler to achieve much the same thing, see the folowing link for a very good description:
How to Automate Maintenace Tasks with SQL Server Express
If you have the commands available and you're on an edition of SQL Server that has a SQL Agent, create an agent job and use that to do the scheduling.
Related
I need to collect data from a SQL Server table, format it, and then put it into a different table.
I have access to SQL Server but cannot setup triggers or scheduled jobs.
I can create tables, stored procedures, views and functions.
What can I setup that will automatically collect the data and insert it into a SQL Server table for me?
I would probably create a stored procedure to do this task.
In the stored procedure you can create a CTE or use temp tables (depending on the task) and do all the data manipulation you require and once done, you can use the SELECT INTO statement to move all the data from the temp table into the SQL Server table you need.
https://www.w3schools.com/sql/sql_select_into.asp
You can then schedule this stored procedure to run at a time desired by you
A database is just a storage container. It doesn't "do" things automatically all by itself. Even if you did have the access to create triggers, something would have to happen to the table to cause the trigger to fire, typically a CRUD operation on the parent table. And something external needs to happen to initiate that CRUD operation.
When you start talking about automating a process, you're talking about the function of a scheduler program. SQL Server has one built in, the SQL Agent, and depending on your needs you may find that it's appropriate to enlist help from whoever in your organization does have access to it. I've worked in a couple of organizations, though, that only used the SQL Agent to schedule maintenance jobs, while data manipulation jobs were scheduled through an outside resource. The most common one I've run across is Control-M, but there are other players in that market. I even ran across one homemade scheduler protocol that was just built in C#.NET that worked great.
Based on the limitations you lay out in your question, and the comments you've made in response to others, it sounds to me like you need to do socialize your challenge within your organization to find out what their routine mechanism is for setting up data transfers. It's unlikely that this is the first time it's come up, unless the company was founded in the last week or two. It will probably require that you set up your code, probably a stored procedure or maybe an SSIS package, and then work with someone else, perhaps a DBA or a Site Operations team or some such, to get that process automated to fire when you need it to, whether through an Agent job or maybe a file listener.
Well you have two major options, SP and SSIS.
Both of them can be scheduled to run at a given time with a simple Job from the SQL Server Agent. Keep in mind that if you are doing this on a separate server you might need to add the source server as a Linked Server so you can access it from the script.
I've done this approach in the past and it has worked great. Note, for security reasons, I am not able to access the remote server's task scheduler, so I go through the SQL Server Agent:
Run a SQL Server Agent on a schedule of your choice
Use the SQL Server Agent to call an SSIS Package
The SSIS Package then calls an executable which can pull the data you want from your original table, evaluate it, and then insert a formatted version of it, one record at a time. Alternatively, you can simply create a C# script within the SSIS package via a Script Task.
I hope this helps. Please let me know if you need more details.
I am trying to migrate a database from a sql server into Azure. This database have 2 rather simple TSQL script that inserts data. Since the SQL Agent does not exist on Azure, I am trying to find an alternative.
I see the Automation thing, but it seems really complex for something as simple as running SQL scripts. Is there any better or at least easier way to do this ?
I was under the impression that there was a scheduller for that for I can't find it.
Thanks
There are several ways to run a scheduled Task/job on the azure sql database for your use case -
If you are comfortable using the existing on-premise sql sever agent you can connect to your azure sql db(using linked servers) and execute jobs the same way we used to on on-premise sql server.
Use Automation Account/Runbooks to create sql jobs. If you see marketplace you can find several examples on azure sql db(backup,restore,indexing jobs..). I guess you already tried it and does not seem a feasible solution to you.
Another not very famous way could be to use the webjobs(under app service web app) to schedule tasks(can use powershell scripts here). The disadvantage of this is you cannot change anything once you create a webjob
As #jayendran suggested Azure functions is definitely an option to achieve this use case.
If some how out of these if you do not have options to work with the sql directly , there is also "Scheduler Job Collection" available in azure to schedule invocation of HTTP endpoints, and the sql operation could be abstracted/implemented in that endpoint. This would be only useful for less heavy sql operations else if the operation takes longer chances are it might time out.
You can use Azure Functions to Run the T-SQL Queries for Schedule use Timely Trigger.
You can use Microsoft Flow (https://flow.microsoft.com) in order to create a programmed flow with an SQL Server connector. Then in the connector you set the SQL Azure server, database name, username and password.
SQL Server connector
There are many options but the ones that you can use to run a T-SQL query daily are these:
SQL Connector options
Execute a SQL Query
Execute stored procedure
You can also edit your connection info in Data --> Connections menu.
I am using SQL Server 11.0.6251 Express (SQL Server 2012 Express). I have some software that logs data to the database continuously. However, there are some maintenance tasks that are performed on the database every so often. Whenever this happens, there are some data points that don't get logged.
I want to reschedule and configure these maintenance tasks so that I can recreate the problem and troubleshoot the software so that I don't lose any more data points.
I am aware that an easy way to do this is to just upgrade SQL Server so that I have the maintenance plan wizard and SQL Server agent. I just want to see if any of you SQL gurus out there know a way around this problem!
I've also looked into how scripts and using the Windows Task Scheduler can help create maintenance plans, but I'm not sure how to use that to edit existing maintenance tasks.
Is there any way to edit and re-schedule current Maintenance Tasks for SQL Server Express?
Is it possible to have a stored procedure or set of SQL code run periodically by specifying a time-based trigger in SQL Server?
Not directly, but look at SQL Jobs.
A job is a specified series of operations performed sequentially by SQL Server Agent. A job can perform a wide range of activities, including running Transact-SQL scripts, command-line applications, Microsoft ActiveX scripts, Integration Services packages, Analysis Services commands and queries, or Replication tasks. Jobs can run repetitive tasks or those that can be scheduled, and they can automatically notify users of job status by generating alerts, thereby greatly simplifying SQL Server administration.
(emphasis mine)
You can use a SQL Agent job. IF you have a requirement to run on Express editions, that lack SQL Agent, you can use dialog timers and activation.
You can use a SQL job to run any SQL on a schedule. If you are needing to do something a little more dynamic you can control the jobs (creation, scheduling, removing etc) from SQL itself. This provides an immense amount of flexibility.
Some more info on controlling jobs with TSQL here.
My company at present has the following Setup:
127 SQL servers (2000 and 2005) and over 700 databases. We are in the process of server consolidation and are planning on having a Master server / Target servers setup to enable centralized administration. As part of this project, I have been given the responsiblity of creating a script based automated backup / maintenance solution.
Thanks to Ola Hallengren's script available here I have made a lot of progress.
Here is what I plan:
I have a database in the master server which has details of SQL instances, databases and backup path details.
I am in the process of modifying Hallengren's script to read from this database and create jobs dynamically.
Users are allowed to define what kind of backup they want, how often and how long the backup needs to be kept.
I am also looking at having the ability to spread out jobs, so that I do not have too many jobs running at the same time.
My thoughts are to create tables that have the data needed to be passed as parameters to sp_add_job, sp_add_jobstep and sp_add_jobschedule.
Please share your experiences in the pitfalls and hurdles with this setup. All ideas welcome.
Thanks,
Raj
You might also consider the approach of creating a full backup job and a transaction log backup job on each server, which retrieve the databases from the master database and feeds them into a procedure for backup. You could run the jobs every 5 minutes and the procedure would have to work out what time it is and what type of backup is required.
I say this, because things could get messy creating massive amounts of jobs in an automated manner - but maybe you have it worked out well. Be sure to create a 'primary key' with the job name if you take your original approach.
Spreading out jobs should be easy if you keep record in the database and find available windows to put new jobs in. I've seen scripts for this.
You could also do this in a SSIS package that runs from your admin server. It would iterate over the databases and connect to servers to perform the backups.
Check out the first 3 article here: http://www.sqlmag.com/Authors/AuthorID/1089/1089.html
Moving to 2005 we were not happy with the Intergration Services Maintenance Plans
We wrote sp's to do Full and Tran Backups as well as reindex, arrgegate management, archiving etc
A Daily and Hourly Job would step thru master..sysdatabases and in a try catch block
apply the necessary maintenance. Would not be hard to read from any table and check user defined conditions.
Unfortunatedly there was no way to tie output to msdb..sysjobhistry, so we logged to central table. The upside was we had a lot more control over what was logged.
However would be simpler to read than going thru 700 jobs.