Ir al contenido principal

Migrar DTS packages entre servidores SQL Server

Supongamos que en un servidor de SQLServer( 70 o 2000 ) llamado ServidorA tenemos almacenado un package (en Local Packages ) de nombre "cargaTXT" que lo que hace es cargar "c:\datos.txt" a la tabla "base.dbo.tabla"


Y lo que se quiere lograr es migrar cargaTXT a otro servidor de SQLServer ( 2000 en este caso ) llamado ServidorB


La idea general sería copiar el package cargaTXT al ServidorB y luego cambiar las propiedades de conexión y demás para que las conexiones apunten a ServidorB, etc.


Por simplicidad vamos a suponer que la ruta donde se encuentre el archivo txt ( el origen de este package ) no cambia, es decir está en c:\datos.txt, sino fuera así también habría que cambiar las propiedades de este "conexión", por ejemplo a "d:\datos.txt" ).


Para copiar el package al servidorB se puede tanto hacer cualquiera de las siguientes 2 opciones:

A) Abrir cargaTXT en ServdiorA y hacer un SaveAs del package al ServidorB

B) Copiarlo desde el diccionario de datos( sin miedo, está documentado por microsoft )

insert into msdb.dbo.sysdtspackages ([name], [id], [versionid], [description], [categoryid], [createdate], [owner], [packagedata], [owner_sid])select [name], [id], [versionid], [description], [categoryid], [createdate], [owner], [packagedata], [owner_sid]from servidorA.msdb.dbo.sysdtspackageswhere name = 'cargaTXT'


Para ajustar las conexiones a la base que utiliza el package se distinguen 2 casos:


CASO1: Los nombres de la base de datos y la tabla son IGUALES en el servidor origen y destino En este caso lo único que hay que hacer es abrir el package en modo diseño, cambiar las propiedades de la conexión para que apunten al servidorB y salvar los cambios (cuando aparezca el cuadro de diálogo para borrar las transformaciones asociadas decirle que no se quiere borrar nada)


CASO2: Los nombres de la base de datos y/o la tabla son DISTINTAS en el servidor origen y destinoAcá viene la dificultad, pero bien, la solución es:

abrir el package en modo diseño y editar el package pero en modo desconectado, o sea ejecutar el comando "Disconnected Edit" que permite modificar el package sin hacer ninguna verificación sobre si las propiedades de conexión son correctas, la tabla existe, etc (peligroso pero es lo que hay).


Luego..- En el objeto conexión ( conexión a sqlserver ) las propiedades que hay que cambiar son:

- Data Source : De ServidorA ServidorB Data Source Name : De ServidorA

- ServidorBServerName : De ServidorA ServidorB- En el objeto task (o sea la tarea que se encarga realmente de copiar)

- cambiar DestinationObjectName : De "base.dbo.tabla" a lo que corresponda ahora

Comentarios

Entradas populares de este blog

O365 - Forms - Transferir la propiedad de un formulario

Fuente :  https://support.office.com/es-es/article/transferir-la-propiedad-de-un-formulario-921a6361-a4e5-44ea-bce9-c4ed63aa54b4 Si ha creado una encuesta, una prueba o un sondeo, puede moverlos fácilmente a un grupo para que todos los miembros del grupo se conviertan en propietarios de ese formulario. Transferir el formulario a un grupo En el explorador Web, vaya a  Forms.Office.com . En la pestaña  mis formularios  , busque el formulario que desea transferir. Haga clic en  más acciones de formulario    y, a continuación, seleccione  mover . Nota:  Solo puede mover el formulario si es el propietario de ese formulario. No puede transferir la propiedad de un formulario que está compartido con usted. Seleccione el grupo al que desea transferir el formulario y, a continuación, haga clic en  mover . El formulario que ha movido aparecerá en la pestaña  formularios de grupo  . ¿Qué ocurre con el libr...

Event ID 8031 The uri endpoint information may be stale

An exception occurred while updating addresses for connected app {6783ce5e-c88h-4021-8d5b-12614875cbfa_b79f19ab-1d40-4824-9911-3466cf8b070a}. The uri endpoint information may be stale. System.InvalidOperationException: The requested application could not be found.    at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.ProcessCommonExceptions(Uri endpointAddress, String operationName, Exception ex, SPServiceLoadBalancerContext context)    at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.ExecuteOnChannel(String operationName, CodeBlock codeBlock)    at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.GetEndPoints(Guid serviceId)    at Microsoft.SharePoint.SPConnectedServiceApplicationAddressesRefreshJob.Execute(Guid targetInstanceId) After de-commissioning some SharePoint servers, you might notice the above error on other WFEs /Application server’s event viewer . It appears that the SharePoint still has a reference...

SP 2013–2010 - An exception occurred in AD claim provider when calling SPClaimProvider.FillResolve(): Thread was being aborted

  Error: An exception occurred in AD claim provider when calling SPClaimProvider.FillResolve(): Thread was being aborted..   Resolution In order to determine the best MaxConcurrentApi value for your servers, several data points must be brought together and calculated by using a formula. The data to be used to estimate MaxConcurrentApi is as follows: Net Logon semaphore acquires Net Logon semaphore time-outs Net Logon average semaphore hold time Duration of the performance logging that is completed, measured in seconds After the data is obtained, the following formula can be used to estimate the correct MaxConcurrentApi value: ( semaphore_acquires + semaphore_time-outs ) * average_semaphore_hold_time / time_collection_length = < New_MaxConcurrentApi_setting After you collect the Net Logon performance data from when the server was under authentication load, you should determine the duration of the data-collecting process by looking at the Line View beginning and en...