Tareas de un Administrador de Oracle Database

Oracle Universal Installer

Un administrador de la base de datos (DBA) suele ser responsable de la instalación del software deOracle y de la creación de la base de datos. Como DBA, puede que sea responsable de la creación de las estructuras de almacenamiento de la base de datos como, por ejemplo, los tablespaces. Además, puede crear el esquema o juego de objetos para incluir los datos de la aplicación. Es preciso garantizar que la base de datos esté disponible para los usuarios. Para ello, puede iniciar la base de datos, realizar copias de seguridad de la misma con cierta periodicidad y supervisar el rendimiento de la base de datos. Estas tareas se deben realizar dentro del marco de una estrategia de seguridad.

Herramientas para Administrar Oracle Database:

• Oracle Universal Installer

• Asistente de Configuración de Bases de Datos

• Asistente de Actualización de Bases de Datos

• Oracle Net Manager (Realiza tareas en el entorno de red.)

• Asistente de Configuración de Red de Oracle

• Oracle Enterprise Manager

• Utilidad Server Control

• SQL*Plus (Cliente para ejecutar instrucciones SQL.)

• Recovery Manager

• Pump de Datos (Herramienta de migración de datos.)

• SQL*Loader (Herramienta de migración de datos.)

Se pueden utilizar las siguientes herramientas para la instalación y actualización:

• Oracle Universal Installer (OUI): instala el software y las opciones de Oracle; puede iniciar de forma automática el Asistente de Configuración de Bases de Datos para crear una base de datos.

• Asistente de Configuración de Bases de Datos (DBCA): crea una base de datos a partir de plantillas proporcionadas por Oracle, lo que permite copiar una base de datos inicial preconfigurada (como alternativa, puede crear su propia base de datos y plantillas).

• Asistente de Actualización de Bases de Datos (DBUA): le guía por los pasos necesarios para actualizar su base de datos existente a una nueva versión de Oracle.

• Oracle Net Manager (netmgr): configura la conectividad de red de sus aplicaciones y bases de datos Oracle.

• Asistente de Configuración de Red de Oracle (NetCA): herramienta gráfica basada en asistentes que se utiliza para configurar y gestionar las configuraciones de Red de Oracle.

Las siguientes herramientas se utilizan para gestionar su instancia y base de datos Oracle:

• Oracle Enterprise Manager (EM): combina una consola gráfica, agentes, servicios comunes y herramientas para proporcionar una plataforma de gestión del sistema completa e integrada para la gestión de productos Oracle. Después de instalar el software de Oracle, crear o actualizar una base de datos y configurar la red, puede utilizar EM como la única interfaz para gestionar la base de datos. Además de proporcionar una interfaz de usuario basada en web para ejecutar comandos SQL, interactúa con otros componentes de Oracle que se utilizan para administrar la base de datos (por ejemplo, Recovery Manager y el Programador).

• Las herramientas principales de EM que se utilizan para administrar una base de datos Oracle son las siguientes:

- Consola de Base de Datos de Enterprise Manager: para administrar una base de datos.

- Enterprise Manager Grid Control: para administrar varias bases de datos al mismo

tiempo.

• Utilidad Server Control (srvctl): interfaz de línea de comandos estándar que se puede utilizar para iniciar y parar la base de datos y las instancias, gestionar instancias de ASM, gestionar información de configuración y mover o eliminar instancias y servicios. También

puede utilizar SRVCTL para agregar servicios y gestionar información de configuración.

• SQL*Plus: interfaz de línea de comandos estándar para gestionar la base de datos.

• Recovery Manager (RMAN): herramienta de Oracle que ofrece una solución completa para cubrir las necesidades de copia de seguridad, restauración y recuperación de toda la base de datos o de archivos específicos de ésta.

• Pump de Datos: permite la transferencia de datos de una base de datos a otra a alta velocidad.(Por ejemplo, puede exportar una tabla e importarla a otra base de datos.)

• SQL*Loader: permite la carga de datos de un archivo externo en una base de datos Oracle; es una de las diversas utilidades de Oracle que puede utilizar para cargar datos en tablas de base

de datos.

• Herramientas de línea de comandos:

- Para administrar Enterprise Manager:

emctl start | status | stop dbconsole

- Para administrar el listener:

lsnrctl start | status | stop

Fuente: Instalación del software de Oracle

Costos de mantención

Para tener una estimación de los costos de un mantenimiento en particular, podemos utilizar el modelo COCOMO 2 (Bohem et. al., 2000), para calcular el esfuerzo de entender el código existente y el de desarrollar un nuevo código. En el modelo COCOMO 2 se calcula el nú- mero de líneas de código que se van a realizar, dándoles un tiempo dependiendo del lenguaje utilizado. Los costos de mantenimiento van a depender del:

 a) Tipo de aplicación: si está distribuida, si es web, si es local o si es en red. Mientras más compleja, mayor va a ser el costo.

 b) Disponibilidad de conocimientos y recursos: si es muy específico (ejemplo: de carácter científico), o si está escrito en un lenguaje poco común, es posible que la contratación de personal nos salga extremadamente cara.

 c) Ciclo de la vida de producto de software: el costo dependerá del ciclo, ya que si lo conocemos muy bien y sabemos la modificación, es posible que tengamos menos tiempo en las primeras etapas. d) Características de hardware: esto está referido a los requerimientos no funcionales, y si estos son pocos o básicos, el tiempo y el costo, podrían ser menores.

 e) Calidad de diseño, construcción y la documentación de software y pruebas: también son factores incidentes. Mientras más exigencias tengamos, más costos tendremos involucrado en el proceso. Según precisa Rogers S. Pressman, del tiempo utilizado para el desarrollo en una organización, el 60% se destina a mantenimiento. De ese porcentaje, el 65% es mantenimiento adaptativo, 17% correctivo, y el 18% es perfectivo.

Referencias bibliográficas Pressman R. (2010). Ingeniería del software, séptima edición. Mexico: Mc Graw Hill Educación. Estándar IEEE 1219. Estándar IEEE/ISO 12207.

Categorías de mantención de software

Como vimos anteriormente, un problema no necesariamente implica un defecto del software. Estos aparecen simplemente porque el comportamiento esperado del sistema no coincide con el actual. Esto puede ser de un defecto del software, pero también puede ser fácilmente el resultado de: un desconocimiento de las capacidades del sistema, de la utilización incorrecta del flujo de trabajo, de una documentación pobre de cambios en las directrices de la empresa, o de otras tantas razones. La gestión de respuestas a los problemas del sistema cubre muchas de las potenciales actividades. Algunas de las posibles soluciones a los problemas del sistema podrían incluir: • Liberación de nuevas versiones. • Sesiones de planificación. • Identificación de la formación necesaria. • Actualización de la documentación, etc. La gran mayoría de los estándares relacionados con el mantenimiento de software, definen las siguientes categorías:

 a) Mantenimiento adaptativo Es la modificación de un software (después de su puesta en producción), para mantenerlo en funcionamiento en un ambiente que ha cambiado o que lo va a hacer. Tiene por objetivo la modificación de un sistema debido a cambios en el entorno (sistema operativo, por ejemplo), o en el hardware (por ejemplo pasar de un sistema de 16 bits a uno de 32) o en el software (por ejemplo, los cambios de un cliente clásico desarrollado en Visual Basic, Delphi o C/C++ a uno “ligero” Thin Client para ejecutarse sobre un navegador de internet; etc.) en el que se realiza. Este tipo de mantenimiento es el más usual debido a los rápidos cambios que se producen en la tecnología informática, que en la mayoría de las ocasiones dejan obsoletos los softwares desarrollados, no por su inoperancia, sino por la competitividad entre las empresas, en las que cada vez influye más el software utilizado.

 b) Mantenimiento correctivo Es la modificación de un software, después de su puesta en producción, para corregir los fallos descubiertos. Tiene por objetivo localizar y eliminar los posibles defectos de los programas. A pesar de las pruebas y verificaciones que se deben realizar durante el ciclo de vida del software, los programas pueden tener desperfectos. Estos se producen cuando el comportamiento del sistema es diferente al esperado por su especificación. Estos pueden ser: de procesamiento, de rendimiento, de programación o de documentación. La mayoría de los defectos se originan en la etapa de especificación de requisitos y en la de codificación, por lo que también son importantes las primeras fases del ciclo de vida para el mantenimiento del software.

 c) Mantenimiento perfectivo Es la modificación de un software, después de su puesta en producción y para mejorar el rendimiento. Estos cambios pueden ser: la inclusión de un monitor transaccional y su gestión, para mejorar los accesos a la base de datos, la utilización de cachés en los usuarios de un sistema cliente-servidor, para liberar la carga de la red de comunicaciones, etc. El aumento del número de usuarios del sistema, como el incremento de las funcionalidades, puede repercutir en el rendimiento de este y requerir un mantenimiento perfectivo.

 d) Mantenimiento preventivo Este mantenimiento es citado en algunos importantes textos de Ingeniería de software (Pressman, R. (2010). Ingeniería del software. Editorial McGraw-Hill, 7° edición), sin embargo, no se menciona como tal en el estándar IEEE 1219, sino que se incluye como parte del Mantenimiento perfectivo. Éste consiste en la modificación del software sin alterar las especificaciones del mismo. Es decir, no se quitan ni agregan funcionalidades ni propiedades, pero se cambian para mejorar los atributos del producto y facilitar así futuras tareas de mantenimiento. Los cambios que se llevan a cabo son en cuanto a los comentarios del código y la reestructuración de los programas para mejorar su comprensión. Se debe realizar cuando sabemos que un sistema tiene un alto grado de probabilidad de que requiera modificaciones, de manera que sea más fácil su mantención. Como ejemplo, podemos citar el agregar comentarios en el código, explicando lo que hace cada grupo de instrucciones.

Referencias bibliográficas Pressman R. (2010). Ingeniería del software, séptima edición. Mexico: Mc Graw Hill Educación. Estándar IEEE 1219. Estándar IEEE/ISO 12207.

Fuentes de mantención de software

 La necesidad de cambio en un software es porque a la organización ya no le es funcional, iniciándose el proceso de mantención con la identificación del problema y sufriendo modificaciones en el código y en la documentación asociada, debido a: 

a) Corrección de fallas: se considera que el software presenta una irregularidad, cuando presenta un problema generado por una mantención anterior, por un dato mal ingresado, por una interfaz que cambió, etc. 

b) Mejora en el diseño: tenemos un software en producción, sin embargo, debemos adaptarlo para que conviva de mejor manera con nuevas tecnologías. Por ejemplo, cuando modificamos: la versión del sistema operativo, el hardware que lo alberga, la base de datos, la interfaz de ingreso de datos de manual a automática, etc. 

c) Implementación de nuevas funcionalidades: la organización, en su propio ciclo de vida debe ir adaptándose a nuevas condiciones, por ejemplo: si quiere comenzar a operar con nuevas sucursales, en otras áreas geográ- ficas, debe contratar a más personas, arrendar y/o comprar nuevos locales, aumentar la producción, etc. De la misma manera, los diferentes sistemas que operan en la empresa, deben sufrir las modificaciones necesarias para ajustarse a lo que ahora requieren. 

d) Desarrollo de interfaces con nuevos sistemas: la organización, en su necesidad de cambio, puede integrar nuevos sistemas. En algunos de estos casos, se requerirá desarrollar una nueva interfaz que permita la comunicación. 

e) Adaptación del software para que funcione con protocolos/equipos de comunicación diferentes: se basa en determinados protocolos de comunicación, los cuales pueden cambiar y los sistemas deben adecuarse a este nuevo requerimiento. 

f) Migración de software a nuevas tecnologías: Esto se conoce como el proceso de transferencia de los programas desde un ambiente a otro, el que puede incluir un hardware distinto. Los equipos de alta tecnología, tienen un ciclo de vida propio, para luego quedar obsoletos y la organización debe cambiarlos. Esa sustitución de hardware no siempre va acompañado del cambio de software, por lo tanto debemos migrar el software a estos nuevos equipos y modificarlos para que funcionen lo mejor posible.

 g) Retiro del software: los sistemas a veces dejan de tener utilidad para la organización, por lo cual se deben sacar de producción para evitar que se estén realizando operaciones innecesarias en los equipos (por ejemplo respaldos) y utilización de personal (operadores). Si ese sistema alimenta a uno de gestión o de BI ( Business Intelligence: Inteligencia de Negocio), (por ejemplo) el sacarlos del uso diario, nos trae consecuencias en sistemas que se alimentan de estos. 


Referencias bibliográficas Pressman R. (2010). Ingeniería del software, séptima edición. Mexico: Mc Graw Hill Educación. Estándar IEEE 1219. Estándar IEEE/ISO 12207.

Procesos de apoyo al ciclo de vida

En las 8 leyes de la evolución de Lehman, también tiene importancia los procesos de apoyo al ciclo de vida:

a) Documentación: define las actividades para el registro de la información producida por un proceso del ciclo de vida.

b) Gestión de la configuración: define sus propias actividades.

c) Aseguramiento de la calidad: se trata de actividades para asegurar que los productos software y sus procesos son conformes a los requerimientos especificados, ajustándose a los planes establecidos. Revisión conjunta, auditoría, verificación y validación pueden ser utilizadas como técnicas de aseguramiento de la calidad.

d)  Verificación: son  actividades  que  se  realizan  para comprobar en detalle el nivel de los productos software 

(para  el  adquiriente,  proveedor  o  una  parte  independiente). 

e) Validación: define las actividades (para el adquiriente, proveedor o una parte independiente) para aprobar los productos software del proyecto.

f) Revisión conjunta: son las tareas que se realizan para evaluar  el  estado  y  productos  de  una  actividad.  Este proceso puede ser empleado por cualquiera de las dos partes indistintamente.

g) Auditoría: se trata de las actividades para determinar la conformidad con los requerimientos, planes y contrato. En este proceso la parte auditora, revisa los productos software o actividades de la contraparte.

h) Solución de problemas: define las actividades para analizar  y  eliminar  los  problemas,  (incluyendo  las  no conformidades) que sean descubiertos durante la ejecución  del  proceso  de  desarrollo,  operación,  mantenimiento, etc. 

Debemos tener presente que parte importante del éxito en la Mantención del software, radica en el conocimiento que se tenga de este mismo y de las modificaciones que se deba realizar, por lo tanto, cuando tenemos un equipo que lleva a cabo el desarrollo y otro que hace la  mantención,  la  comunicación  entre  ambos,  emerge como un punto muy relevante. Por esa razón el primer 

punto que tenemos es la documentación, la cual puede ser interna (efectuada en el mismo código de la aplicación o en textos externos).

Referencias bibliográficas Pressman R. (2010). Ingeniería del software, séptima edición. Mexico: Mc Graw Hill Educación. Estándar IEEE 1219. Estándar IEEE/ISO 12207.

Leyes de Lehamn (resumen)

Mantención de Software.

Meir M. Lehman y László Bélády nos presentan las leyes de la Evolución del software:

László Bélády

Ley I : Cambio continuo o continuidad de cambio.

Cuando un programa es utilizado en un entorno real, este siempre estará destinado a cambiar. Será menos utilizado en dicho entorno. (Tan pronto como un programa este creado, ya está desfasado.) Las razones que conducen esta afirmación son la evolución, crecimiento tecnológico en tiempo real.

Ley II : Complejidad creciente o incremento de complejidad.

Cuando los cambios transforman los programas, la estructura de este se hace progresivamente más compleja (salvo si se logra un esfuerzo activo para evitarlo). Esto significa que al realizar cambios, la estructura se hace más compleja cuando los programadores no pueden o no usan técnicas de ingeniería de software.

Ley III : Autorregulación o evolución del programa.

Es un proceso autorregulado. La medida de determinadas propiedades (tamaño, tiempo entre versiones y número de errores) revelan estadísticamente determinadas tendencias e invariantes.

Ley IV : Conservación de estabilidad organizacional. 

A lo largo de un tiempo de vida de un programa, la carga que supera el desarrollo de dicho programa es aproximadamente constante e independiente de los recursos dedicados.

Ley V : Conservación de la familiaridad.

A medida que un sistema evoluciona todos los involucrados, tales como: los desarrolladores, personal de ventas, y usuarios, deben 
conocer el total de su contenido y su comportamiento para lograr un desarrollo satisfactorio.

Ley VI : Crecimiento continuo.

Esta ley contiene un símil aspecto al que refleja la primera ley. A esto debe incrementarse el contenido funcional de un programa para mantener la satisfacción del usuario durante un ciclo de vida. (Los requisitos que se habían descartado volvieron a aparecer como necesidad.)

Explicados con otras palabras:

un  desarrollo  exagerado disminuye  la  familiaridad  de  los  involucrados  con  el sistema. Por tanto, este incremento promedio debe permanecer continuo para mantener la satisfacción de los 

usuarios.

Ley VII : Calidad decreciente.

Esta comenzará a disminuir a menos que dichos sistemas se adapten a los cambios de su entorno de funcionamiento. (Tiene que ver con los cambios en los criterios del usuario.)

Ley VIII : Retroalimentación del sistema.

Son incorporados los sistemas de retroalimentación multibucle y multiagente. Estos deben ser tratados como tal para mejorar de manera signifactiva un producto.

Multiagente : Es un sistema distribuido en el cual los nodos o elementos son estructuras de inteligencia artificial, donde la conducta combinada de dichos elementos producen un resultado en conjunto inteligente.

Multibucle : Multibucle o  ciclos  múltiples,  consiste  en  tener, de  manera constante, una retroalimentación de los resultados obtenidos y así poder ir mejorándolos.

Meir M. Lehman

Referencias bibliográficas Pressman R. (2010). Ingeniería del software, séptima edición. Mexico: Mc Graw Hill Educación. Estándar IEEE 1219. Estándar IEEE/ISO 12207.

Preguntas y respuestas Exploración de Arquitectura de Oracle Database

El proceso de supervisión de proceso (PMON) :

1. Realiza la recuperación al iniciar la instancia.

2. Realiza la recuperación de procesos cuando falla un proceso de usuario.

3. Resuelve automáticamente todas las transacciones dudosas.

4. Escribe el buffer de redo log en un archivo redo log.

¿Con qué tipos de instancias se accede a los archivos de ASM?

1. Sólo instancias de RDBMS

2. Sólo instancias de ASM

3. Instancias de RDBMS y ASM

La región de memoria que contiene datos e información de control para un proceso de servidor o de segundo plano se llama:

1. Pool compartido

2. PGA

3. Caché de buffers

4. Datos de sesión de usuario

¿Qué se lee en la caché de buffers de la base de datos desde los archivos de datos?

1. Filas

2. Cambios

3. Bloques

4. SQL

1.  Explique qué es la infraestructura de Grid de Oracle. ¿Qué es un Grid de aplicaciones

(RAC) y un Grid de almacenamiento (ASM)?

R: La infraestructura de Grid de Oracle Database es conocida en base de datos como estructura de clusters. En este caso, un cluster no existe si no hay instancia. Cada instancia de una base de datos está asociada a una única. Si existen varias bases de datos en el mismo servidor, existirá una instancia diferente. Propia para cada base de datos. Cabe destacar que no se pueden compartir las instancias.

     Explicado la infr. de Grid. Un Grid de aplicaciones RAC, que significa Real Application Cluster se define como varias instancias  en servidores independientes para la misma base de datos compartida.  En este modelo, se asocia la misma base de datos a cada instancia de RAC, para que se cumpla el requisito de que solo una base de datos pueda estar asociada a una instancia.  (Grid de servidor.)

 y un grid ASM puede mantener copias redundantes de los datos para ofrecer tolerancia ante fallos o se pueden montar mecanismos de almacenamiento suministrado al proveedor. También ahorran tiempoa los administradores de la base de datos al automizar el almacenamiento manual y, en consecuencia, les permiten aumentar su capacidad para gestionar bases de datos más grandes (y en mayor número) con mayor eficiencia.

2. ¿Qué sucede cuando un usuario se conecta una base de datos Oracle? Describa el

proceso completo.

R: Se levanta una instancia al servidor. Esta una vez iniciada se asignaun área de memoria compartida dentro de SGA (Área global de Sistema) y se inician los procesos ensegundo plano. Los procesos son trabajos que funcionan en la memoria de las computadoras. Los procesos se conocen como "thread de control" y después de iniciar una instancia de base de datos, el software de Oracle la asocia a una base de datos concreta denominada montaje de la base de datos. La base de datos está ahora lista para su apertura, lo que la

hace accesible a los usuarios autorizados.

3.  ¿Qué es la instancia de Oracle? ¿Diría usted que una instancia puede administrar más de

una base de datos? Justifique su respuesta.

R: Una instancia nace con el proceso de conexión a un servidor. Y se conoce cuando un usuario se conecta al sistema operativo que ejecuta la instancia de Oracle e inicia una aplicación o herramienta que accede a la base de datos de ese sistema. La vía de comunicación se establece mediante los mecanismos de comunicación entre procesos disponibles en el sistema operativo del host.

     ¿Diría usted que una instancia puede administrar más de una base de datos?

No, Cada instancia de base de datos está asociada a una única base de datos.

4. ¿En qué se diferencia la SGA de la PGA?

R: PGA define un proceso del servidor mientras que, SGA se inicia una vez definida la entrada a la instancia.

5.  ¿Cuál es el objetivo de la Caché de Buffers de la Base de Datos y del Buffer de Redo Log?

R:  De Caché de Buffers de la Base de Datos contener copias de los bloques de datos. Lugar donde son leídos los archivos de datos. Y además compartir todos los usuarios de forma simultánea. Además utilizado por DBWn para avanzar al hacia el punto de control.

Buffer de Redo Log contener información sobre cambios realizados en la base de datos. Conteniendo entradas de redo con información de los cambios de redo, que son realizados por operaciones DML o DDL. Finalmente al igual que el primero, es utilizado por el LGWR, cuando un usuario confirma una transacción o cuando el buffer de redo log está lleno en un tercio, entre otros.

6. ¿Cómo funcionan los procesos DBWn y LGWR?

R: DBWn: Escribe los buffers modificados (sucios: archivos que son modificados) de la caché de buffers de base de datos en el disco:

• De forma asíncrona mientras realiza otro procesamiento

• Para avanzar el punto de control (El punto de control permite saber en qué lugar están las inconsistencias).

LGWR: • Escribe el buffer de redo log en un archivo redo log en el disco

            • Escribe:

                         – Cuando un proceso de usuario confirma una transacción.

                         – Cuando el buffer de redo log está lleno en un tercio.

                         – Antes de que un proceso DBWnescriba buffers modificados

                         en el disco.

                         – Cada 3 segundos.

7. ¿Qué estructuras de memoria, procesos y almacenamiento intervienen en la recuperación de instancias?

R: En DBWn SGA contiene una estructura de memoria con la dirección de byte de redo (RBA) de la posición en el flujo de redo donde debe empezar la recuperación en caso de fallo de la instancia. Esta estructura actúa de puntero en el redo y se escribe en el archivo de control con el proceso CKPT cada tres segundos. Ya que DBWn escribe los buffers sucios en orden SCN y ya que redo está en orden SCN, cada vez que DBWn escribe buffers sucios de la lista LRUW, también avanza el puntero de la estructura de memoria SGA para que la recuperación de instancia (si es necesaria) empiece por leer el redo desde la ubicación correcta aproximada y evite E/S innecesarias. Esto se conoce como punto de control incremental.

8.  ¿Qué es un Tablespace y qué Tablespaces son obligatorios? Explique para que sirven éstos.

R: Tablespaces son unidades lógicas de almacenamiento y agrupan archivos de datos o estructuras lógicas relacionadas. Por ejemplo, los tablespaces suelen agrupar todos los segmentos de una aplicación para simplificar algunas operaciones administrativas. Los tablespaces por defecto son 2 :

               1. System

               2. Sisaux

9. Investigue y explique los diferentes tipos de Segmentos.

R: Al nivel de almacenamiento de la base de datos lógica por encima de una extensión se denomina 

segmento. Un segmento es un juego de extensiones asignadas para una determinada estructura lógica. 
Por ejemplo:

Segmentos de datos: Cada tabla no de cluster y no organizada por índices tiene un segmento de datos, con la excepción de las tablas externas, tablas temporales globales y tablas particionadas en las que hay uno o varios segmentos. Para una tabla particionada, cada partición tiene un segmento de datos. Cada cluster tiene un segmento de datos.

Segmentos de índice: Cada índice tiene un segmento de índice que almacena todos sus datos.
Para un índice particionado, cada partición tiene un segmento de índice.

Segmentos de deshacer: se crea un tablespace UNDOpara cada instancia de la base de datos. Este tablespace contiene numerosos segmentos de deshacer para almacenar de forma temporal la información de deshacer.

Segmentos temporales: la base de datos Oracle crea segmentos temporales cuando una sentencia SQL necesita un área de trabajo temporal para terminar la ejecución. Cuando la sentencia termina la ejecución, las extensiones del segmento temporal vuelven a la instancia para un uso futuro.

Nota: hay otros tipos de segmentos que no se han mencionado.