• Skip to main content
  • Skip to primary sidebar

DallasDBAs.com

SQL Server Database Consulting

  • Services
  • Pocket DBAยฎ
  • Blog
  • Testimonials
  • Contact
  • About

Kevin3NF

SQL 101 – Replication vs. Log Shipping vs. Clustering

January 11, 2008 by Kevin3NF Leave a Comment

SQL 101 – Replication vs. Log Shipping vs. Clustering

Continuing the “Englishification” of SQL Server for those new to the product…

These three terms are the most incorrectly used terms in all of SQL Server, not just by CEOs and pointy haired managers but by some very sharp developers and more than a few experienced DBAs. If you don’t know them, pull up a virtual chair for a 3 minute primer.

Clustering – its all about high availability and uptime

In its most basic form, a Windows/SQL “Cluster” is two or more servers (nodes) attached to a shared storage – a SAN. Only ONE of the nodes is running the SQL Server instance at any given time. So…you can have a 4 node cluster with one SQL Server instance, and it will NOT be running 4 times faster. If the node you are running on suffers a meltdown, the Cluster service moves it to another node. Key Point: This is NOT a fully redundant solution!!! If the SAN dies, your data is gone. Period. Go find your backups.

Log Shipping – move that data!

Log Shipping’s sole purpose is disaster recovery. There is a secondary benefit that you can use the destination server as a reporting server if you set it up in a specific configuration.

LS is nothing more than a glorified backup/copy/restore process with a GUI and jobs:
Backup the data on Server A.
Copy the backup files to Server B
Restore the files on Server B.

You cannot edit the data on Server B…just read it.

Replication (no, I won’t discuss the different types here):

Replication is all about distributed processing. This means having the data in two different places (Walla Walla, WA and Kissimmee, FL for example) so users don’t have to depend on the server and WAN in the remote city. Or for sales/field personnel entering data from their cars.

Replication can be a partial DR solution, but understand that not everything gets replicated (security changes), and only new data gets sent automatically. Schema changes, new tables, etc. do not.

Summary:

  • Clustering – High availability is its only purpose.
  • Log Shipping – Disaster recovery/possible reporting server
  • Replication – Distributed data processing with some DR benefit.
  • NONE of these are gonig to increase performance!!!!

Yes, you can combine some of these. Set up two clusters in different cities and Log Ship between them. Now you have HA and DR. Expensive, but effective.

For all the SQL Experts that are chomping at the bit ready to scream that I left out what LUN is, or didn’t discuss Geoclustering, please see the post title…this is a 101 level post ๐Ÿ™‚

Thanks,

Kevin3NF

Filed Under: Uncategorized

SQL 101 โ€“ Recovery models in simple terms

January 10, 2008 by Kevin3NF Leave a Comment

A recovery model is simply a choice made on each database that determines how much data you can recover if your db goes “toes up”.

If you do not backup your database, you have chosen recovery model “terminated” or “update resume”

The 3 that are offered by Microsoft are:

  • Bulk-logged (rarely seen, and generally more advanced, so I’m skipping it)
  • Simple
  • Full

Simple vs. Full is very simply a matter of how much data can you afford to lose if the database is lost and you are forced to restore from your backups.

Simple recovery model: does not allow backing up the transaction logs, therefore you cannot restore any of the data in them. You can only restore to the point of the Full backup and any one Differential you may have.

Full recovery model: You can restore from t-log backups (assuming you have them), right up to a specific point in time. Reduced data loss, assuming the backup files are valid.

When to use:

Simple: When you do not care about the data, such as in a Development or Test environment where you can regenerate from another source. Also useful in a static, read-only database (assuming you have a full backup).

Full: Pretty much any live production database that has Inserts, Updates and Deletes happening.

Switching from one to the other:

Simple to Full: Immediately take a Full or Differential backup

Full to Simple: No specific action required, other than verifying regular data backups are in place and working.

Maintenance plan considerations:

If you have both Simple and Full recovery model databases in your SQL instance, and you create a Maintenance Plan to back up data and logs, you may run into an issue (at least in SQL 2000) where the automated deletion of old t-log backups is failing. Make two plans: one for Full and one for Simple. I have no idea if this issue still presents in SQL 2005.

I hope this is clear…please feel free to comment.

Kevin3NF

Filed Under: Accidental DBA, backup, Beginner, EntryLevel, SQL

SQL 101 – Understanding Transaction logs

January 9, 2008 by Kevin3NF Leave a Comment

SQL 101 – Understanding Transaction logs

I posted this in the microsoft.public.sqlserver.server newsgroup (response to questions about log file space):

If you build a bookshelf (physical .ldf file) and fill it up with books (transactions), its full.
If you loan 5 books to a friend (backup the t-log), there is space available on the shelf, but the shelf size didn’t change, correct?

If you buy another book (DML transaction), it goes where one of the others was.
If you fill up your bookshelf and then buy 3 more books, your only choices (besides stacking) are to expand the size of the shelf (grow the physical .ldf file) or add a 2nd one (MyDB_Log2.ldf) to the wall. Or return the books (failed transaction).

Chopping off the end of the bookshelf (Shrinking the .ldf file) makes no sense, nor does making a shelf that can hold 1000 books, when you’ll never have more than 100 there….wasted wall space (disk).

Hope that helps.

Kevin3NF

Filed Under: Uncategorized

Fun with the overnight crew…

December 10, 2007 by Kevin3NF Leave a Comment

Dateline: Sunday morning, 2:30am (my week on call)…

Ring!!!!!
Kevin3NF: {snort} thisiskevin
Caller: Hey man…sorry to wake you but we have some t-log backups failing for Acme Widgets
Kevin3NF: whatstheerrormessagein the job (waking up a bit, not out of bed)
Caller: I can’t find the job in the SQL Agent job list
Kevin3NF: WhatIsTheExactAlertFromNetIQ? (slightly clearer now)
Caller: SQL Task failed: ‘Backup Job 17’ failed
Kevin3NF: The job list is alphabetical…did you sort by name?
Caller: Yeah…but theres like 2000 jobs…most have numbers and letters and stuff
Kevin3NF: Those are reporting services jobs…just ignore them and look for the Backup job
Caller: I’m looking for Job 17, but its not in the ‘J’s
Kevin3NF: Did you look under ‘B’, since the job’s name starts with ‘Backup…’ ?
Caller: silence
Caller: I’m an idiot
Kevin3NF: Goodnight.
Caller: Click
Kevin3NF: snore.

Still makes me laugh…I went back to sleep knowing I would post this little 2 minute interaction ๐Ÿ™‚

Kevin3NF

Filed Under: Uncategorized

Why we maintain databases

November 20, 2007 by Kevin3NF Leave a Comment

Why we maintain databases…

I was blissfully unaware of this issue until I came in this morning and saw the debris…

The players: Freakshow and Tiny (my co-workers), the Customer, and the application Vendor.

Customer: Everything is slow and my cluster keeps failing over! Must be SQL Server!
Freakshow: We didn’t change anything on your servers sir…
Customer: You must have!
Freakshow: Could be bad indexes or stats…
Customer’s Vendor: Oracle doesn’t have this issue
Freakshow: Grrrr….
Tiny: Double Grrrrrr…..
Freakshow: You have 49 million rows, and are table scanning/locking…
Customer: We have 3 years of data
Vendor: You should have 90 days, and you are 3 years behind on versions of the application…
Freakshow: Let me update the stats….
Customer: Hey…its working!!!
Vendor: You know that ‘purge’ utility we provide?….it comes with fries ๐Ÿ™‚
Freakshow: I’m going back to bed
Tiny: I’m going home (6 hours past end of the shift…)

Moral: Purge your data, keep your versions up, and maintain your indexes folks…

Filed Under: Uncategorized

Do What?

October 25, 2007 by Kevin3NF Leave a Comment

Do what?

So….I’ve got this job that backs up the T-log every 15 minutes (SQL 2005). Works like a champ across all servers.

Out of the blue, it starts failing with a “No full backup detected”, despite the fact that one occurred less than an hour ago. Its recorded in the msdb system tables and the file is right where the full backup job left it.

The customer had decided for reasons unknown to create a job that does this (every hour):

Use MyDB
DBCC SHRINKFILE(MyDB_Log, EMPTYFILE)
BACKUP LOG MyDB WITH TRUNCATE_ONLY
DBCC SHRINKFILE(MyDB_Log, EMPTYFILE)

go

I kid you not. And no…there is not a second file to EMPTY the log contents into.

For those of you new to the game, when you Truncate a T-log, the sequence is broken and SQL Server barfs on future log backups until you run a full.

Kudos to my co-worker (code name Freakshow) for catching this as I was headed to the ERRORLOG to see what was going on. He nailed in 10 seconds what would have taken me 7 minutes. And then he knew it was a new job while I was still reading the log. Scary smart, that dude.

No fries, but ketchup squirted all over that client.

Kevin3NF

Filed Under: backup, Fries

  • « Go to Previous Page
  • Go to page 1
  • Interim pages omitted …
  • Go to page 40
  • Go to page 41
  • Go to page 42
  • Go to page 43
  • Go to page 44
  • Go to Next Page »

Primary Sidebar

Search

Sign up for blogs, DBA availability and more!

Home Blog About Privacy Policy
  • Home-draft
  • Blog
  • About Us

Copyright © 2026 ยท WordPress ยท Log in