Hola Andres
EL trafico por defecto de SQL server es del tipo Tabular Data Stream, TDS, propietario Sybase-Microsoft. Como tal debe ser encauzado por puertos TCP, el por defecto es el 1433, etc. El tema es que hay que abrir estos puertos de ambos lados para que funcione, pero un escaneo de puertos puede enseguida revelar que de tu lado está un SQL expuesto, no es para nada buena idea. Un mejor approach es justamente encapsular este tráfico utilizando una red privada virtual VPN. El trafico TDS está bastante optimizado si lo comparás con otro tipo de tráfico como XML, por lo que para una latencia y velocidad de transferencia determinada, el TDS te puede dar la mejor medida de performance. Sin embargo, como vos decís que es un tráfico entre servidores, pero no comentás bien qué tipo de servidores, podemos asumir dos escenarios: 1. Es entre 2 servidores SQL Server (en este caso, por definición, tendrías que usar replicación porque la solución está pre-armada). 2. Es entre un servidor de aplicaciones y un servidor SQL Server Suponiendo que sea 1, entonces tendríamos que SQL Enterprise permite replicar entre servidores 3 modelos distintos, desde copia rígida (estática) a replicación de mezcla (merge). En este escenario, las aplicaciones se conectan con el SQL server local, el cual está replicado por internet con otro servidor lejano. La interrupción del vinculo de internet no implica caída de servicio de datos, porque el local actúa como un caché. Sin embargo, como te dije, de un lado debe haber necesariamente un SQL Server Enterprise (extremo publicador). Del otro, podés montar hasta un MSDE/SQL Express, que son clientes o suscriptores de replicación. El tráfico por defecto sería TDS, pero lo bueno es que por internet lo podes hacer, y lo malo es que necesitás un certificado para SSL (tráfico HTTPS). En este caso, del lado servidor vos corres el wizard de replicación del lado servidor, armas tu publicación, y luego sobre esta armas la sincronización web. Solamente se permite tráfico HTTP estándar (sin certificado) si el extremo suscriptor es SQL Server Mobile, pero para versiones convencionales, necesitás implementar HTTPS. Podes conseguir free por 30 dias certificados SSL que te permiten probar todo sin necesidad de compra, fijate en FreeSSL, etc. Para la instantánea inicial, te conviene no hacerlo por replicación porque intentará cargar la base de datos replicada por internet y esto puede consumir mucho tiempo, transferí la base de datos primero y después replicala para que el tráfico subsiguiente de replicación lleve solamente los deltas (es decir, los cambios). Igual, si el negocio da, creo que un certificado SSL de raíz única sería una inversión más que aceptable para sacarte de encima varios problemas, porque esto está previsto en SQL Server, ya lo tenés a medio armar. Una opción adicional que debes evaluar es transferir el archivo de instantáneas por FTP para lograr la replicación del tipo pull-suscription, donde el iniciador de la replicación es el cliente (suscriptor). Adicionalmente, se *podría* ver la posibilidad de colocar el FTP en una carpeta alternativa a la que está por defecto (esto también está previsto), a fin de poder aplicarle compresión .CAB antes de transferirlo por la internet. Esto puede reducir significativamente el tiempo de transferencia, esta facilidad está prevista durante el armado del archivo de instantáneas y es especialmente indicado en redes muy lentas. Acordate de que el modelo de suscripción es pull-suscription, fijate si te sirve en books online, etc. Todo esto que te cuento es válido para SQL Server 2005. Para SQL Server 2000, leí que es más indicado hacerlo por FTP. Suponiendo que sea 2, si no tenés conexión con el back-end, no tenés datos. Asumiendo que vos aceptás esta condición, aquí quizás sería mejor utilizar un web service del lado del SQL server, y de este lado un cliente de web services. Esto te libera de la necesidad de estar abriendo puertos e instalando VPNs, pero tenés que implementar un IIS del lado del servidor SQL, etc. El servicio web es tráfico de texto, por lo tanto no es tan performante como el TDS, sobre todo si en el extremo servidor generás los datasets y los pasás como tales al extremo cliente. La ventaja aquí es que el dataset , si existe .NET de ambos lados, no necesita mucha transformación entre los dos extremos (casi nada diría). No se si ayudé o contribuí un poco más al desconcierto generalizado J. Por si te sirve de comparativa, sobre una conexión MUY mala de GPRS, la sincronización por merge replication a través de http estándar con un Windows Mobile anda muy, muy aceptable (base de datos de 67MB), siempre y cuando transfiera solamente los deltas. Estimo que entre dos servers a través de banda ancha (OJO que acá cuenta la velocidad de subida y no la de bajada) debe ser mucho más performante. Suerte! Carlos De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Andrés Guzmán O Enviado el: Viernes, 06 de Junio de 2008 12:21 p.m. Para: [email protected] Asunto: [puntonet] Consulta con connecion Amigos: Tengo una duda si quiero hacer una coneccion a base de datos entre dos servidores diferentes, que no estan en la misma LAN, uno esta aca en chile y otro esta en EEUU. Como se haria esto, y me imagino que la performance de la aplicación no sería de las mejores, me gustaria que me guiaran un poco antes de ponerme a desarrollar De antemano muchas gracias. Andrés Guzmán O. __________ Información de NOD32, revisión 2980 (20080328) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com
