Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Differential Backups Internals Expand / Collapse
Author
Message
Posted Monday, December 10, 2007 11:27 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, April 27, 2012 2:56 PM
Points: 124, Visits: 73
Comments posted to this topic are about the item Differential Backups Internals

ken kaufman
Lead DBA, Zillow.com
Post #431638
Posted Tuesday, December 11, 2007 8:14 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Tuesday, November 25, 2014 1:39 PM
Points: 775, Visits: 1,202
I wish I read this before doing the QotD, which implied I got it wrong

SQLServerNewbie

MCITP: Database Administrator SQL Server 2005
Post #431816
Posted Tuesday, December 11, 2007 8:19 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 22, 2008 2:03 PM
Points: 180, Visits: 35
althought the knowlege is good to have, but asking this question in interview will make them think you are crazy, I would not like to work for you if you ask me that.


Post #431820
Posted Tuesday, December 11, 2007 10:54 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:05 PM
Points: 31,284, Visits: 15,750
Actually it's an interesting question for an interview. If you have a lot of simple mode databases, then differentials could conceivably save you lots of resources on backups.

It's not crazy, and I'm not sure I'd penalize you in an interview, but I'd be curious to see how you thought through the logic if you didn't know the answer.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #431936
Posted Tuesday, December 11, 2007 12:21 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, November 25, 2014 3:20 PM
Points: 2,665, Visits: 837
I got it right because this is exactly what I am doing hourly for one of our databases, in lieu of transaction log backups (DB is 3GB in size, generates 3GB per hour of transaction log traffic. Backend for an off-the-shelf product and the vendor/creator is of little use).

What I have noticed and cannot explain, is the varying size of the differential backups. Theoretically, the differential backup only backs up extents changed since the last full backup. That would imply the differential backup file will only get bigger and bigger. However, I am noticing a more up down pattern: 18, 10, 10, 10, 18, 10, 10, 20, 10, 10, 26, 70, 72, 77, 92, 84, 85, 89, 93 and so on. Generally up (especially once people get in & use the system) but not consistently so.

Of no concern whatsoever, just curious to know why it should be. Possibly by an extent being updated more than once but a subsequent update having less data in it?




Scott Duncan

MARCUS. Why dost thou laugh? It fits not with this hour.
TITUS. Why, I have not another tear to shed;
--Titus Andronicus, William Shakespeare
Post #431982
Posted Tuesday, December 11, 2007 6:24 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, April 27, 2012 2:56 PM
Points: 124, Visits: 73
As for the first part on being able to do a tran backup in simple mode, this is a pretty entry level question, in fact it was one of the first basics covered when I taught the MCDBA classes. As for the follow up, it’s intended to separate out levels of expertise. When I’m deciding on a candidate, I need to be able to distinguish whether they are entry/mid/SR level. Answering this is one of ten questions that qualify as SR level. Obviously I don’t expect everyone to get them all right, but if they can land over 50% there in the SR category. At Zillow we’re very strong on understanding internals of the applications you work with. My theory is if you’re paying your mortgage with SQL you should know how it works under the hood, and specifically look for people with the same attitude. :)

Ken Kaufman
Lead DBA, Zillow.com


ken kaufman
Lead DBA, Zillow.com
Post #432104
Posted Wednesday, December 12, 2007 7:58 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 22, 2008 2:03 PM
Points: 180, Visits: 35
all right, guys, doesn't mean to offending, apologize if I did. actually I love the post here and benefit a lot, as a DBA that dealing with sql, oracle and sybase, the posts keep me up to speed with sql...

I agree with you that some apps require DBA to baby-sitting it, I've been there and are still supporting on one oracle app which we spent 70 million dollars and still cannot see the light. we have to answer questions like what the server was running in from 12pm to 12:05pm, and what was the db lock at that moment, etc. etc.

I hate the app so much because it was not well designed and caused a lot DBA time, it is paying my mortgate. ;) but I would rather spend my time doing other stuff because being able to answer those questions does not help the vendor to improve the app, we are still receiving letter patch everyday.

I am telling you my story to say why i was mentioning the "crazy" and "don't want to work for you".

have a nice day, guys.



Post #432319
Posted Wednesday, December 12, 2007 8:24 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 6:47 AM
Points: 1,570, Visits: 684
Good information, thanks.

I agree with Ken, when interviewing candidates, its important to gauge their level of knowledge of the product and you can't do that without asking in-depth questions.



Post #432337
Posted Tuesday, December 18, 2007 6:50 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, November 22, 2011 8:44 AM
Points: 395, Visits: 275
I ran across this article through a Google search. I am already familiar with DCM, and I thought this would be the perfect tool to use to determine the rate of change (ROC) in bytes/day for my production databases. You might ask why I'm doing this. We have a new NetApp SAN, and it has the ability to perform SQL Server snapshots for amazingly fast short-term backup and recovery. In order to implement this, however, I need to size the volumes appropriately and not waste a lot of space. The formula I have been provided is this:

Space for Snapshot copies = ROC in bytes per day * number of Snapshot copies

Does anybody have any ideas as to how I might calculate ROC?

Thanks,
Aaron
Post #434250
Posted Monday, April 11, 2011 10:36 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, September 6, 2013 11:40 AM
Points: 16, Visits: 51
Will this manual replication plan work?
1. To be more specific, at Date1, we want to detach US DB, copy and attach to PacRim.
2. On Date1, also turn on differential backup transaction log on PacRim DB
3. Set Identity Odd# + 2x increments for PacRim Db
4. Set Identity Event# + 2x increments for US Db
5. After pilot user testing on PacRim Db went well, we then want to repeat this.
Few weeks after Date1, detach the existing PacRim DB.
6. Then detach US DB (Date1+few weeks new data), copy and attach to PacRim.
7. Then Restore the PacRim DB transaction log from Date1 onto the 2nd time Attached PacRim DB which is the US DB (Date1+few weeks new data).

The utimate goal is PacRim DB =
(US DB + US few weeks new data) + PacRim few weeks new data

Will task#7 Restore produce expected result for PacRim DB having both odd and even # Identity?

For illustration, User inserts 2 records with transaction log turned on.
“TableX from PacRim” (Identity ID seeded (1, 1 + 2x) => Odd # ID
ID, Name
1, A
3, C

“TableX from US” (Identity ID seeded (0, 0 + 2x) => Even# ID.
ID, Name
2, B
4, D

What will be the result after applying transaction log (insert A & C)
from “TableX from PacRim”
to “TableX from US”?

Expected Result
“TableX from US”?
ID, Name
2, B
4, D
1, A
3, C

Or

UnExpected Result
“TableX from US”?
ID, Name
2, B
4, D
6, A
8, C


Many Thanks,
Jeffrey
Post #1091578
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse