Showing posts with label mssql. Show all posts
Showing posts with label mssql. Show all posts

Wednesday, March 28, 2012

Log shipping through firewall

I attempted to set up log shipping where the standby server is in the DMZ
and the master server is on the internal network. Both are MSSQL 2000 servers.
I used the Maintenance Plan Wizard in order to set it up.
My problem is that the standby server does not appear in the list of servers
available to choose from when choosing a destination server. I would expect
that list to contain all servers found via broadcast on the local network,
as well as servers registered in EM, but the latter does not seem to be the
case.
The standby server is registered in the master servers EM, and port 1433
is open through the firewall, so the server can be managed. However, the
server still does not appear in the list of "destination servers" to choose
from.
What are the requirements for a server to appear in that list? Would opening
the RPC ports make a difference? (that is what's next on the agenda - as
file transfer uses the RPC).
Hi
Have your read
http://support.microsoft.com/default...b;en-us;287932
For most locations where you require to name a server, even if the server
does not appear you can usually type in the name.
John
"Inge" <inge@.norway.net> wrote in message
news:36b19dde6ba838c7d29534d97760@.news.microsoft.c om...
>I attempted to set up log shipping where the standby server is in the DMZ
>and the master server is on the internal network. Both are MSSQL 2000
>servers. I used the Maintenance Plan Wizard in order to set it up.
> My problem is that the standby server does not appear in the list of
> servers available to choose from when choosing a destination server. I
> would expect that list to contain all servers found via broadcast on the
> local network, as well as servers registered in EM, but the latter does
> not seem to be the case.
> The standby server is registered in the master servers EM, and port 1433
> is open through the firewall, so the server can be managed. However, the
> server still does not appear in the list of "destination servers" to
> choose from.
> What are the requirements for a server to appear in that list? Would
> opening the RPC ports make a difference? (that is what's next on the
> agenda - as file transfer uses the RPC).
>
|||Thank you for your quick reply!
I can successfully communicate through the port 1433 as per the article.
with EM on one side of the firewall, I can administer the server on the other
side, no problem.
Unfortunately, the dialog box with regards to Log Shipping does not allow
me to type in the name - I can only choose from the list. I would believe
that the servers in that list should include those registered in Enterprise
Manager on that server, but that does not appear to be the case.
[vbcol=seagreen]
> Hi
> Have your read
> http://support.microsoft.com/default...b;en-us;287932
> For most locations where you require to name a server, even if the
> server does not appear you can usually type in the name.
> John
> "Inge" <inge@.norway.net> wrote in message
> news:36b19dde6ba838c7d29534d97760@.news.microsoft.c om...
|||You have two issues to deal with in this scenario.
1. To get the list of servers you will need to open up UDP port 1434.
2. MS Logshipping requires that the account running running your SQL Agent
service be able to map a drive (open a UNC) to the destination server. This
means that AD must be available on both sides and that SMB traffic must be
allowed through the firewall. Most firewall admins don't like to open up
SMB taffic because of the exposures it causes. Since this is to the DMZ
perhaps thats not an issue.
An alternative would be write your own custom version of Log shipping. I
wrote one that uses FTP to send the log files. On the destination, a
routine is called to pick the sent files, check for contigous LSN and apply
them to standby mode.
Also bear in mind that every timie a log is being applied the database goes
offline during the restore.
"Inge" <inge@.norway.net> wrote in message
news:36b19dde6ba838c7d29534d97760@.news.microsoft.c om...
>I attempted to set up log shipping where the standby server is in the DMZ
>and the master server is on the internal network. Both are MSSQL 2000
>servers. I used the Maintenance Plan Wizard in order to set it up.
> My problem is that the standby server does not appear in the list of
> servers available to choose from when choosing a destination server. I
> would expect that list to contain all servers found via broadcast on the
> local network, as well as servers registered in EM, but the latter does
> not seem to be the case.
> The standby server is registered in the master servers EM, and port 1433
> is open through the firewall, so the server can be managed. However, the
> server still does not appear in the list of "destination servers" to
> choose from.
> What are the requirements for a server to appear in that list? Would
> opening the RPC ports make a difference? (that is what's next on the
> agenda - as file transfer uses the RPC).
>
|||The issue was that the DMZ server was std. edition, not Enterprise edition...
As long as the server is registered in the Log Shipping source EM, I don't
think the UDP port is necessary. The file share is still an issue, but we
can deal with it.
Thanks for the input
[vbcol=seagreen]
> You have two issues to deal with in this scenario.
> 1. To get the list of servers you will need to open up UDP port 1434.
> 2. MS Logshipping requires that the account running running your SQL
> Agent
> service be able to map a drive (open a UNC) to the destination server.
> This
> means that AD must be available on both sides and that SMB traffic
> must be
> allowed through the firewall. Most firewall admins don't like to open
> up
> SMB taffic because of the exposures it causes. Since this is to the
> DMZ
> perhaps thats not an issue.
> An alternative would be write your own custom version of Log shipping.
> I wrote one that uses FTP to send the log files. On the destination,
> a routine is called to pick the sent files, check for contigous LSN
> and apply them to standby mode.
> Also bear in mind that every timie a log is being applied the database
> goes offline during the restore.
> "Inge" <inge@.norway.net> wrote in message
> news:36b19dde6ba838c7d29534d97760@.news.microsoft.c om...
sql

Log shipping through firewall

I attempted to set up log shipping where the standby server is in the DMZ
and the master server is on the internal network. Both are MSSQL 2000 servers.
I used the Maintenance Plan Wizard in order to set it up.
My problem is that the standby server does not appear in the list of servers
available to choose from when choosing a destination server. I would expect
that list to contain all servers found via broadcast on the local network,
as well as servers registered in EM, but the latter does not seem to be the
case.
The standby server is registered in the master servers EM, and port 1433
is open through the firewall, so the server can be managed. However, the
server still does not appear in the list of "destination servers" to choose
from.
What are the requirements for a server to appear in that list? Would opening
the RPC ports make a difference? (that is what's next on the agenda - as
file transfer uses the RPC).Hi
Have your read
http://support.microsoft.com/default.aspx?scid=kb;en-us;287932
For most locations where you require to name a server, even if the server
does not appear you can usually type in the name.
John
"Inge" <inge@.norway.net> wrote in message
news:36b19dde6ba838c7d29534d97760@.news.microsoft.com...
>I attempted to set up log shipping where the standby server is in the DMZ
>and the master server is on the internal network. Both are MSSQL 2000
>servers. I used the Maintenance Plan Wizard in order to set it up.
> My problem is that the standby server does not appear in the list of
> servers available to choose from when choosing a destination server. I
> would expect that list to contain all servers found via broadcast on the
> local network, as well as servers registered in EM, but the latter does
> not seem to be the case.
> The standby server is registered in the master servers EM, and port 1433
> is open through the firewall, so the server can be managed. However, the
> server still does not appear in the list of "destination servers" to
> choose from.
> What are the requirements for a server to appear in that list? Would
> opening the RPC ports make a difference? (that is what's next on the
> agenda - as file transfer uses the RPC).
>|||You have two issues to deal with in this scenario.
1. To get the list of servers you will need to open up UDP port 1434.
2. MS Logshipping requires that the account running running your SQL Agent
service be able to map a drive (open a UNC) to the destination server. This
means that AD must be available on both sides and that SMB traffic must be
allowed through the firewall. Most firewall admins don't like to open up
SMB taffic because of the exposures it causes. Since this is to the DMZ
perhaps thats not an issue.
An alternative would be write your own custom version of Log shipping. I
wrote one that uses FTP to send the log files. On the destination, a
routine is called to pick the sent files, check for contigous LSN and apply
them to standby mode.
Also bear in mind that every timie a log is being applied the database goes
offline during the restore.
"Inge" <inge@.norway.net> wrote in message
news:36b19dde6ba838c7d29534d97760@.news.microsoft.com...
>I attempted to set up log shipping where the standby server is in the DMZ
>and the master server is on the internal network. Both are MSSQL 2000
>servers. I used the Maintenance Plan Wizard in order to set it up.
> My problem is that the standby server does not appear in the list of
> servers available to choose from when choosing a destination server. I
> would expect that list to contain all servers found via broadcast on the
> local network, as well as servers registered in EM, but the latter does
> not seem to be the case.
> The standby server is registered in the master servers EM, and port 1433
> is open through the firewall, so the server can be managed. However, the
> server still does not appear in the list of "destination servers" to
> choose from.
> What are the requirements for a server to appear in that list? Would
> opening the RPC ports make a difference? (that is what's next on the
> agenda - as file transfer uses the RPC).
>

Log shipping through firewall

I attempted to set up log shipping where the standby server is in the DMZ
and the master server is on the internal network. Both are MSSQL 2000 server
s.
I used the Maintenance Plan Wizard in order to set it up.
My problem is that the standby server does not appear in the list of servers
available to choose from when choosing a destination server. I would expect
that list to contain all servers found via broadcast on the local network,
as well as servers registered in EM, but the latter does not seem to be the
case.
The standby server is registered in the master servers EM, and port 1433
is open through the firewall, so the server can be managed. However, the
server still does not appear in the list of "destination servers" to choose
from.
What are the requirements for a server to appear in that list? Would opening
the RPC ports make a difference? (that is what's next on the agenda - as
file transfer uses the RPC).Hi
Have your read
http://support.microsoft.com/defaul...kb;en-us;287932
For most locations where you require to name a server, even if the server
does not appear you can usually type in the name.
John
"Inge" <inge@.norway.net> wrote in message
news:36b19dde6ba838c7d29534d97760@.news.microsoft.com...
>I attempted to set up log shipping where the standby server is in the DMZ
>and the master server is on the internal network. Both are MSSQL 2000
>servers. I used the Maintenance Plan Wizard in order to set it up.
> My problem is that the standby server does not appear in the list of
> servers available to choose from when choosing a destination server. I
> would expect that list to contain all servers found via broadcast on the
> local network, as well as servers registered in EM, but the latter does
> not seem to be the case.
> The standby server is registered in the master servers EM, and port 1433
> is open through the firewall, so the server can be managed. However, the
> server still does not appear in the list of "destination servers" to
> choose from.
> What are the requirements for a server to appear in that list? Would
> opening the RPC ports make a difference? (that is what's next on the
> agenda - as file transfer uses the RPC).
>|||Thank you for your quick reply!
I can successfully communicate through the port 1433 as per the article.
with EM on one side of the firewall, I can administer the server on the othe
r
side, no problem.
Unfortunately, the dialog box with regards to Log Shipping does not allow
me to type in the name - I can only choose from the list. I would believe
that the servers in that list should include those registered in Enterprise
Manager on that server, but that does not appear to be the case.
[vbcol=seagreen]
> Hi
> Have your read
> http://support.microsoft.com/defaul...kb;en-us;287932
> For most locations where you require to name a server, even if the
> server does not appear you can usually type in the name.
> John
> "Inge" <inge@.norway.net> wrote in message
> news:36b19dde6ba838c7d29534d97760@.news.microsoft.com...
>|||You have two issues to deal with in this scenario.
1. To get the list of servers you will need to open up UDP port 1434.
2. MS Logshipping requires that the account running running your SQL Agent
service be able to map a drive (open a UNC) to the destination server. This
means that AD must be available on both sides and that SMB traffic must be
allowed through the firewall. Most firewall admins don't like to open up
SMB taffic because of the exposures it causes. Since this is to the DMZ
perhaps thats not an issue.
An alternative would be write your own custom version of Log shipping. I
wrote one that uses FTP to send the log files. On the destination, a
routine is called to pick the sent files, check for contigous LSN and apply
them to standby mode.
Also bear in mind that every timie a log is being applied the database goes
offline during the restore.
"Inge" <inge@.norway.net> wrote in message
news:36b19dde6ba838c7d29534d97760@.news.microsoft.com...
>I attempted to set up log shipping where the standby server is in the DMZ
>and the master server is on the internal network. Both are MSSQL 2000
>servers. I used the Maintenance Plan Wizard in order to set it up.
> My problem is that the standby server does not appear in the list of
> servers available to choose from when choosing a destination server. I
> would expect that list to contain all servers found via broadcast on the
> local network, as well as servers registered in EM, but the latter does
> not seem to be the case.
> The standby server is registered in the master servers EM, and port 1433
> is open through the firewall, so the server can be managed. However, the
> server still does not appear in the list of "destination servers" to
> choose from.
> What are the requirements for a server to appear in that list? Would
> opening the RPC ports make a difference? (that is what's next on the
> agenda - as file transfer uses the RPC).
>|||The issue was that the DMZ server was std. edition, not Enterprise edition..
.
As long as the server is registered in the Log Shipping source EM, I don't
think the UDP port is necessary. The file share is still an issue, but we
can deal with it.
Thanks for the input
[vbcol=seagreen]
> You have two issues to deal with in this scenario.
> 1. To get the list of servers you will need to open up UDP port 1434.
> 2. MS Logshipping requires that the account running running your SQL
> Agent
> service be able to map a drive (open a UNC) to the destination server.
> This
> means that AD must be available on both sides and that SMB traffic
> must be
> allowed through the firewall. Most firewall admins don't like to open
> up
> SMB taffic because of the exposures it causes. Since this is to the
> DMZ
> perhaps thats not an issue.
> An alternative would be write your own custom version of Log shipping.
> I wrote one that uses FTP to send the log files. On the destination,
> a routine is called to pick the sent files, check for contigous LSN
> and apply them to standby mode.
> Also bear in mind that every timie a log is being applied the database
> goes offline during the restore.
> "Inge" <inge@.norway.net> wrote in message
> news:36b19dde6ba838c7d29534d97760@.news.microsoft.com...
>

Monday, March 19, 2012

Log shipping in mssql 2000

Hi,

I am now trying to configure Log Shipping in my compeny but I have encountered some difficulties. The destination site and the source site are far from each other and the transaction logs are too big, this situation causes an huge overload on our private network (we use WAN which is complitly disconnected from the internet). Is there any way to compress the transacion logs with zip or rar and combine it in the log shipping mechanizem?

Is there another way for making this files smaller?

I would be greatful for any ideas in this matter.

Thanks in advance,
Zvi GilinskyThe only way I think is to increase time of Log shipping and meanwhile use compress software and ftp to transfer the file, then unzip it at desired location where LS can acces to restore.

BTW, any chance of hosting another standby server on the network and copy the files to this remote location as contingency.|||Dear Satya,

Correct me if I wrong.
As far as I know LS uses 3 primary jobs: one job on the source and two on the destinaion.
The job on the source creates the transaction logs, one job on the destination copy this files to the destination and the other job applies them on the destination DB.

If I will stop the job that copy the files and replace it by another job that compress these files, transfer them and then extract them won't it demage the LS mechanizem (wrong data in log shipping tables in msdb database)?

I also try to understand what the job that copy the files does but when I I see that it does the following line : EXECUTE master.dbo.xp_sqlmaint'-LSCopyPlainID "plan id"...
but when I query the msdb database : exec sp_help_maintenance_plan
this plan id isn't there. Where else can I see this plan id and it's details?

thanks,
zvi gilinsky|||Try to get dedicated link between primary & secondary servers to ensure no issues on network.

If you've such network problems in complying the log shipping to complete then better to think of contingency solution on a local network and use this remote server as seperate server.

Try to query against master database and see.

Monday, February 20, 2012

Log Shipping accross the WAN?

Can I setup Log Shipping accross the WAN if I enable very specific firewall
rules to allow access to MSSQL. (ie. WAN IP on port 1440 to WAN IP2 on 1440
)
Has anyone tried this? Is it as simple as opening up that port, or are ther
e
a whole host of ports to open up.Hi
Log shipping relies on a file copy from one server to another, so you need
the NT Challenge Response ports (135, 137, 138, 139) and 445. Then you need
to port that SQL Server listens on, which is generally 1433, depending on
your installation.
Look at http://www.speedguide.net/ports.php to see what ports I list and if
it is UDP or TCP.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Soul_Chicken" <Soul_Chicken@.discussions.microsoft.com> wrote in message
news:DC13165D-15E8-4A71-99BC-DA2B9AC4AE9C@.microsoft.com...
> Can I setup Log Shipping accross the WAN if I enable very specific
> firewall
> rules to allow access to MSSQL. (ie. WAN IP on port 1440 to WAN IP2 on
> 1440)
> Has anyone tried this? Is it as simple as opening up that port, or are
> there
> a whole host of ports to open up.
>|||In article <#4rPey6kFHA.1996@.TK2MSFTNGP10.phx.gbl>, mike@.epprecht.net
says...
> Hi
> Log shipping relies on a file copy from one server to another, so you need
> the NT Challenge Response ports (135, 137, 138, 139) and 445. Then you nee
d
> to port that SQL Server listens on, which is generally 1433, depending on
> your installation.
> Look at http://www.speedguide.net/ports.php to see what ports I list and i
f
> it is UDP or TCP.
Connections between SQL Servers in different locations (WAN to WAN)
should be done through a VPN tunnel and not exposed directly to the
Internet - there is no reason to expose a SQL server to the Internet.
spam999free@.rrohio.com
remove 999 in order to email me

Log Shipping accross the WAN?

Can I setup Log Shipping accross the WAN if I enable very specific firewall
rules to allow access to MSSQL. (ie. WAN IP on port 1440 to WAN IP2 on 1440)
Has anyone tried this? Is it as simple as opening up that port, or are there
a whole host of ports to open up.Hi
Log shipping relies on a file copy from one server to another, so you need
the NT Challenge Response ports (135, 137, 138, 139) and 445. Then you need
to port that SQL Server listens on, which is generally 1433, depending on
your installation.
Look at http://www.speedguide.net/ports.php to see what ports I list and if
it is UDP or TCP.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Soul_Chicken" <Soul_Chicken@.discussions.microsoft.com> wrote in message
news:DC13165D-15E8-4A71-99BC-DA2B9AC4AE9C@.microsoft.com...
> Can I setup Log Shipping accross the WAN if I enable very specific
> firewall
> rules to allow access to MSSQL. (ie. WAN IP on port 1440 to WAN IP2 on
> 1440)
> Has anyone tried this? Is it as simple as opening up that port, or are
> there
> a whole host of ports to open up.
>|||In article <#4rPey6kFHA.1996@.TK2MSFTNGP10.phx.gbl>, mike@.epprecht.net
says...
> Hi
> Log shipping relies on a file copy from one server to another, so you need
> the NT Challenge Response ports (135, 137, 138, 139) and 445. Then you need
> to port that SQL Server listens on, which is generally 1433, depending on
> your installation.
> Look at http://www.speedguide.net/ports.php to see what ports I list and if
> it is UDP or TCP.
Connections between SQL Servers in different locations (WAN to WAN)
should be done through a VPN tunnel and not exposed directly to the
Internet - there is no reason to expose a SQL server to the Internet.
--
spam999free@.rrohio.com
remove 999 in order to email me

Log Shipping accross the WAN?

Can I setup Log Shipping accross the WAN if I enable very specific firewall
rules to allow access to MSSQL. (ie. WAN IP on port 1440 to WAN IP2 on 1440)
Has anyone tried this? Is it as simple as opening up that port, or are there
a whole host of ports to open up.
Hi
Log shipping relies on a file copy from one server to another, so you need
the NT Challenge Response ports (135, 137, 138, 139) and 445. Then you need
to port that SQL Server listens on, which is generally 1433, depending on
your installation.
Look at http://www.speedguide.net/ports.php to see what ports I list and if
it is UDP or TCP.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Soul_Chicken" <Soul_Chicken@.discussions.microsoft.com> wrote in message
news:DC13165D-15E8-4A71-99BC-DA2B9AC4AE9C@.microsoft.com...
> Can I setup Log Shipping accross the WAN if I enable very specific
> firewall
> rules to allow access to MSSQL. (ie. WAN IP on port 1440 to WAN IP2 on
> 1440)
> Has anyone tried this? Is it as simple as opening up that port, or are
> there
> a whole host of ports to open up.
>
|||In article <#4rPey6kFHA.1996@.TK2MSFTNGP10.phx.gbl>, mike@.epprecht.net
says...
> Hi
> Log shipping relies on a file copy from one server to another, so you need
> the NT Challenge Response ports (135, 137, 138, 139) and 445. Then you need
> to port that SQL Server listens on, which is generally 1433, depending on
> your installation.
> Look at http://www.speedguide.net/ports.php to see what ports I list and if
> it is UDP or TCP.
Connections between SQL Servers in different locations (WAN to WAN)
should be done through a VPN tunnel and not exposed directly to the
Internet - there is no reason to expose a SQL server to the Internet.
spam999free@.rrohio.com
remove 999 in order to email me