I want to schedule datebase backup in IBM DB2.
Is it possible?
I found some information about it from documentation: https://www.ibm.com/docs/en/db2/11.1?topic=commands-backup-database
I would like to schedule it to happen every 3 months and saved in a specific location.
Thanks for the answers and best regards.
There are multiple choices for that.
You may use your OS task scheduler (at, cron).
Db2 has its own task scheduler called Admin Task Scheduler (ATS).
You may use the ADMIN_TASK_ADD routine to schedule online backup like described in the Example 1 after setting up Db2 ATS.
You may set up Automatic database backup (both offline and online) as well.
Related
I have an SQL Azure Database instance which provide data to a windows 8 app. The data in my database should be updated periodically (weekly). Is the any way to make it? I'm thinking of write a app which will run weekly and update the database. But still don't know how to make it run on Window Azure? Please help!
Thank you,
There are a number of ways to achieve this, does the data however need to come from a different source or can it be calculated?
Either way, seeing as you're already knee deep in SQL Azure I would suggest putting your logic into a worker role that can be scheduled to run your updates once a week. This would give you a great opportunity to do calculations and/or fetch data externally.
Azure gives you the flexibility to scale this worker role into numerous instances as well depending on the work load.
Here is a nice intro tutorial on creating a worker role on Azure: link
Write the application and set it to run through your cron job manager on a weekly time schedule. The cron job manager should be provided by your host.
I actually search for a system to do a task every day at a precise time. This task is to delete some entries in the database.
I have a Web Role and a Sql Azure database.
I found some tutorial but nothing very effective and simple.
Can somebody help me ?
Thanks a lot.
Take a lok at this SO post Scheduled Tasks with Sql Azure?.
As of now there is no equivalent of SQL job in SQL server.
If you are open to using a service to do this scheduling of tasks, an alternate solution to purchasing your own worker role is to use Cotega which supports this functionality. For example, you can schedule it to launch stored procedure on regular intervals.
Full disclosure, I work on this service.
i was trying to prepare a primary database for standby database creation. while executing set_log_params.sql, we struck with an error "ORA-32017 failure in updating SPFILE" and "ORA-00439 feature not enabled: managed standby".
from the detailed error message, it has been seen that the error when setting "log_archive_dest_2" parameter.
we are using oracle 11g standard edition with RHEL 5
It will be appreciable if you could tell me if there will be an easy way to setup a backup database server.
thanks and regards
Jayalaxmi
I'm reasonably certain that the creation of standby databases is a feature of Enterprise Edition only.
RMAN has this capability, if you are using poor man's oracle like we are, you can take care of the log shipping and log apply with shell scripts and cron (unix) or batch files and scheduler (windows) we do it every 30 minutes....
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.
I have an archiving process that basically deletes archived records after a set number of days. Is it better to write a scheduled SQL job or a windows service to accomplish the deletion? The database is mssql2005.
Update:
To speak to some of the answers below, this question is regarding an in house application and not a distributed product.
It depends on what you want to accomplish.
Do you want to store the deleted archives somewhere? Log the changes? An SQL Job should perform better since it is run directly in the database, but it is easier to give a service acces to resources outside the database. So it depends on what you want to do,,,
I would think a scheduled SQL job would be a safer solution since if the database is migrated to a new machine, someone doing the migration might forget that there is a windows service involved and forget to start/install it on the new server.
In the past we've had a number of SQL Jobs run. Recently, however, we've been moving to calling those processes from .Net code as a client application run from a windows schedule task, for two reasons:
It's easier to implement features like logging this way.
We have other batch jobs that don't run in the database, and therefore must be in windows scheduled tasks. This way all the batch jobs of any type will be listed in one place.
Please note that regardless of how you do it, for this task you do not want a service. Services run all day, and will consume a bit of the server's ram all day.
In this, you have a task you need to run, and run once a day, every day. As such, you'd either want a job in SQL Server or as Joel described an application (console or winforms) that was setup on a schedule to execute and then unload from the server's memory space.
Is this for you/in house, or is this part of a product that you distribute.
If in house, I'd say the SQL job. That's just another service too.
If it's part of a product that you distribute, I would consider how the installation and support will be.
To follow on Corey's point, if this is externally distributed, will you need to support SQL Express? If not, I'd go with the SQL job directly. Otherwise, you'll have to get more creative as SQL Express does not have the SQL Agent that comes with the full versions of SQL 2005 (as well as MSDE). Without the SQL Agent, you'll need another way to automatically fire the job. It could be a windows service, a scheduled task (calling a .NET app, powershell script, VBscript, etc.), or you could try to implement some trigger in SQL Server directly.