SQL Server Magazine UPDATE, November 21, 2002

More Than a Little Help from My Friends

COMDEX: Microsoft Delivers Final Visual Studio .NET 2003 Beta

Microsoft Provides Upgrade and Debugging Information

Results of Previous Instant Poll: What's Your Job?

New Instant Poll: Moving to 64-Bit SQL Server

Did You Miss SQL Server Magazine's Web Seminars?

Join The SQL Server Magazine Research Panel

What's New in SQL Server Magazine: The 64-Bit Era

Hot Thread: RAID 0 Is Slower Than RAID 1

Tip: Creating Individual Log Reader and Distribution Agents

Limit Database Exposure to Attacks and Worms

Back Up and Recover Your Database

See this section for a list of ways to contact us.

MORE THAN A LITTLE HELP FROM MY FRIENDS

(contributed by Brian Moran, news editor, [email protected])

Online peer support communities such as the Microsoft newsgroups and SQL Server Magazine forums are invaluable resources. Like many of you, I contribute to and learn from these communities every day. Peer support is a great option and can meet your support needs much of the time, especially when your problem isn't a down mission-critical server.

But peer support isn't always the best option. You can't expect your peers online to solve all your problems, especially in emergency situations that require an immediate response. You also shouldn't rely on peer support to solve your problems when a misstep might cause irretrievable loss of your data. Nevertheless, I see a surprising number of messages posted to the SQL Server newsgroups that look like this:

Subject: Help!!!!Message: I've done a terrible thing to my production database, and I'm not sure how to fix the problem. The database is completely inaccessible, and I'm afraid that the data may be lost. My boss is furious. Please respond ASAP with a fix for my problem.

Of course, I've exaggerated the situation a bit to demonstrate my point. But such messages often come from SQL Server newcomers — the folks least likely to be able to solve the problem on their own.

Although peer support can provide great information, the answers you get don't always appear right away. After all, the people on the other end are simply volunteering their time — they have jobs and other responsibilities just like you do. Sometimes, you get what you pay for. Personally, I wouldn't rely on a newsgroup posting if crucial corporate data was at risk, time was of the essence, or my job might depend on solving the problem. Instead, I might use one of Microsoft's paid product-support options. Some people who are new to SQL Server might not know that these mechanisms exist, and often these newcomers are most in need of a fee-based helping hand when their data is at risk. Sometimes, paying a small fee can save the day — and your database.

I can't possibly cover the myriad ways to get paid support from Microsoft. The company provides different kinds of support depending on your licensing agreement and other relationships you might have with our friends in Redmond. Microsoft has posted a list of support options at http://support.microsoft.com/default.aspx?scid=fh;EN-US;offerprophone&sd=msdn. And you can always buy a single, per-incident phone call for $245 by using one of the following numbers:

Developers 800-936-5800

IT Professionals 800-936-4900

Partners (resellers/consultants)888-456-5570

Microsoft Certified Partners 888-677-9444

Original Equipment Manufacturers 800-936-2197

System Builders 888-456-5570

If you're outside the United States or prefer not to phone, you can submit your request online for $99 by using the Web site above.

Is your SQL Server recovery problem a genuine emergency? Is your data worth $245? Free peer support can be a great resource — but sometimes it makes sense to shell out a few bucks.

HAPPY 10TH ANNIVERSARY SQL SERVER!

Microsoft and SQL Server Magazine want to thank you for your support over the past 10 years of SQL Server on the Windows platform. To show our appreciation, we're running a 20-week contest that will test your SQL Server knowledge. Answer our quiz and you'll be entered in a biweekly drawing for cool prizes like Microsoft Press books and MCDBA exam vouchers. You'll also be entered to win the grand prize: a Microsoft Xbox video game console including two controllers and three Xbox games! Get all the details and enter the contest athttp://www.sqlmag.com/quiz

2. SQL SERVER NEWS AND VIEWS

Q. We have transactional replication set up on our production database. Two publications point to the same database and share one Log Reader Agent. The two pull subscriptions also share one Distribution Agent, whose schedule is set to "continuously." We want to create a third publication that points to the same database. This publication contains articles that change less frequently, so we want to update them only once a day. However, this publication will use the shared Log Reader Agent and the Distribution Agent that's scheduled continuously. How can we create individual Log Reader and Distribution agents for each publication that point to the same database?

A. You can't create an individual Log Reader Agent because SQL Server allows only one Log Reader Agent per transactionally replicated database. SQL Server can't clear the log until all published changes have been pulled out and put into the distribution database, so running the Log Reader Agent continuously is a good idea to prevent excessive log growth. However, SQL Server does permit one Distribution Agent per publication. You can create a separate Distribution Agent for your third publication after you create the publication. To create the Distribution Agent, right-click the publication, then select Properties. Go to the Subscription Options tab and select the "Use a distribution agent that is independent of other publications from this database" option.

When you create a subscription through Enterprise Manager, both the pull and push options let you set a specific replication schedule, so you can implement your own less-frequent schedule specifically for the third subscription. Note that many installations need to retain a record of changes against production systems. This requirement can be hard to meet when you run a GUI tool such as Enterprise Manager directly against the production database, so if you want to retain the scripts for change-control purposes, simulate the action in a nonproduction environment. Then, you can use SQL Server Profiler to capture the SQL code that Enterprise Manager uses and modify the code to match the needs of your production environment.

Send your technical questions to [email protected].

5. NEW AND IMPROVED

(contributed by Carolyn Mader, [email protected])