Does a view change things at the bit level?

[jymm]

sounds like a stupid question, but just want to be sure that my reality is not getting bent.

We went to mirroring our storage to our other facility - this copies the bit changes from one site to the other. My company has some 'other' non SQL things running on my SQL box but is blaming the DBs (which are NOT huge with updates) for so much data trying to be pushed across.

Many of our reports are using views of other already existing data tables on this or other servers. I maintain that the views are not rally making bit level changes (which would trigger the push) on the disks since in my simple mind it is just a view of the real data.

So - how wrong am I?

 

[mrdenny]

Querying views won't change anything within the data files.

Is your tempdb on disks which are being replicated to the remote site? If so that's probably the problem.

Denny
MVP
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / SQL 2005 BI / SQL 2008 DBA / SQL 2008 DBD / SQL 2008 BI / MWSS 3.0: Configuration / MOSS 2007: Configuration)
MCITP (SQL 2005 DBA / SQL 2008 DBA / SQL 2005 DBD / SQL 2008 DBD / SQL 2005 BI / SQL 2008 BI)

My Blog

 

[jymm]

yup - I they are doing the whole server the way it has been explained to me. So when I query a view is tempdb 'changed'??

thanks much Denny

 

[mrdenny]

It depends on the query behind the view. Some will use tempdb, others won't.

There's no point in replicating tempdb, as tempdb is deleted each time the SQL Server is restarted anyway. All you are doing is adding WAN traffic with 0 added benifit. Just make sure that the folders exist on the backup server and you are fine.

Denny
MVP
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / SQL 2005 BI / SQL 2008 DBA / SQL 2008 DBD / SQL 2008 BI / MWSS 3.0: Configuration / MOSS 2007: Configuration)
MCITP (SQL 2005 DBA / SQL 2008 DBA / SQL 2005 DBD / SQL 2008 DBD / SQL 2005 BI / SQL 2008 BI)

My Blog

 

[jymm]

thanks - this software / hardware config does not allow us to acutally choose what is being 'replicated' except for the machine... so once the machine is chosen to be kept in sync - any bits that are changed on the one are copied to the other storage array.. unfortunatly no way to not choose selected DBs or not choose selected folders.

I will keep with it though.

 

[mrdenny]

Wow, that's crappy design. Most packages let you choose which drives you want to replicate, for this specific reason.

Denny
MVP
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / SQL 2005 BI / SQL 2008 DBA / SQL 2008 DBD / SQL 2008 BI / MWSS 3.0: Configuration / MOSS 2007: Configuration)
MCITP (SQL 2005 DBA / SQL 2008 DBA / SQL 2005 DBD / SQL 2008 DBD / SQL 2005 BI / SQL 2008 BI)

My Blog

 

[jymm]

MrDenny=the voice in the back of my head - 'wow that is a $#(*&$##@! stupid design'

seems I said ALMOST exactly that a while back.

this is some 'solution' from HP that at x bytes (or x minutes) from all servers on the array it will copy those bytes across the channel to the identical array on the 'other' side of things. The idea is that in a disaster you are x bytes away (or x minutes away) from where you were when the disaster happened and VOILA everything is as it was... but even with two T1 lines running the pipe fills pretty quickly even with a small number of transactions.

I am still blaming MS CRM for most of the problems since the problem is also on Exchange side of things... (and that db is 'funky') but I need to prooooove it.

thanks for the ideas/un-bending of my reality

 

[mrdenny]

No problem.

Denny
MVP
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / SQL 2005 BI / SQL 2008 DBA / SQL 2008 DBD / SQL 2008 BI / MWSS 3.0: Configuration / MOSS 2007: Configuration)
MCITP (SQL 2005 DBA / SQL 2008 DBA / SQL 2005 DBD / SQL 2008 DBD / SQL 2005 BI / SQL 2008 BI)

My Blog