Diseño y desarrollo para mejorar el rendimiento

Rendimiento óptimo del sistema comienza con el diseño y continúa a lo largo de la vida de su sistema. Considerar cuidadosamente los problemas de rendimiento durante la fase de diseño inicial, y será más fácil para ajustar el sistema durante la producción.
Este capítulo contiene las siguientes secciones:

2.1 Metodología de Oracle

El rendimiento del sistema se ha convertido cada vez más importante en los sistemas informáticos se hacen más grandes y más complejas a medida que Internet juega un papel más importante en las aplicaciones de negocio. Con el fin de dar cabida a este, Oracle ha producido una metodología de actuación basado en años de experiencia en diseño y rendimiento.Esta metodología explica las actividades claras y sencillas que pueden mejorar drásticamente el rendimiento del sistema.
Estrategias de actuación varían en su efectividad, y los sistemas con los propósitos, tales como diferentes sistemas operativos y sistemas de apoyo a las decisiones requieren cualificaciones diferentes resultados. Este libro analiza las consideraciones que cualquier experto diseñador de bases de datos, administrador, o el rendimiento debe centrar sus esfuerzos en.
El rendimiento del sistema está diseñado y construido en un sistema. No sucede así como así. Problemas de rendimiento son generalmente el resultado de la contención para, o el agotamiento de algunos recursos del sistema. Cuando un recurso del sistema se agota, el sistema no es capaz de escalar a mayores niveles de rendimiento. Esta metodología nuevo espectáculo se basa en una cuidadosa planificación y diseño de la base de datos, para evitar que los recursos del sistema de agotarse y que causa el tiempo de inactividad. Al eliminar los conflictos de recursos, los sistemas pueden ser escalable a los niveles requeridos por el negocio.

2.2 Descripción de las opciones de inversión

Con la disponibilidad de los procesadores de relativamente bajo costo, de alta potencia, memoria y unidades de disco, hay una tentación de comprar más recursos del sistema para mejorar el rendimiento. En muchas situaciones, nuevas CPUs, memoria, o más unidades de disco hecho puede proporcionar una mejora de rendimiento inmediato. Sin embargo, cualquier mejora el rendimiento alcanzado por la adición de hardware debe ser considerado como un alivio a corto plazo a un problema inmediato. Si la demanda y las tasas de carga en la aplicación de seguir creciendo, entonces la posibilidad de que se enfrentan al mismo problema en un futuro próximo es muy probable.
En otras situaciones, hardware adicional no mejora el rendimiento del sistema en absoluto. Sistemas mal diseñados bajo rendimiento, sin importar la cantidad de hardware extra se asigna. Antes de comprar hardware adicional, asegúrese de que no existe una sola serialización o roscado pasando dentro de la aplicación. A largo plazo, suele ser más valiosa para incrementar la eficiencia de su aplicación en términos de la cantidad de recursos físicos para cada transacción comercial.

2.3 Entender Escalabilidad

La palabra escalabilidad se utiliza en muchos contextos en los entornos de desarrollo. La siguiente sección contiene una explicación de escalabilidad que está dirigido a diseñadores de aplicaciones y especialistas en el rendimiento.
Esta sección cubre los siguientes temas:

2.3.1 ¿Qué es la escalabilidad?

La escalabilidad es la capacidad del sistema para procesar más carga de trabajo, con un incremento proporcional en el uso de recursos del sistema. En otras palabras, en un sistema escalable, si se duplica la carga de trabajo, entonces el sistema se utiliza el doble de los recursos del sistema muchos. Esto suena obvio, pero debido a los conflictos dentro del sistema, el uso de recursos podría superar el doble de la carga de trabajo original.
Ejemplos de escalabilidad mal debido a los conflictos de recursos son las siguientes:

Las aplicaciones que requieren la gestión de la concurrencia significativa de las poblaciones de usuarios aumento
Aumento de las actividades de cierre
El aumento de los datos de carga de trabajo consistencia
El aumento de la carga de trabajo del sistema operativo
Las transacciones que requieren el aumento de acceso a datos como aumentar los volúmenes de datos
Pobres SQL y diseño de índices que resulta en un mayor número de lógica E / S para el mismo número de filas devueltas
Reducción de la disponibilidad, ya que los objetos de base de datos tardan más en mantener

Una aplicación se dice que es infranqueable si se agota un recurso del sistema hasta el punto donde no existe el intercambio más es posible cuando la carga de trabajo aumenta. Este tipo de aplicaciones como resultado rendimientos fijos y tiempos de respuesta pobres.
Ejemplos de agotamiento de recursos son las siguientes:

Hardware agotamiento
Los recorridos de tablas en transacciones de alto volumen que causa inevitable de disco E / S de la escasez de
Exceso de solicitudes de red, resultando en los cuellos de botella y la programación
La asignación de memoria que causa el paginado e intercambio
Proceso y la asignación excesiva hilo causando paliza del sistema operativo

Esto significa que los diseñadores de aplicaciones deben crear un diseño que utiliza los mismos recursos, independientemente de las poblaciones de usuarios y volúmenes de datos, y no poner cargas sobre los recursos del sistema más allá de sus límites.

2.3.2 Sistema de escalabilidad

Las aplicaciones que son accesibles a través de Internet tienen un rendimiento más complejos y los requisitos de disponibilidad. Algunas aplicaciones se han diseñado y escrito sólo para el uso de Internet, pero incluso típica aplicaciones back-office, como un libro mayor general de la aplicación podría requerir algunos o todos los datos estén disponibles en línea.
Características de las aplicaciones era de Internet son las siguientes:

Disponibilidad 24 horas al día, 365 días al año
Número imprevisible e impreciso de usuarios simultáneos
Dificultad en la planificación de la capacidad
Disponibilidad para cualquier tipo de consulta
Multinivel arquitecturas
Middleware apátridas
Desarrollo rápido de escala de tiempo
Un mínimo de tiempo para las pruebas

Figura 2-1 ilustra la curva de carga de trabajo clásico de crecimiento, la demanda crece a un ritmo creciente. Las solicitudes deben escala con el aumento de la carga de trabajo y también cuando se agrega hardware adicional para soportar la creciente demanda. Errores de diseño pueden causar la ejecución de llegar a su máximo, independientemente de los recursos adicionales de hardware o los esfuerzos de re-diseño.

Figura 2-1 Curva de Crecimiento de carga de trabajo

Descripción de la figura 2.1 a continuación

Descripción de la "Figura 2-1 Curva de Crecimiento de carga de trabajo"

Las aplicaciones son cuestionadas por los plazos de desarrollo muy corto, con un tiempo limitado para pruebas y evaluación. Sin embargo, un mal diseño en general, significa que en algún momento en el futuro, el sistema tendrá que ser rediseñado o re-implementado. Si una aplicación con la conocida limitaciones de la arquitectura y la aplicación se implementa en la Internet, y si la carga de trabajo supera la demanda prevista, entonces no hay posibilidad real de fracaso en el futuro. Desde una perspectiva empresarial, el bajo rendimiento puede significar una pérdida de clientes. Si los usuarios de Internet no obtener una respuesta en siete segundos, y luego la atención del usuario podría perderse para siempre.
En muchos casos, el costo de re-diseño de un sistema con los costos de tiempo de inactividad asociado con la migración a las nuevas implementaciones excede los costos de la adecuada construcción del sistema original. La moraleja de la historia es simple: diseñar e implementar con la escalabilidad en mente desde el principio.

2.3.3 Factores de Prevención de escalabilidad

Cuando la creación de aplicaciones, diseñadores y arquitectos deben aspirar a lo más cercano a la escalabilidad perfecta como sea posible. A veces se denomina lineales escalabilidad, donde el rendimiento del sistema es directamente proporcional al número de CPUs.
En la vida real, la escalabilidad lineal es imposible por razones fuera del control del diseñador. Sin embargo, por lo que el diseño de la aplicación e implementación, escalable como sea posible deben asegurarse de que los objetivos de desempeño actual y futuro se puede lograr mediante la ampliación de los componentes de hardware y la evolución de la tecnología de CPU.
Los factores que pueden prevenir una escalabilidad lineal son:

El diseño de aplicaciones pobres, la implementación y configuración
La aplicación tiene el mayor impacto en la escalabilidad. Por ejemplo:
- El diseño del esquema deficiente puede causar SQL caro que no se adaptan.
- Diseño de transacciones pobres pueden causar problemas de bloqueo y la serialización.
- La gestión de una mala conexión puede causar tiempos de respuesta pobres y los sistemas poco confiables.
Sin embargo, el diseño no es el único problema. La implementación física de la aplicación puede ser el eslabón más débil. Por ejemplo:
- Los sistemas se pueden mover a los entornos de producción con el mal de E / S de estrategias.
- El entorno de producción podría utilizar los diferentes planes de ejecución que los generados en las pruebas.
- Aplicaciones de memoria intensiva que asignar una gran cantidad de memoria, sin pensar mucho para liberar la memoria en tiempo de ejecución puede causar el uso excesivo de memoria.
- Uso de la memoria ineficientes y pérdidas de memoria poner un alto estrés en el subsistema de memoria del sistema operativo virtual. Esto afecta el rendimiento y la disponibilidad.
Incorrecto dimensionamiento de los componentes de hardware
Mala planificación de la capacidad de todos los componentes de hardware se está convirtiendo en un problema menor como el hardware relativa disminución de los precios.Sin embargo, un exceso de capacidad puede ocultar problemas de escalabilidad como la carga de trabajo se incrementa en un sistema.
Limitaciones de los componentes de software
Todos los componentes de software han escalabilidad y limitaciones de uso de recursos. Esto se aplica a los servidores de aplicaciones, servidores de bases de datos y sistemas operativos. Diseño de la aplicación no debe poner demandas en el software más allá de lo que puede manejar.
Limitaciones de los componentes de hardware
Hardware no es perfectamente escalable. La mayoría de máquinas multiprocesador se puede acercar a la escala lineal con un número finito de CPU, pero después de cierto punto cada CPU adicional puede aumentar el rendimiento general, pero no proporcionalmente. No puede llegar un momento en que una CPU adicional no ofrece ningún aumento en el rendimiento, o incluso disminuye el rendimiento. Este comportamiento está estrechamente relacionado con la carga de trabajo y la configuración del sistema operativo.

Nota :
Estos factores se basan en la experiencia de Oracle grupo de rendimiento del servidor de sistemas de puesta a punto infranqueable.

2.4 Arquitectura del sistema

Hay dos partes principales de la arquitectura de un sistema:

2.4.1 Componentes de hardware y software

Esta sección trata sobre los componentes de hardware y software.

2.4.1.1 Componentes de Hardware

Hoy los diseñadores y arquitectos son responsables para el dimensionamiento y planificación de la capacidad de hardware en cada nivel en un entorno de varios niveles. Es responsabilidad del arquitecto para lograr un diseño equilibrado. Esto es análogo a un diseñador de puentes que se deben tener en cuenta todos los diversos carga y requisitos estructurales para el puente. Un puente es tan fuerte como su componente más débil. Como resultado, un puente se ha diseñado en equilibrio, de tal manera que todos los componentes de llegar a sus límites de diseño de forma simultánea.
Los principales componentes de hardware incluyen:

2.4.1.1.1 CPU

No puede haber una o más CPUs, y pueden variar en potencia de procesamiento de CPU simple que se encuentra en los dispositivos de mano para CPUs de servidores de alta potencia. Dimensionamiento de los componentes de hardware suele ser un múltiplo de la CPU en el sistema. Ver el capítulo 9, "La comprensión de Recursos del sistema operativo" .

2.4.1.1.2 Memoria

Servidores de bases de datos y de aplicaciones requieren considerables cantidades de memoria caché de datos y evitar el tiempo de acceso a disco. Ver el capítulo 7, "Configuración de la memoria y el uso" .

2.4.1.1.3 subsistema I / O

El subsistema de E / S puede variar entre el disco duro en un PC cliente y de alto rendimiento de los arrays de disco. Arrays de disco puede realizar miles de E / S por segundo y ofrecer disponibilidad a través de la redundancia en términos de E / S múltiples caminos y hot-pluggable discos duplicados. Ver el capítulo 8, "Configuración E / S y diseño" .

2.4.1.1.4 Red

Todos los equipos de un sistema están conectados a una red, desde una línea de módem de alta velocidad LAN interna. Las principales preocupaciones con las especificaciones de la red son el ancho de banda (volumen) y la latencia (la velocidad).

2.4.1.2 Componentes de software

De la misma manera los equipos tienen componentes comunes de hardware, las aplicaciones tienen en común los componentes funcionales. Mediante la división de desarrollo de software en componentes funcionales, es posible comprender mejor el diseño de aplicaciones y la arquitectura. Algunos de los componentes del sistema son realizadas por los programas informáticos existentes compró para acelerar la implementación de aplicaciones, o para evitar la re-desarrollo de componentes comunes.
La diferencia entre los componentes de software y componentes de hardware es que mientras que los componentes de hardware sólo se lleve a cabo una tarea, una pieza de software puede realizar las funciones de los varios componentes de software. Por ejemplo, una unidad de disco sólo almacena y recupera los datos, pero un programa cliente puede manejar la interfaz de usuario y realizar la lógica de negocio.
La mayoría de las aplicaciones incluyen los siguientes componentes:

2.4.1.2.1 Gestión de la interfaz de usuario

Este componente es el más visible para los usuarios de la aplicación. Esto incluye las siguientes funciones:

Pintura de la pantalla en frente del usuario
La recopilación de datos de usuario y su transferencia a la lógica de negocio
Validación de los datos de entrada
Navegando a través de los niveles o estados de la aplicación

2.4.1.2.2 implementar la lógica de negocios

Este componente implementa reglas empresariales básicas que son fundamentales para la función de aplicación. Los errores cometidos en este componente pueden ser muy costosos de reparar. Este componente es ejecutado por una mezcla de enfoques declarativo y procedimental. Un ejemplo de una actividad declarativa es la definición de claves únicas y extranjeros. Un ejemplo de la lógica basada en procedimientos está implementando una estrategia de descuentos.
Las funciones más comunes de este componente incluyen:

Traslado de un modelo de datos a una estructura de tabla relacional
Las limitaciones de la definición de la estructura de la tabla relacional
Codificación de la lógica de procedimiento para poner en práctica las reglas de negocio

2.4.1.2.3 Gestión de Solicitudes de usuario y asignación de recursos

Este componente se implementa en todas las piezas de software. Sin embargo, hay algunas peticiones y recursos que pueden ser influenciados por el diseño de la aplicación y algunos que no pueden.
En una aplicación multiusuario, la mayoría de la asignación de recursos por solicitudes de los usuarios son manejados por el servidor de base de datos o el sistema operativo. Sin embargo, en una aplicación de gran tamaño, donde el número de usuarios y su patrón de uso es desconocido o de rápido crecimiento, el arquitecto del sistema debe ser proactivo para garantizar que ningún componente de software solo se sobrecarga e inestable.
Las funciones más comunes de este componente incluyen:

Gestión de la conexión con la base de datos
La ejecución de SQL de manera eficiente (cursores y el intercambio de SQL)
Cliente la gestión de la información de estado
Equilibrar la carga de solicitudes de los usuarios a través de los recursos de hardware
El establecimiento de objetivos operacionales para los componentes de hardware / software
Colas persistentes para la ejecución asíncrona de tareas

2.4.1.2.4 Gestión de Datos y Operaciones

Este componente es en gran parte la responsabilidad del servidor de base de datos y el sistema operativo.
Las funciones más comunes de este componente incluyen:

Proporcionar acceso simultáneo a los datos mediante bloqueos y la semántica transaccional
Proporcionar un acceso optimizado a los datos utilizando los índices y la memoria caché
Asegurar que los cambios de datos se registran en el caso de un fallo de hardware
La aplicación de las reglas definidas para los datos

2.4.2 Configuración de la arquitectura del sistema ideal para sus necesidades

Configuración de la arquitectura inicial del sistema es un proceso iterativo en gran medida. Los arquitectos deben satisfacer los requisitos del sistema dentro del presupuesto y las limitaciones de horario. Si el sistema requiere que los usuarios interactivos transacciones de hacer negocios, las decisiones basadas en el contenido de una base de datos, los requisitos de usuario de la unidad de la arquitectura. Si hay pocos usuarios interactivos en el sistema, la arquitectura está basada en procesos.
Ejemplos de aplicaciones de usuario interactiva:

Contabilidad y cálculo de las aplicaciones
Sistemas de entrada de pedidos
Servidores de correo electrónico
Aplicaciones basadas en Web al por menor
Los sistemas de comercio

Ejemplos de aplicaciones para procesos:

Los sistemas de servicios de facturación
Sistemas de detección de fraude
El correo directo

En muchos sentidos, un proceso impulsado por las aplicaciones son más fáciles de diseñar que las aplicaciones multiusuario porque el elemento de la interfaz de usuario se elimina.Sin embargo, ya que los objetivos están orientados al proceso, los arquitectos no acostumbrado a tratar con grandes volúmenes de datos y factores de éxito puede llegar a confundirse. Proceso impulsado por las aplicaciones de sacar de las habilidades utilizadas en ambos conjuntos basados en el usuario de aplicaciones y almacenamiento de datos. Por lo tanto, este libro se centra en la evolución de las arquitecturas de sistema para los usuarios interactivos.

Nota:

La generación de una arquitectura de sistema no es un proceso determinista. Se requiere una cuidadosa consideración de los requerimientos del negocio, las opciones de tecnología, infraestructura y sistemas existentes, y la actual de los recursos físicos, tales como el presupuesto y mano de obra.

Las siguientes preguntas deberían estimular la reflexión sobre la arquitectura, aunque no son una guía definitiva para la arquitectura del sistema. Estas preguntas demuestran cómo los requerimientos del negocio puede influir en la arquitectura, la facilidad de implementación, y el rendimiento general y la disponibilidad de un sistema. Por ejemplo:

¿Cuántos usuarios del sistema de apoyo?
La mayoría de las aplicaciones de caer en una de las siguientes categorías:
- Muy pocos usuarios en una máquina ligera, utilizada o exclusivos
  Para este tipo de aplicación, por lo general hay un usuario. El enfoque de diseño de la aplicación es hacer que el usuario solo tan productivo como sea posible al ofrecer buen tiempo de respuesta, sin embargo, que la aplicación requiere una administración mínima. Los usuarios de estas aplicaciones rara vez interfieren unos con otros y tener un mínimo de conflictos de recursos.
- A mediano y gran número de usuarios en una empresa que utilice las aplicaciones compartidas
  Para este tipo de aplicación, los usuarios están limitados por el número de empleados de la corporación en realidad transacciones comerciales a través del sistema. Por lo tanto, el número de usuarios es predecible. Sin embargo, la entrega de un servicio confiable es fundamental para el negocio. Los usuarios van a utilizar un recurso compartido, por lo que los esfuerzos de diseño debe abordar el tiempo de respuesta bajo carga del sistema, la progresividad del recurso para cada uso la sesión, y espacio para el crecimiento futuro.
- Una población de usuarios infinitas distribuido en Internet
  Para este tipo de aplicación, los esfuerzos de ingeniería adicional es necesario para garantizar que ningún componente del sistema supera los límites de diseño. Esto crearía un cuello de botella que lleva al sistema a un alto y se vuelve inestable. Estas aplicaciones requieren de balanceo de carga compleja, servidores de aplicaciones sin estado, y la gestión eficiente de base de datos de conexión. Además, las estadísticas y los gobernadores se deben utilizar para garantizar que el usuario recibe una retroalimentación, si sus peticiones no puede ser satisfecha debido a la sobrecarga del sistema.
¿Cuál será el método de interacción con el usuario?
Las opciones de la gama de interfaces de usuario a partir de un simple navegador Web a un programa personalizado del cliente.
¿Dónde están los usuarios que se encuentran?
La distancia entre los usuarios influye en cómo la aplicación está diseñada para hacer frente a las latencias de red. La ubicación también afecta a que las horas del día están muy ocupados, cuando no es posible llevar a cabo funciones de lote o de mantenimiento del sistema.
¿Cuál es la velocidad de la red?
Velocidad de la red afecta a la cantidad de datos y el carácter conversacional de la interfaz de usuario con la aplicación y los servidores de base de datos. Una interfaz de usuario altamente conversacional puede comunicarse con los servidores back-end en cada golpe de tecla o validación sobre el terreno. Una interfaz de menos de conversación funciona en la pantalla-y envió una pantalla, recibió el modelo. En una red lenta, es imposible de alcanzar altas velocidades de entrada de datos con una interfaz de usuario de conversación.
Cantidad de datos que será el acceso de los usuarios, y la cantidad de datos que es en gran parte de sólo lectura?
La cantidad de datos consultados en línea influye en todos los aspectos del diseño, desde el diseño de la tabla y el índice de las capas de presentación. Los esfuerzos de diseño debe asegurar que el tiempo de respuesta del usuario no es una función del tamaño de la base de datos. Si la solicitud es en gran medida de sólo lectura, la replicación y distribución de datos en memorias caché locales en los servidores de aplicaciones convertido en una opción viable. Esto también reduce la carga de trabajo en el servidor de transacciones básicas.
¿Cuál es la respuesta de los usuarios requisito de tiempo?
Consideración del tipo de usuario es importante. Si el usuario es un ejecutivo que requiere de información precisa para dividir las decisiones de segundo, entonces el tiempo de respuesta del usuario no se puede comprometer. Otros tipos de usuarios, como los usuarios que realizan actividades de introducción de datos, no puede ser que necesite un alto nivel de rendimiento.
Hacer que los usuarios esperan 24 horas de servicio?
Esto es obligatorio para las aplicaciones de Internet de hoy, donde el comercio se lleva a cabo las 24 horas del día. Sin embargo, los sistemas corporativos que se ejecutan en una sola zona horaria puede ser capaz de tolerar después de horas de tiempo de inactividad. Este tiempo de inactividad después de la hora se puede utilizar para ejecutar procesos por lotes o para llevar a cabo la administración del sistema. En este caso, podría ser más económica que no se ejecute un sistema totalmente disponible.
Todos los cambios deben hacerse en tiempo real?
Es importante determinar si las transacciones se deben ejecutar en el tiempo de respuesta del usuario, o si pueden ser revisados por la ejecución asíncrona.

Los siguientes son cuestiones secundarias, que también puede influir en el diseño, pero en realidad tienen más impacto en el presupuesto y la facilidad de implementación. Por ejemplo:

¿Qué tan grande será la base de datos ser?
Esto influye en el tamaño de la máquina servidor de bases de datos. En sistemas con una gran base de datos, podría ser necesario tener una máquina más grande que la dictada por la carga de trabajo. Esto se debe a la sobrecarga de administración con grandes bases de datos es una función del tamaño de la base de datos. Como las tablas y los índices aumentan, se necesitan proporcionalmente más CPU para permitir la reorganización de tablas e índices se basa para completar en un plazo aceptable.
¿Cuál es el rendimiento requerido de las transacciones comerciales?
¿Cuáles son los requisitos de disponibilidad?
No existe capacidad para construir y administrar esta solicitud?
¿Qué compromisos se verá obligado por las limitaciones presupuestarias?

2.5 Principios de diseño de aplicaciones

Esta sección describe las siguientes decisiones de diseño que participan en la creación de aplicaciones:

2.5.1 La simplicidad en el diseño de aplicaciones

Las solicitudes no son diferentes de cualquier otro producto diseñado y desarrollado. Estructuras bien diseñadas, las máquinas y herramientas son generalmente confiables, fáciles de usar y mantener, y el concepto es simple. En los términos más generales, si el diseño es correcto, entonces probablemente lo es. Este principio debe mantenerse siempre en mente al crear aplicaciones.
Considere algunos de los siguientes aspectos del diseño:

Si el diseño de la tabla es tan complicado que nadie puede comprender totalmente, a continuación, la mesa es, probablemente, mal diseñados.
Si las sentencias SQL son tan largo y complicado que sería imposible para cualquier optimizador para que se pudiera optimizar en tiempo real, entonces es probable que haya una declaración mal, transacción subyacente, o diseño de la tabla.
Si hay índices en una tabla y las mismas columnas están indexadas en repetidas ocasiones, entonces es probable que haya un diseño de índice de pobres.
Si las consultas se presentó sin la calificación adecuada para una rápida respuesta para los usuarios en línea, entonces es probable que haya una interfaz de usuario pobre o el diseño de la transacción.
Si las llamadas a la base de datos se extraen fuera de la lógica de la aplicación de muchas capas de software, entonces es probable que haya un método de desarrollo de software mal.

2.5.2 Modelado de datos

El modelado de datos es importante para el éxito del diseño de aplicaciones relacionales. Esto debe hacerse de una manera que rápidamente se representa las prácticas de negocio.Lo más probable es, habrá acalorados debates sobre el modelo de datos correcto. Lo importante es la aplicación de mayores esfuerzos de modelado para las entidades afectadas por las transacciones de negocio más frecuentes. En la fase de modelado, hay una gran tentación de dedicar demasiado tiempo a modelar los elementos no esenciales de datos, lo que se traduce en un aumento de los plazos de desarrollo. El uso de herramientas de modelado puede generar rápidamente las definiciones de esquema y puede ser útil cuando un prototipo rápido es requerido.

2.5.3 Tabla y diseñar índices

Diseño de la tabla es en gran parte a un compromiso entre la flexibilidad y el rendimiento de las operaciones básicas. Para mantener la base de datos flexible y capaz de adaptarse a las cargas de trabajo previstas, el diseño de la tabla debe ser muy similar al modelo de datos, y debe ser normalizada, al menos en tercera forma normal. Sin embargo, algunas operaciones básicas requeridas por los usuarios puede requerir desnormalización selectiva para mejorar el rendimiento.
Ejemplos de esta técnica incluyen el almacenamiento de tablas pre-unido, la adición de columnas derivadas, y valores agregados. Oracle ofrece numerosas opciones para el almacenamiento de los agregados y los datos pre-acompañado por la agrupación y se materializó funciones de vista. Estas características permiten un diseño de tabla simple para ser aprobado inicialmente.
Una vez más, el enfoque y los recursos deben gastarse en las mesas de negocio críticos, por lo que el rendimiento óptimo se puede lograr. Para no críticos tablas, accesos directos en el diseño se pueden adoptar para permitir un desarrollo de aplicaciones más rápido. Sin embargo, si prototipos y pruebas de una mesa no esenciales se convierte en un problema de rendimiento, entonces el esfuerzo de recuperación de diseño se debe aplicar inmediatamente.
El diseño de índices es también un gran proceso iterativo, basado en el SQL generado por los diseñadores de aplicaciones. Sin embargo, es posible hacer un comienzo razonable por los índices de la construcción que hacen cumplir las restricciones de clave principal y los índices en los patrones de acceso conocidos, como el nombre de una persona. Como la aplicación se desarrolla y las pruebas se realizan sobre los montos reales de los datos, algunas preguntas se necesitan mejoras en el rendimiento para que la construcción de un índice mejor es una buena solución. La siguiente lista de ideas de diseño de indexación deben ser considerados en la construcción de un nuevo índice:

2.5.3.1 Añadiendo columnas de un índice o usando Índice de tablas organizadas

Una de las maneras más fáciles para acelerar una consulta es el de reducir el número de lógica E / S mediante la eliminación de un acceso a la tabla del plan de ejecución. Esto puede hacerse añadiendo al índice de todas las columnas referenciadas por la consulta. Estas columnas son las columnas de lista de selección, y cualquier otro necesario unirse o columnas de orden. Esta técnica es particularmente útil en la aceleración de aplicaciones en línea de los tiempos de respuesta al tiempo de E / S se reducen. Esto se aplica mejor al probar la aplicación con los datos del tamaño adecuado, por primera vez.
La forma más agresiva de esta técnica es la construcción de una organizada por índices de mesa (IOT). Sin embargo, hay que tener cuidado de que el aumento de tamaño de la hoja de una IOT no socavar los esfuerzos para reducir la E / S.

2.5.3.2 El uso de un tipo de índice diferente

Hay varios tipos de índices disponibles, y cada índice tiene ventajas para ciertas situaciones. La siguiente lista nos da ideas de rendimiento asociados con cada tipo de índice.

2.5.3.2.1 índices B-tree

Estos índices son el tipo de índice estándar, y son excelentes para los principales índices de clave y altamente selectivo. Utilizados como índices concatenados, B-tree índices pueden ser usados para recuperar los datos ordenados por las columnas de índice.

2.5.3.2.2 índices de mapa de bits

Estos índices son adecuados para los datos de cardinalidad baja. A través de técnicas de compresión, que pueden generar un gran número de ROWIDs con un mínimo de I / O. La combinación de los índices de mapa de bits en la no-selectiva columnas permite eficiente Y y O las operaciones con un gran número de ROWIDs con un mínimo de I / O. Los índices de mapa de bits son particularmente eficientes en las consultas con CONTAR (), porque la consulta puede ser satisfecho en el índice.

2.5.3.2.3 Función de los índices basados en

Estos índices permiten el acceso a través de un B-tree en un valor derivado de una función en la base de datos. Basado en función de los índices tienen algunas limitaciones en lo que respecta al uso de valores nulos, y que requieren que usted tenga el optimizador de consultas habilitado.
Basado en función de los índices son especialmente útiles cuando se consulta en columnas compuestas para producir un resultado derivado o para superar las limitaciones en la forma de datos se almacenan en la base de datos. Un ejemplo es la consulta de elementos de línea en un orden superior a un cierto valor derivado de (precio de venta - de descuento) la cantidad x, donde se trataba de columnas de la tabla. Otro ejemplo es la aplicación de la alta función de los datos para permitir búsquedas de mayúsculas y minúsculas.

2.5.3.2.4 índices con particiones

Particiones en un índice global permite la poda partición que tendrá lugar dentro de un índice de acceso, que se traduce en reducción de E / S. Por definición del rango de bueno o partición de la lista, el índice rápidamente explora una de las particiones de índice correcto puede resultar en tiempos de consulta muy rápido.

2.5.3.2.5 índices de clave inversa

Estos índices están diseñados para eliminar los puntos calientes en índice de las aplicaciones de inserción. Estos índices son excelentes para el desempeño de inserción, pero están limitados en cuanto a que no se puede utilizar para escaneo de rangos de índices.

2.5.3.3 Encontrar el costo de un Índice de

Construcción y mantenimiento de una estructura de índice puede ser costoso, y puede consumir recursos como el espacio en disco, CPU, y la capacidad de E / S. Los diseñadores deben asegurar que los beneficios de cualquier índice superan a los negativos de mantenimiento de índices.
Use esta guía simple estimación de los costos de mantenimiento de índices: cada índice que mantiene una instrucción INSERT , DELETE , o ACTUALIZACIÓN de las claves del índice requiere tres veces más de recursos tanto como el funcionamiento real de DML en la tabla. Lo que esto significa es que si usted INSERTAR en una tabla con tres índices, entonces será aproximadamente 10 veces más lento que un INSERTAR en una tabla sin índices. De DML, y en particular para INSERTAR aplicaciones pesadas, el diseño del índice debe ser seriamente analizado, el cual podría requerir un compromiso entre la consulta y INSERTAR rendimiento.

Ver también:

Guía del administrador de base de datos Oracle para obtener información sobre la vigilancia del uso de índice

2.5.3.4 Seriación dentro de los índices

El uso de secuencias, o marcas de tiempo, para generar los valores fundamentales que están indexados se puede llevar a problemas de punto de acceso de base de datos, que afectan el tiempo de respuesta y el rendimiento. Este suele ser el resultado de una clave monótona creciente que se traduce en un índice de crecimiento de la derecha. Para evitar este problema, tratar de generar las claves que se insertan en todo el rango del índice. Esto se traduce en un índice bien equilibrada que es más escalable y eficiente del espacio.Puede lograr esto mediante el uso de un índice de clave inversa o mediante una secuencia de ciclos a los valores de prefijo y una secuencia.

2.5.3.5 Columnas de pedido en un índice

Los diseñadores deben ser flexibles en la definición de las reglas para la construcción del índice. Dependiendo de sus circunstancias, utilice uno de los siguientes dos formas de pedir las llaves en un índice:

Columnas de orden con la mayoría de selectividad en primer lugar. Este método es el más utilizado, ya que proporciona el acceso más rápido con un mínimo de E / S a la ROWIDs real necesario. Esta técnica se utiliza principalmente para las claves principales y para el escaneo de rangos muy selectivo.
Columnas para reducir la E / S de la agrupación o la clasificación de datos. En las exploraciones amplia gama, E / S por lo general se puede reducir al ordenar las columnas en el orden por lo menos selectiva, o de una manera que ordena los datos en la forma en que debe ser recuperada. Vea el Capítulo 14, "Uso de Índices y Clusters" .

2.5.4 Uso de Vistas

Las vistas pueden acelerar y simplificar el diseño de aplicaciones. Una definición simple vista puede ocultar la complejidad de los datos del modelo de los programadores, cuyas prioridades son para recuperar, mostrar, recopilar y almacenar datos.
Sin embargo, mientras que las vistas proporcionan interfaces de programación de limpieza, pueden causar sub-óptimo, requiere muchos recursos consultas. El peor tipo de uso del punto de vista es cuando una vista hace referencia a otros puntos de vista, y cuando se juntan en las consultas. En muchos casos, los desarrolladores pueden satisfacer la consulta directamente de la tabla sin usar un punto de vista. Por lo general, debido a sus propiedades, puntos de vista hacen que sea difícil para el optimizador para generar el plan de ejecución óptimo.

2.5.5 SQL eficiencia en la ejecución

En la fase de diseño y arquitectura de cualquier sistema de desarrollo, se debe tener cuidado para asegurar que los desarrolladores de aplicaciones de entender la eficiencia de ejecución de SQL. Para ello, el entorno de desarrollo debe ser compatible con las siguientes características:

Buena base de datos de gestión de conexión
La conexión a la base de datos es una operación costosa que es muy inaccesibles. Por lo tanto, el número de conexiones simultáneas a la base de datos se debe minimizar tanto como sea posible. Un sistema simple, donde un usuario se conecta a la inicialización de la aplicación, es ideal. Sin embargo, en una aplicación basada en Web o de varios niveles, donde los servidores de aplicaciones se utilizan para las conexiones de base de datos múltiple a los usuarios, esto puede ser difícil. Con este tipo de aplicaciones, los esfuerzos de diseño debe garantizar que las conexiones de base de datos se agrupan y no se restableció por cada petición del usuario.
El buen uso del cursor y de gestión
El mantenimiento de conexiones de usuario es igual de importante para reducir al mínimo la actividad de análisis en el sistema. Análisis es el proceso de interpretación de una sentencia SQL y la creación de un plan de ejecución de la misma. Este proceso tiene muchas fases, incluida la comprobación de sintaxis, de verificación de seguridad, generación de plan de ejecución, y la carga de estructuras compartidas en la piscina comunitaria. Existen dos tipos de operaciones de análisis:
- Análisis duro: Una sentencia SQL se presenta por primera vez, y no hay coincidencia en la zona compartida. Duro analiza son los más intensivos en recursos y no escalable, ya que realizar todas las operaciones involucradas en un análisis.
- Análisis de Soft: Una sentencia SQL se presenta por primera vez, y un partido se encuentra en la zona compartida. El partido puede ser el resultado de la ejecución previa de otro usuario. La sentencia SQL es compartida, lo cual es bueno para el rendimiento. Sin embargo, suave analiza no son las ideales, debido a que todavía requieren una sintaxis y la comprobación de seguridad, que consumen recursos del sistema.
Dado que el análisis se debe minimizar tanto como sea posible, los desarrolladores de aplicaciones deben diseñar sus aplicaciones para analizar las sentencias SQL de una vez y ejecutar muchas veces. Esto se hace a través de los cursores. Experimentados programadores de SQL debe estar familiarizado con el concepto de apertura y re-ejecución de los cursores.
Los desarrolladores de aplicaciones también deben garantizar que las sentencias SQL se comparten dentro de la piscina comunitaria. Para ello, se unen las variables que representan las partes de la consulta que el cambio de la ejecución de la ejecución. Si esto no se hace, entonces la sentencia de SQL es probable que sea analizada una vez y nunca re-utilizados por otros usuarios. Para asegurarse de que SQL es compartida, utilice las variables se unen y no utilizar literales de cadena con sentencias SQL. Por ejemplo:
Declaración con literales de cadena:
```
SELECT * FROM empleados WHERE apellidos LIKE 'REY';
```
Declaración de variables ligadas:
```
SELECT * FROM empleados WHERE apellidos LIKE: 1;
```
El siguiente ejemplo muestra los resultados de algunas pruebas en una sencilla aplicación OLTP:
```
Prueba n º usuarios soportados No análisis de todas las declaraciones de 270 análisis de todas las declaraciones Soft 150 análisis de todas las declaraciones duro 60 Re-Conexión para cada transacción 30
```
Estas pruebas se realizaron en una máquina de cuatro CPU. Las diferencias aumentan a medida que el número de CPUs en el sistema de aumento. Ver el capítulo 16, "Visión general de SQL Tuning" para obtener información sobre la optimización de sentencias SQL.

2.5.6 Implementación de la aplicación

La elección del entorno de desarrollo y lenguaje de programación es en gran parte una función de las capacidades disponibles en el equipo de desarrollo y las decisiones arquitectónicas hechas cuando se especifica la aplicación. Hay, sin embargo, algunas reglas simples de gestión de rendimiento que puede dar lugar a escalables y de alto rendimiento de las aplicaciones.

Elegir un entorno de desarrollo adecuado de los componentes de software, y no dejes que se limite su diseño para las decisiones de rendimiento. Si lo hace, entonces es probable que eligió el idioma incorrecto o el medio ambiente.
- Interfaz de usuario
  El modelo de programación puede variar entre la generación de HTML y llamar al sistema de ventanas directamente. El método de desarrollo deberían centrarse en el tiempo de respuesta del código de interfaz de usuario. Si el HTML o Java se envían a través de una red, a continuación, tratar de minimizar el volumen de la red y las interacciones.
- Lógica de Negocio
  Lenguajes interpretados, como Java y PL / SQL, es ideal para codificar la lógica de negocio. Son totalmente portátiles, lo que facilita la actualización lógica relativamente fácil. Ambos lenguajes son sintácticamente ricos para permitir que el código que sea fácil de leer e interpretar. Si la lógica de negocio requiere complejas funciones matemáticas, a continuación, un lenguaje binario compilado podría ser necesaria. El código de la lógica de negocio puede estar en la máquina cliente, el servidor de aplicaciones, y el servidor de base de datos. Sin embargo, el servidor de aplicaciones es el lugar más común para la lógica empresarial.
- Solicitudes de usuario y asignación de recursos
  La mayor parte de esto no se ve afectada por el lenguaje de programación, pero las herramientas y lenguajes de 4 ª generación que la conexión de bases de datos y máscara de gestión del cursor puede utilizar los mecanismos ineficientes. Al evaluar estas herramientas y entornos, comprobar su modelo de conexión de bases de datos y su uso de los cursores y las variables se unen.
- Gestión de datos y transacciones
  La mayor parte de esto no se ve afectada por el lenguaje de programación.
Al implementar un componente de software, ejecutar su función y no la funcionalidad asociada con otros componentes. Aplicación de los resultados de otro componente en la funcionalidad óptimas diseños e implementaciones. Esto se aplica a todos los componentes.
No dejar huecos en la funcionalidad o componentes de software investigado en el diseño, implementación o pruebas. En muchos casos, las diferencias no se descubren hasta que la aplicación es lanzada al mercado o probadas en volúmenes realistas. Este suele ser un signo de la arquitectura pobre o especificación inicial del sistema. Datos de archivo modules / purga con más frecuencia descuidado durante el diseño inicial del sistema, construcción e implementación.
Al aplicar la lógica de procedimiento, la aplicación en un lenguaje procedural, como C, Java o PL / SQL. En la aplicación de acceso a datos (consultas) o los cambios de datos (DML), el uso de SQL. Esta norma es específica para los módulos de lógica de negocio de código donde se mezcla con el código de procedimiento de acceso a datos (no de procedimiento SQL). No es grande la tentación de poner la lógica de procedimiento en el acceso SQL. Esto tiende a resultar en un rendimiento de SQL que es intensivo en recursos. Sentencias SQL con DESCODIFICAR declaraciones de casos son muy a menudo los candidatos para la optimización, como son las declaraciones con una gran cantidad de O predicados u operadores del sistema, tales como UNION y MINUS .
Caché se accede con frecuencia, rara vez cambio de datos que es caro para recuperar de manera repetida. Sin embargo, hacen de este mecanismo de caché fácil de usar, y asegurarse de que sí es más barato que el acceso a los datos en el método original. Esto es aplicable a todos los módulos que utilizan con frecuencia los valores de datos deben ser almacenados en caché o almacenar localmente, en lugar de ser varias veces recuperan de un almacén de datos a distancia o cara.
Los ejemplos más comunes de los candidatos para almacenamiento local son los siguientes:
- Fecha de hoy. SELECCIONAR SYSDATE DE DOBLE puede dar cuenta de más del 60% de la carga de trabajo en una base de datos.
- El nombre del usuario actual.
- Repite las variables de aplicación y las constantes, tales como las tasas de impuestos, las tasas de descuento, o la información de ubicación.
- Caché de datos a nivel local puede ser extendido en la construcción de una caché de datos locales en los niveles medio del servidor de aplicaciones. Esto ayuda a tomar la carga de los servidores de base de datos central. Sin embargo, se debe tener cuidado en la construcción de depósitos locales a fin de que no es tan compleja que dejan de dar una ganancia de rendimiento.
- Generación de la secuencia local.
Las implicaciones del diseño de la utilización de una memoria caché debe ser considerado. Por ejemplo, si un usuario está conectado a la medianoche y la fecha en que se almacenan en caché, entonces el valor del usuario la fecha no es válida.
Optimizar las interfaces entre los componentes y garantizar que todos los componentes se utilizan en la configuración más escalable. Esta norma exige un mínimo de explicaciones y se aplica a todos los módulos y sus interfaces.
Use referencias de claves externas. Exigir la integridad referencial a través de una aplicación es costosa. Usted puede mantener una referencia de clave externa, seleccione el valor de columna de los niños de los padres y asegurar que existe. La aplicación de restricción de clave externa suministrada por Oracle, que no utiliza SQL, es rápido, fácil de declarar, y no crea el tráfico de red.
Considerar la creación de la acción y los nombres de módulo en la aplicación para utilizar con De extremo a extremo de aplicaciones de localización. Esto permite una mayor flexibilidad en la localización de los problemas de carga de trabajo. Ver "de extremo a extremo de aplicaciones de seguimiento" .

2.5.7 Tendencias en el desarrollo de aplicaciones

Los dos mayores retos en el desarrollo de aplicaciones hoy en día son el aumento del uso de Java para reemplazar compilado en C o C + +, y el mayor uso de técnicas orientadas a objetos, que influyen en el diseño del esquema.
Java proporciona una mayor portabilidad del código y la disponibilidad de los programadores. Sin embargo, hay una serie de implicaciones de rendimiento asociados con Java. Dado que Java es un lenguaje interpretado, es más lento en la ejecución de la misma lógica que los lenguajes compilados como C. Como resultado, el uso de recursos de las máquinas cliente aumenta. Esto requiere CPUs más potentes que se aplicarán en el cliente o de nivel medio de máquinas y una mayor atención de los programadores generar código eficiente.
Dado que Java es un lenguaje orientado a objetos, alienta el aislamiento de acceso a los datos en clases de no realizar la lógica de negocio. Como resultado, los programadores podrían invocar métodos, sin el conocimiento de la eficiencia del método de acceso a los datos que se utiliza. Esto tiende a resultar en un acceso de base de datos que es muy mínima y utiliza las interfaces más simples y más cruda de la base de datos.
Con este tipo de diseño de software, las consultas no siempre incluyen todos los DONDE predicados para ser eficiente, y el filtrado de fila se lleva a cabo en el programa Java. Esto es muy ineficiente. Además, para las operaciones de DML-y especialmente para INSERTAR s-solo INSERTAR s se llevan a cabo, haciendo uso de la interfaz de serie imposible. En algunos casos, esto se hace más ineficiente de las llamadas a procedimientos. Se utilizan más recursos de mover los datos hacia y desde la base de datos que en las llamadas de base de datos real.
En general, lo mejor es colocar el acceso de llamadas de datos junto a la lógica de negocio para lograr el mejor diseño de operación en general.
La aceptación de la orientación a objetos en un nivel de programación se ha llevado a la creación de bases de datos orientadas a objetos en el servidor Oracle. Esto se ha manifestado de muchas maneras, desde el almacenamiento de las estructuras objeto dentro de BLOB s, y sólo con la base de datos con eficacia como un archivo de tarjeta de índice para el uso de las características del objeto relacional Oracle.
Si usted adopta un enfoque orientado a objetos para el diseño del esquema, asegúrese de que no se pierde la flexibilidad del modelo de almacenamiento relacional. En muchos casos, el enfoque orientado a objetos para el diseño del esquema termina en una estructura de datos sin normalizar en gran medida que requiere el mantenimiento y la considerableREF indicadores asociados a los objetos. A menudo, estos diseños representan un paso atrás para los diseños de base de datos jerárquica y la red que fueron sustituidos por el método de almacenamiento relacional.
En resumen, si usted está almacenando sus datos en su base de datos para el largo plazo y prever un grado de consultas ad hoc o el desarrollo de aplicaciones en el mismo esquema, entonces usted probablemente encontrará que el método de almacenamiento relacional ofrece el mejor rendimiento y flexibilidad.

2.6 Carga de trabajo de pruebas, modelado e implementación

En esta sección se describe la estimación de la carga de trabajo, modelado, implementación y pruebas. Esta sección cubre los siguientes temas:

2.6.1 Dimensionamiento de datos

Usted puede experimentar errores en sus estimaciones de tamaño cuando se trata de datos de longitud variable, si se trabaja con un conjunto de muestras pobres. Ya que los volúmenes de datos crecen, su longitud de las claves podría crecer considerablemente, la alteración de sus suposiciones para los tamaños de las columnas.
Cuando el sistema entre en funcionamiento, se hace más difícil predecir el crecimiento de la base de datos, especialmente para los índices. Tablas de crecer con el tiempo, y los índices están sujetos a la conducta individual de la aplicación en términos de generación de claves, el patrón de inserción y eliminación de filas. El peor caso es donde se inserta mediante una clave ascendente, a continuación, eliminar la mayoría de las filas de la izquierda, pero no todas las filas. Esto deja lagunas y espacios perdidos. Si usted tiene el uso de este índice, asegúrese de que sabe cómo utilizar el servicio de reconstrucción de índices en línea.
DBA debe monitorear la asignación de espacio para cada objeto y buscar objetos que pueden crecer fuera de control. Una buena comprensión de la aplicación se puede resaltar los objetos que pueden crecer rápidamente y de forma impredecible. Esta es una parte crucial del rendimiento y planificación de la disponibilidad de cualquier sistema. Al aplicar la base de datos de producción, el diseño debe tratar de garantizar que la gestión de un espacio mínimo se lleva a cabo cuando los usuarios interactivos se utiliza la aplicación. Esto se aplica a todos los datos, temporales, y los segmentos de rollback.

2.6.2 Cálculo de las cargas de trabajo

Estimación de la carga de trabajo para planificar la capacidad y los propósitos de prueba se describe a menudo como un arte negro. Al considerar el número de variables involucradas, es fácil ver por qué este proceso es prácticamente imposible de obtener con precisión correcta. Sin embargo, los diseñadores deben especificar las máquinas con CPU, memoria y unidades de disco, y, finalmente, lanzar una aplicación. Hay una serie de técnicas que se utilizan para determinar el tamaño, y cada técnica tiene su mérito. Cuando el tamaño, lo mejor es utilizar los dos métodos siguientes para validar la toma de decisiones y proporcionar la documentación de apoyo:

2.6.2.1 La extrapolación de un sistema similar

Este es un enfoque totalmente empírico en el que se utiliza un sistema existente de similares características y el rendimiento se conoce como un sistema de base. La especificación de este sistema es modificado por el especialista en tamaño de acuerdo a las diferencias conocidas. Este enfoque tiene la ventaja de que se correlaciona con un sistema existente, pero ofrece muy poca ayuda cuando se trata de las diferencias.
Este método se usa en casi todas las disciplinas de ingeniería a gran hora de preparar el costo de un proyecto de ingeniería, como un gran edificio, un barco, un puente o una plataforma petrolífera. Si el sistema de referencia es un orden de magnitud diferente en el tamaño del sistema previsto, a continuación, algunos de los componentes puede haber excedido sus límites de diseño.

2.6.2.2 Benchmarking

El proceso de benchmarking es tanto de recursos y tiempo, y es posible que no producen los resultados correctos. Mediante la simulación de una aplicación en el desarrollo temprano o forma de prototipo, se corre el riesgo de medir algo que no tiene parecido con el sistema de producción actual. Esto suena extraño, pero en los últimos años muchas de las aplicaciones de los clientes de referencia con la organización de desarrollo de bases de datos, Oracle todavía no ha visto una correlación fiable entre la solicitud de referencia y el sistema de producción actual. Esto se debe principalmente al número de solicitudes presentadas ineficiencias en el proceso de desarrollo.
Sin embargo, los puntos de referencia se han utilizado con éxito para sistemas de tamaño a un nivel aceptable de precisión. En particular, los puntos de referencia son muy buenos en la determinación de la E / S reales necesidades y los procesos de pruebas de recuperación cuando el sistema está totalmente cargado.
Puntos de referencia por su naturaleza, el estrés de todos los componentes del sistema a sus límites. Como todos los componentes están estresados, estar preparados para ver todos los errores en el diseño de la aplicación e implementación se manifiestan al mismo tiempo de referencia. Puntos de referencia también prueba de la base de datos, sistema operativo y los componentes de hardware. Como la mayoría de los puntos de referencia se llevan a cabo en un apuro, le espera contratiempos y problemas cuando un componente del sistema falla. El benchmarking es una actividad estresante, y que se necesita experiencia para sacar el máximo provecho de un ejercicio de benchmarking.

2.6.3 Aplicación de modelado

Modelado de la aplicación puede variar desde complejos ejercicios de modelización matemática de los cálculos clásicos simples realizadas en el reverso de un sobre. Ambos métodos tienen sus méritos, con un intento de ser muy preciso y el otro la realización de estimaciones brutas. La desventaja de ambos métodos es que no permiten errores de implementación y las ineficiencias.
El proceso de estimación y el tamaño es una ciencia imprecisa. Sin embargo, al investigar el proceso, algunas estimaciones inteligente se puede hacer. El proceso de estimación de todo no hace las asignaciones para las ineficiencias solicitud presentada por los pobres SQL, diseño de índices, o de gestión del cursor. Un ingeniero de tamaño debe construir en el margen de las ineficiencias de la aplicación. Un ingeniero de desempeño deben descubrir las ineficiencias y hace que las estimaciones de aspecto realista. El proceso de descubrir las deficiencias de aplicación se describe en el método de rendimiento de Oracle.

2.6.4 prueba, depuración y validación de un diseño

El proceso de prueba se compone principalmente de pruebas funcionales y de estabilidad. En algún momento del proceso, las pruebas de rendimiento se lleva a cabo.
La siguiente lista describe algunas reglas simples para probar el funcionamiento de una aplicación. Si bien documentado, este proporciona información importante para la aplicación de producción y el proceso de planificación de la capacidad después de la aplicación ha ido en directo.

Utilice la base de datos de Monitor de Diagnóstico Automático (ADDM) y la optimización de SQL para la validación del diseño
Prueba con los volúmenes de datos realistas y distribuciones
Todas las pruebas deben hacerse con tablas completamente llena. La base de datos de ensayo deberán contener datos representativos del sistema de producción en términos de volumen de datos y la cardinalidad entre tablas. Todos los índices de producción deben ser construidas y las estadísticas de esquema se debe rellenar correctamente.
Utilice el modo de optimizador correcta
Todas las pruebas deben realizarse con el modo de optimización que se utiliza en la producción. Todas las investigaciones y esfuerzos de desarrollo de Oracle se centra en el optimizador de consultas, y por lo tanto el uso del optimizador de consultas se recomienda.
Prueba de una actuación de usuario único
Un solo usuario en un sistema inactivo o ligeramente usado, debe ser probado para un rendimiento aceptable. Si un usuario no puede obtener un rendimiento aceptable en condiciones ideales, es imposible que no habrá un desempeño aceptable en virtud de múltiples usuarios, donde los recursos son compartidos.
Obtener y documentar los planes de todas las sentencias SQL
Obtener un plan de ejecución de cada instrucción SQL, y algunos indicadores se deben obtener por lo menos una ejecución de la sentencia. Este proceso debe ser utilizado para validar que un plan de ejecución óptima se obtiene por el optimizador, y el costo relativo de la sentencia de SQL se entiende en términos de tiempo de CPU y E / S físicas.Este proceso ayuda a identificar las operaciones de uso intensivo que requieren mayor ajuste y rendimiento en el trabajo en el futuro.
Intento de prueba multiusuario
Este proceso es difícil de realizar con precisión, porque la carga de trabajo y perfiles de usuario pueden no estar totalmente cuantificado. Sin embargo, las transacciones de realizar declaraciones DML debe ser probado para asegurar que no hay conflictos o problemas de bloqueo de serialización.
Prueba con la configuración del hardware adecuado
Es importante probar con una configuración lo más cerca posible del sistema de producción posible. Esto es particularmente importante con respecto a las latencias de red, E / S de ancho de banda del subsistema, y el tipo de procesador y la velocidad. El hecho de no hacer esto podría resultar en un análisis erróneo de los problemas potenciales de rendimiento.
Medir el desempeño de estado estable
Cuando la evaluación comparativa, es importante para medir el rendimiento en condiciones estables. Cada corrida de referencia debe tener una fase de ramp-up, donde los usuarios están conectados a la aplicación y poco a poco comenzar a realizar el trabajo de la aplicación. Este proceso permite que los datos almacenados en caché con frecuencia se inicia en la memoria caché y las operaciones, tales como el análisis de la ejecución individual, para ser terminado antes de que la condición de estado estacionario. Del mismo modo, al final de una carrera de referencia, debe haber un período de desaceleración, donde se liberan los recursos del sistema y los usuarios dejar de trabajar y desconectar.

2.7 despliegue de nuevas aplicaciones

Esta sección describe las siguientes decisiones de diseño que participan en el despliegue de aplicaciones:

2.7.1 Estrategias de Implantación

Cuando las nuevas aplicaciones se implanten, hay dos estrategias comúnmente adoptadas:

Gran enfoque Bang - todos los usuarios a migrar al nuevo sistema a la vez
Goteo enfoque - los usuarios poco a poco la migración de los sistemas existentes a la nueva

Ambos métodos tienen ventajas y desventajas. El enfoque del Big Bang se basa en las pruebas de fiabilidad de la aplicación a la escala requerida, pero tiene la ventaja de la conversión de un mínimo de datos y sincronización con el sistema antiguo, porque es simplemente apagado. El enfoque por goteo permite la depuración de problemas de escalabilidad a medida que aumenta la carga de trabajo, pero podría significar que los datos necesitan ser migrados y de los sistemas heredados como la transición se lleva a cabo.
Es difícil recomendar un enfoque sobre el otro, ya que cada método tiene riesgos asociados que podrían llevar a interrupciones en el sistema como la transición se lleva a cabo. Sin duda, el enfoque por goteo permite que el perfil de los usuarios reales, ya que se introducen a la nueva aplicación, y permite que el sistema sea reconfigurado mientras que sólo afecten a los usuarios a migrar. Este enfoque afecta el trabajo de los primeros en adoptar, sino que se limita la carga de los servicios de apoyo. Esto significa que no programado cortes sólo afectan a un pequeño porcentaje de la población de usuarios.
La decisión sobre cómo poner en marcha una nueva aplicación es específica para cada negocio. El enfoque adoptado tiene su propio y único presiones y tensiones. La prueba más y el conocimiento derivados del proceso de pruebas, más te darás cuenta de lo que es mejor para el lanzamiento.

2.7.2 Lista de verificación del rendimiento

Para ayudar en el proceso de despliegue, crear una lista de tareas que-si se realiza correctamente, aumenta la probabilidad de un rendimiento óptimo en la producción y si hay un problema de depuración a activar rápidamente la aplicación:

Cuando se crea el archivo de control para la base de datos de producción, permitir el crecimiento mediante el establecimiento de MaxInstances , MAXDATAFILES ,MAXLOGFILES , MAXLOGMEMBERS y MAXLOGHISTORY a los valores más altos que lo que anticipamos para el lanzamiento. Esta vez se traduce en más espacio en disco y el uso de grandes archivos de control, sino que ahorra más adelante si estos necesitan de extensión en caso de emergencia.
Establecer el tamaño de bloque para el valor utilizado para desarrollar la aplicación. Las estadísticas de exportación de esquema desde el entorno de desarrollo / prueba para la base de datos de producción si la prueba se llevó a cabo en los volúmenes de datos representativos y los actuales planes de ejecución de SQL es correcta.
Establecer el número mínimo de parámetros de inicialización. Lo ideal sería que la mayoría de los otros parámetros se debe dejar por defecto. Si hay más ajuste para llevar a cabo, esto se manifiesta cuando el sistema está bajo carga.
Esté preparado para administrar la contención de bloques mediante el establecimiento de opciones de almacenamiento de objetos de base de datos. Tablas e índices que la experiencia de alta INSERTAR / ACTUALIZACIÓN / DELETE tasas deben ser creados con la gestión automática del segmento espacial. Para evitar la contención de los segmentos de rollback, gestión automática de deshacer debe ser utilizado.
Todas las sentencias SQL se debe verificar que sean óptimas y se entiende su uso de los recursos.
Validar que el middleware y los programas que se conectan a la base de datos son eficientes en su gestión de la conexión y no de inicio de sesión / cierre de sesión en varias ocasiones.
Comprobar que las sentencias SQL utiliza cursores de manera eficiente. Cada sentencia SQL debe ser analizada una vez y luego ejecutan varias veces. La razón más común esto no sucede es porque las variables se unen no se utilizan correctamente y DONDE predicados cláusula se envían como literales de cadena. Si el precompiladores se utilizan para desarrollar la aplicación, asegúrese de que los parámetros MAXOPENCURSORS , HOLD_CURSOR y RELEASE_CURSOR se han restablecido los valores por defecto antes de precompilar la aplicación.
Validar que todos los objetos de esquema han sido correctamente migrado desde el entorno de desarrollo para la base de datos de producción. Esto incluye tablas, índices, secuencias, triggers, paquetes, procedimientos, funciones, objetos Java, sinónimos, subvenciones y puntos de vista. Asegúrese de que todas las modificaciones realizadas en las pruebas se realizan en el sistema de producción.
Tan pronto como el sistema es lanzada al mercado, establecer un conjunto básico de estadísticas del sistema de base de datos y de funcionamiento. Este primer conjunto de estadísticas de valida o corrige las hipótesis formuladas en el proceso de diseño y puesta en marcha.
Comenzarán a anticipar el primer cuello de botella (siempre hay uno) y seguir el método de rendimiento de Oracle para mejorar el rendimiento. Para más información.

El rendimiento de Oracle mejora el método

Metodología del rendimiento de Oracle ayuda a identificar problemas de rendimiento en el sistema Oracle. Esto implica la identificación de bo ttlenecks y la fijación de ellos. Se recomienda que se hagan cambios en un sistema sólo después de haber confirmado que existe un cuello de botella.
Mejora del rendimiento, por su naturaleza, es repetitivo. Por esta razón, la eliminación del primer cuello de botella no podría conducir a la mejora del rendimiento inmediato, ya que otro cuello de botella puede ser revelado. Además, en algunos casos, si los puntos de serialización pasar a un mecanismo de reparto más eficiente, el rendimiento puede degradarse.Con la experiencia, y siguiendo un riguroso método de eliminación de cuellos de botella, las aplicaciones pueden ser depurado e hizo escalable.
Problemas de rendimiento en general el resultado de ya sea una falta de rendimiento, inaceptable usuario / trabajo el tiempo de respuesta, o ambas cosas. El problema puede estar ubicado entre los módulos de aplicación, o puede ser que sea para todo el sistema.
Antes de pasar a cualquier base de datos o las estadísticas del sistema operativo, es crucial para obtener retroalimentación de los componentes más importantes del sistema: los usuarios del sistema y el pueblo en última instancia, el pago de la solicitud. Comentarios de los usuarios típicos incluyen afirmaciones como las siguientes:

"El desempeño en línea es tan grave que impide que mi equipo de hacer su trabajo."

"La carrera de facturación lleva demasiado tiempo."

"Cuando la experiencia altas cantidades de tráfico web, el tiempo de respuesta se hace inaceptable, y estoy perdiendo clientes."

"Actualmente estoy realizando 5000 operaciones al día, y el sistema está al máximo. El próximo mes, lanzamos a todos nuestros usuarios, y el número de negociaciones se espera multiplicar por cuatro".

De regeneración sincera, es fácil de configurar los factores críticos de éxito para cualquier desempeño laboral. La determinación de las metas de desempeño y criterios del ingeniero rendimiento de salida de que la gestión del proceso de ejecución mucho más simple y más exitoso de todos los niveles. Estos factores críticos de éxito están mejor definidos en términos de los objetivos de negocio reales en lugar de las estadísticas del sistema.
Algunos de los objetivos de negocio real para estas declaraciones usuario típico podría ser:

"La carrera de facturación debe procesar 1.000.000 de cuentas en una ventana de tres horas."

"En un período máximo de un sitio Web, el tiempo de respuesta no superior a cinco segundos para una actualización de la página."

"El sistema debe ser capaz de procesar 25.000 transacciones en una ventana de ocho horas."

La medida del éxito será la percepción del usuario del rendimiento del sistema. El papel del ingeniero de desempeño es la de eliminar los cuellos de botella que afectan al rendimiento. Estos cuellos de botella pueden ser causados por el uso ineficiente de los limitados recursos compartidos, o por el abuso de los recursos compartidos, lo que la serialización. Debido a que todos los recursos compartidos son limitados, el objetivo de un ingeniero de desempeño es el de maximizar el número de operaciones comerciales con el uso eficiente de los recursos compartidos. A un nivel muy alto, el servidor de base de datos completa puede ser vista como un recurso compartido. Por el contrario, en un nivel bajo, una sola CPU o disco puede ser visto como los recursos compartidos.
El rendimiento de Oracle método de mejora se puede aplicar hasta que los objetivos de rendimiento se cumplen o se considera imposible. Este proceso es muy repetitivo, y es inevitable que algunas investigaciones se realizarán de que tienen poco impacto en el rendimiento del sistema. Se necesita tiempo y experiencia para desarrollar las habilidades necesarias para determinar con precisión los cuellos de botella críticos en el momento oportuno. Sin embargo, la experiencia previa a veces puede trabajar en contra del ingeniero con experiencia que se niega a utilizar los datos y las estadísticas a su disposición. Es este tipo de conducta que fomenta la puesta a punto base de datos por el mito y el folclore. Este es un método muy arriesgado, caro, y pocas posibilidades de éxito de la puesta a punto base de datos.
La base de datos de Monitor de Diagnóstico Automático (ADDM) implementa las partes del método de mejora del rendimiento y análisis de estadísticas para proporcionar un diagnóstico automático de los problemas de rendimiento importantes. Utilizando ADDM puede acortar significativamente el tiempo necesario para mejorar el rendimiento de un sistema. Ver el capítulo 6, "Diagnóstico de rendimiento automático" para una descripción de ADDM.
Los sistemas de hoy son tan diversas y complejas que las reglas duras y rápidas para análisis de rendimiento no se puede hacer. En esencia, el rendimiento de Oracle método de mejora define una forma de trabajar, pero no un conjunto definitivo de normas. Con la detección de cuellos de botella, la única regla es que no hay reglas! Los ingenieros de mejor rendimiento utilizar los datos proporcionados y pensar lateralmente para determinar los problemas de rendimiento.

3.1.1 Pasos en el método de mejora de rendimiento de Oracle

Realice las siguientes comprobaciones iniciales estándar:
1. Obtener retroalimentación sincera de los usuarios. Determinar el alcance del proyecto y los objetivos de rendimiento en las prestaciones, así como las metas de desempeño para el futuro. Este proceso es clave en la planificación de la capacidad futura.
2. Obtener un conjunto completo de sistema operativo, base de datos y estadísticas de la aplicación del sistema cuando el rendimiento es bueno y malo. Si estos no están disponibles, a continuación, obtener lo que está disponible. Estadísticas que faltan son análogas a las pruebas que faltan en la escena del crimen: Hacen detectives trabajar más y es más lento.
3. La cordura a comprobar los sistemas operativos de todos los equipos involucrados en el rendimiento del usuario. Por la cordura, la comprobación del sistema operativo, buscar recursos de hardware o de sistema operativo que se utilizan plenamente. Haga una lista de recursos sobre los que se utilizan como síntomas para su posterior análisis. Además, compruebe que todos los equipos no muestra ningún error o de diagnóstico.

Compruebe que los diez errores más comunes con Oracle, y determinar si alguno de estos es probable que sea el problema. Lista de los síntomas como para su posterior análisis. Estos se incluyen debido a que representan los problemas más probable. ADDM automáticamente detecta e informa de nueve de estos diez temas. Ver el capítulo 6, "Diagnóstico de rendimiento automático" y "Top Ten Los errores encontrados en los sistemas de Oracle" .

Construir un modelo conceptual de lo que está sucediendo en el sistema con los síntomas como pistas para entender la causa de los problemas de rendimiento. Ver "Un proceso de toma de muestras para el Modelado Conceptual de rendimiento" .

Proponemos una serie de acciones de remediación y el comportamiento esperado para el sistema, y luego se aplican en el orden que se pueden beneficiar de la aplicación de la mayoría. ADDM produce recomendaciones, cada uno con un beneficio esperado. Una regla de oro en el rendimiento del trabajo es que sólo cambiar una cosa por vez y luego medir las diferencias. Por desgracia, los requisitos del sistema el tiempo de inactividad podría prohibir este método de investigación riguroso. Si los cambios se aplican varias al mismo tiempo, y luego tratar de asegurarse de que están aislados de modo que los efectos de cada cambio puede ser validado independientemente.

Validar que los cambios realizados han tenido el efecto deseado, y ver si la percepción del usuario sobre el rendimiento ha mejorado. De lo contrario, buscar más cuellos de botella, y seguir perfeccionando el modelo conceptual hasta su comprensión de la aplicación se hace más preciso.

Repita los tres últimos pasos hasta que los objetivos de rendimiento se cumplen o se hace imposible debido a limitaciones de otros.

Este método identifica los principales cuellos de botella y utiliza un enfoque objetivo de mejorar el rendimiento. El foco está en hacer grandes mejoras de rendimiento mediante el aumento de la eficiencia de aplicación y la eliminación de la escasez de recursos y los cuellos de botella. En este proceso, se prevé que un mínimo (menos del 10%) las ganancias de rendimiento se realizan desde el ajuste de ejemplo, y grandes ganancias (100% +) están hechos de aislar las ineficiencias de la aplicación.

3.1.2 Un proceso de toma de muestras para el Modelado Conceptual de rendimiento

Modelado conceptual es casi determinista. Sin embargo, a medida que aumenta la experiencia de ajuste del rendimiento, usted podrá apreciar que no hay reglas reales de seguir. Un flexible heads-up enfoque es necesario para interpretar las diferentes estadísticas y tomar buenas decisiones.
Para un enfoque rápido y sencillo a la optimización del rendimiento, el uso de la base de datos de diagnóstico automático Monitor (ADDM). ADDM controla automáticamente su sistema Oracle y ofrece recomendaciones para la solución de los problemas de rendimiento que se producen problemas. Por ejemplo, supongamos que un DBA recibe una llamada de un usuario se queja de que el sistema es lento. El DBA simplemente examina el último informe de ADDM para ver cuál de las recomendaciones que deben aplicarse para resolver el problema. Ver el capítulo 6, "Diagnóstico de rendimiento automático" para obtener información sobre las características que ayudan a controlar y diagnosticar los sistemas de Oracle.
Los pasos siguientes ilustran cómo un ingeniero de rendimiento puede tener un aspecto de los cuellos de botella sin necesidad de utilizar las funciones de diagnóstico automático.Estos pasos son sólo pretende ser una guía para el proceso manual. Con la experiencia, los ingenieros de rendimiento añadir a los pasos a seguir. Este análisis supone que las estadísticas, tanto para el sistema operativo y la base de datos han sido recogidos.

Es el tiempo de respuesta / tiempo de ejecución por lotes aceptables para un solo usuario en una máquina de vacío o con poca carga?
Si no es aceptable, entonces la aplicación es, probablemente, no codificado o diseñado de forma óptima, y que nunca será aceptable en una situación de múltiples usuarios, cuando los recursos del sistema son compartidos. En este caso, obtener estadísticas de aplicación interna, y obtener información de seguimiento de SQL y SQL plan. Trabajar con los desarrolladores para investigar los problemas en los datos, el índice de transacciones de SQL diseño, la exclusión potencial de trabajo de procesamiento por lotes / fondo.

Es toda la CPU que se utilizan?
Si la utilización del núcleo es más del 40%, y luego investigar el sistema operativo para la transferencia de la red, búsqueda, intercambio, o paliza proceso. De lo contrario, pasar a la utilización de CPU en el espacio de usuario. Compruebe si hay alguna base de datos no-consumo de puestos de trabajo de la CPU en la máquina de limitar la cantidad de recursos de la CPU compartidos, tales como copias de seguridad, transforma archivos, colas de impresión, y así sucesivamente. Después de determinar que la base de datos está utilizando la mayor parte de la CPU, investigar la parte superior de SQL utilización de la CPU. Estas declaraciones constituyen la base de todos los análisis en el futuro. Compruebe el SQL y las operaciones de la presentación de la SQL para la ejecución óptima. Oracle proporciona estadísticas de la CPU en V $ SQL y SQLSTATS V $ .

Ver también:

Oracle de base de datos de referencia para obtener más información sobre V $ SQL y V $ SQLSTATS

Si la aplicación es óptima y no hay ineficiencias en la ejecución de SQL, tenga en cuenta la reprogramación un trabajo a las horas o el uso de una máquina más grande.

En este punto, el rendimiento del sistema no es satisfactorio, sin embargo, los recursos de la CPU no se utilizan plenamente.
En este caso, usted tiene la serialización y el comportamiento no escalable en el servidor. Obtener el WAIT_EVENTS las estadísticas del servidor, y determinar el punto más grande de la serialización. Si no hay puntos de la serialización, entonces el problema es más probable que fuera la base de datos, y esto debe ser el foco de la investigación.Eliminación de WAIT_EVENTS implica la modificación de la aplicación de SQL y los parámetros de ajuste de bases de datos. Este proceso es muy iterativo y requiere la capacidad de profundizar en el WAIT_EVENTS sistemática para eliminar los puntos de serialización.

3.1.3 Top Ten de errores detectados en los sistemas de Oracle

En esta sección se enumeran los errores más comunes que se encuentran en los sistemas de Oracle. Siguiendo la metodología de mejora de rendimiento de Oracle, usted debería ser capaz de evitar estos errores por completo. Si encuentra estos errores en el sistema, de reingeniería de la aplicación en la que el esfuerzo vale la pena el rendimiento. Ver"Características automática el ajuste del rendimiento" para obtener información sobre las características que ayudan a diagnosticar y ajustar los sistemas de Oracle. Ver el capítulo 10, "Ajuste Instancia Uso de las vistas de rendimiento" para una discusión sobre cómo esperan los datos del evento revela síntomas de problemas que pueden afectar al rendimiento.

Gestión de conexiones mal
La aplicación se conecta y se desconecta para cada interacción de bases de datos. Este problema es común con el middleware de apátridas en servidores de aplicaciones.Cuenta con más de dos órdenes de magnitud el impacto en el rendimiento, y es totalmente inaccesibles.

Mal uso de los cursores y la piscina comunitaria
No utilizar los resultados de los cursores en repetidas analiza. Si las variables se unen no se utilizan, entonces no es difícil el análisis de todas las sentencias SQL. Esto tiene un orden de magnitud del impacto en el rendimiento, y es totalmente inaccesibles. Utilice los cursores con variables bind que abrir el cursor y ejecutar muchas veces. Desconfíe de las aplicaciones de generación de SQL dinámico.

Mal SQL
Mal SQL es SQL que utiliza más recursos de los adecuados para los requisitos de registro. Esto puede ser una consulta de los sistemas de soporte de decisiones (DSS), que tiene una duración de más de 24 horas o una consulta desde una aplicación en línea que tiene más de un minuto. SQL que consume recursos de sistema significativos deben ser investigados para posibles mejoras. ADDM identifica una carga alta de SQL y el asesor de ajuste SQL se pueden utilizar para proporcionar recomendaciones para su mejora. Ver el capítulo 6, "Diagnóstico de rendimiento automático" y el Capítulo 17, "Automatic SQL Tuning" .

El uso de parámetros de inicialización no estándar
Estos podrían haber llevado a cabo basándose en el asesoramiento pobres o malas interpretaciones. La mayoría de los sistemas que dan un rendimiento aceptable con sólo el conjunto de parámetros básicos. En particular, los parámetros asociados con SPIN_COUNT en los cierres y las características indocumentados optimizador puede causar una gran cantidad de problemas que pueden requerir una investigación considerable.
Del mismo modo, los parámetros del optimizador en el archivo de parámetros de inicialización puede anular demostrado los planes de ejecución óptimos. Por estas razones, los esquemas, las estadísticas de esquema y configuración del optimizador debe ser manejado como un grupo para asegurar la coherencia de sus resultados.

Véase también :

Guía del administrador de base de datos Oracle para obtener información sobre los parámetros de inicialización y creación de bases de datos
Oracle de base de datos de referencia para obtener información sobre los parámetros de inicialización
"Consideraciones de rendimiento para la configuración inicial de instancia" para obtener información sobre los parámetros y ajustes en una configuración de la instancia inicial

Obtención de la base de datos de E / S incorrecto
Muchos sitios muestran sus bases de datos poco más de los discos disponibles. Otros sitios de especificar el número de discos de forma incorrecta, ya que configurar los discos de espacio en disco y no de E / S de ancho de banda. Ver el capítulo 8, "Configuración E / S y diseño" .

Rehacer los problemas de registro de instalación
Muchos sitios de correr con los registros de rehacer muy pocos que son demasiado pequeños. Pequeños troncos rehacer causa puestos de control del sistema para poner continuamente una alta carga en la caché del búfer de E / S del sistema. Si hay registros de rehacer muy pocos, entonces el archivo no se puede mantener el ritmo, y la base de datos será esperar a que el proceso de archivado para ponerse al día. Vea el Capítulo 4, "Configuración de una base de datos de rendimiento" para obtener información sobre el tamaño de los registros de rehacer el rendimiento.

Serialización de los bloques de datos en la caché del búfer, debido a la falta de listados libres, grupos de libre lista, las ranuras de la transacción ( INITRANS ), o la escasez de los segmentos de rollback.
Esto es particularmente común en INSERTAR aplicaciones pesadas, en las aplicaciones que han aumentado el tamaño de bloque por encima de 8K, o en aplicaciones con un gran número de usuarios activos y algunos de los segmentos de retrotracción. El uso automático del segmento de gestión del espacio (ASSM) y la gestión automática de deshacer para resolver este problema.

Largo escaneos completos de tabla
Largo escaneos completos de tabla para las operaciones en línea de gran volumen o interactivo podría indicar un diseño de transacción pobres, los índices que faltan, o de mala optimización de SQL. Exploraciones larga mesa, por naturaleza, son de E / S intensiva y no escalable.

Las altas cantidades de recursiva ( SYS ) SQL
Grandes cantidades de SQL recursivo ejecutado por SYS podría indicar las actividades de gestión del espacio, tales como las asignaciones de extensiones, que tendrá lugar.Esto es infranqueable y el tiempo de los impactos de respuesta del usuario. Use tablespaces gestionados localmente para reducir SQL recursivo, debido a la asignación de extensión. SQL recursivo ejecutado bajo otro nombre de usuario es, probablemente, SQL y PL / SQL, y esto no es un problema.

Implementación y migración de los errores
En muchos casos, una aplicación utiliza demasiados recursos, porque el esquema propietario de las tablas no se ha migrado con éxito desde el entorno de desarrollo o de una implementación mayor. Ejemplos de esto son los índices que faltan o estadísticas incorrectas. Estos errores pueden llevar a los planes de ejecución sub-óptima y un rendimiento pobre de usuario interactivo. Al migrar las aplicaciones de los resultados conocidos, las estadísticas de exportación de esquema para mantener la estabilidad con el plan de DBMS_STATS paquete.
Aunque estos errores no son detectados directamente por ADDM, ADDM destaca el código SQL resultante de carga.

3.2 Métodos de emergencia de rendimiento

Esta sección proporciona las técnicas para hacer frente a emergencias rendimiento. Usted ya ha tenido la oportunidad de leer acerca de una metodología detallada para el establecimiento y la mejora de rendimiento de las aplicaciones. Sin embargo, en una situación de emergencia, un componente del sistema ha cambiado para pasar de ser un sistema fiable y predecible a uno que es impredecible y no satisfacer las peticiones del usuario.
En este caso, el papel del ingeniero de rendimiento es determinar rápidamente qué ha cambiado y tomar las medidas adecuadas para reanudar el servicio normal tan pronto como sea posible. En muchos casos, es necesario tomar medidas inmediatas, y un proyecto de mejora del desempeño riguroso no es realista.
Después de abordar el problema de rendimiento inmediato, el ingeniero de rendimiento debe recoger la información de depuración sea suficiente para obtener una mayor claridad sobre el problema de rendimiento o para garantizar al menos que no vuelva a ocurrir.
El método para depurar problemas de rendimiento de emergencia es el mismo que el método descrito en el método de mejora del rendimiento en este libro. Sin embargo, se toman atajos en varias etapas debido a la naturaleza oportuna del problema. Mantener notas detalladas y los registros de hechos constatados como el proceso de depuración avanza es esencial para su posterior análisis y justificación de las medidas correctivas. Esto es análogo a un médico mantener buenas notas paciente para futuras referencias.

3.2.1 Pasos en el método del rendimiento de emergencia

La Método de emergencia de rendimiento es la siguiente:

Encuesta del problema de rendimiento y recoger los síntomas del problema de rendimiento. Este proceso debe incluir lo siguiente:
- Comentarios de los usuarios sobre el funcionamiento del sistema es de bajo rendimiento. Es el rendimiento de problema o el tiempo de respuesta?
- Haga la pregunta: "¿Qué ha cambiado desde la última vez que había un buen desempeño?" Esta respuesta puede dar pistas sobre el problema. Sin embargo, obtener respuestas imparciales en una situación de escalada puede ser difícil. Trate de localizar algunos puntos de referencia, tales como las estadísticas recogidas o archivos de registro, que fueron tomadas antes y después del problema.
- Utilizar las funciones de sintonización automática para diagnosticar y controlar el problema. Ver "Características automática el ajuste del rendimiento" para obtener información sobre las características que ayudan a diagnosticar y ajustar los sistemas de Oracle. Además, puede utilizar Oracle Enterprise Manager para funciones de rendimiento de SQL identificar la parte superior y sesiones.
La cordura a comprobar la utilización del hardware de todos los componentes del sistema de aplicación. Compruebe que la utilización de la CPU es alta, y comprobar el disco, uso de memoria y rendimiento de la red en todos los componentes del sistema. Este proceso de rápida identifica qué nivel está causando el problema. Si el problema está en la aplicación, y luego cambio el análisis de la depuración de aplicaciones. De lo contrario, pasar al análisis de la base de datos del servidor.
Determinar si el servidor de base de datos se ve limitada en la CPU o si se está gastando el tiempo de espera en eventos de espera. Si el servidor de base de datos con restricciones de CPU, y luego investigar lo siguiente:
- Las sesiones que se consumen grandes cantidades de CPU en el nivel de sistema operativo y base de datos, control V $ SESS_TIME_MODEL para el uso de bases de datos de la CPU
- Sesiones o declaraciones que ejercen funciones reguladoras muchos se a nivel de base de datos, control V $ SESSTAT y V $ SQLSTATS
- Cambios en la ejecución del plan causando sub-óptima ejecución de SQL, que pueden ser difíciles de localizar
- Ajuste incorrecto de los parámetros de inicialización
- Problemas algorítmicos, como resultado de cambios en el código o las actualizaciones de todos los componentes
Si las sesiones de base de datos están a la espera de acontecimientos, a continuación, seguir los acontecimientos en la lista de espera V $ session_wait para determinar qué está causando la serialización. El V $ ACTIVE_SESSION_HISTORY vista contiene una muestra de la historia de actividad de la sesión que se puede utilizar para realizar el diagnóstico, incluso después de un incidente ha terminado y el sistema ha vuelto a la normalidad. En casos de disputa masiva de la caché de biblioteca, puede que no sea posible iniciar la sesión o enviar a la base de datos SQL. En este caso, el uso de datos históricos para determinar qué hay de repente la contención en este seguro. Si la mayoría se espera para E / S, y luego examinar V $ ACTIVE_SESSION_HISTORY para determinar el SQL se ejecuta en las sesiones que se están realizando todas las entradas y salidas. Ver el capítulo 10, "Ajuste Instancia Uso de las vistas de rendimiento" para una discusión sobre eventos de espera.
Aplicar medidas de emergencia para estabilizar el sistema. Esto podría implicar acciones que tienen partes de la solicitud fuera de línea o restringir la carga de trabajo que se pueden aplicar al sistema. También podría considerar un reinicio del sistema o la terminación del trabajo en proceso. Estos, naturalmente, tienen implicaciones de nivel de servicio.
Validar que el sistema es estable. Después de haber hecho los cambios y restricciones en el sistema, compruebe que el sistema es estable, y recoger un conjunto de referencia de las estadísticas de la base de datos. Ahora sigue el método de actuación rigurosa descrito anteriormente en este libro para traer de vuelta todas las funciones y los usuarios del sistema. Este proceso puede requerir la aplicación significativa re-ingeniería antes de que finalice.

Nuevas caracteristicas de rendimiento

Diseño y desarrollo para mejorar el rendimiento

2.1 Metodología de Oracle

2.2 Descripción de las opciones de inversión

2.3 Entender Escalabilidad

2.3.1 ¿Qué es la escalabilidad?

2.3.2 Sistema de escalabilidad

2.3.3 Factores de Prevención de escalabilidad

2.4 Arquitectura del sistema

2.4.1 Componentes de hardware y software

2.4.1.1 Componentes de Hardware

2.4.1.1.1 CPU

2.4.1.1.2 Memoria

2.4.1.1.3 subsistema I / O

2.4.1.1.4 Red

2.4.1.2 Componentes de software

2.4.1.2.1 Gestión de la interfaz de usuario

2.4.1.2.2 implementar la lógica de negocios

2.4.1.2.3 Gestión de Solicitudes de usuario y asignación de recursos

2.4.1.2.4 Gestión de Datos y Operaciones

2.4.2 Configuración de la arquitectura del sistema ideal para sus necesidades

2.5 Principios de diseño de aplicaciones

2.5.1 La simplicidad en el diseño de aplicaciones

2.5.2 Modelado de datos

2.5.3 Tabla y diseñar índices

2.5.3.1 Añadiendo columnas de un índice o usando Índice de tablas organizadas

2.5.3.2 El uso de un tipo de índice diferente

2.5.3.2.1 índices B-tree

2.5.3.2.2 índices de mapa de bits

2.5.3.2.3 Función de los índices basados ​​en

2.5.3.2.4 índices con particiones

2.5.3.2.5 índices de clave inversa

2.5.3.3 Encontrar el costo de un Índice de

2.5.3.4 Seriación dentro de los índices

2.5.3.5 Columnas de pedido en un índice

2.5.4 Uso de Vistas

2.5.5 SQL eficiencia en la ejecución

2.5.6 Implementación de la aplicación

2.5.7 Tendencias en el desarrollo de aplicaciones

2.6 Carga de trabajo de pruebas, modelado e implementación

2.6.1 Dimensionamiento de datos

2.6.2 Cálculo de las cargas de trabajo

2.6.2.1 La extrapolación de un sistema similar

2.6.2.2 Benchmarking

2.6.3 Aplicación de modelado

2.6.4 prueba, depuración y validación de un diseño

2.7 despliegue de nuevas aplicaciones

2.7.1 Estrategias de Implantación

2.7.2 Lista de verificación del rendimiento

El rendimiento de Oracle mejora el método

3.1.1 Pasos en el método de mejora de rendimiento de Oracle

3.1.2 Un proceso de toma de muestras para el Modelado Conceptual de rendimiento

3.1.3 Top Ten de errores detectados en los sistemas de Oracle

3.2 Métodos de emergencia de rendimiento

3.2.1 Pasos en el método del rendimiento de emergencia

2.5.3.2.3 Función de los índices basados en