我在哪里创建SSIS目录
我有一个可能非常基本的问题。 如果我有一个SSIS软件包，其中有传输数据库任务将数据库从具有SQL Server 2016实例的服务器传输到具有实例SQL Server 2019的另一台服务器，
- 我是否需要在每个服务器上为每个实例安装SSIS？
- 我需要在源和目标实例中创建目录吗？还是仅在源实例上创建它足以创建它？还是必须在目的地？
谢谢！
I have a question that might be very basic.
If I have a SSIS package where I have the Transfer DB task to transfer a database from a server with a SQL Server 2016 Instance to another server with an Instance SQL Server 2019,
- Do I need to install SSIS for each instance on each server?
- Do I need to create the catalog in both source and destination instances? or is it enough to create it only on the source instance? or it has to be on the destination?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
SSIS是一种ETL工具，因此您将在服务器上安装SSIS，要指定为ETL服务器。该服务器所在的位置有几种常见的方案。
独立的ETL服务器，它既不是您正在从事的当前ETL作业的源或目标。
单独的ETL服务器是与当前源或当前目的地同一服务器上的实例。
您当前的源服务器
您当前的目标服务器
您必须确定哪种情况在您的环境中最有意义。在我目前的演出中，我们有一些专用的ETL盒子，我们按主题将工作重点。
以前，我在一个ETL进口数据的环境中工作，而90％的人在一台服务器上进行操纵。在这种情况下，将所有SSIS所有东西全部放在目标服务器上是有意义的，这样我们就不会通过电线移动数据以将其转换。
随着情况的发展，您使用越来越多的SSI，您可能会改变主意。没关系。改变这并不是一件琐碎的事情，但是一旦您将SSIS落在某个地方，也不会将其放在石头上。
SSIS is an ETL tool, so you'll install SSIS on the server that you want to designate as your ETL server. There are several common scenarios for where that server is located.
A stand-alone ETL server, which is neither the source nor the target of the current ETL job you're working on.
A separate ETL server that is an instance on the same server as either your current source or your current destination.
Your current source server
Your current destination server
You'll have to decide which scenario makes the most sense in your environment. At my current gig, we have a few dedicated ETL boxes, and we cluster the jobs on them by subject matter.
Previously, I worked in an environment where 10% of the ETL was importing data and 90% was manipulating it on one server. In that situation, it made sense to have the SSIS stuff all on the destination server so that we weren't moving data over the wire to transform it.
As your situation evolves, and you use more and more SSIS, you might change your mind. That's fine. It's not a trivial thing to change, but it's also not set in stone once you plunk SSIS down someplace.