LOVELY PROFESSIONAL UNIVERSITY HOME WORK:#1 CAP613T: DATABASE ADMINISTRATION School: CAP Section:D1803 Max.

Marks: 20

PART-A Q1. We can monitor our scheduled jobs' conversations currently being processed and their success by running queries. Justify the statement thereby giving queries. Ans: Tables
We need two tables: - ScheduledJobs stores information about our scheduled jobs - ScheduledJobsErrors stores possible errors when manipulating scheduled jobs CREATE TABLE ScheduledJobs ( ID INT IDENTITY(1,1), ScheduledSql nvarchar(max) NOT NULL, FirstRunOn datetime NOT NULL, LastRunOn datetime, LastRunOK BIT NOT NULL DEFAULT (0), IsRepeatable BIT NOT NULL DEFAULT (0), IsEnabled BIT NOT NULL DEFAULT (0), ConversationHandle uniqueidentifier NULL

) CREATE TABLE ScheduledJobsErrors ( Id BIGINT IDENTITY(1, 1) PRIMARY KEY, ErrorLine INT, ErrorNumber INT, ErrorMessage NVARCHAR(MAX), ErrorSeverity INT, ErrorState INT, ScheduledJobId INT, ErrorDate DATETIME NOT NULL DEFAULT GETUTCDATE() )

ScheduledJobs Table This holds information about our scheduled jobs such as job name, enabled status, etc... CREATE TABLE ScheduledJobs ( ID INT IDENTITY(1,1), JobScheduleId INT NOT NULL, ConversationHandle UNIQUEIDENTIFIER NULL, JobName NVARCHAR(256) NOT NULL DEFAULT (''), ValidFrom DATETIME NOT NULL, LastRunOn DATETIME, NextRunOn DATETIME, IsEnabled BIT NOT NULL DEFAULT (0), CreatedOn DATETIME NOT NULL DEFAULT GETUTCDATE() ) ScheduledJobSteps Table This holds the job step name, the SQL statement to run in the step, whether to retry the step on failure and how many times, step duration, etc...

CREATE TABLE ScheduledJobSteps ( ID INT IDENTITY(1,1), ScheduledJobId INT NOT NULL, StepName NVARCHAR(256) NOT NULL DEFAULT (''), SqlToRun NVARCHAR(MAX) NOT NULL, -- sql statement to run RetryOnFail BIT NOT NULL DEFAULT (0), -- do we wish to retry the job step on failure RetryOnFailTimes INT NOT NULL DEFAULT (0), -- if we do how many times do we wish to retry it DurationInSeconds DECIMAL(14,4) DEFAULT (0), -- duration of the step with all retries CreatedOn DATETIME NOT NULL DEFAULT GETUTCDATE(), LastExecutedOn DATETIME )

Q2 It is important to choose the right strategy for backing up Analysis Services databases.Which one you would like to choose as your database back up strategy and why? Ans: Backing up a database enables administrators to save a particular state of a
Microsoft Analysis Services database and its objects. Restoring enables administrators to restore an Analysis Services database to a previous state. The reasons for doing backups include data recovery and preparation for audits. If you do not already have a backup plan and your data is valuable, you should design and implement a plan as soon as possible. For a full backup that includes source data, you must back up the database which contains detail data. In general, Analysis Services backups only contain metadata and a subset of the source data and/or aggregations, not the complete underlying detail data. However, if all objects are MOLAP, the backup will contain both metadata and source data. One clear benefit of automating backups is that the data snapshot will always be as up-to-date as the frequency of backup specified. Automated schedulers ensure that backups are not forgotten. Restoring a database can also be automated, and can be a good way to replicate data, but be sure to back up the encryption key file on the instance you replicate to. The synchronization feature is dedicated to

replication of Analysis Services databases, but only for the data that is out of date. All of the features mentioned here can be implemented through the user interface, by way of XML/A commands or programmatically through AMO. For more information about backup strategies. In SQL Server Analysis Services, administrators can back up an Analysis Services database to a single operating system file, regardless of size of the database. If the Analysis Services database contains remote partitions, the remote partitions can also be backed up. When you back up a database with remote partitions, all the remote partitions on each remote server are backed up to a single file on each of the remote servers. Therefore, if you want to create those remote backups off their respective host computers, you will have to manually copy those files to the designated storage areas. Backing up an Analysis Services database produces a backup file whose contents vary depending upon the storage mode used by the database objects. This difference in backup content results from the fact that each storage mode stores a different set of information within an Analysis Services database. For example, hybrid OLAP (HOLAP) partitions and dimensions store aggregations and metadata in the Analysis Services database, while relational OLAP (ROLAP) partitions and dimensions only store metadata in the Analysis Services database. Because the content of an Analysis Services database varies depending on the storage mode of each partition, the contents of the backup file also vary. The following table associates the contents of the backup file to the storage mode used by the objects.

Q3 Differentiate between Differential backups, Transaction-log backups, File-group backups. Ans: Differential Backup

A differential backup provides a backup of files that have changed since a full backup was performed. A differential backup typically saves only the files that are different or new since the last full backup, but this can vary in different backup programs. Together, a full backup and a differential backup include all the files on your computer, changed and unchanged. Example: Monday - Perform a full backup and save the file set. Tuesday - Perform a differential backup using the same file set. All files that have changed since the full backup are backed up in the differential backup. Wednesday - Perform a differential backup using the same file set. All the files that have changed since Monday's full backup are backed up. Advantages: Differential backups require even less disk, tape, or network drive space than incremental backups. Backup time is faster than full or incremental backups. Disadvantages: Restoring all your files may take considerably longer since you may have to restore both the last differential and full backup. Restoring an individual file may take longer since you have to locate the file on either the differential or full backup.

Transaction-log backups
The transaction log is a serial record of all the transactions that have been performed against the database since the transaction log was last backed up. With transaction log backups, you can recover the database to a specific point in time (for example, prior to entering unwanted data), or to the point of failure. When restoring a transaction log backup, Microsoft SQL Server rolls forward all changes recorded in the transaction log. When SQL Server reaches the end of the transaction log, it has re-created the exact state of the database at the time

the backup operation started. If the database is recovered, SQL Server then rolls back all transactions that were incomplete when the backup operation started. Transaction log backups generally use fewer resources than database backups. As a result, you can create them more frequently than database backups. Frequent backups decrease your risk of losing data.

Using Transaction Log Backups with Database Backups

Restoring a database using both database and transaction log backups works only if you have an unbroken sequence of transaction log backups after the last database or differential database backup. If a log backup is missing or damaged, you must create a database or differential database backup and start backing up the transaction logs again. Retain the previous transaction logs backups if you want to restore the database to a point in time within those backups. The only time database or differential database backups must be synchronized with transaction log backups is when starting a sequence of transaction log backups. Every sequence of transaction log backups must be started by a database or differential database backup. Usually, the only time that a new sequence of backups is started is when the database is backed up for the first time or a change in recovery model from Simple to Full or Bulk-Logged has occurred.

File-group backups
In addition to doing "File" backups you can also do "Filegroup" backups which allows you to backup all files that are in a particular filegroup. By default each database has a PRIMARY filegroup which is tied to the one data file that is created. You have an option of creating additional filegroups and then placing new data files in any of the filegroups. In most cases you will probably only have the PRIMARY filegroup, so this is topic is not relevant. As mentioned above you can back up each filegroup individually. The one advantage of using filegroup backups over file backups is that you can create a Read-Only filegroup which means the data will not change. So instead of backing up the entire database all of the time you can just backup the Read-Write filegroups.

A filegroup backup can be completed either using T-SQL or by using SSMS. Create a filegroup backup of the TestBackup database For this example I created a new database called TestBackup that has three data files and one log file. Two data files are the PRIMARY filegroup and one file is in the ReadOnly filegroup. The code below shows how to do a filegroup backup. T-SQL BACKUP DATABASE TestBackup FILEGROUP = 'ReadOnly' TO DISK = 'C:\TestBackup_ReadOnly.FLG' GO

PART-B Q4 :-What is SQL Server Agent Service. How it helps in automating various administrative task. Explain its various properties. Ans: SQL Server Agent is a Microsoft Windows service that executes scheduled
administrative tasks, which are called jobs in SQL Server 2012. SQL Server Agent uses SQL Server to store job information. Jobs contain one or more job steps. Each step contains its own task, for example, backing up a database. SQL Server Agent can run a job on a schedule, in response to a specific event, or on demand. For example, if you want to back up all the company servers every weekday after hours, you can automate this task. Schedule the backup to run after 22:00 Monday through Friday; if the backup encounters a problem, SQL Server Agent can record the event and notify you.

SQL Server Agent uses the following components to define the tasks to be performed, when to perform the tasks, and how to report the success or failure of the tasks. Jobs A job is a specified series of actions that SQL Server Agent performs. Use jobs to define an administrative task that can be run one or more times and monitored for success or failure. A job can run on one local server or on multiple remote servers. Schedules A schedule specifies when a job runs. More than one job can run on the same schedule, and more than one schedule can apply to the same job. Alerts An alert is an automatic response to a specific event. For example, an event can be a job that starts or system resources that reach a specific threshold. You define the conditions under which an alert occurs. Operators An operator defines contact information for an individual responsible for the maintenance of one or more instances of SQL Server. In some enterprises, operator responsibilities are assigned to one individual. In enterprises with multiple servers, many individuals can share operator responsibilities. An operator does not contain security information, and does not define a security principal.

Q5. To stop the Alert from being sent every two minutes, you have two options disable the alert or provide a more appropriate size and response times. Elaborate all the steps involved in both these approaches.

Ans: To disable or reactivate an alert

1. In Object Explorer, click the plus sign to expand server that contains the alert you wish to disable or reactivate. 2. Click the plus sign to expand SQL Server Agent. 3. Click the plus sign to expand the Alerts folder. 4. Right-click the alert you wish to enable and select Enable To disable an alert, right-click the alert you want to disable and select Disable. 5. The Disable Alert or Enable Alert dialog box displays showing the status of the process. When finished, click Close.

To disable or reactivate an alert 1. In Object Explorer, connect to an instance of Database Engine. 2. On the Standard bar, click New Query. 3. Copy and paste the following example into the query window and click Execute. -- changes the enabled setting of Test Alert to 0 USE msdb ; GO EXEC dbo.sp_update_alert @name = N'Test Alert', @enabled = 0 ;

GO

Q6 .Why do we make use of database snapshots. Is there any limitation of using database snapshot. Ans: Database snapshots operate at the data-page level. Before a page of the
source database is modified for the first time, the original page is copied from the source database to the snapshot. The snapshot stores the original page, preserving the data records as they existed when the snapshot was created. The same process is repeated for every page that is being modified for the first time. To the user, a database snapshot appears never to change, because read operations on

a database snapshot always access the original data pages, regardless of where they reside. To store the copied original pages, the snapshot uses one or more sparse files. Initially, a sparse file is an essentially empty file that contains no user data and has not yet been allocated disk space for user data. As more and more pages are updated in the source database, the size of the file grows. The following figure illustrates the effects of two contrasting update patterns on the size of a snapshot. Update pattern A reflects an environment in which only 30 percent of the original pages are updated during the life of the snapshot. Update pattern B reflects an environment in which 80 percent of the original pages are updated during the life of the snapshot.

Snapshots can be used for reporting purposes. Clients can query a database snapshot, which makes it useful for writing reports based on the data at the time of snapshot creation.

 Maintaining historical data for report generation. A snapshot can extend user access to data from a particular point in time. For example, you can create a database snapshot at the end of a given time period (such as a financial quarter) for later reporting. You can then run end-of-period reports on the snapshot. If disk space permits, you can also maintain end-of-period snapshots indefinitely, allowing queries against the results from these periods; for example, to investigate organizational performance. Using a mirror database that you are maintaining for availability purposes to offload reporting. Using database snapshots with database mirroring permits you to make the data on the mirror server accessible for reporting. Additionally, running queries on the mirror database can free up resources on the principal. For more information, see Database Mirroring and Database Snapshots (SQL Server). Safeguarding data against administrative error. In the event of a user error on a source database, you can revert the source database to the state it was in when a given database snapshot was created. Data loss is confined to updates to the database since the snapshot's creation. For example, before doing major updates, such as a bulk update or a schema change, create a database snapshot on the database protects data. If you make a mistake, you can use the snapshot to recover by reverting the database to the snapshot. Reverting is potentially much faster for this purpose than restoring from a backup; however, you cannot roll forward afterward.