DataBase Administration Scheduling jobs Backing up and restoring Performing basic defragmentation and index rebuilding Using alerts Archiving

Scheduling Jobs Tasks - single processes to be executed or a batch of commands that are to be run. Jobs – groupings or one or more tasks that should be run together. –you can setup dependencies and branching depending on the success or failure of individual tasks. Example: task A runs if previous task succeeds but task B runs if previous task fails

Jobs Can be scheduled based on the following: –Daily, weekly, monthly basis –Specific time of day – Specific frequency (e.g., every 10 minutes or every hour) –When CPU becomes idle for a period of time –When SQL server agent starts –In response to an alert

Tasks Task is a logical unit of work Tasks run by virtue of being part of a job, based on branching rules you have defined. –Running a job does not mean all tasks in that job will run – depends on success/failure of previous tasks and branching rules you have defined.

Job Branching Provide notification of job success/failure to operator –Network message, pager, Write information to event log Automatically delete the job (to prevent executing it later )

Creating an Operator Management Studio –SQL server Agent node Operators member –New operator Agent may not start automatically (See new operator screen figure 19-1)

Creating Jobs & Tasks Task is logical unit of work –E.g., backing up one database –E.g., running a t-sql script to rebuild all your indexes Book says that “even among highly advanced SQL server developers, programmatic construction of jobs and tasks is very rare – pg 558)

Creating Jobs & Tasks Using Management Studio See book figure 19-3 through (attempt in class)

Backup and Recovery Book has two key points (pg 567): –No database-driven application should ever be deployed or sold to a customer without a mechanism for dealing with backup and recovery. –Backups are like voting in Chicago “Do it early and often”

Creating a Backup A.k.a “A DUMP” Object explorer of particular database Tasks -> Backup fig –Dialog box figure 19-15

Backup Types Full – full backup of actual database file as of end of last transaction that was committed prior to your issuing the backup command

Differential Backup “Backup since” backup Only writes a backup of extents that have chanced since you did last full backup Typically runs much faster than full Takes up less space –How much less? – depends on database

Backup Strategy Full backup only once a week or even only once a month Differential backups in between to save space and time Only need to restore from full backup and one differential – BUT Longer time from last full backup means more and more extents written in differential –Differentials take more and more time –Recovery takes more and more time

Transaction Log Backup Copy of transaction log Discussed more later

Backup Set (pg 569) SQL server allows for idea that for various reasons (e.g., very large database) you need to backup across multiple devices e.g., drives or tapes –If so, for recovery, you need all of these destinations available to recover from any of them – they are a “set” Backup set holds the definition of what destinations were involves in your particular backup –Also holds some property information )(e.g., exp date)

Destination This is where your data is going to be backed up to –(How to fix the grammar of this sentence?) Generally a file location on separate disk which is then moved to tape Can also define a backup device Note other miscellaneous options –Note transaction log area of dialog box

Backup Scheduling Note scheduling button to define a regular schedule

Recovery Models Full – everything is logged –No data loss in event of system failure assuming backup of data available and all transaction logs since that backup. –If missing or damaged log then can still recover up through last intact log Full can take up a lot of space

Recovery Models Bulk Logged – “full recovery light” –Regular transactions logged but bulk operations are not. –Restored backup will contain all non-bulk changes to data pages –Much faster –Can recreate database IFF can redo bulk operations –Your mileage may vary

Recovery Models Simple –Transaction log only supports transactions as they happen –Log of ZERO value for restore GENERALLY, you want to be setup for FULL RECOVERY

Recovery (also be used to make copy of Database) Right click on DB and fire up restore dialog box (fig 19-16) –Fairly straight forward if restore in same location

Restoring to different location Not enough to change database name Must also change which physical files are affected.

Recovery Status State you want Database to be into after restore –With recovery -> database immediately in full online status when restore operation is completed. –With no recovery -> delayed start to allow operations to be undertaken first

Index Maintenance Indexes can become fragmented –Cylinders and disks SQL server has commands that will reorganize data and indexes to clean things up –Use job scheduling to setup automatic routine defragmentation

Alter Index ALTER INDEX { | ALL} on {REBUILD { [ WITH ( [,..n])] | PARTITION = [with ( [,..n])]]] | disable | reorganize [partition= ] [with (LOB_compaction={on|off})] | set ( [,..n]} } [;]

Alter Index Details Index Name – either individual index or all on table Table/view name Rebuild – industrial strength approach –Old index destroyed and new one built – best rebuild result, but index is GONE during re build so queries on this are SLOW during rebuild

Alter Index Details Disable – drastic as marks index as unusable, not just temp disables –Must be rebuilt to be used again –Not used much as more likely to just drop it –CAREFUL – if disable clustered index then DISABLE TABLE!!

Alter Index Details Reorganize – very useful –Almost as good a resulting index as rebuild with far less downtime. –Only works on leaf level of index – non-leaf nodes not touched –Most of the time Close enough for government work/jazz/rock/funk –Usually the tool you want as part of your regular maintenance plan

Index Reorganization Alter index all on Production.TransactionHistory reorganize;

Archiving Data Think about archiving needs at time design database Considerations –How often is data really used? Is it worth keeping – legal reasons to keep or NOT KEEP! Legal requirements to keep can be done with backups or a copy –Don’t leave orphans (ref integrity) –May be slow – TEST TEST TEST!