Victor Hugo dos Santos escribió:
> Maestros,
>
> estoy leyendo y trabajando con snapshots en un servidor con BD
> oracle.. la idea es reducir el actual downtime actual (unas 8 horas)
> para un valor mas aceptable. ;-)
>
> hasta el momento va todo de maravilla, logramos que el downtime sea <
> a 15 minutos, con un procedimento para parar la BD, hacer el snapshot
> y volver a llevantar la BD.
>
> las dos preguntas que tengo, son:
>
> - he visto en varios documentos (LVM-howto incluso) indicando que se
> debe de eleminar el cuanto antes el snapshot por un tema de rendimento
> !!!la verdad es que entendi poco el porque.. no se supone que una vez
> creado una instantanea del FS, este ya no tiene ninguna relacion con
> el FS original ??? en que afecta el rendimento tener por ejemplo un
> SNAP de 600GB durante un mes ??? cual seria el TTL limite para un SNAP
> ???
Por en contrario, un snapshot _sí_ mantiene relación con el FS original, ya que
va
guardando los cambios a partir del momento en que "sacó la foto". Por eso es
que un
snapshot ocupa (físicamente) menos espacio que el FS original.
Por ejemplo, supón un FS como este, y supongamos que ABCD son bloques de tu
datafile:
Original
+-------+
| A |
+-------+
| B |
+-------+
| C |
+-------+
| D |
+-------+
| ... |
+-------+
Al crear el snapshot(t=0), nace vacío. Si no hay cambios en tu filesystem
original,
cualquier lectura del snapshot se entrega desde el FS original, por lo que no
ves mayor
impacto.
Original Snapshot
+-------+ +-------+
| A | | |
+-------+ +-------+
| B | | |
+-------+ +-------+
| C | | |
+-------+ +-------+
| D |
+-------+
| ... |
+-------+
Si, por ejemplo, cambias el bloque 'C', este debe copiarse al snapshot
_antes_de escribir
el bloque nuevo, lo cual te genera un impacto en la escritura.
Original Snapshot
+-------+ +-------+
| A | | |
+-------+ +-------+
| B | | |
+-------+ +-------+
| C | ---C---> | |
+-------+ +-------+
| D |
+-------+
| ... |
+-------+
Original Snapshot
+-------+ +-------+
| A | | C |
+-------+ +-------+
| B | | |
+-------+ +-------+
| C' | | |
+-------+ +-------+
| D |
+-------+
| ... |
+-------+
Si ahora lees tu snapshot, la lectura es:
orig(A), orig(B), _SNAP_(C), orig(D) ...,
lo cual (por lo general) significa estar buscando los datos en particiones y/o
discos
distintos
Extrapola para unos cuantos GB y hartos cambios, y le vas a encontrar sentido a
la
recomendación de deshacerte del snapshot tan pronto como cumpla su función.
> - mis conocimentos en oracle son bastante limitados, pero he visto en
> internet que existe un "backup mode" que permite que la BD continue
> operativa durante el processo de creaccion del SNAP... alguien tiene
> algun enlace que explique como puedo aplicar esto en un script que se
> ejecute en un CRON ???
>
> mmm. esto era.
>
> salu2 y atento
>
--
It is pitch black. You are likely to be eaten by a grue.
From [EMAIL PROTECTED] Fri Aug 10 18:30:12 2007
From: [EMAIL PROTECTED] (Julio Pacheco T.)
Date: Fri Aug 10 19:28:20 2007
Subject: LVM y Snapshots
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Victor Hugo dos Santos escribió:
> Maestros,
>
> estoy leyendo y trabajando con snapshots en un servidor con BD
> oracle.. la idea es reducir el actual downtime actual (unas 8 horas)
> para un valor mas aceptable. ;-)
>
> hasta el momento va todo de maravilla, logramos que el downtime sea <
> a 15 minutos, con un procedimento para parar la BD, hacer el snapshot
> y volver a llevantar la BD.
>
> las dos preguntas que tengo, son:
>
> - he visto en varios documentos (LVM-howto incluso) indicando que se
> debe de eleminar el cuanto antes el snapshot por un tema de rendimento
> !!!la verdad es que entendi poco el porque.. no se supone que una vez
> creado una instantanea del FS, este ya no tiene ninguna relacion con
> el FS original ??? en que afecta el rendimento tener por ejemplo un
> SNAP de 600GB durante un mes ??? cual seria el TTL limite para un SNAP
> ???
Por en contrario, un snapshot _sí_ mantiene relación con el FS original, ya que
va
guardando los cambios a partir del momento en que "sacó la foto". Por eso es
que un
snapshot ocupa (físicamente) menos espacio que el FS original.
Por ejemplo, supón un FS como este, y supongamos que ABCD son bloques de tu
datafile:
Original
+-------+
| A |
+-------+
| B |
+-------+
| C |
+-------+
| D |
+-------+
| ... |
+-------+
Al crear el snapshot(t=0), nace vacío. Si no hay cambios en tu filesystem
original,
cualquier lectura del snapshot se entrega desde el FS original, por lo que no
ves mayor
impacto.
Original Snapshot
+-------+ +-------+
| A | | |
+-------+ +-------+
| B | | |
+-------+ +-------+
| C | | |
+-------+ +-------+
| D |
+-------+
| ... |
+-------+
Si, por ejemplo, cambias el bloque 'C', este debe copiarse al snapshot
_antes_de escribir
el bloque nuevo, lo cual te genera un impacto en la escritura.
Original Snapshot
+-------+ +-------+
| A | | |
+-------+ +-------+
| B | | |
+-------+ +-------+
| C | ---C---> | |
+-------+ +-------+
| D |
+-------+
| ... |
+-------+
Original Snapshot
+-------+ +-------+
| A | | C |
+-------+ +-------+
| B | | |
+-------+ +-------+
| C' | | |
+-------+ +-------+
| D |
+-------+
| ... |
+-------+
Si ahora lees tu snapshot, la lectura es:
orig(A), orig(B), _SNAP_(C), orig(D) ...,
lo cual (por lo general) significa estar buscando los datos en particiones y/o
discos
distintos
Extrapola para unos cuantos GB y hartos cambios, y le vas a encontrar sentido a
la
recomendación de deshacerte del snapshot tan pronto como cumpla su función.
> - mis conocimentos en oracle son bastante limitados, pero he visto en
> internet que existe un "backup mode" que permite que la BD continue
> operativa durante el processo de creaccion del SNAP... alguien tiene
> algun enlace que explique como puedo aplicar esto en un script que se
> ejecute en un CRON ???
>
> mmm. esto era.
>
> salu2 y atento
>
--
It is pitch black. You are likely to be eaten by a grue.
From [EMAIL PROTECTED] Mon Aug 13 11:06:36 2007
From: [EMAIL PROTECTED] (jose sALAS)
Date: Mon Aug 13 11:08:44 2007
Subject: Problemas con correo y dns
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Estimados, luego de varios días Entel realizo el reverso...
y todo volvio a la normalidad.
Muchas Gracias a todos por el apoyo y la educación que me brindaron.
Lo importante fue el debate planteado, que cada cual lo tomará como es debido.
Atte.
J~S~
On 7/30/07, Horst H. von Brand <[EMAIL PROTECTED]> wrote:
> Miguel Oyarzo O. <[EMAIL PROTECTED]> wrote:
> > At 22:57 29-07-2007, Horst H. von Brand wrote:
> > >Miguel Oyarzo O. <[EMAIL PROTECTED]> wrote:
> > > > At 10:47 26-07-2007, Horst H. von Brand wrote:
>
> [...]
>
> > >Revisa lo que significa SHOULD en los RFC: Basicamente, significa que
> > >/tiene/ que estar salvo que hayan razones de peso en contra.
> > >
> > > > Bucar por "define:should" en goole
> > >
> > >No es relevante, los RFC tienen su propia definicion.
> >
> > yep, ahora bajaste un grado tu dura definicion anterior (debe).
> >
> > RFC 2119 no se contradice con la definicion general:
> > SHOULD = RECOMMENDED <> MUST = REQUIRED
>
> SHOULD es "haga esto; puede no hacerlo, pero solo si tiene razones de
> gran peso (que nos damos cuenta podrian existir), y bajo su exclusiva
> responsabilidad", MUST es "haga esto". Y "es que me da flojera poner los
> reversos como se debe" no es una razon de peso.
>
> [...]
>
> > La razon mas importante que di es la disminucion del SPAM.
>
> No lo disminuye mas que en una fraccion minima.
>
> > Rechazar hosts conmutados
>
> Hay listas de tales cosas. Y no todos son fuentes de correo basura.
>
> > y sin reverso reduce drasticamente ese lastre.
>
> No.
>
> > Ese es un caso particularmente valido e indiscutible.
>
> Recuerdan SPF? Se invento para eliminar spam, via "solo estas maquinas
> son origenes legitimos de correo para el dominio xyz", y al par de
> semanas habia mas spam "protegido" por SPF que correo legitimo.
>
> > > > > > Las conexiones conmutadas no necesitan reverso en lo absoluto! Los
> > > > > > usuarios de la casa no lo requieren.
> > >
> > > > >Claro que si lo requieren!
> > >
> > > > por que? ni idea a que cosa te refieres.. muy vago el comentario esta
> > > > vez.
> > >
> > >Conexiones conmutadas usan una IP ==> requieren nombres inscritos en DNS
> > >con sus respectivos reversos.
>
> > Falso,
>
> Que cosa? Usan IP? Porque solo si no usan IP, lo demas es falso...
> --
> Dr. Horst H. von Brand User #22616 counter.li.org
> Departamento de Informatica Fono: +56 32 2654431
> Universidad Tecnica Federico Santa Maria +56 32 2654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
>
