el caos del administrador corporativo :|

13/12/2004 - 02:56 por Paulino Padial | Informe spam
Bueno, solo queria escribiros para contaros algo que a estas horas me ha
dejado estupefacto, y es que, a pesar de que Miguel Egea ya me comento
esto que os voy a explicar ( que porsupuesto yo no le creí xDDD ).
Bueno, no es que desconfie de alguien tan sabio, solo que yo suelo
fiarme de las cosas que yo mismo compruebo ;)
Bueno al grano, tengo algo de tiempo porque estoy ayudando a mi novia a
hacer un howto de como configurar un servidor linux, y mientras estaba
tumbado leyendo algo de sql server.. en el capitulo de almacenamiento
interno, me dio el picazon de ver que hacia de verdad esta herramienta
cuando trabajaba con ella.

Me he quedado estupefacto cuando en algo tan simple como esto :

Creo una tabla que se llama "borrame", le añado dos campos uno identity
y un varchar.. ( el identity porspuesto lo declaro como la clave primaria ).
Abro el profiler que ya tenia puesto, y observo que hace mil
comprobaciones.. bueno , esto esta bastante bien. Aunque claro yo en el
Analizador de consultas me hubiera fallado al crear la tabla si ya
estubviese creada.. sin tanto rodeo.

Despues, meto registros en la tabla para que vaya creando numericos en
el campo identity. Cuando tengo unos 20 ( del 1 al 20 ), borro del 15 al
19, con lo que apartir de entonces, la secuencia de los numeros se ve
rota, ya que el identity sigue su curso sin rellenar los "huecos" "vacios".

Algo tan trivial como insertar datos en esa tabla de otra tabla que tb
tenia un campo con un valor identity, se me ocurre una forma que un
compañero me comento que hizo el en una de sus tablas ( yo ya sabia como
se hacia con el analizador de consultas( con el identity_insert ), pero
claro la forma que el me comentaba era muuuuuuuy sencilla y en 3 pasitos
). El hacia lo siguiente :
primero le daba a diseñar tabla y en el campo identity le daba a que no
era identity ( ponia, a No esa propiedad ) y guardaba.
segundo el copio datos de otra tabla uqe tenian identity y bueno todo
perfecto porque la mi tabla problematica, ( la receptora ) ya no tenia
un campo identity, si no un int.
tercero le daba a diseñar tabla y la ponia con identity a Si, y asi
ademas de no darle fallo, se le ponian bien todos los indices del
identity , es decir, empezaba de 1, hasta el numero de registro que
fuese, ( ejemplo = 1 al 100 ).

Bueno, la gracia esque despues de hacer esto, rebusco en las infinitas
lineas que a registrado profiler de la actividad del administrador
corporativo y esto es lo que encuentro:

Primero crea una tabla temporal identica a la mia llamada
dbo.tmp_borrame ( el nombre borrame, es porque mi tabla se llamaba así ) :P.

Segundo crea un CURSOR y carga en memoria los datos de mi tabla original
para irlos pasando a su tabla temporal. ( aqui me quedo flipao, usea,
que si tengo 8 millones de registros me lio a petar la memoria del
server?, es mas, puedo permitirme que en un servidor de produccion se
realize esta barbaridad para llenar log, y consumir el doble de
espacio???. el doble espacio es evidentek, porqeu hay un momento en el
que esisten dos tablas "iguales", la mia y la suya llamada tmp_).
Despues de esto, borra mi tabla. Luego la vuelve a crear, y viceversa


Bueno la verdad, no es por criticarlo, porque os diré qeu a mi me
resulta muy comodo para tareas como observar y dianosticar las
replicaciones, y los jobs junto con su estado, por ejemplo, que es mucho
mas "engorroso" hacerlo a mano ( por no decir casi que imposible :P ).

Esto solo lo expongo a la comunidad, para que lo sepais los que no lo
sabian, qeu yo , un alma inocente se a dado cuenta algo que podria
causar algun "digustillo" a mas de uno. Y por supuesto darme cuenta de
lo mucho uqe me queda por aprender y de investigar.

Sin mas me despido que ya es tarde ;)

Saludos Paulino Padial

ATTE: Miguel, lo digo y lo dire siempre, ¡eres una makina!

Preguntas similare

Leer las respuestas

#6 Javier Loria
13/12/2004 - 15:23 | Informe spam
Hola:
Es "facil" criticar al Enterprise Manager por hacer las cosas como las
hace, pero pensando en que una dba puede "alterar" tanto un tabla
(Crear/Eliminar/Cambiar columnas, Crear/Eliminar Indices/Constraints, etc.)
de un solo golpe, no me inmagino otra forma de hacer este trabajo tan
"sucio".
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Paulino Padial" wrote in message
news:
Bueno, solo queria escribiros para contaros algo que a estas horas me ha
dejado estupefacto, y es que, a pesar de que Miguel Egea ya me comento
esto que os voy a explicar ( que porsupuesto yo no le creí xDDD ).
Bueno, no es que desconfie de alguien tan sabio, solo que yo suelo
fiarme de las cosas que yo mismo compruebo ;)
Bueno al grano, tengo algo de tiempo porque estoy ayudando a mi novia a
hacer un howto de como configurar un servidor linux, y mientras estaba
tumbado leyendo algo de sql server.. en el capitulo de almacenamiento
interno, me dio el picazon de ver que hacia de verdad esta herramienta
cuando trabajaba con ella.

Me he quedado estupefacto cuando en algo tan simple como esto :

Creo una tabla que se llama "borrame", le añado dos campos uno identity
y un varchar.. ( el identity porspuesto lo declaro como la clave


primaria ).
Abro el profiler que ya tenia puesto, y observo que hace mil
comprobaciones.. bueno , esto esta bastante bien. Aunque claro yo en el
Analizador de consultas me hubiera fallado al crear la tabla si ya
estubviese creada.. sin tanto rodeo.

Despues, meto registros en la tabla para que vaya creando numericos en
el campo identity. Cuando tengo unos 20 ( del 1 al 20 ), borro del 15 al
19, con lo que apartir de entonces, la secuencia de los numeros se ve
rota, ya que el identity sigue su curso sin rellenar los "huecos"


"vacios".

Algo tan trivial como insertar datos en esa tabla de otra tabla que tb
tenia un campo con un valor identity, se me ocurre una forma que un
compañero me comento que hizo el en una de sus tablas ( yo ya sabia como
se hacia con el analizador de consultas( con el identity_insert ), pero
claro la forma que el me comentaba era muuuuuuuy sencilla y en 3 pasitos
). El hacia lo siguiente :
primero le daba a diseñar tabla y en el campo identity le daba a que no
era identity ( ponia, a No esa propiedad ) y guardaba.
segundo el copio datos de otra tabla uqe tenian identity y bueno todo
perfecto porque la mi tabla problematica, ( la receptora ) ya no tenia
un campo identity, si no un int.
tercero le daba a diseñar tabla y la ponia con identity a Si, y asi
ademas de no darle fallo, se le ponian bien todos los indices del
identity , es decir, empezaba de 1, hasta el numero de registro que
fuese, ( ejemplo = 1 al 100 ).

Bueno, la gracia esque despues de hacer esto, rebusco en las infinitas
lineas que a registrado profiler de la actividad del administrador
corporativo y esto es lo que encuentro:

Primero crea una tabla temporal identica a la mia llamada
dbo.tmp_borrame ( el nombre borrame, es porque mi tabla se llamaba así )


:P.

Segundo crea un CURSOR y carga en memoria los datos de mi tabla original
para irlos pasando a su tabla temporal. ( aqui me quedo flipao, usea,
que si tengo 8 millones de registros me lio a petar la memoria del
server?, es mas, puedo permitirme que en un servidor de produccion se
realize esta barbaridad para llenar log, y consumir el doble de
espacio???. el doble espacio es evidentek, porqeu hay un momento en el
que esisten dos tablas "iguales", la mia y la suya llamada tmp_).
Despues de esto, borra mi tabla. Luego la vuelve a crear, y viceversa


Bueno la verdad, no es por criticarlo, porque os diré qeu a mi me
resulta muy comodo para tareas como observar y dianosticar las
replicaciones, y los jobs junto con su estado, por ejemplo, que es mucho
mas "engorroso" hacerlo a mano ( por no decir casi que imposible :P ).

Esto solo lo expongo a la comunidad, para que lo sepais los que no lo
sabian, qeu yo , un alma inocente se a dado cuenta algo que podria
causar algun "digustillo" a mas de uno. Y por supuesto darme cuenta de
lo mucho uqe me queda por aprender y de investigar.

Sin mas me despido que ya es tarde ;)

Saludos Paulino Padial

ATTE: Miguel, lo digo y lo dire siempre, ¡eres una makina!
Respuesta Responder a este mensaje
#7 qwalgrande
13/12/2004 - 18:21 | Informe spam
Hola.

Como veo que la cosa va de filosofar y ya somos varios los que estamos en
ello, voy a dejar también un enfoque algo distinto.

Siguiendo con el ejemplo, supongamos que estás cometiendo el error de
modificar una tabla de 8 millones de registros a las bravas, incluyendo un
campo adicional en mitad de la tabla usando el Enterprise Manager (en lugar
de, tras backup completo, crear la tabla de cero con el campo adicional y
vacía, pero con otro nombre, luego importar los datos, luego renombrar las
dos tablas conservando la antigua unos cuantos días, que es como yo haría
seguramente).

Si estás haciendo eso, EM te crea la tabla tmp_Tabla, un cursor cargando
idéntities, tarda un huevo, etc... Hombre, tú le criticas, pero, ¿si no has
recapacitado en el hecho de modificar una tabla enorme sin saber exactamente
lo que hace por dentro, crees que vas a esperar pacientemente más de 15
minutos a que se complete la operación, sin matar el mmc.exe desde el Task
Manager? Yo, personalmente, creo que lo más normal es que tras lanzar el
cambio, el usuario normal se cansa de esperar (o le entra miedo o mientras
espera recapacita en la burrada que está haciendo) y le da matarile al
proceso. Si el Enterprise Manager se ve en la tesitura de tener que deshacer
la transacción tras un final tan abrupto, sólo tiene que eliminar una tabla
que además no estaba ni en tu base de datos y si algo queda dañado es una
tabla tmp_, no tu tabla original.

Mi conclusión (desde este punto de vista) es que EM está pensado para el
gran público, y en especial, para el menos experto, con lo que debe
robustecerse tanto como pueda. Es decir, lento, quizá torpe, pero seguro.

Puestos a criticar EM, yo criticaría otras cosas. Tendrías que ver lo que
tarda un desplegar las bases de datos en un servidor con 190 bases de datos
(ya estaba así el día que llegué) porque se trae ingentes cantidades de
información de todas las bases de datos, la vayas a necesitar o no,
contraviniendo cualquier teoría sobre Cliente /Servidor. Por suerte, Yukon
viene al rescate. O cómo son los scripts que genera para los jobs. Aunque te
avisa de ello, si tienes algún paso en el que se use la sentencia "GO", ya
puedes tener cuidado a la hora de ejecutar el script, porque te ejecuta el
script y el paso entre cada GO cuando menos lo esperas. Si el job en cuestión
es para programar para x horas más tarde una parada de bases de datos y
realiza dettach de varias bases de datos después de matar las conexiones vía
"kill", vamos, te partes de la risa si cuando creas el job se ejecutan los
kill y luego los dettach. Es como si saltan los plomos.

qwalgrande

"Paulino Padial" wrote:

Bueno, solo queria escribiros para contaros algo que a estas horas me ha
dejado estupefacto, y es que, a pesar de que Miguel Egea ya me comento
esto que os voy a explicar ( que porsupuesto yo no le creí xDDD ).
Bueno, no es que desconfie de alguien tan sabio, solo que yo suelo
fiarme de las cosas que yo mismo compruebo ;)
Bueno al grano, tengo algo de tiempo porque estoy ayudando a mi novia a
hacer un howto de como configurar un servidor linux, y mientras estaba
tumbado leyendo algo de sql server.. en el capitulo de almacenamiento
interno, me dio el picazon de ver que hacia de verdad esta herramienta
cuando trabajaba con ella.

Me he quedado estupefacto cuando en algo tan simple como esto :

Creo una tabla que se llama "borrame", le añado dos campos uno identity
y un varchar.. ( el identity porspuesto lo declaro como la clave primaria ).
Abro el profiler que ya tenia puesto, y observo que hace mil
comprobaciones.. bueno , esto esta bastante bien. Aunque claro yo en el
Analizador de consultas me hubiera fallado al crear la tabla si ya
estubviese creada.. sin tanto rodeo.

Despues, meto registros en la tabla para que vaya creando numericos en
el campo identity. Cuando tengo unos 20 ( del 1 al 20 ), borro del 15 al
19, con lo que apartir de entonces, la secuencia de los numeros se ve
rota, ya que el identity sigue su curso sin rellenar los "huecos" "vacios".

Algo tan trivial como insertar datos en esa tabla de otra tabla que tb
tenia un campo con un valor identity, se me ocurre una forma que un
compañero me comento que hizo el en una de sus tablas ( yo ya sabia como
se hacia con el analizador de consultas( con el identity_insert ), pero
claro la forma que el me comentaba era muuuuuuuy sencilla y en 3 pasitos
). El hacia lo siguiente :
primero le daba a diseñar tabla y en el campo identity le daba a que no
era identity ( ponia, a No esa propiedad ) y guardaba.
segundo el copio datos de otra tabla uqe tenian identity y bueno todo
perfecto porque la mi tabla problematica, ( la receptora ) ya no tenia
un campo identity, si no un int.
tercero le daba a diseñar tabla y la ponia con identity a Si, y asi
ademas de no darle fallo, se le ponian bien todos los indices del
identity , es decir, empezaba de 1, hasta el numero de registro que
fuese, ( ejemplo = 1 al 100 ).

Bueno, la gracia esque despues de hacer esto, rebusco en las infinitas
lineas que a registrado profiler de la actividad del administrador
corporativo y esto es lo que encuentro:

Primero crea una tabla temporal identica a la mia llamada
dbo.tmp_borrame ( el nombre borrame, es porque mi tabla se llamaba así ) :P.

Segundo crea un CURSOR y carga en memoria los datos de mi tabla original
para irlos pasando a su tabla temporal. ( aqui me quedo flipao, usea,
que si tengo 8 millones de registros me lio a petar la memoria del
server?, es mas, puedo permitirme que en un servidor de produccion se
realize esta barbaridad para llenar log, y consumir el doble de
espacio???. el doble espacio es evidentek, porqeu hay un momento en el
que esisten dos tablas "iguales", la mia y la suya llamada tmp_).
Despues de esto, borra mi tabla. Luego la vuelve a crear, y viceversa


Bueno la verdad, no es por criticarlo, porque os diré qeu a mi me
resulta muy comodo para tareas como observar y dianosticar las
replicaciones, y los jobs junto con su estado, por ejemplo, que es mucho
mas "engorroso" hacerlo a mano ( por no decir casi que imposible :P ).

Esto solo lo expongo a la comunidad, para que lo sepais los que no lo
sabian, qeu yo , un alma inocente se a dado cuenta algo que podria
causar algun "digustillo" a mas de uno. Y por supuesto darme cuenta de
lo mucho uqe me queda por aprender y de investigar.

Sin mas me despido que ya es tarde ;)

Saludos Paulino Padial

ATTE: Miguel, lo digo y lo dire siempre, ¡eres una makina!

email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida