SQL Server Questions
SQL Server Questions
DATABASE
ADMINISTRATION
Sub by: Mukteshwar Parbhat
Sub to: Ms. Gennia Kakkar,
Roll No: RA3803A11,
Regd No: 10810056
HOMEWORK 3
0|Page
CAP464: Administration of Database
Homework3
Part A
Q1. Write a stored procedure to insert data into a table “CustomerInfo” with fields
CustomerId, Customername, CustomerAddress, CustEmail, CustMobile. Supply data values
as parameters to the stored procedure. While inserting data, check in the procedure that
CustomerId is greater than zero.
If we enter the value less then 0 or 0 in CustomerId than the procedure will work but the
data is not inserted into the table as shown below.
Command execution:
Output:
1|Page
Now, insert data with customer id greater than 0. The data will be inserted into the table.
Command execution:
Output:
Output:
Output:
Output:
Output:
4|Page
Q3. Write a stored procedure to create a job with 2 job steps. Create a schedule for this
job to execute this job every Wednesday and Friday at 9:00AM starting from 22-Apr-10.
EXECUTE msdb.dbo.sp_add_job
@job_name = 'MCAJOB',
@description = 'RECORD OF STUDENT PERFORMANCE IN EXAMS.',
@job_id = @jobId OUTPUT
select @jobId
EXECUTE msdb.dbo.sp_add_jobstep
@job_name = 'MCAJOB',
@step_name= 'STEP2',
@step_id=2,
@retry_attempts=1,
@retry_interval=1,
@subsystem = 'TSQL',
@command = 'SELECT * FROM MCAH WHERE TMARKS>400',
@database_name = 'hw3',
@output_file_name = 'D:\New folder\MCAHJOB'
Creating Schedule:
EXECUTE msdb.dbo.sp_add_jobschedule
@schedule_name = ‘Weekend Schedule’,
@job_name = 'MCAJOB',
@name = 'SCH1',
@freq_type = 8,
@freq_interval = 40,
@freq_subday_type = 1,
@freq_subday_interval = 0,
6|Page
@active_start_date = 20100422,
@active_start_time = 90000,
@schedule_id = @schedule_id OUTPUT
select @schedule_id
Part B
Q4. Write a stored procedure “SP_BACK_DB” to take full backup of a database with
transaction log.
7|Page
Full backup with Transaction Log.
Q5. Explicate the procedure to take different types of backup in SQL Server 2005. The
disk on your database server is crashed. Prepare a plan to restore the data.
Ans: We can take different types of backup in SQL Server 2005. These are explained below
one by one.
(i) Full Backup: In this we take full backup of our database. All transaction and updated
data is stored with records of all database location. Its advantage is that we have
full data for recovery in case of any kind of damage or data loss. But, its
disadvantage is, its size increases rapidly and it takes so much space to storage.
8|Page
(ii) Differential Backup: In this kind of backup, we take full backup of database at first
time and each time after that we take the backup only that much data which is
updated or only those transaction are taken under backup which are modified.
Its benefit is we need less space and time to store the data. Its disadvantage is
that it takes lots of time to recover the data.
9|Page
(iv) File/Filegroup with Differential: Also if we are taking regular backups, than
there are chances that we can not update the whole file on regular basis and only
a certain part of the file is update on consuctive days. Than, if we use full
File/Filegroup backup, it is totally space and storage wastage. Therefore, we can
use Differential mathod with File/ Filegroup.
Plan to restore the data: Following points to be consider while taking backup, which helps
us to recover the data.
The manner in which you perform database backups should not be a technical decision. It
should be dictated by the business. Small systems with low transaction rates and/or
reporting systems that are loaded regularly will only ever need a full database backup.
Medium sized systems and large systems become dependent on the type of data managed
to determine what types of backup are required.
For a medium sized system, a daily backup with log backups during the day would
probably answer most data requirements in a timely manner.
For a large database the best approach is to mix and match the backups to ensure
maximum recoverability in minimum time. For example, run a weekly full backup. Twice a
day during the week, run a differential backup. Every 10 minutes during the day, run a log
backup. This gives you a large number of recovery mechanisms.
For very large databases, you'll need to get into running filegroup and file backups because
doing a full backup or even a differential backup of the full database may not be possible. A
number of additional functions are available to help out in this area, but I won't be going
into them here.
You should take the time to develop some scripts for running your backups and restores. A
naming convention so you know what database, from which server, from which date, in
what specific backup and format will be very conducive to your sanity. A common location
for backups, log, full or incremental, should be defined. Everyone responsible should be
trained in both backup and recovery and troubleshooting the same. There are many ways
of doing this, but you can find a few suggestions in Pop backs up and Pop Restores.
10 | P a g e
The real test is to run your backup mechanisms and then run a restore. Then try a different
type of restore, and another, and another. Be sure that, not only have you done due
diligence in defining how to backup the system, but that you've done the extra step of
ensuring that you can recover those backups. If you haven't practiced this and documented
the practice and then tested the document, in effect, you're not ready for a disaster.
Q6. Give a real life case where an organization has suffered due to data loss.
Ans: (Mar 20, 2009) there was a meltdown at bookmark sharing website Ma.gnolia Friday
morning. The service lost both its primary store of user data, as well as its backup. The site
has been taken offline while the team tries to reconstruct its databases, though some users
may never see their stored bookmarks again.
The failure appears to be catastrophic. The company can’t say to what extent it will be able
to restore any of its users’ data. It also says the data failure was so extensive; repairing the
loss will take "days, not hours."
Ma.gnolia posted a short note on its website shortly after 9 a.m. Pacific time, saying it was
down temporarily due to a database failure. Later Friday morning, company founder Larry
Halff issued an apology on the homepage along with the following note:
Ma.gnolia experienced every web service’s worst nightmare: data corruption and loss. For
Ma.gnolia, this means that the service is offline and members’ bookmarks are unavailable,
both through the website itself and the API.
Ma.gnolia or your bookmarks will return; only that this process will take days, not hours.
Wired.com also contacted Halff shortly after the outage was first reported, but he declined
to give a comment beyond what he posted on the homepage. You can get status updates
from Ma.gnolia’s Twitter account.
Ma.gnolia is a free, public service for saving links to websites. Most users rely on it as a
bookmarking storage service, or a place to save links that they may want to revisit later.
Links can be saved privately or shared publicly, so that they can be browsed by other users
looking for new destinations. Many people prefer to use bookmark sharing services like
Ma.gnolia rather than saving bookmarks locally — the main advantage being that while
your browser’s bookmarks are stored on your machine, you can access bookmarks you
share on the web from any computer with an internet connection.
Ma.gnolia’s main competitor is Delicious.com, which is owned by Yahoo. Ma.gnolia is
preferred by many of the web’s tech elite for two reasons: The site has a robust and easy-
to-use API for accessing stored data, and it takes a snapshot when you create a bookmark,
so even if the linked site disappears, Ma.gnolia enables you to access a cached version.
Last year, Ma.gnolia mirrored its API with that of Delicious, so any web tools written for
Delicious could also be used for Ma.gnolia. The API also makes it easy to create a regular
local backup, though we suspect most people haven’t bothered to do that.
11 | P a g e