Sql-server – How to copy specific tables into one SQL Server Table into a separate table automatically

I haven't used it before but there is an object in SSIS called Transfer SQL Server Objects. It has an option to copy data or not and you can select copy all objects or just specific types of objects, permissions etc.

You could also look into doing replication but blocking the data portion of it. In fact if you set up a snapshot replication that just pushed schema for each of your servers you could potentially have an automated process to do the push.

I think the SSIS option is probably your best bet though.

As I understand it, you want to monitor network traffic in between a web application hosted in IIS and SQL Server, both of which are running on the same server. This is going to be complicated by a few things:

• Most packet sniffers don't support monitoring traffic over a loopback interface like you are using if your web app connects to SQL Server on localhost or 127.0.0.1. Microsoft's Message Analyzer is an exception, but it is beta, doesn't appear to have much in the way of visualisation or analysis tools, and doesn't appear to be exportable to a format that network sniffers with decent throughput analysis tools can read.

• The traffic won't be analysable if you're using shared memory or local named pipes instead of TCP to connect to SQL Server.

• Wireshark also doesn't know what process IDs the packets were sent or received from, which could be a problem depending on your filtering requirements.

Wireshark has good visualisation and analysis tools compared to other network sniffers, though, including throughput graphs and statistics on conversations. What I've done in the past where I needed to filter on process ID was to capture with nmcap or Network Monitor, and then import to Wireshark to do the analysis. None of these will work if you're connecting over the loopback, though, or connecting via local named pipes or shared memory.

I agree with the advice to just get a 1 gbps switch if possible, even if you don't need it today. If you don't need it now, you might later, and it's easier to upgrade in a planned manner while your app is performing well rather than in an emergency where the network is saturated.

A few times a year I encounter a web app that is managing to saturate a 100mbps link to a database server, so I don't think this is an outlandish scenario. Many of the applications I support are not well designed, though, so this may never be a problem for you if you're using common-sense design principles like not retrieving giant results on every page view.