I considered the idea, but have decided to produce a few
articles on the main changes that I'm interested in
instead - merge over the internet and peer-to-peer
transactional. Hilary's the man for books, and he'll be
able to update you about his plans.
BTW to be honest as MVPs we don't have much of an
advantage over anyone else in this regard - we still have
to do the research, trial and error, digging through
system stored procedures etc, although some changes we
hear about a little earlier. I know Kalen was able to
interview PMs for the various groups but that was
exceptional and we don't really have such access. If this
is something you're interested in - ie close contact with
the developers - then now is the time we can all do it.
Have a good look at the Beta2 and try to figure the
replication features out, then post your questions in the
Beta2 newsgroups
(http://communities.microsoft.com/new...s/default.asp?
icp=sqlserver2005&slcid=us). I have used these and the
Yukon ones, and the questions are answered by the actual
TSQL code developers - the people we don't usually see on
the public newsgroups, so this is pretty valuable stuff.
Regards,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Paul is right. Please post your comments about SQL server 2005 betas. We
will be delighted to have your feedback.
thanks - Deepak
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:1f5e01c4f7c1$8cafb250$a401280a@.phx.gbl...
> I considered the idea, but have decided to produce a few
> articles on the main changes that I'm interested in
> instead - merge over the internet and peer-to-peer
> transactional. Hilary's the man for books, and he'll be
> able to update you about his plans.
> BTW to be honest as MVPs we don't have much of an
> advantage over anyone else in this regard - we still have
> to do the research, trial and error, digging through
> system stored procedures etc, although some changes we
> hear about a little earlier. I know Kalen was able to
> interview PMs for the various groups but that was
> exceptional and we don't really have such access. If this
> is something you're interested in - ie close contact with
> the developers - then now is the time we can all do it.
> Have a good look at the Beta2 and try to figure the
> replication features out, then post your questions in the
> Beta2 newsgroups
> (http://communities.microsoft.com/new...s/default.asp?
> icp=sqlserver2005&slcid=us). I have used these and the
> Yukon ones, and the questions are answered by the actual
> TSQL code developers - the people we don't usually see on
> the public newsgroups, so this is pretty valuable stuff.
> Regards,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
Showing posts with label paul. Show all posts
Showing posts with label paul. Show all posts
Monday, March 26, 2012
Hilary and Paul : SQL 2005 Book and Materials
Hilary and Paul
Thank you both for all your help. This board would be
sorely lacking without the two of you.
Hilary: Heres the deal. Your custom sync object was
working, mine wasn't.
@.sync_method = N'character'
That was the whole problem. I know you asked me to try
this a while back and I did, but I have no idea what else
I was doing back then that would have affected this
outcome. You're example on the 08/11 didnt specify (not
blaming you by any means) and by then I had forgot you're
mentioning it.
Paul: from you're reply @. 1:59 am. Do you ever sleep?
>
I personally would prefer to use indexed views.
I suppose simplistically the downside is that there is
increased overhead on
the publisher to maintain the materialized data.
I see the huge benifit being not needing to write the
ins,upd, and del procs with the Indexed View option. What
increased overhead are you refering too? Does the whole
Arithabort thing ever become a real pain?
Thanks again both of you.
ChrisR
ChrisR,
for an indexed view you've got 2 types of overhead:
a.. The disk space taken up by the view
a.. The cost of maintaining the view on disk as the base tables are
modified - this is conceptually like a set of invisible triggers.
BTW I'm not really such an SQL insomniac :-) I guess the post times are
Western US timezone times: UK - 7 hours.
Regards,
Paul Ibison
|||Ahhh. I forgot you were in the UK. Thanks.
>--Original Message--
>ChrisR,
>for an indexed view you've got 2 types of overhead:
>a.. The disk space taken up by the view
>a.. The cost of maintaining the view on disk as the base
tables are
>modified - this is conceptually like a set of invisible
triggers.
>BTW I'm not really such an SQL insomniac :-) I guess the
post times are
>Western US timezone times: UK - 7 hours.
>Regards,
>Paul Ibison
>
>.
>
sorely lacking without the two of you.
Hilary: Heres the deal. Your custom sync object was
working, mine wasn't.
@.sync_method = N'character'
That was the whole problem. I know you asked me to try
this a while back and I did, but I have no idea what else
I was doing back then that would have affected this
outcome. You're example on the 08/11 didnt specify (not
blaming you by any means) and by then I had forgot you're
mentioning it.
Paul: from you're reply @. 1:59 am. Do you ever sleep?
>
I personally would prefer to use indexed views.
I suppose simplistically the downside is that there is
increased overhead on
the publisher to maintain the materialized data.
I see the huge benifit being not needing to write the
ins,upd, and del procs with the Indexed View option. What
increased overhead are you refering too? Does the whole
Arithabort thing ever become a real pain?
Thanks again both of you.
ChrisR
ChrisR,
for an indexed view you've got 2 types of overhead:
a.. The disk space taken up by the view
a.. The cost of maintaining the view on disk as the base tables are
modified - this is conceptually like a set of invisible triggers.
BTW I'm not really such an SQL insomniac :-) I guess the post times are
Western US timezone times: UK - 7 hours.
Regards,
Paul Ibison
|||Ahhh. I forgot you were in the UK. Thanks.
>--Original Message--
>ChrisR,
>for an indexed view you've got 2 types of overhead:
>a.. The disk space taken up by the view
>a.. The cost of maintaining the view on disk as the base
tables are
>modified - this is conceptually like a set of invisible
triggers.
>BTW I'm not really such an SQL insomniac :-) I guess the
post times are
>Western US timezone times: UK - 7 hours.
>Regards,
>Paul Ibison
>
>.
>
Hilary / Paul 2. questions.
1. I need to upgrade to sp3a on a distributor
that has about 40 publications to various
subscribers. I will be going from sql2k rtm to
sql2k sp3a. Are there any issues as far as
replication goes patching from rtm to sp3a? I
cannot afford to reinitilize any of these
publications.
2. Is there like a file size limit on using the
compress feature of a snapshot? I was able to
compress a 1gb table fine, but when I tried a
10gb one it always fails with a time out.
tia
-comb
btw, Hilary I just ordered your book for
45bucks.. hope it helps.
1. There are not issues that I am aware of. Your best bet is to stop all
agents, upgrade the distributor, then the publisher and then the
subscribers.
It is critical to upgrade the distributor and the publisher simultaneously.
The subscribers can wait.
2. You may need to restore your publication database on your subscriber and
then fix it up (ie NFR on all triggers, constraints, and identity columns).
Then do a nosync subscription and do a validation and try to sync any
discrepancies manually.
"Combfilter" <adsf@.asdf.com> wrote in message
news:MPG.1bf96d8fc0db9a09896dc@.news.newsreader.com ...
> 1. I need to upgrade to sp3a on a distributor
> that has about 40 publications to various
> subscribers. I will be going from sql2k rtm to
> sql2k sp3a. Are there any issues as far as
> replication goes patching from rtm to sp3a? I
> cannot afford to reinitilize any of these
> publications.
> 2. Is there like a file size limit on using the
> compress feature of a snapshot? I was able to
> compress a 1gb table fine, but when I tried a
> 10gb one it always fails with a time out.
> tia
> -comb
> btw, Hilary I just ordered your book for
> 45bucks.. hope it helps.
>
|||In article <eEcwkWfxEHA.748
@.TK2MSFTNGP14.phx.gbl>, hilary.cotter@.gmail.com
says...
Actually everyone is already at sp3a except the
dist. Pub and Sub are already sp3a. So I am
just going to do the distributor. I think that
should go on without a hitch right? I shouldn't
have to do anything to any of the db's on the
servers (pub/sub) that are already sp3a.
Do you have any websites or documentation that
explains how to do step 2. in a step by step
format?
Thanks for the info.
> 1. There are not issues that I am aware of. Your best bet is to stop all
> agents, upgrade the distributor, then the publisher and then the
> subscribers.
> It is critical to upgrade the distributor and the publisher simultaneously.
> The subscribers can wait.
> 2. You may need to restore your publication database on your subscriber and
> then fix it up (ie NFR on all triggers, constraints, and identity columns).
> Then do a nosync subscription and do a validation and try to sync any
> discrepancies manually.
>
> "Combfilter" <adsf@.asdf.com> wrote in message
> news:MPG.1bf96d8fc0db9a09896dc@.news.newsreader.com ...
>
>
that has about 40 publications to various
subscribers. I will be going from sql2k rtm to
sql2k sp3a. Are there any issues as far as
replication goes patching from rtm to sp3a? I
cannot afford to reinitilize any of these
publications.
2. Is there like a file size limit on using the
compress feature of a snapshot? I was able to
compress a 1gb table fine, but when I tried a
10gb one it always fails with a time out.
tia
-comb
btw, Hilary I just ordered your book for
45bucks.. hope it helps.
1. There are not issues that I am aware of. Your best bet is to stop all
agents, upgrade the distributor, then the publisher and then the
subscribers.
It is critical to upgrade the distributor and the publisher simultaneously.
The subscribers can wait.
2. You may need to restore your publication database on your subscriber and
then fix it up (ie NFR on all triggers, constraints, and identity columns).
Then do a nosync subscription and do a validation and try to sync any
discrepancies manually.
"Combfilter" <adsf@.asdf.com> wrote in message
news:MPG.1bf96d8fc0db9a09896dc@.news.newsreader.com ...
> 1. I need to upgrade to sp3a on a distributor
> that has about 40 publications to various
> subscribers. I will be going from sql2k rtm to
> sql2k sp3a. Are there any issues as far as
> replication goes patching from rtm to sp3a? I
> cannot afford to reinitilize any of these
> publications.
> 2. Is there like a file size limit on using the
> compress feature of a snapshot? I was able to
> compress a 1gb table fine, but when I tried a
> 10gb one it always fails with a time out.
> tia
> -comb
> btw, Hilary I just ordered your book for
> 45bucks.. hope it helps.
>
|||In article <eEcwkWfxEHA.748
@.TK2MSFTNGP14.phx.gbl>, hilary.cotter@.gmail.com
says...
Actually everyone is already at sp3a except the
dist. Pub and Sub are already sp3a. So I am
just going to do the distributor. I think that
should go on without a hitch right? I shouldn't
have to do anything to any of the db's on the
servers (pub/sub) that are already sp3a.
Do you have any websites or documentation that
explains how to do step 2. in a step by step
format?
Thanks for the info.
> 1. There are not issues that I am aware of. Your best bet is to stop all
> agents, upgrade the distributor, then the publisher and then the
> subscribers.
> It is critical to upgrade the distributor and the publisher simultaneously.
> The subscribers can wait.
> 2. You may need to restore your publication database on your subscriber and
> then fix it up (ie NFR on all triggers, constraints, and identity columns).
> Then do a nosync subscription and do a validation and try to sync any
> discrepancies manually.
>
> "Combfilter" <adsf@.asdf.com> wrote in message
> news:MPG.1bf96d8fc0db9a09896dc@.news.newsreader.com ...
>
>
Subscribe to:
Posts (Atom)