Showing posts with label physical. Show all posts
Showing posts with label physical. Show all posts

Monday, March 12, 2012

Replication over the Internet - Resolving server name

We are using anonymouse pull subscriptions over the internet. We are not
using VPN.
The physical SQL Server is called SQL22Server. We have a Domain assigned to
it called something like company.com.
However, I found that on the client machine, I had to put in a hosts entry
to route SQL22Server to the IP address. I was hoping I could just use the
domain name.
This creates an administrative overhead because we have to do add a host
entry during the client install instead of having just assigning value to the
merge object.
If I try the domain, the error I get is: The remote server does not exist or
has not been designated as a valid Publisher.
I created the replication using the SQL22Server name.
Thanks,
Buzz
use the activeX scripts to deploy your subscriptions. In it there are
PublisherNetwork, DistributorNetwork, PublisherAddress, and
DistributorAddress properties. These map to the entries you would otherwise
put in your CNU or hosts file to make this work.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Buzz" <buzz@.online.nospam> wrote in message
news:2C0E041F-5DA1-4DAB-B747-E52E2196395D@.microsoft.com...
> We are using anonymouse pull subscriptions over the internet. We are not
> using VPN.
> The physical SQL Server is called SQL22Server. We have a Domain assigned
to
> it called something like company.com.
> However, I found that on the client machine, I had to put in a hosts entry
> to route SQL22Server to the IP address. I was hoping I could just use the
> domain name.
> This creates an administrative overhead because we have to do add a host
> entry during the client install instead of having just assigning value to
the
> merge object.
> If I try the domain, the error I get is: The remote server does not exist
or
> has not been designated as a valid Publisher.
> I created the replication using the SQL22Server name.
> Thanks,
> Buzz
|||Thanks for the quick reply.
I am publishing what I found for the newsgroup.
For us, the publisher and the distributer are the same machine. We are using
FTP for the initial snapshot. We are using SQL Server 2000 SP4 on the server
and MSDE SP4 on the laptop subscribers.
I found I did not need the distributer values because my distributer and
publisher where the same machine. I will most likely set them anyway so that
someday in production I can have a different distributer.
Here are the subscriber properties of the Merge object:
.Distributor = "SQL22Server"
.DistributorSecurityMode = SECURITY_TYPE.DB_AUTHENTICATION
.DistributorAddress = "company.com"
.DistributorNetwork = NETWORK_TYPE.TCPIP_SOCKETS
.DistributorLogin = "login"
.DistributorPassword = "password"
.Publisher = "SQL22Server"
.PublisherAddress = "company.com"
.PublisherDatabase = "data"
.PublisherNetwork = NETWORK_TYPE.TCPIP_SOCKETS
.Publication = "data"
.PublisherSecurityMode = SECURITY_TYPE.DB_AUTHENTICATION
.PublisherLogin = "login"
.PublisherPassword = "password"
The one last thing to make sure is that when setting up the FTP on the
server, use the PublisherAddress value. So "company.com" so that the
subscriber hits ftp://company.com/.
Also if you do this in production be careful the change to the FTP address
causes the publication to force a recreation of the initial snapshot.
Thanks,
Buzz
"Hilary Cotter" wrote:

> use the activeX scripts to deploy your subscriptions. In it there are
> PublisherNetwork, DistributorNetwork, PublisherAddress, and
> DistributorAddress properties. These map to the entries you would otherwise
> put in your CNU or hosts file to make this work.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Buzz" <buzz@.online.nospam> wrote in message
> news:2C0E041F-5DA1-4DAB-B747-E52E2196395D@.microsoft.com...
> to
> the
> or
>
>
|||Hi Buzz,
It looks more than a network issue.
- Could you PING SQL22Server from client and get the response?
- Could you telnet SQL22Server from client use the command like below
telnet <SQL22Server Domain Name>: 1433
- Do you have firewall between server and client? Have you open the TCP
port for them?
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are always here to be of
assistance!
Sincerely yours,
Michael Cheng
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.

Saturday, February 25, 2012

Replication Maintanance Issues!

Hi Guys/Gals,

Need some comments/ideas on the following scenario:

Current Situation:
-I have a PROD DB and a REPORTING DB( Separte Physical Servers).
-PROD DB replicates (Transactional) to REPORTING DB. ( Using only Replication Wizard to set up, quite easy)
-DB is for running shopfloor(manufacturing) applications, thus needs to be minimum downtime.
-Retention period for PROD DB data is 3 months ,Reporting DB is 3 years.

Future Problem that I will encounter:
-Purging of data in PROD DB will be replicated into Reporting.
-Schema change in PROD DB need to delete existing Publication before able to change schema.
-After schema change, need to recreate publication and rerun snapshot.

Questions:
-How to prevent the purging to be replicated to Reporting?
Switching off Replication when Purging takes place will not help. The only solution
I am thinking of is to alter the store procedure for replication during purging.
Is there any other "CLEANER" hassle free way?

- How to cater shema changes better?
Currently the data is not alot, but down the road, it might go to Terabytes, by then running a
snapshot will cost us alot. Is there any way not to redo a snapshot for this scenario?

Please give your comments/ideas/ .

Thanks.--> another thing I miss out, doing a snapshot again would clear any data
Reporting DB has stored. e.g. Prod DB( 3 months data) , Reporting DB(1 year data), do snapshot....all gone.|||Anyone...any suggestions?|||Patrick, have you thought about replication without snapshot? That will minimize the impact of snapshoting on publications.

Changing replication stored procs sounds the best way to avoid data changes on the subscribers. But it could go wild if you have a lot of sprocs to modify.|||replication without snapshot..hmmm...I'll check it out...
no idea as of how not to have a snapshot for now....can u give some highlights...

Anybody else? I'm sure other ppl would have the same senario as me....|||there was a thread a few days back that was talking about transactional replication without snapshot. check it out:
http://www.dbforums.com/showthread.php?p=3665793#post3665793

SQL Magazine also has an article on this.

I have used this technique for years. The key is to ensure publisher and subscriber are in sync without snapshoting. make sure no one can do transactions in the servers. break replication, dropping subscriber, articles etc, while the publisher and subscriber dbs are not modified. At the end when you reset up replication, click on the option that says "subscriber already has the data".