Trasvase de registros?????

Hola.

Llama la atención la disponibilidad que se te requiere teniendo encuenta el
licenciamiento que te ofrecen. Como lo que permite realizar estas cosas de
forma automática no están a tu alcance, como el clustering o la replicación
transaccional, que requiere de una licencia superior, o el mirroring (nuevo
en SQL SERVER 2005), tienes que aplicar el ingenio y poner mucho de tu
parte.

Y aquí se te abre un amplio abanico de posibilidades. La que yo te
recomiendo es la de tener una buena política de backup, la cual pase por
verificar dichos backups restaurándolos en otro servidor. Ese otro servidor
sería tu servidor de respaldo. Cuanto más frecuentes sean esos backups,
menor pérdida de información tendrás en caso de desastre. Los backups no
tienen que ser completos, los más frecuentes (cada pocos minutos) pueden ser
backups del log. Automatízalo con unos jobs y ya tienes tu servidor de
StandBy.

Sí, manual y artesanal, pero... Un servidor que no está en producción, si no
que sólo es para desarrollo no parece que deba ser fuertemente restaurado,
entiendo que por eso no se incluyen en la versión MSDE este tipo de
funcionalidades.

qwalgrande

"De lo que ves créete la mitad, de lo que no ves no te creas nada"
V. del V.


"Agalvan" escribió en el mensaje
news:%

Jorge Martinez wrote:

Uff, pues no se si seria la mejor solucion pero si tienes que implementar
lo
que comentas yo miraria por una Replicacion del tipo SnapShot, sino
tendrias
que implementarte tu mismo mediante trabajos el trasvase de registros.

Gracias Jorge. No sé si estoy equivocado (probablemente sí...). Las
replicaciones SnapShot son lo mismo que las duplicaciones de instantáneas,
no?
Ten en cuenta que necesitaría hacer una duplicación cada pocos minutos
(2-3 minutos), y eso no ralentazaría al servidor? La base de datos se
"limpia cada año". A finales de año podría tener un tamaño de unos 200-300
MB (según estimaciones). Calculo que en hora punta de trabajo puede haber
unos 10 terminales accediendo continuamente al servidor de SQL, (el 99% de
las operaciones serían de inserciones de registros en la tabla). Como
solemos decir por aquí... "estoy mas perdido que el barco del arroz".

Muchas gracias de nuevo por tomarte la molestia.
Un saludo a

A. Galvan.

qwalgrande wrote:

Hola.

Llama la atención la disponibilidad que se te requiere teniendo encuenta el
licenciamiento que te ofrecen. Como lo que permite realizar estas cosas de
forma automática no están a tu alcance, como el clustering o la replicación
transaccional, que requiere de una licencia superior, o el mirroring (nuevo
en SQL SERVER 2005), tienes que aplicar el ingenio y poner mucho de tu
parte.

Y aquí se te abre un amplio abanico de posibilidades. La que yo te
recomiendo es la de tener una buena política de backup, la cual pase por
verificar dichos backups restaurándolos en otro servidor. Ese otro servidor
sería tu servidor de respaldo. Cuanto más frecuentes sean esos backups,
menor pérdida de información tendrás en caso de desastre. Los backups no
tienen que ser completos, los más frecuentes (cada pocos minutos) pueden ser
backups del log. Automatízalo con unos jobs y ya tienes tu servidor de
StandBy.

Sí, manual y artesanal, pero... Un servidor que no está en producción, si no
que sólo es para desarrollo no parece que deba ser fuertemente restaurado,
entiendo que por eso no se incluyen en la versión MSDE este tipo de
funcionalidades.

Gracias de nuevo por responderme.
He intentado una duplicación de instantáneas y parece que me funciona
correctamente y no sobrecarga demasiado el servidor. Pero se me plantea
otro problema (OTRO MAS!!!). Resulta que en la configuración de dicha
duplicación, sólo he puesto dos tablas (las que tienen más movimientos de
inserción), pero cuando se "copian" al servidor de respaldo, me ocurren 2
cosas.
1) Me cambia el propietario. Pasa de ser dbo.NombreTabla a
invitado.NombreTabla. Supongo que será pq conecto como invitado
(logico...). ¿Cómo puedo hacer para que se copie con el nombre del
propietario de la tabla?
2) En las tablas que copia, no me respeta los valores por defecto de los
campos. Yo tengo puesto, por ejemplo, para los valores int, money, bit,
etc, que por defecto tome el valor "0" (por necesidades del programa .NET
que gestiona esa base de datos), pero en la copia en el servidor de
respaldo, desaparecen esos valores.

¿Alguna idea?

No sabéis cuanto agradezco vuestra colaboración y ayuda.
Un saludo.

A. Galván.

Hola.

No soy ningún experto en replicación snapshot, pero vamos a ver si puedo
ayudarte.

Los problemas que me comentas (diferente owner y no tener en cuenta los
default) ponen de manifiesto que la estructura de las tablas del suscriptor
no son idénticas a las del publicador. En la snapshot inicial se incluye un
fichero de esquema. Es posible que este fichero no sea todo lo bueno que
debiera. Te aconsejo que tomes un script de las tablas del publicador, le
elimines los posibles identities y lo ejecutes en el suscriptor. Así te
aseguras que los valores por defecto están en tu tabla de destino y que el
propietario de los objetos es el que tú deseas (porque creas tú mismo, y no
la snapshot, las tablas).

Luego, en la configuración de la publicación no incluyas el esquema, sólo
incluyes los datos.

Espero que así tengas un mejor resultado. Suerte.

qwalgrande

"De lo que ves créete la mitad, de lo que no ves no te creas nada"
V. del V.


"A. Galvan" escribió en el mensaje
news:%

qwalgrande wrote:

Hola.

Llama la atención la disponibilidad que se te requiere teniendo encuenta
el
licenciamiento que te ofrecen. Como lo que permite realizar estas cosas
de
forma automática no están a tu alcance, como el clustering o la
replicación
transaccional, que requiere de una licencia superior, o el mirroring
(nuevo
en SQL SERVER 2005), tienes que aplicar el ingenio y poner mucho de tu
parte.

Y aquí se te abre un amplio abanico de posibilidades. La que yo te
recomiendo es la de tener una buena política de backup, la cual pase por
verificar dichos backups restaurándolos en otro servidor. Ese otro
servidor
sería tu servidor de respaldo. Cuanto más frecuentes sean esos backups,
menor pérdida de información tendrás en caso de desastre. Los backups no
tienen que ser completos, los más frecuentes (cada pocos minutos) pueden
ser
backups del log. Automatízalo con unos jobs y ya tienes tu servidor de
StandBy.

Sí, manual y artesanal, pero... Un servidor que no está en producción, si
no
que sólo es para desarrollo no parece que deba ser fuertemente
restaurado,
entiendo que por eso no se incluyen en la versión MSDE este tipo de
funcionalidades.

Gracias de nuevo por responderme.
He intentado una duplicación de instantáneas y parece que me funciona
correctamente y no sobrecarga demasiado el servidor. Pero se me plantea
otro problema (OTRO MAS!!!). Resulta que en la configuración de dicha
duplicación, sólo he puesto dos tablas (las que tienen más movimientos de
inserción), pero cuando se "copian" al servidor de respaldo, me ocurren 2
cosas.
1) Me cambia el propietario. Pasa de ser dbo.NombreTabla a
invitado.NombreTabla. Supongo que será pq conecto como invitado
(logico...). ¿Cómo puedo hacer para que se copie con el nombre del
propietario de la tabla?
2) En las tablas que copia, no me respeta los valores por defecto de los
campos. Yo tengo puesto, por ejemplo, para los valores int, money, bit,
etc, que por defecto tome el valor "0" (por necesidades del programa .NET
que gestiona esa base de datos), pero en la copia en el servidor de
respaldo, desaparecen esos valores.

¿Alguna idea?

No sabéis cuanto agradezco vuestra colaboración y ayuda.
Un saludo.

A. Galván.

Problema resuelto.
Muchísimas gracias a los que habéis leído los mensajes y
especialmente a aquellos que me habéis contestado.

Un saludo.

Hola.

No soy ningún experto en replicación snapshot, pero vamos a ver si puedo
ayudarte.

Los problemas que me comentas (diferente owner y no tener en cuenta los
default) ponen de manifiesto que la estructura de las tablas del suscriptor
no son idénticas a las del publicador. En la snapshot inicial se incluye un
fichero de esquema. Es posible que este fichero no sea todo lo bueno que
debiera. Te aconsejo que tomes un script de las tablas del publicador, le
elimines los posibles identities y lo ejecutes en el suscriptor. Así te
aseguras que los valores por defecto están en tu tabla de destino y que el
propietario de los objetos es el que tú deseas (porque creas tú mismo, y no
la snapshot, las tablas).

Luego, en la configuración de la publicación no incluyas el esquema, sólo
incluyes los datos.

Espero que así tengas un mejor resultado. Suerte.