Hopefully there's some SQL architect gurus reading...
I have a couple servers where none of the Net Protocols are enabled. I'm
not sure how they ended up that way. Usually we have at (default?) for
TCP/IP then Named Pipes, we have no need for other net protocols. However,
our apps and services are still able make SQL connections.
I'm verifying this via the SQL Network Client Utility. What else can
determine or configure Network Libraries? And what impacts might this have
on connectivity with no protocols enabled?
Thanks,
ThuanAre you saying that you use Client Network Utility on the server machine and
in the Client Network
Utility on the server machine not netlibs are enabled? You should be using S
erver Network Utility on
the server machine.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Thuan" <Thuan@.discussions.microsoft.com> wrote in message
news:1B4C234A-B5C8-474C-92A5-DB071BB530D3@.microsoft.com...
> Hopefully there's some SQL architect gurus reading...
> I have a couple servers where none of the Net Protocols are enabled. I'm
> not sure how they ended up that way. Usually we have at (default?) for
> TCP/IP then Named Pipes, we have no need for other net protocols. However
,
> our apps and services are still able make SQL connections.
> I'm verifying this via the SQL Network Client Utility. What else can
> determine or configure Network Libraries? And what impacts might this hav
e
> on connectivity with no protocols enabled?
> Thanks,
> Thuan|||Hi
If this is an MSDE instance then network access is not enabled by default on
the server. You should check out the Server Network Utility to see if
clients can connect and on each client check the Client Network Utility.
Enabling the protocols in the Client Network Utility will only affect the
client applications on the server.
John
"Thuan" <Thuan@.discussions.microsoft.com> wrote in message
news:1B4C234A-B5C8-474C-92A5-DB071BB530D3@.microsoft.com...
> Hopefully there's some SQL architect gurus reading...
> I have a couple servers where none of the Net Protocols are enabled. I'm
> not sure how they ended up that way. Usually we have at (default?) for
> TCP/IP then Named Pipes, we have no need for other net protocols.
> However,
> our apps and services are still able make SQL connections.
> I'm verifying this via the SQL Network Client Utility. What else can
> determine or configure Network Libraries? And what impacts might this
> have
> on connectivity with no protocols enabled?
> Thanks,
> Thuan
Showing posts with label reading. Show all posts
Showing posts with label reading. Show all posts
Monday, March 26, 2012
Net Protocols - what if none are enabled?
Hopefully there's some SQL architect gurus reading...
I have a couple servers where none of the Net Protocols are enabled. I'm
not sure how they ended up that way. Usually we have at (default?) for
TCP/IP then Named Pipes, we have no need for other net protocols. However,
our apps and services are still able make SQL connections.
I'm verifying this via the SQL Network Client Utility. What else can
determine or configure Network Libraries? And what impacts might this have
on connectivity with no protocols enabled?
Thanks,
ThuanAre you saying that you use Client Network Utility on the server machine and in the Client Network
Utility on the server machine not netlibs are enabled? You should be using Server Network Utility on
the server machine.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Thuan" <Thuan@.discussions.microsoft.com> wrote in message
news:1B4C234A-B5C8-474C-92A5-DB071BB530D3@.microsoft.com...
> Hopefully there's some SQL architect gurus reading...
> I have a couple servers where none of the Net Protocols are enabled. I'm
> not sure how they ended up that way. Usually we have at (default?) for
> TCP/IP then Named Pipes, we have no need for other net protocols. However,
> our apps and services are still able make SQL connections.
> I'm verifying this via the SQL Network Client Utility. What else can
> determine or configure Network Libraries? And what impacts might this have
> on connectivity with no protocols enabled?
> Thanks,
> Thuan|||Hi
If this is an MSDE instance then network access is not enabled by default on
the server. You should check out the Server Network Utility to see if
clients can connect and on each client check the Client Network Utility.
Enabling the protocols in the Client Network Utility will only affect the
client applications on the server.
John
"Thuan" <Thuan@.discussions.microsoft.com> wrote in message
news:1B4C234A-B5C8-474C-92A5-DB071BB530D3@.microsoft.com...
> Hopefully there's some SQL architect gurus reading...
> I have a couple servers where none of the Net Protocols are enabled. I'm
> not sure how they ended up that way. Usually we have at (default?) for
> TCP/IP then Named Pipes, we have no need for other net protocols.
> However,
> our apps and services are still able make SQL connections.
> I'm verifying this via the SQL Network Client Utility. What else can
> determine or configure Network Libraries? And what impacts might this
> have
> on connectivity with no protocols enabled?
> Thanks,
> Thuansql
I have a couple servers where none of the Net Protocols are enabled. I'm
not sure how they ended up that way. Usually we have at (default?) for
TCP/IP then Named Pipes, we have no need for other net protocols. However,
our apps and services are still able make SQL connections.
I'm verifying this via the SQL Network Client Utility. What else can
determine or configure Network Libraries? And what impacts might this have
on connectivity with no protocols enabled?
Thanks,
ThuanAre you saying that you use Client Network Utility on the server machine and in the Client Network
Utility on the server machine not netlibs are enabled? You should be using Server Network Utility on
the server machine.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Thuan" <Thuan@.discussions.microsoft.com> wrote in message
news:1B4C234A-B5C8-474C-92A5-DB071BB530D3@.microsoft.com...
> Hopefully there's some SQL architect gurus reading...
> I have a couple servers where none of the Net Protocols are enabled. I'm
> not sure how they ended up that way. Usually we have at (default?) for
> TCP/IP then Named Pipes, we have no need for other net protocols. However,
> our apps and services are still able make SQL connections.
> I'm verifying this via the SQL Network Client Utility. What else can
> determine or configure Network Libraries? And what impacts might this have
> on connectivity with no protocols enabled?
> Thanks,
> Thuan|||Hi
If this is an MSDE instance then network access is not enabled by default on
the server. You should check out the Server Network Utility to see if
clients can connect and on each client check the Client Network Utility.
Enabling the protocols in the Client Network Utility will only affect the
client applications on the server.
John
"Thuan" <Thuan@.discussions.microsoft.com> wrote in message
news:1B4C234A-B5C8-474C-92A5-DB071BB530D3@.microsoft.com...
> Hopefully there's some SQL architect gurus reading...
> I have a couple servers where none of the Net Protocols are enabled. I'm
> not sure how they ended up that way. Usually we have at (default?) for
> TCP/IP then Named Pipes, we have no need for other net protocols.
> However,
> our apps and services are still able make SQL connections.
> I'm verifying this via the SQL Network Client Utility. What else can
> determine or configure Network Libraries? And what impacts might this
> have
> on connectivity with no protocols enabled?
> Thanks,
> Thuansql
Friday, March 23, 2012
Nested Views: How Inefficient?
I've been reading around that nested views can be quite inefficient because:
a) Using views in general involves some overheads (getting info from system tables etc.)
b) The optimiser doesn't do anything intelligent with them but just mixes all the joins from each of the nested views into one big, nasty join
If the only way to get the results I need involves writing this "big, nasty" join anyway, does it matter that I'm not putting it directly into a single view, but breaking it into components so that I can also access parts of the join for other purposes?
If the queries process lots of data, are the system overheads really that noticeable?
THANX!,
Angeloslook into udfs and see if some views can be converted into functions.|||look into udfs and see if some views can be converted into functions.
example, please|||Thanks for the tip. I think I see the point.
This would be faster because each function would perform its join seperately, and only the results would be joined to eachother, right?
Or is it rather a matter of system overheads being reduced?
All the best,
Angelos|||you got it, and overhead will be reduced because of that.
example? of what?|||you got it, and overhead will be reduced because of that.
example? of what?
thanks!
I think the example was requested of *me*...
I'm just experimenting now, so don't have a concrete example yet...
Basically, I'm trying to get my principles correct before choosing a method to use. A main concern is code maintainability. Nested views could easily be avoided by repeating code. But building simpler views and then composing them into more complicated ones allows subsequent use of the simpler ones independently whenever they are sufficient.|||no, the example was requested of ms_sql_dba
an example of a view that can be converted to a udf|||Functions are precompiled, while views are not. Functions are generally more efficient because of that. In your case, however, some experimentation may be required, because it also means that the entire function must be processed before joining it to your other functions/views/tables. It's possible that if you were using views the server would combine all the view and table references to come up with the most efficient plan for that combination. You would suffer some overhead cost in devising the query plan, but you might avoid needless or redundant joins and calculations that are not required in your final dataset.
a) Using views in general involves some overheads (getting info from system tables etc.)
b) The optimiser doesn't do anything intelligent with them but just mixes all the joins from each of the nested views into one big, nasty join
If the only way to get the results I need involves writing this "big, nasty" join anyway, does it matter that I'm not putting it directly into a single view, but breaking it into components so that I can also access parts of the join for other purposes?
If the queries process lots of data, are the system overheads really that noticeable?
THANX!,
Angeloslook into udfs and see if some views can be converted into functions.|||look into udfs and see if some views can be converted into functions.
example, please|||Thanks for the tip. I think I see the point.
This would be faster because each function would perform its join seperately, and only the results would be joined to eachother, right?
Or is it rather a matter of system overheads being reduced?
All the best,
Angelos|||you got it, and overhead will be reduced because of that.
example? of what?|||you got it, and overhead will be reduced because of that.
example? of what?
thanks!
I think the example was requested of *me*...
I'm just experimenting now, so don't have a concrete example yet...
Basically, I'm trying to get my principles correct before choosing a method to use. A main concern is code maintainability. Nested views could easily be avoided by repeating code. But building simpler views and then composing them into more complicated ones allows subsequent use of the simpler ones independently whenever they are sufficient.|||no, the example was requested of ms_sql_dba
an example of a view that can be converted to a udf|||Functions are precompiled, while views are not. Functions are generally more efficient because of that. In your case, however, some experimentation may be required, because it also means that the entire function must be processed before joining it to your other functions/views/tables. It's possible that if you were using views the server would combine all the view and table references to come up with the most efficient plan for that combination. You would suffer some overhead cost in devising the query plan, but you might avoid needless or redundant joins and calculations that are not required in your final dataset.
Subscribe to:
Posts (Atom)