Hello, I'm trying to restore a large database (350gb) to a sql server over the network. However after running for about 10 hours or so the target sql server crushes with a blue screen. Has anybody encountered similar problem or do you have an idea as to why this may happen. Thanks a lot for any help.Hello Wolv,
What sort of network are you running? If you are working on a gigabyte LAN/SAN, then you should have no problem depending on whether your SQL server hardware is up to scratch.
You are trying to move a big DB, therefore if you don't have the hardware to support that move then you may want to consider an alternative for moving the data.
Hope this helps, at least in understanding why...|||well, what kind of network would be helpful, but If you are restoring it, I would think that you've had it in the same place before, just something happened, and that's why you are restoring it...correct?
Showing posts with label network. Show all posts
Showing posts with label network. Show all posts
Monday, March 19, 2012
Thursday, March 8, 2012
Blocking a specific host
here's one... we have a rogue system on our network. Every 8months or so,
someone flips the "on" switch to the computer and brings it up. Aparently, it
has an application that uses a generic login (used by other applications) to
access SQL Server. The problem is, what ever file that once was there is no
longer there, so when the startup routine trys connecting to the db and
application, it gets connected to the db, but hangs trying to get connected
to the app. Our network team has no idea where the offending system is, but
obviously it's booted up every once in a blue moon.
My question is, can one block access from a Host to a SQL Server box? If
not, does anyone have ideas on how to capture the ip address or something
that could identify this rogue system by means other than User (remember,
it's a generic userid) or Host?
Thanks a ton for any idea presented!!
Andy wrote:
> here's one... we have a rogue system on our network. Every 8months or
> so, someone flips the "on" switch to the computer and brings it up.
> Aparently, it has an application that uses a generic login (used by
> other applications) to access SQL Server. The problem is, what ever
> file that once was there is no longer there, so when the startup
> routine trys connecting to the db and application, it gets connected
> to the db, but hangs trying to get connected to the app. Our network
> team has no idea where the offending system is, but obviously it's
> booted up every once in a blue moon.
> My question is, can one block access from a Host to a SQL Server box?
> If not, does anyone have ideas on how to capture the ip address or
> something that could identify this rogue system by means other than
> User (remember, it's a generic userid) or Host?
> Thanks a ton for any idea presented!!
You can get the MAC address and Host Name from the sysprocesses table in
the master database once the rogue system in connected. Your network
admin should be able to trace that back to the PC that's causing the
problem.
David Gugick
Quest Software
www.imceda.com
www.quest.com
someone flips the "on" switch to the computer and brings it up. Aparently, it
has an application that uses a generic login (used by other applications) to
access SQL Server. The problem is, what ever file that once was there is no
longer there, so when the startup routine trys connecting to the db and
application, it gets connected to the db, but hangs trying to get connected
to the app. Our network team has no idea where the offending system is, but
obviously it's booted up every once in a blue moon.
My question is, can one block access from a Host to a SQL Server box? If
not, does anyone have ideas on how to capture the ip address or something
that could identify this rogue system by means other than User (remember,
it's a generic userid) or Host?
Thanks a ton for any idea presented!!
Andy wrote:
> here's one... we have a rogue system on our network. Every 8months or
> so, someone flips the "on" switch to the computer and brings it up.
> Aparently, it has an application that uses a generic login (used by
> other applications) to access SQL Server. The problem is, what ever
> file that once was there is no longer there, so when the startup
> routine trys connecting to the db and application, it gets connected
> to the db, but hangs trying to get connected to the app. Our network
> team has no idea where the offending system is, but obviously it's
> booted up every once in a blue moon.
> My question is, can one block access from a Host to a SQL Server box?
> If not, does anyone have ideas on how to capture the ip address or
> something that could identify this rogue system by means other than
> User (remember, it's a generic userid) or Host?
> Thanks a ton for any idea presented!!
You can get the MAC address and Host Name from the sysprocesses table in
the master database once the rogue system in connected. Your network
admin should be able to trace that back to the PC that's causing the
problem.
David Gugick
Quest Software
www.imceda.com
www.quest.com
Blocking a specific host
here's one... we have a rogue system on our network. Every 8months or so,
someone flips the "on" switch to the computer and brings it up. Aparently, it
has an application that uses a generic login (used by other applications) to
access SQL Server. The problem is, what ever file that once was there is no
longer there, so when the startup routine trys connecting to the db and
application, it gets connected to the db, but hangs trying to get connected
to the app. Our network team has no idea where the offending system is, but
obviously it's booted up every once in a blue moon.
My question is, can one block access from a Host to a SQL Server box? If
not, does anyone have ideas on how to capture the ip address or something
that could identify this rogue system by means other than User (remember,
it's a generic userid) or Host?
Thanks a ton for any idea presented!!Andy wrote:
> here's one... we have a rogue system on our network. Every 8months or
> so, someone flips the "on" switch to the computer and brings it up.
> Aparently, it has an application that uses a generic login (used by
> other applications) to access SQL Server. The problem is, what ever
> file that once was there is no longer there, so when the startup
> routine trys connecting to the db and application, it gets connected
> to the db, but hangs trying to get connected to the app. Our network
> team has no idea where the offending system is, but obviously it's
> booted up every once in a blue moon.
> My question is, can one block access from a Host to a SQL Server box?
> If not, does anyone have ideas on how to capture the ip address or
> something that could identify this rogue system by means other than
> User (remember, it's a generic userid) or Host?
> Thanks a ton for any idea presented!!
You can get the MAC address and Host Name from the sysprocesses table in
the master database once the rogue system in connected. Your network
admin should be able to trace that back to the PC that's causing the
problem.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com
someone flips the "on" switch to the computer and brings it up. Aparently, it
has an application that uses a generic login (used by other applications) to
access SQL Server. The problem is, what ever file that once was there is no
longer there, so when the startup routine trys connecting to the db and
application, it gets connected to the db, but hangs trying to get connected
to the app. Our network team has no idea where the offending system is, but
obviously it's booted up every once in a blue moon.
My question is, can one block access from a Host to a SQL Server box? If
not, does anyone have ideas on how to capture the ip address or something
that could identify this rogue system by means other than User (remember,
it's a generic userid) or Host?
Thanks a ton for any idea presented!!Andy wrote:
> here's one... we have a rogue system on our network. Every 8months or
> so, someone flips the "on" switch to the computer and brings it up.
> Aparently, it has an application that uses a generic login (used by
> other applications) to access SQL Server. The problem is, what ever
> file that once was there is no longer there, so when the startup
> routine trys connecting to the db and application, it gets connected
> to the db, but hangs trying to get connected to the app. Our network
> team has no idea where the offending system is, but obviously it's
> booted up every once in a blue moon.
> My question is, can one block access from a Host to a SQL Server box?
> If not, does anyone have ideas on how to capture the ip address or
> something that could identify this rogue system by means other than
> User (remember, it's a generic userid) or Host?
> Thanks a ton for any idea presented!!
You can get the MAC address and Host Name from the sysprocesses table in
the master database once the rogue system in connected. Your network
admin should be able to trace that back to the PC that's causing the
problem.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com
Blocking a specific host
here's one... we have a rogue system on our network. Every 8months or so,
someone flips the "on" switch to the computer and brings it up. Aparently, i
t
has an application that uses a generic login (used by other applications) to
access SQL Server. The problem is, what ever file that once was there is no
longer there, so when the startup routine trys connecting to the db and
application, it gets connected to the db, but hangs trying to get connected
to the app. Our network team has no idea where the offending system is, but
obviously it's booted up every once in a blue moon.
My question is, can one block access from a Host to a SQL Server box? If
not, does anyone have ideas on how to capture the ip address or something
that could identify this rogue system by means other than User (remember,
it's a generic userid) or Host?
Thanks a ton for any idea presented!!Andy wrote:
> here's one... we have a rogue system on our network. Every 8months or
> so, someone flips the "on" switch to the computer and brings it up.
> Aparently, it has an application that uses a generic login (used by
> other applications) to access SQL Server. The problem is, what ever
> file that once was there is no longer there, so when the startup
> routine trys connecting to the db and application, it gets connected
> to the db, but hangs trying to get connected to the app. Our network
> team has no idea where the offending system is, but obviously it's
> booted up every once in a blue moon.
> My question is, can one block access from a Host to a SQL Server box?
> If not, does anyone have ideas on how to capture the ip address or
> something that could identify this rogue system by means other than
> User (remember, it's a generic userid) or Host?
> Thanks a ton for any idea presented!!
You can get the MAC address and Host Name from the sysprocesses table in
the master database once the rogue system in connected. Your network
admin should be able to trace that back to the PC that's causing the
problem.
David Gugick
Quest Software
www.imceda.com
www.quest.com
someone flips the "on" switch to the computer and brings it up. Aparently, i
t
has an application that uses a generic login (used by other applications) to
access SQL Server. The problem is, what ever file that once was there is no
longer there, so when the startup routine trys connecting to the db and
application, it gets connected to the db, but hangs trying to get connected
to the app. Our network team has no idea where the offending system is, but
obviously it's booted up every once in a blue moon.
My question is, can one block access from a Host to a SQL Server box? If
not, does anyone have ideas on how to capture the ip address or something
that could identify this rogue system by means other than User (remember,
it's a generic userid) or Host?
Thanks a ton for any idea presented!!Andy wrote:
> here's one... we have a rogue system on our network. Every 8months or
> so, someone flips the "on" switch to the computer and brings it up.
> Aparently, it has an application that uses a generic login (used by
> other applications) to access SQL Server. The problem is, what ever
> file that once was there is no longer there, so when the startup
> routine trys connecting to the db and application, it gets connected
> to the db, but hangs trying to get connected to the app. Our network
> team has no idea where the offending system is, but obviously it's
> booted up every once in a blue moon.
> My question is, can one block access from a Host to a SQL Server box?
> If not, does anyone have ideas on how to capture the ip address or
> something that could identify this rogue system by means other than
> User (remember, it's a generic userid) or Host?
> Thanks a ton for any idea presented!!
You can get the MAC address and Host Name from the sysprocesses table in
the master database once the rogue system in connected. Your network
admin should be able to trace that back to the PC that's causing the
problem.
David Gugick
Quest Software
www.imceda.com
www.quest.com
Friday, February 24, 2012
blob and network packet size
1) For performance of BLOB only data that will have at least 100 KB per BLOB,
what is the best network packet size setting? The resource kit indicates that
it is 8080. Is that correct, or is it a typo that should say 8192?
2) Does the client connection have to match the network packet size setting
for it to be used?
In general the network packet size setting should be left alone, it is not
going to give you much one way or another in terms of performance.
The main reason I say this is everything has to go across TCP-IP, which has
a limit of ~1430 bytes per packet. So the TDS packet size is not the
limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
the end.
Another problem with cranking it up is that it causes SQL Server to also
chew up more memory holding larger packets, reducing scalability. So 4K
default is good. Network packet size > 8000 bytes should be avoided for
server scalability reasons, this causes SQL to allocate packets out of
mem2leave area instead of normal buffer pool.
Matt Neerincx [MSFT]
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"dp" <dp@.discussions.microsoft.com> wrote in message
news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
> 1) For performance of BLOB only data that will have at least 100 KB per
> BLOB,
> what is the best network packet size setting? The resource kit indicates
> that
> it is 8080. Is that correct, or is it a typo that should say 8192?
> 2) Does the client connection have to match the network packet size
> setting
> for it to be used?
>
>
|||Your reply make me quite confused. The following are from Chapter 11 - Using
BLOBs in SQL Server 2000 Resource Kit. url:
http://www.microsoft.com/technet/pro...rt3/c1161.mspx
If your database application sends or receives large amounts of BLOB data,
consider changing the packet size of the chunks of data that transfer
requests and results between clients and servers. To change or set the packet
size, use the network packet size option in Configuration Options. A packet
size larger than the 4,096-byte default may improve efficiency by lowering
the network reads and writes. A packet size of 8,080 bytes is best for
performance in SQL Server 2000 and SQL Server 7.0.
So which configuration should I follow? From your reply, tha statement above
is not quite correct, isn't it?
Anyway, would you (or someone) mind give me some direction on how to
configure a sql server 2000 which only hold blob data for best performance?
thanks much,
dp
m
"Matt Neerincx [MS]" wrote:
> In general the network packet size setting should be left alone, it is not
> going to give you much one way or another in terms of performance.
> The main reason I say this is everything has to go across TCP-IP, which has
> a limit of ~1430 bytes per packet. So the TDS packet size is not the
> limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
> the end.
> Another problem with cranking it up is that it causes SQL Server to also
> chew up more memory holding larger packets, reducing scalability. So 4K
> default is good. Network packet size > 8000 bytes should be avoided for
> server scalability reasons, this causes SQL to allocate packets out of
> mem2leave area instead of normal buffer pool.
> Matt Neerincx [MSFT]
> This posting is provided "AS IS", with no warranties, and confers no rights.
> Please do not send email directly to this alias. This alias is for newsgroup
> purposes only.
> "dp" <dp@.discussions.microsoft.com> wrote in message
> news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
>
>
what is the best network packet size setting? The resource kit indicates that
it is 8080. Is that correct, or is it a typo that should say 8192?
2) Does the client connection have to match the network packet size setting
for it to be used?
In general the network packet size setting should be left alone, it is not
going to give you much one way or another in terms of performance.
The main reason I say this is everything has to go across TCP-IP, which has
a limit of ~1430 bytes per packet. So the TDS packet size is not the
limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
the end.
Another problem with cranking it up is that it causes SQL Server to also
chew up more memory holding larger packets, reducing scalability. So 4K
default is good. Network packet size > 8000 bytes should be avoided for
server scalability reasons, this causes SQL to allocate packets out of
mem2leave area instead of normal buffer pool.
Matt Neerincx [MSFT]
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"dp" <dp@.discussions.microsoft.com> wrote in message
news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
> 1) For performance of BLOB only data that will have at least 100 KB per
> BLOB,
> what is the best network packet size setting? The resource kit indicates
> that
> it is 8080. Is that correct, or is it a typo that should say 8192?
> 2) Does the client connection have to match the network packet size
> setting
> for it to be used?
>
>
|||Your reply make me quite confused. The following are from Chapter 11 - Using
BLOBs in SQL Server 2000 Resource Kit. url:
http://www.microsoft.com/technet/pro...rt3/c1161.mspx
If your database application sends or receives large amounts of BLOB data,
consider changing the packet size of the chunks of data that transfer
requests and results between clients and servers. To change or set the packet
size, use the network packet size option in Configuration Options. A packet
size larger than the 4,096-byte default may improve efficiency by lowering
the network reads and writes. A packet size of 8,080 bytes is best for
performance in SQL Server 2000 and SQL Server 7.0.
So which configuration should I follow? From your reply, tha statement above
is not quite correct, isn't it?
Anyway, would you (or someone) mind give me some direction on how to
configure a sql server 2000 which only hold blob data for best performance?
thanks much,
dp
m
"Matt Neerincx [MS]" wrote:
> In general the network packet size setting should be left alone, it is not
> going to give you much one way or another in terms of performance.
> The main reason I say this is everything has to go across TCP-IP, which has
> a limit of ~1430 bytes per packet. So the TDS packet size is not the
> limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
> the end.
> Another problem with cranking it up is that it causes SQL Server to also
> chew up more memory holding larger packets, reducing scalability. So 4K
> default is good. Network packet size > 8000 bytes should be avoided for
> server scalability reasons, this causes SQL to allocate packets out of
> mem2leave area instead of normal buffer pool.
> Matt Neerincx [MSFT]
> This posting is provided "AS IS", with no warranties, and confers no rights.
> Please do not send email directly to this alias. This alias is for newsgroup
> purposes only.
> "dp" <dp@.discussions.microsoft.com> wrote in message
> news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
>
>
blob and network packet size
1) For performance of BLOB only data that will have at least 100 KB per BLOB
,
what is the best network packet size setting? The resource kit indicates tha
t
it is 8080. Is that correct, or is it a typo that should say 8192?
2) Does the client connection have to match the network packet size setting
for it to be used?In general the network packet size setting should be left alone, it is not
going to give you much one way or another in terms of performance.
The main reason I say this is everything has to go across TCP-IP, which has
a limit of ~1430 bytes per packet. So the TDS packet size is not the
limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
the end.
Another problem with cranking it up is that it causes SQL Server to also
chew up more memory holding larger packets, reducing scalability. So 4K
default is good. Network packet size > 8000 bytes should be avoided for
server scalability reasons, this causes SQL to allocate packets out of
mem2leave area instead of normal buffer pool.
Matt Neerincx [MSFT]
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"dp" <dp@.discussions.microsoft.com> wrote in message
news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
> 1) For performance of BLOB only data that will have at least 100 KB per
> BLOB,
> what is the best network packet size setting? The resource kit indicates
> that
> it is 8080. Is that correct, or is it a typo that should say 8192?
> 2) Does the client connection have to match the network packet size
> setting
> for it to be used?
>
>|||Your reply make me quite confused. The following are from Chapter 11 - Using
BLOBs in SQL Server 2000 Resource Kit. url:
[url]http://www.microsoft.com/technet/prodtechnol/sql/2000/reskit/part3/c1161.mspx[/url
]
If your database application sends or receives large amounts of BLOB data,
consider changing the packet size of the chunks of data that transfer
requests and results between clients and servers. To change or set the packe
t
size, use the network packet size option in Configuration Options. A packet
size larger than the 4,096-byte default may improve efficiency by lowering
the network reads and writes. A packet size of 8,080 bytes is best for
performance in SQL Server 2000 and SQL Server 7.0.
So which configuration should I follow? From your reply, tha statement above
is not quite correct, isn't it?
Anyway, would you (or someone) mind give me some direction on how to
configure a sql server 2000 which only hold blob data for best performance?
thanks much,
dp
--
m
"Matt Neerincx [MS]" wrote:
> In general the network packet size setting should be left alone, it is not
> going to give you much one way or another in terms of performance.
> The main reason I say this is everything has to go across TCP-IP, which ha
s
> a limit of ~1430 bytes per packet. So the TDS packet size is not the
> limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
> the end.
> Another problem with cranking it up is that it causes SQL Server to also
> chew up more memory holding larger packets, reducing scalability. So 4K
> default is good. Network packet size > 8000 bytes should be avoided for
> server scalability reasons, this causes SQL to allocate packets out of
> mem2leave area instead of normal buffer pool.
> Matt Neerincx [MSFT]
> This posting is provided "AS IS", with no warranties, and confers no right
s.
> Please do not send email directly to this alias. This alias is for newsgro
up
> purposes only.
> "dp" <dp@.discussions.microsoft.com> wrote in message
> news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
>
>
,
what is the best network packet size setting? The resource kit indicates tha
t
it is 8080. Is that correct, or is it a typo that should say 8192?
2) Does the client connection have to match the network packet size setting
for it to be used?In general the network packet size setting should be left alone, it is not
going to give you much one way or another in terms of performance.
The main reason I say this is everything has to go across TCP-IP, which has
a limit of ~1430 bytes per packet. So the TDS packet size is not the
limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
the end.
Another problem with cranking it up is that it causes SQL Server to also
chew up more memory holding larger packets, reducing scalability. So 4K
default is good. Network packet size > 8000 bytes should be avoided for
server scalability reasons, this causes SQL to allocate packets out of
mem2leave area instead of normal buffer pool.
Matt Neerincx [MSFT]
This posting is provided "AS IS", with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
"dp" <dp@.discussions.microsoft.com> wrote in message
news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
> 1) For performance of BLOB only data that will have at least 100 KB per
> BLOB,
> what is the best network packet size setting? The resource kit indicates
> that
> it is 8080. Is that correct, or is it a typo that should say 8192?
> 2) Does the client connection have to match the network packet size
> setting
> for it to be used?
>
>|||Your reply make me quite confused. The following are from Chapter 11 - Using
BLOBs in SQL Server 2000 Resource Kit. url:
[url]http://www.microsoft.com/technet/prodtechnol/sql/2000/reskit/part3/c1161.mspx[/url
]
If your database application sends or receives large amounts of BLOB data,
consider changing the packet size of the chunks of data that transfer
requests and results between clients and servers. To change or set the packe
t
size, use the network packet size option in Configuration Options. A packet
size larger than the 4,096-byte default may improve efficiency by lowering
the network reads and writes. A packet size of 8,080 bytes is best for
performance in SQL Server 2000 and SQL Server 7.0.
So which configuration should I follow? From your reply, tha statement above
is not quite correct, isn't it?
Anyway, would you (or someone) mind give me some direction on how to
configure a sql server 2000 which only hold blob data for best performance?
thanks much,
dp
--
m
"Matt Neerincx [MS]" wrote:
> In general the network packet size setting should be left alone, it is not
> going to give you much one way or another in terms of performance.
> The main reason I say this is everything has to go across TCP-IP, which ha
s
> a limit of ~1430 bytes per packet. So the TDS packet size is not the
> limiting factor. Everything is squeezed down into ~1430 byte TCP packet in
> the end.
> Another problem with cranking it up is that it causes SQL Server to also
> chew up more memory holding larger packets, reducing scalability. So 4K
> default is good. Network packet size > 8000 bytes should be avoided for
> server scalability reasons, this causes SQL to allocate packets out of
> mem2leave area instead of normal buffer pool.
> Matt Neerincx [MSFT]
> This posting is provided "AS IS", with no warranties, and confers no right
s.
> Please do not send email directly to this alias. This alias is for newsgro
up
> purposes only.
> "dp" <dp@.discussions.microsoft.com> wrote in message
> news:1DAAA61D-5512-45A1-83F4-BAD4EF1CDDB7@.microsoft.com...
>
>
Subscribe to:
Posts (Atom)