Simplifying SQL Server Management

8/14/2019 Simplifying SQL Server Management

1/14


2/14

1

contents

This content was adapted from Internet.com'sDatabase Journal, DevX, and InternetNews.comWeb sites. Contributors: Gregory A. Larsen,Susan Sales Harkins, and Richard Adhikari.

Simplifying SQL Server Management, an Internet.com Storage eBook. 2008, Jupitermedia Corp.

2 Connection Strategy forMultiple Database

EnvironmentsGregory A. Larsen

5 Setting Up a Linked Serverfor a Remote SQL ServerInstanceGregory A. Larsen

10 Maintain Healthy TransactionLogs for Easy Data Recovery

Susan Sales Harkins

Simplifying SQL Server Management

[ ]

2

5 10


3/14

As machines get more powerful and less expensive,people are more likely to use a single machine tohost more than a single SQL Server database. Over

time, a SQL Server machine might support more and more

databases. But eventually you will need to replace yourhardware, your database server willfail due to a hardware problem, oryour multi-database machine mightbecome saturated with activity frommultiple applications, eventuallycausing performance of all applica-tions to suffer.

What are you to do when one ofthese situations occurs? How canyou minimize the work required

to re-point your applications to anew database machine, or splityour environment into multipledatabase machines for perform-ance reasons? Let's look at oneway to design your databaseconnection strategy to simplifychanging application connec-tions so you can plug-and-playdatabases with less administrative overhead when theneed arises.

How Applications ConnectEach application needs to identify the database serverit will be connecting with to retrieve data. Applications

do this by using a connection string. A typical connec-tion string might look something like:

Server=SSEDB01; Initial Catalog=AdventureWorks;

Integrated Security=SSPI;

In this example, the databaseserver is identified with amachine name, in this caseSSEDB01. Now a connectionstring doesn't have to have amachine name. It could be an IPaddress, an OBDC DSN name, aDNS alias name, etc. The name

just needs to be something thatcan be resolved to an IP address.

Name resolution can be done anumber of different ways.

If your SQL Server machine islocated within a domain, it canbe registered with the domaincreating a DNS name. When amachine is registered with DNSthen a client or application can

connect to it using the machines registered name,which is how the connection string above works. Evenbetter, with DNS you can create a DNS alias, which is a

logical name to represent your SQL Server machine. Byusing a DNS alias name in your connection string, DNStranslates the name to an IP address behind the scenes

2 Simplifying SQL Server Management, an Internet.com Storage eBook. 2008, Jupitermedia Corp.

Simplifying SQL Server Management[ ]

Connection Strategy for MultipleDatabase Environments

By Gregory A. Larsen

Let's look at one way to design your database connection strategy to simplify changing applicationconnections so you can plug-and-play databases with less administrative overhead when the need arises.

Jupiterimages


4/14

when a connection to the database server is made. Thisallows you to only need to remember a meaningfulname of where to connect, instead of a cryptic numeric

string of an IP address, or machine name. When youuse a DNS alias name in the connection string you cancreate a connection strategy that insulates applicationsfrom the physical location or machine name of thedatabase server.

Using DNS to Identify Location ofApplication DatabaseWhen using DNS to identify the location of the applica-tion database you can use the name of the domainmachine in the connection string, but this method is

somewhat inflexible. What happens when you want tochange the name of the physical SQL Server machine?If you use the machine name then you need to modifythe application connection strings to reference the newmachine name each time it changes. This might not beso bad when you only have a single application con-necting to a database server. But if you have a lot ofapplications and databases on a single machine thenthis means a lot of connection strings will need to bechanged anytime you rename your server. Thereforeusing the machine name in your connection string isnot flexible when there are environment changes overtime.

A better approach is to creatively use DNS alias namesto resolve where an application database lives. Soinstead of using the machine name to identify the loca-tion of the database machine for all applications, youshould consider creating a meaningful, unique DNSalias name that resolves to the IP address of your data-base server. In my example above instead of codingSSEDB01, which is a machine name, I would be betteroff using a DNS name like SQL2005PROD. In this case,the name SQL2005PROD would be defined in DNS tohave the same IP address as the physical machine

SSEDB01. Using a DNS alias puts some meaningbehind the name. Here by using SQL2005PROD youcan tell this name is associated with the productionSQL Server 2005 machine. So by defining this DNSalias for my production SQL Server 2005 machine myconnection string above would now look like this:

Server=SQL2005PROD; InitialCatalog=AdventureWorks; Integrated Security=SSPI;

This connection string and the one above will resolveto the same IP address.

So why would using a DNS name in the connectionstring be a good idea? One reason would be to have adescriptive name, but that's not the only reason. Sayyour database server contains many different databasesand supports 50 different applications. Now say SQLServer machine SSEDB01 has a hardware error of somekind. Moreover, you have a backup machine SSEDB02that you can quickly restore all the databases fromSSEDB01 to support those 50 different applications,because you have been shipping your SSEDB01 back-ups to this machine for safekeeping. Plus, you knowyou can restore all of the SSEDB01 databases on

SSEDB02 quicker than it would take to resolve thehardware problem with SSEDB01. If you coded all ofyour connections strings for those 50 applications tothe machine name SSEDB01 then you would have tomodify all of the connections strings to use SSEDB02 inorder to have them point to your new fallback server(SSEDB02) for your recovery to be complete.

Modifying 50+ connection strings might take a fairamount of time and be error prone. If instead you useda logical name like SQL2005PROD as a connectionname in each of those 50+ connection strings, thenyou would only need to make one change to re-pointall of your applications to the new fallback server,SSEDB02. That one change would be to DNS, tochange SQL2005PROD to point to the IP address ofSSEDB02, instead of SSEDB01. Once you make thischange, each application would automatically nolonger connect to SSEDB01, and would instead con-nect to SSEDB02, without changing any of those 50+connections strings. By making this small applicationchange to the connection design, to use a logical namefor a SQL Server machine, instead of a physical servername, or IP address, the amount of work required tore-point all applications and potential problems to

point applications at a new SQL Server box is greatlyreduced.

How to Use DNS to Help with Capacity ManagementSo how can using a DNS alias name in your connectionstring help with capacity management? Say your envi-ronment has a number of different production SQLServer machines. Each machine supports many applica-tions. Let's also assume that your database growth forsome applications is fairly linear, but a fair number of




5/14

application databases don't have a predictable growthrate. Those databases grow at an unpredictable rate,sometimes they don't grow at all, and other times they

increase or decrease in size exponentially. Because ofthis volatile growth rate for some databases there aresome servers that have very little space, other serversrun out of space frequently, while still others have toomuch free space. So how can DNS help out with man-aging these kinds of disk space capacity issues?

It is not always easy to add more disk space to a data-base server when the databases have ballooned up tothe capacity of the disks drives of a server. It might takemonths to acquire the additional hardware and sched-ule a timeframe to extend the disks space capacity of a

server. Therefore, if you have an environment with diskspace capacity issues you need a way to plug and playdatabases to manage this kind of capacity problem.

By "plug and play" I mean you need a method whereyou can copy databases from one server to anotherquickly and change that IP address of where applica-tions get their data with minimal effort. By using DNS,you can re-point your applications to the new locationfor databases quickly. Of course, you need to designyour application connection strategy to handle this kindof database movement scenario.

In the prior example of how to use DNS, I talked abouthaving a single DNS name that is logically associatedwith the physical SQL Server machine IP address. Usingthis strategy doesn't work if you only want to move asingle database from one server to another because ofa disk space capacity issue. So instead of having a sin-gle DNS name for all databases on a server, you needto develop a logical DNS naming strategy that has aunique name for each application.

Say you have a database server that contains the data-bases for the Order, Accounting, Personnel, and Billing

systems. For these four different applications, there arefour different databases: Order, REV, HR, and Billing. Inthis situation you would define four different DNSentries one for each of your production applications,where the DNS names would be something like,ORDER, REV, HR, and BILLING. All of the connectionstrings for each application would then use the appro-priate DNS entry from the above list to make sure theapplication was pointing to the current physical

machine where the database lived for the applications.When you need to move one of the databases off toanother server because of capacity issues all you would

need to do is move the database to the new server,and then change the DNS entry to point to the newdatabase server. One change to DNS and all the con-nections for that application are re-pointed to the newlocation.

You can use the logical DNS naming methodology tohandle other situations as well. Say you have a devel-opment, quality assurance and production environmentfor each application. In this case, you can append anenvironment designation to your DNS names. So, foryour BILLING application you might have BILLINGDV

for development, BILLINGQA for quality assurance,and BILLINGPR for production. Or, say you have highCPU on one of your databases servers, then by usingDNS you could quickly move one or more databasesoff the heavy hit server to underutilized servers andthen re-point the DNS entries for the moved databasesto new servers. Doing this provides you a low-techsolution to load balance CPU usage of your databaseservers.

Management by DesignEach environment has its own unique requirements. If

your environment has multiple applications with manydatabases on a single server, then designing your con-nection strategy to minimize issues that might come upover time makes sense. Next time you are bringing upa new machine and migrating your applications over toit, consider whether or not using logical DNS namesmight solve some issues associated with managingyour environment. I




6/14

Sometimes an application may need data stored inanother database on a different instance of SQL Server.That different instance might be on the same physical

machine or might be on another machine altogether. So

what do you do in this situation? Your options depend onyour data requirements, like how up to date does the dataneed to be. Also, the network/computer topology might bea factor in what you can and can-not do. To discuss all the differ-ent possible options would makethis article quite lengthy so let menarrow down the scope a littlebit. For the purpose of this arti-cle, I will be discussing how alinked server can be used toseamlessly provide an application

access to data on a differentinstance of SQL Server. Note thatlinked servers can also be usedto access other non-SQL Serverdata sources, but that notion willbe outside the scope of this article. I will only be discussingoptions and situations related to using linked servers toaccess information stored in a SQL Server database.

Basic Linked Sever ArchitectureBefore I get into how to setup a linked server, let mediscuss the basic architecture of a linked server. Alinked server is a mechanism that allows a query to besubmitted on one server and then have all or part of

the query redirected and processed on another SQLServer instance, and eventually have the results set sentback to the original server to be returned to the client.To better show how this works look at the following

diagram (figure 1):

In this diagram, a "Client" can connect to either an"Application Server" or direct-ly to SQL Server to submit aquery. If the "Client" or appli-cation running on the"Application Server" submits aquery to "SERVER1" thatneeds to retrieve data from adatabase housed on "SERV-ER2", then this kind of query

is known as a distributedquery. Defining a linked serverdefinition for "SERVER2" on"SERVER1" allows for a clientor an application to submit

these kinds of distributed queries. A distributed querythat runs against "SERVER2" from a linked serverdefined on "SERVER1" would look something like this:

SELECT name "DBs on SERVER2" FROM SERV-ER2.master.sys.databases

Here I identify the object I want to reference on mylinked server by using a four part naming convention.In my example, I wanted to return the names of all the



Setting Up a Linked Server for aRemote SQL Server Instance

By Gregory A. Larsen

Jupiterimages

Figure 1


7/14

databases on "SERVER2." Therefore, I used a four partnaming which consisted of ... , or in my case"SERVER2.master.sys.databases." "SERVER2" is thename of the linked server, which is defined on "SERV-ER1."

How to Define a Linked ServerTo create or list the available linked servers alreadydefined you look under the "Server Objects" folderwithin SQL Server Management Studio (SSMS). You canalso use "sp_addlinkedserver" system stored procedureto add a linked server, or "sp_helpserver" to list linkedservers.

To create linked "SERVER2" in my above example inSSMS, I would first expand the "Server Objects" folder,and then right click on the "Linked Servers" item. Thiswould display the following window (Figure 2):

On this window, you name your new linked server andidentify the type of data source your linked server willbe. Remember linked servers can be defined for anumber of different kinds of data sources. For the pur-pose of this article, I will be defining "SERVER2," whichis a SQL Server data source. In order to do that I willneed to identify the name of the linked server and thenuse the "Security" and "Server Options" pages todefine how I would like to authenticate to my linkedserver and what options will be associated with my

linked server. To begin defining my linked server I enter"SERVER2" in the "Name" field and then click on the"SQL Server" radio button to identify that my newlinked server is a SQL Server data source. When I dothat my window looks like this (Figure 3):

To define how clients would authenticate to "SERV-ER2" I would click on the "Security" item in the upperleft hand corner of this page, under the "Select apage" section. When I click on the "Security" item, thefollowing page is displayed (Figure 4):


Simplifying SQL Server Management[ ]Figure 2 Figure 3

Figure 4


8/14

Here you have a number of different ways to identifyhow your clients would be authenticated to the linkedserver. Let me go through each one of these options.

At the top of this screen, in the right hand pane youcan define login mappings. Login mapping is a way toassociate a login on the local server, with a login on theremote server.

There are two different ways a local login can bemapped to a remote login. The first method is toimpersonate, and the second is to associate the locallogin with a remote login and password. The imperson-ate option takes the local Windows login and uses it toconnect to the linked server. It does this by impersonat-ing the local login. In order for the local server to

impersonate, the login requires that delegation besetup between the local server and the linked server. Adiscussion on delegation is outside the scope of thisarticle. To map a local login you would associate it witha remote login and password. The remote login needsto be a SQL Server Authenticated user on the remoteserver. The following screenshot shows how I havemapped some local logins to remote logins on SERV-ER2 (Figure 5):

Here I have mapped three different local logins to twodifferent remote logins. The first login mapping is for"DJ\GREG", which is a Window domain authenticateduser that is defined on the local server. Ive identifiedthe mapping so "DJ\GREG" is to be impersonatedwhen connecting to "SERVER2." This means anytime

"DJ\GREG" is logged onto SERVER1 and issues alinked server query to "SERVER2" those request willconnect and run the query on "SERVER2" in the securi-

ty context of "DJ\GREG." The second mapping is for"WEB_USER" which is a SQL Server authenticated user.I've mapped "WEB_USER" to the same remote login.In doing so, I had to provide the password for login"WEB_USER." This password must be the password forthe "WEB_USER" on linked server, in my case thatwould be "SERVER2." The third login mapping demon-strates how you can map multiple local logins to a sin-gle remote login. In my example I mapped theWindows domain authenticated login "DJ\LINDA" tothe remote login "WEB_USER." Using mapped loginsis a way to identify only those users from the local

machine that can connect to the linked server.

In addition to mapping logins, you can also identifyhow logins that are not defined in the mappings wouldconnect to the linked server. There are four differentoptions that can be used. These four options are thedifferent radio buttons in Figure 5.

The first option "Not be made" is fairly obvious. Whenyou select this option, any users not identified in thelogin mappings will not be able to connect to thelinked server. The second method "Be made withoutusing a security context" is to be used for connectingto data sources that do not require any authentication,like a text file. If you select this option to connect to alinked server then this has the same effect as selectingthe "Not be made" option. The third option "Be madeusing Login's current security context" means you wantthe linked server request to use the Windows accountof the login to connect to the linked server. In order forthis option to work, your SQL Server machine will needto be able to impersonate a local account. This optionis a simple way to identify that all Windows accountscan use a linked server, without mapping each login.However, remember this requires delegation to be set

up. The last option "Be made with this security con-text" is a way to say everyone using this linked serverwill connect with a single remote login and password tothe linked server. The remote login needs to be a SQLServer Authenticated login.

When setting up a linked server the last thing to con-sider is defining the "Server Options." This can bedone by clicking on the "Server Options" under the"Select a page" menu. When I do that, the following



Figure 5


9/14


10/14

tion. Below are some examples of how to referencingobjects on SERVER2.

Here is how I would retrieve information in the"Product" table in the "AdventureWorks" databasesstored on my linked server:

SELECT * FROM SERV-ER2.AdventureWorks.Production.Product

All you have to do here is put the linked server namefollowed by a period before the fully qualified tablename.

If you wanted to execute a stored procedure on a linked

server, you would do something like the following:

EXECUTESERVER2.AdventureWorks.dbo.uspGetBillofMaterials718,'2000-06-26'

Here I have executed the uspGetBillofMaterials storedprocedure on SERVER2.

ConclusionLinked Servers allow you to submit a TSQL statementon one SQL Server instance, which retrieves data froma different SQL Server instances. In fact, linked servercan be used to join data from multiple SQL Serverinstances using a single TSQL statement. When youhave databases on multiple SQL Server instances, youmight find it useful to use linked servers in your appli-cation to retrieve data from more than one instance. Byusing a linked server your application will only need toconnect to one SQL Server instance to retrieve datafrom multiple SQL Server instances. On that single SQLServer instance, you would define linked servers soyour application could retrieve data from the databasesthat reside on a different SQL Server instance. Next

time you are considering how to handle retrieving datafrom multiple instances of SQL Server from a singleconnection or single TSQL statement you might consid-er looking into using a linked server. I




11/14

Data is your business, and maintaining a healthybackup and recovery plan is vital to protectingyour data. SQL Server's transaction logs, which

bridge the most recent changes to the last backup,should be a part of that backup and recovery plan.Without a healthy, well-maintained transaction log,you can recover old data butyour users will still have to re-enter all of their changes sincethe last backup. Fail to maintaintransaction logs and you mayfail to keep your job.Fortunately, SQL Server's trans-action logs are easy to main-tain.

How SQL ServerTransaction LogsWorkMost client/server databases offer a transaction log,which is simply a separate file where the server tracksoperations in the following sequence:

1. The log notes that the server expects a change.2. The log notes that the server made a change.3. The log notes that the server committed the

change to the data file.

When users change data, SQL Server doesn't write that

change directly to the data. Rather, SQL Server locatesthe appropriate data and then loads it into a specialarea of RAM called the data cache. Changes are made

in RAM. Then, SQL Server copies the changes waitingin RAM to the transaction log. Only then does SQLServer write changes to the actual data file. This is

called a write-ahead logbecause SQL Server writeschanges to the log before itwrites changes to the actualdata file. This approach is quitea bit faster than writing directlyto the data file.

Perhaps more important thanperformance is the transactionlog's role in data recovery.Thanks to the transaction log,you can recover changes rightup to the error from which

you're recovering. During the recovery process, SQLServer scans the log for changes that weren't commit-ted. That way, the database can finish what it started.

The log stores changes in three parts: Backed-up: This section contains changes thatwere committed the last time you backed up thedatabase.

Inactive: This section contains committed changes



Maintain Healthy Transaction Logsfor Easy Data Recovery

By Susan Sales Harkins

Jupiterimages

Thanks to the transaction log, you can recover changes right up to the error fromwhich you're recovering. During the recovery process, SQL Server scans the log forchanges that weren't committed. That way, the database can finish what it started.


12/14

that haven't been backed-up yet. Active: This section contains committed anduncommitted changes (depending on their

sequence and relation to other changes).

SQL Server identifies each event with a log sequencenumber (LSN) as follows:

101 Begin transaction 1

102 Update transaction 1

103 Begin transaction 2

104 Update transaction 2

105 Commit transaction 1

106 Checkpoint

107 Commit transaction 2

When SQL Server begins a backup, it records the cur-rent LSN. For instance, from the checkpoint at LSN106, SQL Server searches for the oldest open transac-tion. In this case, that's 103 because that transaction isuncommitted at the checkpoint. Therefore, transac-tions 103 and higher represent transactions thatoccurred during the actual backup process. When thebackup is complete, SQL Server backs up the transac-tions from 103 to the most current transaction.

Avoid a Full TransactionLog at All CostsAs great as full transaction logs are, they'll work foryou only if you maintain them properly. A full transac-tion log file grinds production to a halt. SQL Serverwill simply refuse to write changes, leaving your usersunable to work. You'll probably suffer this error onlyonce, because once is enough.

When it does happen, you must truncate the log byhand using BACKUP LOG as follows:

BACKUP LOG databasename WITHTRUNCATE_ONLY

Executing this statement forces SQL Server to dumpthe inactive area of the log, which gets your databaserunning and lets your users get back to work.However, truncating the log has a downside (you justknew there would be): you lose the history necessaryto restore the database if it crashes. To protect thedata, run a BACKUP DATABASE statement on the



Microsoft announced new Business

Intelligence technologies in October

designed to help knowledge workers use

business intelligence software with more smarts and

analytical tools.

It comes in a bundle that works with mainstay prod-

ucts such as SQL Server, Office applications Excel

and Word, and PerformancePoint Server 2007.

The BI tools are described in projects that include

"Kilimanjaro," a combination of two projects to add

business intelligence capabilities to Microsoft SQLServer 2008.

Self-service analysis capabilities are also in "Project

Gemini," which adds managed self-service analysis

and reporting capabilities, and a project code-named

"Madison" will add advanced data warehousing func-

tionality, Microsoft said.

"It's all about how to get more users empowered as

they try to make relevant and faster business deci-

sions day to day," Andy Kamlet, director of marketing

for Microsoft Business Intelligence product group,

told InternetNews.com. "We want to enable individ-

ual, team and corporate business intelligence, allaligned and with accountability and manageability."

"Kilimanjaro will let users develop reports using

Word and Excel as the front end to Report Builder,

which we first released in SQL Server 2005," Kamet

said. Kiliminjaro's BI capabilities are a continuation

of the capabilities announced last year for Katmai,

which hit the market as SQL Server 2008.

Microsoft is claiming that customers' total cost of

ownership of SQL Server-based BI solutions is lower

than the competition, of which there is plenty. After

all, the Business Intelligence software sector has

been a hot space for a few years now.

Microsoft's biggest rivals are Oracle, which spent

$3.3 billion on BI leader Hyperion Solutions in 2007.

It also faces SAP, which paid $6.7 billion to acquire

Business Objects last year, which was followed by

IBM's purchase of BI provider Cognos for $5 billion.

Mark Smith, CEO and executive vice president of

analyst firm Ventana Research, said Microsoft is still

lagging in the BI sector. In many ways, the company

continued

Microsoft Bundling

for BI


13/14

entire database immediately following the BACKUPLOG statement. Your users can continue to work, andalthough the unexpected backup might be a bit of a

pain, it's necessary.

The key is to avoid a quickly filling transaction logaltogether. Fortunately, you can easily do that byheeding the following administrative guidelines:

Avoid large transactions. A large transaction canbe adding or editing several million records withone INSERT or UPDATE.

Avoid long-running BEGIN TRANSACTIONblocks. Everything between BEGIN TRANSACTION

and COMMIT remains active.

Avoid using the KILL statement or canceling atransaction from Management Studio. Eitheraction will render a statement active--forever. (Anoccasional KILL is sometimes necessary and harm-less; just don't make a habit of it.)

Shrink the LogTruncating the log frees up space inside the log fornew transactions, but it doesn't reclaim disk space. Asa matter of habit, check the log's size. If it's truly

large, shrink it after truncating it as follows:

DBCC SHRINKFILE (databasename_log,

targetsize)

Targetsize represents, as an integer, the size that youwant the file to be in megabytes. If you omit thisvalue, SQL Server reduces it to the default file size. Inaddition, if the log is already larger than targetsize,SQL Server shrinks the file to the size needed to storethe current records.

Although this command will free up some space, it'llalso play havoc with file fragmentation at the disk level,so use it infrequently. Perform this action manually onlywhen necessary. Or, if you're specific about conditions,you can execute this statement via an alert script.

Back It UpSQL Server offers simple, full, and bulk-logged recov-ery models. For the most part, you should choose full,which allows you to back up both the database and

the transaction log. You can back up a transaction logquickly and frequently; every few minutes isn't toooften if data is critical.

If the worst happens, back up the current transactionlog first. Then, restore the last full database backup,and all subsequent transaction log backups. Forinstance, suppose you adhere to the following backup

schedule and a failure occurs at 9:00 PM:

8:00 AM Back up database

10:00 AM Back up transaction log

12:00 PM Back up database

2:00 PM Back up transaction log


6:00 PM Back up database



Simplifying SQL Server Management[ ]is playing catch-up to many of the technology offer-

ings out there already, he said.

Cognos and Hyperion are leveraging Web 2.0 tech-nologies, including mashups. Meanwhile, SAP has

been integrating business intelligence into all its

offerings.

Microsoft also has to grapple with the sales cycle,

Smith said. "The secret to success in software sales

to very large organizations is direct relationships,"

he explained, adding that Microsoft does most of its

business through its channels.

Also, Microsoft's BI capabilities will not be available

in the full market for some time yet, and that will fur-

ther hinder its sales, Smith pointed out.

The advanced data warehousing functionality ofMadison is slated for release in the first half of 2010,

but customers will get early access to it through

community technology previews, which lets cus-

tomers download and play with the software before

it's in production, Microsoft's Kamet said.

In the meantime, Microsoft has lined up a slew of

alliances to work with on BI implementations, includ-

ing appliances, such as Dell, EMC, Hewlett-Packard,

Unisys and Bull in Europe.

"Customers will get preconfigured deployments of

SQL Server out of the box so they can develop solu-

tions at once," Microsoft's Kamet said. "Customerswant to move along the lines of using appliances" as

part of their Business Intelligence strategy.


14/14

First, you'd back up the 8:00 PM transaction log. Then,you'd restore the database using the last databasebackup from 6:00 PM. Finally, you'd apply the 8:00 PM

transaction log backup and the active transaction log.(Differential backups are a bit more complex.)

After backing up a transaction log, SQL Server trun-cates the log's inactive section and reuses it to storenew transactions. That way, the log doesn't growuncontrollably large. Remember, SQL Server doesn'tuse the inactive items during recovery because thosetransactions are already complete.

If possible, don't store a database and its backup andtransaction logs on the same server. Store these files

on different physical disks, ideally located in differentbuildings.

Warning: Simple RecoveryMay Not Be EnoughSome experts suggest using the simple recoverymodel because SQL Server truncates the transaction

log at every checkpoint, which keeps the transactionlog at a manageable size. If you follow this advice,however, you'll be living on the wild side. In a crash,

you'll lose everything up to the last backup becausethe simple recovery model offers no transaction logwith which to restore from the last backup to thecrash. So be sure to back up the database frequentlyif you opt for simple recovery.

On the other hand, if you seldom change data, orchange only a few items frequently, simple can bemore efficient, but that's really the only good reasonto consider it. Otherwise, the full model is the way togo. I

This content was adapted from Internet.com'sDatabase Journal, DevX, and InternetNews.com Websites. Contributors: Gregory A. Larsen, Susan SalesHarkins, and Richard Adhikari.



Documents

Simplifying SQL Server Management