Performing General Administration Tasks in SQL Server 2000
This chapter is from the book
This chapter is from the book
This chapter is from the book
Besides checking server settings and backing up databases you'll be doing a lot of other tasks as a DBA. If being a DBA were too easy, you wouldn't want the job! How boring would that be?
As already mentioned, you must ensure that the server is running smoothly and that your databases are fast and efficient. The good news is that most of these tasks can be done for us automatically. After we have defined which tasks need to be completed and when, we can build scheduled jobs that will run when we specify them.
Let's take a look at setting up a scheduled job that performs a database backup for us during the night, so that we don't have to get up at 3 a.m. to do the backup. Like I would have made you do that? Maybe your new boss will, but I won't.
Scheduling Jobs
What is a scheduled job? Well this is like a reminder in Microsoft Outlook. We can schedule a task or job to fire at a designated time, for example we can set a database backup for 3 a.m. These jobs are simple to set up, and the configuration options for each job are very versatile.
NOTE
Like most things in SQL Server 2000, scheduled jobs can be created either through Enterprise Manager or through Transact-SQL. This time we are going to go for the GUI in Enterprise Manager, but if you would like to know how to set them up with Transact-SQL look up sp_add_jobschedule in Books Online.
Fire up Enterprise Manager and navigate your way through the folders until you find Management, and then open the SQL Server Agent folder. Inside this folder you will find three options.
Alerts—These allow us to configure what actions happen if a specific error occurs.
Operators—These are user accounts that allow us to email, Net send (on Windows NT/2000), or even send a page to someone's pager when something goes wrong.
Jobs—These are tasks that can have one or more steps performed. These steps are Transact-SQL statements that SQL Server can execute. Our jobs can occur one time or can be recurring events.
-
Select the Jobs folder, right-click, and click New Job from the menu shown in Figure 1.
-
This will bring up a screen similar to that shown in Figure 2.
Because we're creating a job to perform our SQLSpyNet database backup, give the job a name that describes the task and the database it is for, such as Database Backup for SQLSpyNet. This allows us to specify a descriptive name so that anyone else will be able to recognize what the job is for. The name can't be any longer than 128 characters, which is more than enough for us!
Next we need to enable the job. Make sure the Enable option is checked. The Target Local Server option allows us to have this job performed on our current instance of SQL Server 2000. If we had linked servers (if we were connected to a network) attached to our server, then we would be able to create our job to run on the other servers, even though it is only enabled on our server.
Next we can assign our job to a particular category so we can better organize our jobs. Let's assign our job to the Database Maintenance category.
Next we can assign an owner to the job. If the job is owned by another login, we need to ensure that the login has sufficient privilege to run the job. For example, we could assign this job to our SQLSpyNetUser, but they wouldn't be able to run the task because they do not have permission to perform database backups. Make sure the sa account is the owner.
Let's add a description to our job. This will allow us to understand the job, why it was created, and by whom. In the future we can review the job and assess whether we still need it. We have a limitation of 512 characters for the description field.
-
Next we need to tell SQL Server 2000 what task to actually perform. Click the Steps tab. This will give you a screen similar to Figure 3.
-
Click the New button. This will allow us to create our first (and only) step that we want SQL Server 2000 to perform for us when doing a database backup. This will give you a screen similar to that shown in Figure 4.
First we need to assign a name for our step, something like Step 1 Database Backup. This name cannot exceed 128 characters and must be unique.
Next we can choose the type of command that we want SQL Server 2000 to execute for us. Most of the time you will want to use the Transact-SQL option, but you do have the ability to get SQL Server 2000 to run operating system commands, such as batch files (these are files that have operating system commands within them) and so forth, as well as a multitude of other scripts. For our task, though, leave the option set to Transact-SQL.
Next we can specify the database against which we want to perform the task. Because we are performing a database backup it doesn't matter whether we have the Transact-SQL execute against the master database. Why? Well we specify the name of the database in the backup statement, so SQL Server 2000 knows which database we are backing up.
Finally, let's enter the command that we want SQL Server 2000 to perform.
In the Advanced tab we can specify what actions SQL Server 2000 takes when the job either succeeds or fails. The defaults for this screen suit our needs fine, so we will leave them as they are.
On success action—Go to the next step.
Retry attempts—0.
On failure action—Quit the job reporting failure.
Click OK. You will see our job appear in the Steps list box. If we had several steps in our process, we could reorder them so that some fired before others.
-
Next we need to specify when our task will run. Click the Schedules tab. Then click the New Schedule button. This will give you a screen similar to that shown in Figure 5.
Like our step names, our schedule names must be descriptive, no greater than 128 characters, and unique. Enter something similar to "3 a.m. Schedule for SQLSpyNet database backup." Make sure the Enabled option is checked.
Next we need to setup a schedule. Let's take a quick look first at the options that we do have.
Start automatically when SQL Server Agent starts—This will get the job to start when the SQL Server Agent starts. You can set the SQL Server Agent to start when the operating system starts by using the SQL Service Manager.
Start whenever the CPU becomes idle—We can specify the CPU idle time for our instance of SQL Server 2000. When the CPU is idle we can get our job to start.
One time—We can set our job to run once only, at a specified time.
Recurring—This is the option that we are going to select. It allows us to have our job repeated for a specified set of time or until some indefinite period.
Select the Recurring option, and click the Change button. You will see a screen similar to that shown in Figure 6.
Figure 6 Defining when we want our job to run in SQL Server 2000.
The screen is self-explanatory, especially if you have set up recurring items in Outlook before. We need to set the following options:
Occurs—Daily.
Daily—Every 1 day.
Daily Frequency—3:00:00 a.m.
Duration—Start date, set that to today's date. Do not specify an end date.
Click OK. This will take us back to the New Job Schedule screen. Once again click OK. You will now see our new schedule in the job screen.
){kind=link}
Figure 1 Selecting the New Job option to create a new job in SQL Server 2000.
){kind=link}
Figure 2 Setting the General properties of the new job.
Linked Servers are data sources that SQL Server 2000 can communicate with (for example, other SQL Servers, Excel, or Access). We can then perform queries on those servers to retrieve and manipulate data.
If we have a multitude of jobs, we can sort the jobs by category, so it is a good idea to assign our jobs to categories.
NOTE
If you click the ellipsis button..., you will see all the current jobs in this category.
The description I have entered appears in the Description box.
"To perform the database backup for the SQLSpyNet database. [ic:ccc] This was created so we didn't have to get up at 3am to [ic:ccc] perform a backup. Created by Rob Hawthorne 16 Aug 2000."
){kind=link}
Figure 3 Setting up the steps in our new job to perform our database backups.
){kind=link}
Figure 4 Telling SQL Server 2000 the actual commands we want our new job to perform.
1: BACKUP DATABASE SQLSpyNet 1a: TO DISK = 'C:\Program Files\Microsoft SQL Server\ [ic:ccc] MSSQL$MYSQLSERVER\BACKUP\SQLSpyNetJob.bak' 1b: WITH NOINIT, NOSKIP, STATS = 10
NOTE
The suffixes on the filenames are not compulsory. It is just something that I believe allows us to easily identify where the backup file came from. It is best to practice and all that, right?
The Open button shown in Figure 4 will allow us to select a saved Transact-SQL script to load. So maybe we should have saved our script from earlier, bugger! Another little Kiwi saying for you.
The Parse button will check that your syntax is correct. Click this now because it's better to be safe than sorry.
){kind=link}
Figure 5 Scheduling how often SQL Server 2000 will run the new job.
){kind=link}
Gee, that was easy, but what do we do if it fails? I'm glad to see you thinking ahead! We can never, ever guarantee that something will work, so it pays to know what to do when it goes wrong. Hence the reason for the Notifications tab. Click this tab. You will see a screen similar to that shown in Figure 7.
){kind=link}
Figure 7 Defining what happens if our job fails or succeeds.
The most common option for this screen is to write to the Windows NT Event log. Unfortunately, because we are using Windows 98 as our operating system, we do not have the ability to write to the NT Event log (because it doesn't exist). So what do we do?
This is where we introduce operators. With an operator, we can specify a specific recipient to SQL Server 2000 to which an email or page (using a third party's paging software) can be sent. But we will take a look at this shortly.
If you now click OK, our new job will be written away, ready to run in the morning at 3 a.m. There are two things you should note about this though:
Your computer must be on for this task to perform. Although it seems obvious, I have heard of people setting up jobs and having them never run because they shut off the system!
Check regularly that the task has run. In the Jobs folder you can see a list of jobs and the last time they ran, and whether they succeeded or failed. Next you should check where you specified that the file be saved to for the backup. This will allow you to check that the file has been successfully created.
Create a secondary database into which you restore the file occasionally just to check that it is actually backing up correctly.
And that, ladies and gentlemen, brings us to the end of yet another section of administration.