Aquí está el escenario. Quiero ser capaz de cambiar el final de los usuarios de conexiones de base de datos automáticamente en caso de que alguna vez tenemos que cambiar a nuestra copia de seguridad de SDE servidor. Mi primer pensamiento fue para configurar sde las conexiones con el servidor de copia de seguridad en las máquinas de los usuarios, a continuación, escribir un archivo por lotes que sería simplemente cambiar el nombre de las conexiones a los usuarios de conexiones estándar. Tengo la esperanza de encontrar una solución automatizada. Idealmente encontrar alguna manera de saber si una conexión no puede realizarse, a continuación, cambie a la alternativa de conexiones. Alguien ha implementado algo como esto? Cualquier ayuda la agradezco mucho.
Respuestas
¿Demasiados anuncios?
Creo que tendrás que configurar algunos de los principales de la base de datos de la agrupación, por lo que los dos servidores aparecen como uno solo. A continuación, en conectar a los clientes no (y no debe) saber en que server están conectando a, y se puede jugar con los extremos traseros tanto como te gusta.
Ahora, esto es sólo una solución ideal si su copia de seguridad es para disponibilidad - o si usted quiere tomar las máquinas fuera de línea y en línea. Si sus copias de seguridad para la integridad de los datos (recuperación de la ups-I-borrado--todo), luego la agrupación no funciona, como el accidental elimina automáticamente se propagan a todos los nodos.
No podría usted hacer algún tipo de reenvío de puertos? Yo no soy de la red de hombre, por lo que no puede proporcionar un montón de detalles. Sé que hemos tenido un nombre de servidor de base de datos una vez que fue actualizado a partir de SQL Server 2005 a 2008 y terminó consiguiendo poner en un nuevo servidor con un nombre nuevo. Le pregunté a la dba si todavía podía conectar con el viejo nombre y me dijo que ellos habían establecido para que el nombre antiguo consiguió redirigido al nuevo nombre - forwarded. Básicamente esto suena como una recuperación de desastres problema - un servidor se cae, el DR servidor viene en transparente para sus usuarios. Tiene que haber una manera de hacer esto. Mira en el reenvío de las conexiones. ¿Tienes un sys admin de red o el tipo de mano que usted puede hablar?
Nos estamos quedando bajo este escenario ahora: dos servidores que ejecutan con un "virtual" del servidor en frente de ellos. Los usuarios de mapa de su conexión a la conexión virtual, el cual monitorea la principal y de copia de seguridad de la SDEs. Si el principal SDE falla, la conexión virtual recoge la copia de seguridad de SDE. Todo se logra con Oracle RAC tecnología.
Ahora el inconveniente: no hay conmutación por error transparente para el usuario. Si el principal SDE falla, el escritorio de los usuarios de la aplicación les dice que han perdido la conexión. Si se sale de la aplicación y reiniciar, el virtual puntos de conexión a la copia de seguridad de SDE en ese momento y los usuarios no tienen idea de que se están ejecutando en la copia de seguridad. Si no ha guardado sus ediciones, esos cambios se pierden. No es completamente transparente, pero menos doloroso y mucho más rápido, a continuación, tener que cambiar de conexiones de base de datos.
He hablado con Esri sobre este, y me ha dicho que el problema radica en el hecho de que los cursores para las sesiones de usuario se almacenan en la SDE que están conectados y no se replican a la copia de seguridad de SDE. La única manera de conseguir realmente una conmutación por error transparente es para desactivar la sesión de cursores, que al parecer viene con un decente rendimiento. Esri señaló que se tiene que sopesar los pros y los contras de este: tome un impacto en el rendimiento para un evento que (con suerte) nunca/rara vez se produce o sólo tiene el usuario de salir y volver a entrar.
Al menos así es como yo entiendo la situación. Soy un analista, no un DBA. Déjeme saber si usted tiene más preguntas.
