Re: Consulta para bkp Postgres 8.3, para poder migrar sistema critico.

Gracias jvenegasperu, intentare realizar tambien esta prueba que me pasas
en la siguiente semana. Agradecido por la ayuda.

El 4 de agosto de 2017, 15:33, jvenegasperu . <jvenegasperu(at)gmail(dot)com>
escribió:

> Hola Diego
>
> Se me ocurre que hagas lo siguiente:
>
> hazte una tabla digamos con 1000 registros extrayendolos de la tabla de
> 1.5 Tb
>
> luego miras cuanto pesa esta tabla de 1000 registros
>
> con eso te haces una idea de cuanto pesa cada registro de tu BD.
>
> luego mide y pesa unas cuantas imagens para que tengas una idea de las
> medidas y pesos de las fotos
>
> Con esos datos a esa tabla de prueba con 1000 registros resultante
> aplicale el script anterior que te pase ajustandole las dimensiones
>
> aplicas el script a la tabla dandole las medidas que te servirian y le
> haces vacuum para que actualice las estadisticas
>
> y nuevamente pasas la consulta para el tamaño asi tendras una idea de
> cuanto puedes reducir las imagenes. en tu tabla real de 1.5 Tb
>
> PD: Esto te serviria si por ejemplo la alta resolucion de las imagenes no
> es necesaria una vez un medico me dijo que necesitaba las fotos con 20
> Megapixels para poder notar un minusculo cambio de color que representaba
> una infección.
>
> Ahora tu hablas de unas 2000 fotos y 5000Gb por dia eso da 2.5 Mb por foto
> y es una barbaridad si te estoy entendiendo bien y se trata de fotos de
> cedulas para identificacion o DNI como le llamamos aqui en Peru yo diria
> que con 100Kb es ya una exageracion mira ahi te adjunto mi foto que uso
> para la cedula y solo pesa 15Kb jeje
>
> Estoy imaginando que se trata de un fotografo que tomas las fotos para la
> cedula con una super camara asi pueden retocar la foto y hasta ponerte
> terno jajaja como mi foto.
>
> O quizas como es postgres 8.3 ya son como 10 años y antes cargaban las
> fotos con scaneres y esas fotos pesaban una barbaridad quiza solo baste
> ajustando las imagenes de años pasados para bajar el peso de tu BD a la
> quinta parte y hasta menos porque quien sabe y por ahi alguien uso en años
> pasados fotos en formato BMP que pesan un monton y por nada porque incluso
> solo cambiando el formato sin cambiar tamaño ya ganas muchisimo espacio eso
> me lleva a pensar que quiza en tu prueba de 1000 registros puedas incluir
> digamos unos 100 registros de cada año. y te averigues cual era el origen
> de las fotos.
>
> Bueno ahi te envio mi foto de la cedula para que veas que es mas que
> suficiente y eso que solo tiene 15Kb si tu caso se parece a lo que te
> comento puedes aplicar estos pequeños aportes saludos
>
> El 4 de agosto de 2017, 13:43, Diego Ayala <netdiego81(at)gmail(dot)com>
> escribió:
>
>> Buen dia, Gracias por tu ayuda, te explico, la tabla principal, de imagen
>> crece a razon de 4 a 5 GB por dia, debido a que se procesan entre 1500 a
>> 2000 renovaciones o nuevas emisiones de cedulas de identidad personal, por
>> eso ese crecimiento. Es un software propietario que se instalo con el 8.3
>> en windows, ya varios años atras, por lo tanto el mantemiento y demas se ha
>> complicado.
>>
>> El 4 de agosto de 2017, 14:08, jvenegasperu . <jvenegasperu(at)gmail(dot)com>
>> escribió:
>>
>>> Diego que tal buen dia
>>> Queria preguntarte porque esta creciendo tanto tu BD ¿no sera que por
>>> ejemplo tienes fotos gigantes y no las necesitas tan grandes?
>>>
>>> Por ejemplo a mi me pasaba que mis usuarios tomaban fotos con camaras y
>>> celulares con resoluciones de 8 10 o hasta 16Mb y luego las subian a la BD
>>> a traves del sistema y bueno el resultado es que cada imagen la mas pequeña
>>> pesaba 3 MB y cuando las mostraban en pantalla en el monitor pues ni
>>> siquiera caben en el monitor tenian estar jugando con la lupa para que
>>> puedan verse.
>>>
>>> y claro se ajustaba el tamaño en el sistema web pero igual a veces se
>>> notaba lento cuando tenia que cargar una iamgen muy grande
>>>
>>> Asi que lo que hice fue pues cambiarle el tamaño a todas las fotos
>>> considerando solo un alto maximo de 999 pixeles y conservando el ratio de
>>> aspecto asi ocupa casi todo el alto de la mayoria de monitores y se ven
>>> bien.
>>> bueno lo hice por partes con un where para ir avanzando y reduje el
>>> tamaño de mi BD como 40 Gb en mi caso no tengo tanta información.
>>>
>>> Quizas sea tu caso aqui te dejo el script en php que use para cambiar el
>>> tamaño a las imagenes quizas sea tu caso.
>>>
>>> set_time_limit(0);
>>>
>>> ini_set('gd.jpeg_ignore_warning', 1);
>>>
>>> $conn = pg_connect("user=usuario password=clave dbname=nombre_bd
>>> host=ip_del_deserver port=5433");
>>>
>>> $result = pg_query($conn, "SELECT fotos_notif_id FROM cp_fotos_notif
>>> where fotos_notif_id >= 17105 ");
>>>
>>> session_start();
>>> ob_end_flush();
>>> ob_start();
>>>
>>> while ($raw = pg_fetch_array($result)) {
>>>
>>> $query = pg_query($conn, "SELECT foto FROM cp_fotos_notif where
>>> fotos_notif_id = " . $raw['fotos_notif_id'] . " ");
>>> $row = pg_fetch_row($query);
>>>
>>> $image = pg_unescape_bytea($row[0]);
>>>
>>> $fichero = file_put_contents('image_original.jpg', $image);
>>>
>>> $fotito = 'image_original.jpg';
>>>
>>> //Ruta de la imagen original
>>> $rutaImagenOriginal = $fotito;
>>>
>>> //Creamos una variable imagen a partir de la imagen original
>>> $img_original = imagecreatefromjpeg($rutaImagenOriginal);
>>>
>>> //Se define el maximo ancho o alto que tendra la imagen final
>>> $max_ancho = 999;
>>> $max_alto = 999;
>>>
>>> //Ancho y alto de la imagen original
>>> list($ancho, $alto) = getimagesize($rutaImagenOriginal);
>>>
>>> if ($alto > 999) {
>>>
>>> //Se calcula ancho y alto de la imagen final
>>> $x_ratio = $max_ancho / $ancho;
>>> $y_ratio = $max_alto / $alto;
>>>
>>> //Si el ancho y el alto de la imagen no superan los maximos,
>>> //ancho final y alto final son los que tiene actualmente
>>> if (($ancho <= $max_ancho) && ($alto <= $max_alto)) {//Si
>>> ancho
>>> $ancho_final = $ancho;
>>> $alto_final = $alto;
>>> }
>>> /*
>>> * si proporcion horizontal*alto mayor que el alto maximo,
>>> * alto final es alto por la proporcion horizontal
>>> * es decir, le quitamos al alto, la misma proporcion que
>>> * le quitamos al alto
>>> *
>>> */ elseif (($x_ratio * $alto) < $max_alto) {
>>> $alto_final = ceil($x_ratio * $alto);
>>> $ancho_final = $max_ancho;
>>> }
>>> /*
>>> * Igual que antes pero a la inversa
>>> */ else {
>>> $ancho_final = ceil($y_ratio * $ancho);
>>> $alto_final = $max_alto;
>>> }
>>>
>>> //Creamos una imagen en blanco de tamanio $ancho_final por
>>> $alto_final .
>>> $tmp = imagecreatetruecolor($ancho_final, $alto_final);
>>>
>>> //Copiamos $img_original sobre la imagen que acabamos de crear
>>> en blanco ($tmp)
>>> imagecopyresampled($tmp, $img_original, 0, 0, 0, 0,
>>> $ancho_final, $alto_final, $ancho, $alto);
>>>
>>> //Se destruye variable $img_original para liberar memoria
>>> imagedestroy($img_original);
>>>
>>> //Definimos la calidad de la imagen final
>>> $calidad = 95;
>>>
>>> //Se crea la imagen final en el directorio indicado
>>> imagejpeg($tmp, "ejemplo.jpg", $calidad);
>>>
>>> $data = file_get_contents('ejemplo.jpg');
>>> $pg_tmp = pg_escape_bytea($data);
>>>
>>> //pg_query($conn, "insert into fotitos (foto) values('{$pg_tmp}')");
>>> pg_query($conn, "UPDATE cp_fotos_notif SET foto = '{$pg_tmp}'
>>> WHERE fotos_notif_id = " . $raw['fotos_notif_id'] . " ");
>>>
>>> echo 'se actualizo'.$raw['fotos_notif_id'].'<br>';
>>>
>>> } else {
>>>
>>> echo $raw['fotos_notif_id'].' ya tiene el tamaño menor a 999
>>> <br>';
>>> }
>>>
>>> ob_flush();
>>> flush();
>>> }
>>> pg_close($conn);
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> El 4 de agosto de 2017, 11:11, Diego Ayala <netdiego81(at)gmail(dot)com>
>>> escribió:
>>>
>>>> Buenos días, tengo un compañero de una institución que esta teniendo
>>>> problemas, el problema es el siguiente, tiene una DB PostgresSQL 8.3 sobre
>>>> windows, aclaro que es un sistema critico, y que al adquirir el software
>>>> hace varios años, se lo entregaron asi, el tema es que se esta quedando sin
>>>> espacio en disco, y ya no puede agregar discos(tiene 2TB de capacidad, pero
>>>> ya esta utilizado 1,8 TB), el cluster tiene varias DB's, pero es una DB la
>>>> que tiene 1 sola tabla que es la que esta con crecimiento , la tabla tiene
>>>> 1.5TB (imágenes), que esta sobre un tablespace (otro disco) que también
>>>> esta quedando sin espacio, la pregunta que tengo, como se puede optimizar
>>>> el Backup, pg_dump, ya que dura aproximadamente 16hs en terminar y otras 15
>>>> horas en restore, es un sistema critico que no se puede parar por mucho
>>>> tiempo, la idea es migrar a un servidor nuevo, con mas disco, pero implica
>>>> parar para realizar el bkp, pero es mucho tiempo, alguien podria darme una
>>>> mano de como realizarlo, lastimosamente, el 8.3 no tiene todavia la
>>>> replicacion nativa, por lo tanto no puedo utilizar el SR.
>>>>
>>>> Gracias.
>>>>
>>>>
>>>
>>>
>>> --
>>> José Mercedes Venegas Acevedo
>>> cel Mov RPC 964185205
>>>
>>> Member of the PHP Documentation Group (Spanish)
>>>
>>
>>
>
>
> --
> José Mercedes Venegas Acevedo
> cel Mov RPC 964185205
>
> Member of the PHP Documentation Group (Spanish)
>