{"id":30280,"date":"2019-10-31T21:34:38","date_gmt":"2019-10-31T18:34:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0\/"},"modified":"2019-10-31T21:34:38","modified_gmt":"2019-10-31T18:34:38","slug":"potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/potochnaya-konvertatsiya-baz-firebird-2-5-v-format-ods12-firebird-3-0","title":{"rendered":"Conversi\u00f3n en l\u00ednea de bases de datos Firebird 2.5 al formato ODS12 (Firebird 3.0)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cada versi\u00f3n de Firebird tiene su propia versi\u00f3n del formato de estructuras de disco de la base de datos \u2013 O(n)D(is)S(tructure). Hasta la versi\u00f3n 2.5 inclusive, el motor Firebird pod\u00eda trabajar con ODS de versiones anteriores, es decir, las bases de datos de versiones antiguas se abr\u00edan con la nueva versi\u00f3n y operaban en modo de compatibilidad, pero el motor Firebird 3.0 solo trabaja con bases de datos en su propia versi\u00f3n ODS 12.0.<\/p>\n

Para actualizar a 3.0, la base de datos de 2.5 debe convertirse al nuevo formato a trav\u00e9s de backup\/restauraci\u00f3n. Por supuesto, asumimos que la base de datos ha sido preparada previamente para la conversi\u00f3n, es decir, que los metadatos y las consultas han sido verificadas por su compatibilidad con Firebird 3.0.<\/p>\n

Siguiendo el enfoque est\u00e1ndar, esto significa que se debe realizar un backup en la versi\u00f3n 2.5, luego instalar la 3.0 y hacer la restauraci\u00f3n. Este procedimiento es aceptable si hay suficiente tiempo, pero al migrar grandes bases de datos, o al migrar simult\u00e1neamente varias decenas de bases de datos, cuando el tiempo es limitado, se puede optar por la conversi\u00f3n continua, que es un 30-40% m\u00e1s r\u00e1pida. C\u00f3mo hacerlo exactamente (en Windows y en Linux), l\u00e9elo a continuaci\u00f3n.
\n<\/a><\/noindex>
\nLa idea general es que para acelerar, utilizaremos una tuber\u00eda:<\/p>\n

gbak -b \u2026 base25 stdout | gbak -c \u2026 stdin base30<\/code><\/pre>\n
\nGbak de 2.5 genera un backup en formato lineal y lo env\u00eda a stdout, que inmediatamente es capturado a trav\u00e9s de stdin por gbak de 3.0 y crea una nueva base de datos.<\/p>\n
Es necesario organizar esta tuber\u00eda utilizando necesariamente el m\u00e9todo de acceso local (a archivos), ya que el acceso por red (incluso a trav\u00e9s de localhost) ralentizar\u00e1 considerablemente el proceso.<\/p>\n
A continuaci\u00f3n, examinamos los detalles para Windows y Linux.<\/p>\n
Windows<\/b><\/p>\n
En el caso de Windows, lo m\u00e1s f\u00e1cil es hacer una compilaci\u00f3n completamente aut\u00f3noma de Firebird. Para ello, tomamos el archivo embed de Firebird 2.5<\/a><\/noindex>, renombramos fbembed.dll a fbclient.dll, a\u00f1adimos desde el archivo 'normal' 2.5 la utilidad gbak.exe y (opcionalmente) \u2013 isql.exe. <\/p>\n
Firebird 3.0 utiliza una \u00fanica compilaci\u00f3n<\/a><\/noindex> y no requiere ninguna modificaci\u00f3n.<\/p>\n
La opci\u00f3n m\u00e1s m\u00ednima (que no requiere instalaci\u00f3n de bibliotecas de tiempo de ejecuci\u00f3n VS2008\/VS2010 en el sistema de destino) contiene los siguientes archivos:<\/p>\n
25\/gbak.exe\n25\/fbclient.dll\n25\/firebird.conf\n25\/firebird.log\n25\/firebird.msg\n25\/ib_util.dll\n25\/icudt30.dll\n25\/icuin30.dll\n25\/icuuc30.dll\n25\/Microsoft.VC80.CRT.manifest\n25\/msvcp80.dll\n25\/msvcr80.dll\n\n30\/fbclient.dll\n30\/firebird.conf\n30\/firebird.msg\n30\/gbak.exe\n30\/ib_util.dll\n30\/icudt52.dll\n30\/icudt52l.dat\n30\/icuin52.dll\n30\/icuuc52.dll\n30\/msvcp100.dll\n30\/msvcr100.dll\n30\/intl\/fbintl.conf\n30\/intl\/fbintl.dll\n30\/plugins\/engine12.dll<\/code><\/pre>\n
\nUn administrador experimentado puede notar que en 2.5 no se incluyen los archivos intl\/fbintl.dll e intl\/fbintl.conf. Esto es cierto, ya que gbak no utiliza el juego de caracteres de conexi\u00f3n y no convierte datos entre conjuntos de caracteres, pero en el lado de 'recepci\u00f3n' de Firebird 3.0, esos archivos son necesarios al crear \u00edndices.<\/p>\n
En firebird.conf se recomienda agregar lo siguiente para Firebird 3.0:<\/p>\n
MaxUnflushedWrites = -1\nMaxUnflushedWriteTime = -1<\/code><\/pre>\n
\nAdem\u00e1s, es deseable establecer un valor diferente para IpcName para 2.5 y 3.0. <\/p>\n
Al elegir los valores de otros par\u00e1metros en firebird.conf, partimos de una consideraci\u00f3n simple: en la etapa de migraci\u00f3n de datos, un proceso utiliza gbak 2.5 y el otro 3.0, luego 2.5 finaliza su trabajo y 3.0 comienza a construir \u00edndices.<\/p>\n
Para acelerar la etapa de construcci\u00f3n de \u00edndices en 3.0, se recomienda aumentar el tama\u00f1o del par\u00e1metro TempCacheLimit a aproximadamente un 40% de RAM (si es un servidor dedicado, por supuesto).<\/p>\n
Por ejemplo, si el servidor tiene 16 GB de RAM, se puede establecer <\/p>\n
TempCacheLimit=6G<\/code><\/pre>\n
\nPor supuesto, este valor solo se puede establecer en Firebird 3 de 64 bits, ya que cualquier proceso de 32 bits no podr\u00e1 asignar m\u00e1s de 2 gigabytes de memoria.<\/i><\/p>\n
Para 2.5, este par\u00e1metro no necesita ser modificado, ya que no puede ser mayor de 2 gigabytes y tampoco afecta la velocidad durante la copia de seguridad.<\/p>\n
Antes de realizar la operaci\u00f3n, es necesario verificar que el cach\u00e9 de p\u00e1ginas en la cabecera de la base de datos est\u00e9 establecido en 0 (orden gstat -h databasename<\/code>, ver la l\u00ednea de buffers de p\u00e1gina). <\/p>\n
Si el cach\u00e9 se establece expl\u00edcitamente en la cabecera de la base de datos, anula los valores de firebird.conf (y databases.conf en 3.0), y en caso de valores excesivamente grandes puede llevar a un consumo excesivo de memoria y al uso de swap.<\/p>\n
Luego, copiamos los archivos al sistema objetivo. <\/p>\n
La conversi\u00f3n se realiza despu\u00e9s de detener el servicio 'sistema' de Firebird 2.5, en la l\u00ednea de comandos con privilegios elevados hasta administrador local (ejemplo):<\/p>\n
set ISC_USER=propietario\n\"25\/gbak\" -z -b -g -v -st t -y 25.log base25 stdout|^\n\"30\/gbak\" -z -c -v -st t -y 30.log stdin base30<\/code><\/pre>\n
\nEn este ejemplo se utiliza la 'barra diagonal' entre comillas (estilo 'unix-style' permitido), y el 'caret' (s\u00edmbolo '^') escapa el s\u00edmbolo de salto de l\u00ednea, lo cual es \u00fatil para teclear comandos largos. La opci\u00f3n -st(atus) apareci\u00f3 en Firebird 2.5.8 y permite registrar en el protocolo los datos sobre el tiempo de funcionamiento del proceso gbak (detalles en la documentaci\u00f3n).<\/p>\n
Linux<\/b><\/p>\n
En Linux, Firebird 3 depende de la biblioteca tommath. En CentOS (RHEL), esta biblioteca se encuentra en el repositorio epel, en Ubuntu (Debian) en \u2013 el sistema.<\/p>\n
Para CentOS, primero es necesario conectar el repositorio epel y solo despu\u00e9s hacer <\/p>\n
yum install libtommath<\/code><\/pre>\n
\nEn Ubuntu no es necesario conectar repositorios adicionales, pero en Ubuntu 16 y en Ubuntu 18 se instalan diferentes versiones de paquetes: libtommath0 y libtommath1, respectivamente.<\/p>\n
Firebird 3.0 busca tommath.so.0 y para Ubuntu 18 adicionalmente es necesario crear un enlace (symlink) de tommath.so.0 a tommath.so.1. Para esto, primero hay que localizar tommath.so.1. <\/p>\n
La ruta buscada en Ubuntu es \/usr\/lib\/x86_64-linux-gnu\/<\/code>, pero en otras distribuciones basadas en Debian puede ser diferente.<\/p>\n
El segundo problema est\u00e1 relacionado con que hasta Firebird 3.0.1, inclusive, no hab\u00eda una forma sencilla de instalar dos versiones diferentes del servidor. La opci\u00f3n de \"compilar desde los fuentes con el prefijo correcto\" no la consideramos debido a su relativa complejidad.<\/p>\n
Para Firebird 3.0.2 y versiones superiores se implement\u00f3 la construcci\u00f3n con \u2013enable-binreloc<\/a><\/noindex> y una opci\u00f3n separada en el instalador (-path ruta).<\/p>\n
Asumiendo que la biblioteca tommath y, si es necesario, el symlink para tommath.so.0 se han agregado al sistema, se puede instalar la distribuci\u00f3n actual (en el momento de escribir este art\u00edculo) de Firebird 3.0.4 en, por ejemplo, \\\/opt\\\/fb3:<\/p>\n
.\/install.sh -path \\\/opt\\\/fb3<\/code><\/pre>\n
\nDespu\u00e9s de esto, se puede detener el servicio del sistema Firebird y comenzar la conversi\u00f3n en lote. <\/p>\n
Al detener Firebird, hay que tener en cuenta que los procesos de Firebird 2.5 en modo Classic generalmente los inicia xinetd, por lo que es necesario o prohibir el servicio firebird para xinetd o detener xinetd completamente.<\/i><\/p>\n
En firebird.conf para 3.0 en Linux no es necesario establecer los par\u00e1metros MaxUnflushed (solo funcionan en Windows) y cambiar la configuraci\u00f3n de Firebird 2.5. <\/p>\n
En Linux, el acceso local (a archivos) de Firebird 2.5 no es equivalente a la variante embebida en Windows: el servidor 2.5 funcionar\u00e1 en el proceso gbak (sin parte de red), pero los derechos de acceso se verificar\u00e1n seg\u00fan la base de usuarios, por lo que se requerir\u00e1n tanto el login como la contrase\u00f1a: <\/p>\n
export ISC_USER=username ISC_PASSWORD=password\n\\\/opt\\\/firebird\\\/bin\\\/gbak -b \u2026 base25 stdout\n|\\\/opt\\\/fb3\\\/bin\\\/gbak -c \u2026 stdin base30<\/code><\/pre>\n
\nDespu\u00e9s de una conversi\u00f3n exitosa, primero hay que eliminar el \"Firebird 3.0 adicional\", luego el \"Firebird 2.5 principal\" y despu\u00e9s hacer una instalaci\u00f3n limpia de Firebird 2.5, preferiblemente desde el instalador tar.gz y no a trav\u00e9s de repositorios, ya que la versi\u00f3n en los repositorios puede estar desactualizada.<\/p>\n
Adem\u00e1s, despu\u00e9s de restaurar la BD en Linux y reinstalar, se debe verificar que la nueva BD tenga como propietario al usuario firebird.<\/p>\n
Si no es as\u00ed, habr\u00e1 que corregirlo<\/p>\n
chown firebird.firebird database<\/code><\/pre>\n
\nSummary<\/b><\/p>\n
Adem\u00e1s del ahorro de tiempo y espacio en disco, la conversi\u00f3n en l\u00ednea tiene otra ventaja importante: la conversi\u00f3n de la base se realiza sin eliminar el Firebird 2.5 existente, lo que facilita notablemente la reversi\u00f3n en caso de una conversi\u00f3n fallida (m\u00e1s com\u00fanmente, debido a la falta de espacio o un reinicio inesperado durante el proceso de migraci\u00f3n).<\/p>\n
El ahorro de tiempo est\u00e1 relacionado con el hecho de que la conversi\u00f3n 'cl\u00e1sica' es 'tiempo de respaldo' m\u00e1s 'tiempo de recuperaci\u00f3n'. La recuperaci\u00f3n consta de dos partes: lectura de datos desde el archivo de respaldo y construcci\u00f3n del \u00edndice.<\/p>\n
En la conversi\u00f3n en l\u00ednea, el tiempo total se calcula como 'tiempo de respaldo m\u00e1s cinco a diez por ciento' y 'tiempo de construcci\u00f3n de \u00edndices'.<\/p>\n
Los resultados espec\u00edficos dependen de la estructura de la base, pero en promedio, el tiempo de recuperaci\u00f3n es aproximadamente el doble del tiempo de respaldo. Por lo tanto, si tomamos como unidad el tiempo de respaldo, la 'conversi\u00f3n cl\u00e1sica' toma tres unidades de tiempo, mientras que la conversi\u00f3n en l\u00ednea toma dos unidades de tiempo. Aumentar el TempCacheLimit ayuda a reducir a\u00fan m\u00e1s el tiempo.<\/p>\n
En general, la conversi\u00f3n en l\u00ednea permite ahorrar entre un 30% y un 40% del tiempo necesario para un respaldo y restauraci\u00f3n secuencial.<\/p>\n
\u00bfPreguntas?<\/b><\/p>\n
Por favor, env\u00eda todas tus preguntas en los comentarios, o dir\u00edgete al autor de la metodolog\u00eda y coautor de este art\u00edculo \u2014 Vasily Sidorov, ingeniero de sistemas l\u00edder de la compa\u00f1\u00eda 'iBase', a la direcci\u00f3n bs at ibase ru.<\/p>\n
Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n
\u00bfQu\u00e9 versi\u00f3n de Firebird utilizas?<\/h2>\n