Hola Como se prometió en una
publicación anterior sobre la redefinición basada en la edición, esta es la segunda parte.
Entonces, ¿con qué estamos trabajando? Nuestro servidor de producción principal es Oracle 12C, Enterprise Edition. Y, lo que es importante tener en cuenta, varias docenas de aplicaciones se ejecutan simultáneamente. ¿Por qué nos estamos centrando en esto? La tecnología es relativamente nueva, no está muy bien implementada. Y sería ilógico transferirle algunos sistemas críticos de inmediato. Por lo tanto, decidimos por nosotros mismos que nos moveremos lentamente de los sistemas menos críticos a los más críticos. En consecuencia, el siguiente problema que teníamos que entender: cómo trabajar con la tecnología EBR y cómo organizar la integración en la situación cuando tenemos una versión versionada y la otra no. En la versión 12 de Oracle, como resultó, puede crear objetos no versionados, paquetes no versionados, representaciones no versionadas en un esquema versionado para organizar la integración.
Por supuesto, podemos crear una API no versionada y dársela al esquema no versionado para su uso. Pero, ¿qué pasa si esta API que no es de versión (o parte de ella) se usa dentro de nuestra aplicación y necesitamos versionarla dentro de nosotros mismos y dejar de lado los objetos que no sean de versión? Este es solo el siguiente problema con el que luchamos. Hemos usado la API muchas veces, pero, como recordarán, existe una limitación de que los objetos versionados no pueden usarse sin versión. Naturalmente, siempre que se estuvieran ejecutando varias aplicaciones en el servidor, era necesario comprender cómo cambiaríamos una aplicación a la nueva Edición y mantener la capacidad de utilizar la API de este esquema con otros esquemas de bases de datos.
Hay varias opciones para instalar Edition:
- establecer el valor de edición predeterminado para toda la base de datos
- instale el entorno nuevamente en la base de datos completa.
Estas opciones se descartan inmediatamente porque al menos algunas aplicaciones no cambiarán al uso de EBR.
También es posible crear un servicio para determinar la versión, o determinar la versión cuando se conecta la aplicación al circuito. Esto es conveniente si nos conectamos a la base de datos a través de alguna aplicación de terceros.
¿Y si necesitamos trabajos para ejecutar según lo programado y trabajar en alguna edición específica? En consecuencia, hay otra opción para cambiar a una nueva versión:
orientar la sesión actual a una versión específica .
En realidad, elegimos esto para nosotros como solución. Puede adjuntar un disparador después del inicio de sesión al esquema versionado, lo que dirá que la sesión actual en este esquema funcionará en esta edición.
Volviendo a la integración y duplicación de la lógica. Hay tareas: quiero versionar algún tipo de lógica de aplicación dentro de mi esquema, y también necesito exponerlo a un usuario que no sea de versión. Al principio, parecía que esto no podía implementarse, pero después de profundizar en la pregunta, observamos que el paquete dbms_sql habitual, que en principio está destinado a realizar algún tipo de consultas dinámicas, puede ayudar a resolver este problema. Como? Muy simple: al procesar una solicitud o llamar a cualquier bloque anónimo, podemos arrojar el nombre de la condición como un parámetro, lo que indica la versión en la que se analizará y ejecutará este código. Si necesitamos usar algún procedimiento dentro de nosotros mismos y darle el mismo procedimiento a un esquema de terceros, simplemente lo envolvemos con una llamada en el procedimiento dbms_sql.parse, creando así un contenedor que se puede colocar en un objeto que no sea de versión y, por favor, podemos usar nuestro objeto versionado usuario no versionado.
¿A qué te enfrentas aquí? Por alguna razón, al especificar la condición, los parámetros de salida no se emiten en los procedimientos. Por qué: no está claro, pero en los esquemas en los que trabajamos, esto no se usa con frecuencia. Tal vez volveremos a hacer la lógica de alguna manera, o buscaremos otras soluciones.
Los siguientes problemas son errores o características del EBR que encontramos. El primero es un problema con los tipos construidos y las funciones canalizadas. ¿Qué tiene que ver Pipeline con esto? Además del hecho de que tenemos realmente ciertos algoritmos que funcionan sobre la base de funciones canalizadas, Pipeline es una cierta solución para dejar a un lado la vista versionada. Heredamos las vistas, que contienen una lógica bastante complicada para el preprocesamiento de datos, y los esquemas de terceros también usan estas vistas. En consecuencia, era necesario comprender cómo configurar nuestras vistas de versiones a un circuito de consumo de datos sin versión, siempre que el conjunto de columnas de salida no cambie. Como una solución de este tipo, estaba claro que podía envolver todas estas vistas con dbms_sql en la función Pipeline y finalmente ponerlas a la vista del consumidor, sí, esto requiere muchos recursos para el servidor, pero esto no requeriría ninguna modificación por parte del sistema receptor.
Entonces, volviendo al uso de las funciones de canalización, resultó que si el tipo que se está construyendo no se crea en el paquete de versión que se está creando y se está construyendo por primera vez, el paquete simplemente no se compila y se desmorona. Inmediatamente no llegó una solución, fue a buscar lo que fue sugerido por otros programadores? Alguien dijo que es necesario crear este tipo en la versión cero del paquete, o crear un paquete con el tipo correspondiente en la versión cero de la base de datos. No estaba claro por qué hacer esto. Encontraron una solución de que estos tipos, que se crean implícitamente cuando se compiló el paquete, podrían simplemente colocarse en un tipo separado como un objeto de base de datos. De este modo, se resuelve el problema con las funciones del transportador.
La siguiente característica con la que nos topamos es el comportamiento no estándar de las vistas versionadas.
¿Recuerdas que hablé sobre el hecho de que los objetos se heredan y actualizan? Entonces, resultó que si usted y yo creamos una vista versionada en una edición condicionalmente cero, en la quinta edición notamos que teníamos inexactitudes en los comentarios. Por ejemplo, me doy cuenta de que en un comentario en una columna puedo intercambiar dos letras en lugares. ¡No dejes tanta imperfección!
Entonces, el comando habitual de comentarios lleva al hecho de que nuestra vista versionada se actualiza en la versión actual. Debido a esto, todos los paquetes dependientes se desmoronan y ¿cómo lidiar con ellos? Para hacer esto, escribieron un cierto script que, al crear una nueva edición, actualizará la vista de versiones cada vez que se lance la próxima versión. Esto no conlleva una gran carga en el diccionario de la base de datos, pero si es necesario, realice correcciones menores o, por ejemplo, emita nuevas subvenciones, no necesitamos crear una nueva edición
Bueno, el último error o característica de este tipo ... No está claro por qué, cuando el cambio no es nulo, las restricciones en la columna de vistas versionadas se desmoronaron. Es decir, tan pronto como decimos que nuestra columna de la tabla base ahora no debería tener restricciones nulas, la vista se desmorona incluso cuando se utiliza la redifinition dbms. No podríamos derrotar esto de ninguna manera, tal vez los lectores se hayan dado cuenta de esto, será interesante saber si se ha encontrado una solución.
¿Qué me gustaría decir en conclusión? La redefinición basada en la edición es una tecnología efectiva para una oportunidad real de lanzar un lanzamiento o revisión en línea, en modo de usuario. Tocamos, sentimos, nos dimos cuenta de que organizar la integración en un servidor, cuando no todos los esquemas se moverán para usar esta tecnología, es real, sin mencionar que el esquema versionado puede funcionar en un servidor dedicado o en una base de datos de contenedor separada.
Y como una aplicación, y una respuesta a la pregunta clave, "¿es posible en la producción?" ... Esperamos que la Redefinición basada en la edición se traslade tarde o temprano a todos nuestros proyectos, y tal vez esta sea la última parada de nuestras aplicaciones y garantice una calma. suspensión del desarrollador responsable de instalar la nueva versión.
En realidad, eso es todo. Gracias por su atencion