Editorial

The average DBA has to perform many routine checks on his or her servers. There will be daily checks, weekly checks and, probably, monthly checks. A short while ago, we were having quite a debate about what items would be on the DBA Daily checklist. Because we all like lists with ten items in them, we compiled a list that goes something like this:

1. Connectivity: Make sure each database is available and accessible both by logging in via user applications, as well as running test scripts.
2. Backups: Check database and log backups, archiving and offsite storage.
3. Events: check all database logs, application logs and system logs, Agent history, device logs, NIC logs etc. Investigate any job failures
4. Processes: Check that all required processes on the server are running, including Replication
5. Integrity: Perform all database and server integrity checks; look for objects that break rules
6. Indexes: Check on indexes to see if they are being used, need re-creating, or if any are missing
7. Volumetrics: Check resources on the server such as files sizes and disk space, and monitor growth
8. Performance: Check application performance, and performance statistics, using the Perfmon tool; research and resolve any issues.
9. Procedures: Check all Disaster Recovery Plans
10. Security: Look for security policy violations

Selecting the database recovery model to ensure proper backups

Written By: Edgewood Solutions Engineers -- 5/13/2008 Join our mailing list! Problem
One of the first things that should be done when managing SQL Server is to setup an appropriate backup plan in order to minimize any data loss in the event of a failure. Along with setting up a backup plan there are certain database configurations that need to be setup to ensure you are able to backup databases correctly. In this tip we will look at the different recovery models that SQL Server offers and how to choose a recovery model for your database.

Solution
For SQL Server 2000 and 2005, Microsoft offers three different recovery models for your databases. Each database on your server can be setup differently and you also have the ability to change the recovery model as needed, so this choice is not permanent.

The three recovery models are:

Simple
The simple recovery model does what it implies, it gives you a simple backup that can be used to replace your entire database in the event of a failure or if you have the need to restore your database to another server. With this recovery model you have the ability to do complete backups (an entire copy) or differential backups (any changes since the last complete backup). With this recovery model you are exposed to any failures since the last backup completed. Here are some reasons why you may choose this recovery model:

• Your data is not critical and can easily be recreated
• The database is only used for test or development
• Data is static and does not change
• Losing any or all transactions since the last backup is not a problem
• Data is derived and can easily be recreated

Type of backups you can run:

• Complete backups
• Differential backups
• File and/or Filegroup backups
• Partial backups
• Copy-Only backups

Bulk_Logged
The bulk logged recovery sort of does what it implies. With this model there are certain bulk operations such as BULK INSERT, CREATE INDEX, SELECT INTO, etc... that are not fully logged in the transaction log and therefore do not take as much space in the transaction log. The advantage of using this recovery model is that your transaction logs will not get that large if you are doing bulk operations and you have the ability to do point in time recovery as long as your last transaction log backup does not include a bulk operation as mentioned above. If no bulk operations are run this recovery model works the same as the Full recovery model. One thing to note is that if you use this recovery model you also need to issue transaction log backups otherwise your database transaction log will continue to grow. Here are some reasons why you may choose this recovery model:

• Data is critical, but you do not want to log large bulk operations
• Bulk operations are done at different times versus normal processing.
• You still want to be able to recover to a point in time

Type of backups you can run:

• Complete backups
• Differential backups
• File and/or Filegroup backups
• Partial backups
• Copy-Only backups
• Transaction log backups

Full
The full recovery model is the most complete recovery model and allows you to recover all of your data to any point in time as long as all backup files are useable. With this model all operations are fully logged which means that you can recover your database to any point. In addition, if the database is set to the full recovery model you need to also issue transaction log backups otherwise your database transaction log will continue to grow forever. Here are some reasons why you may choose this recovery model:

• Data is critical and data can not be lost.
• You always need the ability to do a point-in-time recovery.
• You are using database mirroring

Type of backups you can run:

• Complete backups
• Differential backups
• File and/or Filegroup backups
• Partial backups
• Copy-Only backups
• Transaction log backups

---

Changing Recovery Models

The recovery model can be changed as needed, so if your database is in the Full recovery model and you want to issue some bulk operations that you want to minimally log you can change the recovery model to Bulk_Logged complete your operations and then change your database model again. The one thing to note is that since there will be a bulk operation in your transaction log backup that you can not do a point in time recovery using this transaction log backup file that contains this bulk operation, but any subsequent transaction log backup can be used to do a point in time recovery.

Also, if your database is in the Simple recovery model and you change to the Full recovery model you will want to issue a full backup immediately, so you can then begin to also do transaction log backups. Until you issue a full backup you will not be able to take transaction log backups.

To change the recovery model you can use either SQL Server Management Studio or T-SQL as follows:

Management Studio

• Right click on the database name, select Properties, select the Options tab and select recovery model from the drop-down list and select OK to save.

T-SQL

-- set to Full recovery ALTER DATABASE AdventureWorks SET RECOVERY FULL GO -- set to Bulk Logged recovery ALTER DATABASE AdventureWorks SET RECOVERY BULK_LOGGED GO -- set to Simple recovery ALTER DATABASE AdventureWorks SET RECOVERY SIMPLE GO

Next Steps

• Now that you know what recovery models exist, take the time to check your databases and setup the appropriate model and backup plan
• As mentioned you can change the model as needed, so use this to your advantage if you need to run some large bulk operations such as a bulk insert or a lot of index rebuilds

Forum Posts

Despite China’s Rapid Growth, India Is Still Outsourcing Leader

Posted by Ann All on May 12, 2008 at 8:45 am

IDC last summer came out with a prediction that China would overtake India as the globe’s favored site for outsourcing by 2011.

While there’s no doubt China’s outsourcing industry is experiencing rapid growth, it has much ground to cover to catch India. According to a Reuters story, China exported an estimated $1.8 billion in software and services in all of 2006, vs. India’s estimated $41 billion in such revenues in 2008’s first quarter.

Its limited exposure to the U.S. recession is currently working in China’s favor. U.S. companies account for three-quarters of India’s outsourcing business, leading Indian companies like Infosys and Wipro to expand their presence in other parts of the world as slowing economic conditions cause some U.S. clients to delay major IT projects.

China’s crowded outsourcing industry has yet to produce dominant giants like India’s Tata, Infosys and Wipro. One of the leaders, according to Reuters, is VanceInfo Technologies, with clients IBM and Microsoft accounting for 40 percent of its net revenue in 2006. It has logged an astonishing 80 percent annual revenue growth over the last three years.

Yet VanceInfo’s CFO, Sidney Huang, says it will take “years, if not decades” for Chinese companies to match their Indian competitors. Most Chinese companies do not yet have the scale or sophistication to snag contracts like the multi-million dollar deal to modernize the China Foreign Exchange Trade System’s trading system, won by India’s Tata last year.

Tata, Infosys, Wipro and Satyam Computer Services have all established operations in China over the last three years, according to Reuters. Among their challenges are intellectual property issues and difficulties recruiting local workers.

Multi-national companies like EDS are also making major stakes in China. As I wrote in November, EDS expects to increase its Chinese staff more than five times over by 2010, with a goal of employing 5,000 workers.