3. Aplicación egresados

Realizamos la creación de un proyecto alumnos y aplicación egresados. 

Comando: django-admin startproject nombre_proyecto

Comando: django-admin startproject nombre_aplicacion

Una vez hecho esto, realiza el modelo en el editor pycharm como se muestra y agregamos a installed_apps 'egresados' la app:

Código:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models
import os
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
class egresados(models.Model):
    Num_cont = models.CharField(max_length=10, primary_key=True, null=False,
                                verbose_name="Numero de control")
    Nombre = models.CharField(max_length=50)
    Apellido = models.CharField(max_length=30)
    SEXO = (('F', 'Femenino'), ('M', 'Masculino'), ('N','Ninguno'))
    sexo = models.CharField(max_length=1, choices = SEXO, default ='ninguno')
    Edad = models.IntegerField(help_text='Mayor de Edad')
    Fecha_nacimiento = models.DateField()
    CARRERA_CHOICES = (
    ('CP','Contador Publico'),
    ('IA','Ing. Ambiental'),
    ('IC','Ing. Civil'),
    ('IE','Ing. Electronica'),
    ('IME', 'Ing. Electromecanica'),
    ('ISC', 'Ing. en Sistemas Comp.'),
    ('IGE', 'Ing. en Gestion Empresarial.'),
    ('LAE', 'Lic. en Administración de Empresas'),
    ('IE','Ing. Quimica'),
    ('IM', 'Ing. Mecatronica')
    )
    carrera_choices = models.CharField(max_length=35, choices=CARRERA_CHOICES, default='IS')
    Activo = models.BooleanField(verbose_name= 'Trabaja actualmente',help_text='Marca si es asi')
    Trabajo = models.BooleanField(verbose_name= 'Trabaja en el area de su carrera')
    Lugar_de_trabajo = models.CharField(max_length=50, null = True, default='Ninguno')

    Ingreso_Mensual = models.IntegerField(null = True)
    Telefono = models.CharField(max_length=12)
    email = models.EmailField()
    Domicilio = models.TextField()
    Foto = models.ImageField(db_column="image",upload_to=BASE_DIR+"/media/imagenes",
                             verbose_name="Subir Imagen",default="")
    Archivo = models.FileField(db_column="File",upload_to= BASE_DIR+"/media/archivos",
                             verbose_name="Subir Archivo", default="")

Editor:

Para que nos guarde la imagen en una carpeta, se ingresa el siguiente código en alumnos/settings.py, puede ir al final mientras no interfiere con el resto:

Código:

MEDIA_ROOT = '/'
MEDIA_URL = '/media/'

Para tener el url y ver la imagen, en alumnos/urls.py:

Código:

from django.conf.urls import url
from django.contrib import admin
from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    url(r'^admin/', admin.site.urls),
]

if settings.DEBUG:
   urlpatterns+= static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Para crear el modelo, por consola ejecutamos los siguientes comandos:

 python manage.py makemigrations

python manage.py migrate

No olvides agregar el modelo en egresados/admin.py, se agrega en esta ocasiona el 

código:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.contrib import admin

from.models import egresados
admin.site.register(egresados)

Ya terminado, ahora corremos el servidor:

python manage.py runserver

Ve a la dirección: http://127.0.0.1:8000/admin/, y accede. No olvides crear usuario por consola con el siguiente comando:

python manage.py createsuperusuario

Como se muestra ya esta nuestro modelo 'egresados'.

Registramos datos:

Opciones que se muestran, en caso del campo sexo, si no seleccionamos, entonces por default se queda en ninguno.

Para subir una imagen o archivo:

Ya tenemos en carpetas separadas lo que va en Imagen y Archivo.

Se muestra una dirección donde esta la imagen o archivo, damos click se abre la imagen.

Nos redirige y podemos verla en el navegador.

3. Tipos de campos y atributos

Campos

TIPO DE CAMPOS EN MODELOS
TIPO DE CAMPO	DESCRIPCIÓN
CharField	Tipo de campo para cadena de caracteres alfanuméricos
TextField	Se usa para cadenas de longitud grande o arbitraria.
IntegerField	Campo para almacenar valores de números enteros y para validar los valores introducidos como enteros en los formularios
DataField y DataTimeField	Se utilizan para guardar/representar fechas e información de fecha/hora.
EmailField	Se usa para validar direcciones de correo electrónico
FileField e ImageField	Se usan para subir ficheros e imágenes. Solo ImageField añade una validación adicional de que el fichero subido es una imagen
AutoField	Tipo de campo especial de IntegerField que se incrementa automáticamente. Cuando no especificamos una clave primaria para el modelo, se añade automáticamente una de este tipo
ForeignKey	Se utiliza para especificar una relación uno a muchos con otro modelo de la base de datos
ManyToManyField	Se usa para especificar una relación muchos a muchos.
BinaryField	Un campo para guardar datos binarios. Solo soporta asignación de bytes
BooleanField	Campo de verdadero/falso
CommaSeparatedIntegerField	Campo de enteros separados por comas. Así como en el campo CharField, se requiere el argumento max_length
DecimalField	Un campo preciso de números decimales, representado en python como una instancia decimal. Requiere los argumentos max_digits y decimal_places.
FilePathField	Un CharField que sus opciones son limitadas a los nombres de archivos en ciertas direcciones en el sistema.
SlugField	Slug es un termino de periódico. Un Slug es una etiqueta corta para algo, conteniendo solo letras, números,guiones bajos o guiones. Son usados generalmente en las URLs
URLField	Campo de tipo CharField para una URL.
OneToOneField	Una relación de uno a uno. Conceptualmente, esto es similar a una ForeignKey con el argumento unique=True.

Atributos

PARÁMETROS EN MODELOS
PARÁMETRO	DESCRIPCIÓN
max_length	Establece la longitud máxima del valor de este campo
help_text	Proporciona una etiqueta de texto para mostrar que ayuda a los usuarios a saber que colocar en el campo
verbose_name	Modifica el nombre del campo a mostrar
default	Valor por efecto para el campo. Puede ser un valor o un callable object(objeto que puede ser llamada como una funcion)
null	Si es True, Django guardara valores en blanco o vacíos como NULL. Por defecto es FALSE
blank	Si es True, se permite que el campo quede en blanco en los formularios. El valor por defecto es False, lo que significa que la validación de formularios de Django te forzara a introducir un valor.
choices	Un grupo de valores de selección para este campo
primary_key	Si es True, establece el campo actual como clave primaria para el modelo. Si no se especifica ningún campo como clave,Django añadirá automáticamente un campo para este propósito
editable	Si es falso, el campo no se desplegara en el apartado de admin o en cualquier otra forma. También se saltara durante la validacion del modelo. Por defecto es True
unique	Si es True, el campo deberá ser único en toda la tabla
auto_now_add	se utiliza con DataField y DataTimeField para establecer solo la fecha cuando se crea el modelo por primera vez
auto_now	Si es True, establece en el campo la fecha actual cada vez que se guarda el modelo. Se utiliza con DataField o DataTimeField
set_null	Establece un campo como NULL
on_delete	Define que ocurre cuando un registro asociado se borra. Se utiliza con MannyToManyField
path	Requerido en FilePathField. La dirección de donde el campo obtendrá sus opciones "/hime/images"

2. Proyecto alumnos: Cambios en el modelo (parte 2)

Modificación del modelo

Tipos de Campos, atributos (argumentos)

Un modelo puede tener un número arbitrario de campos, de cualquier tipo.

Previamente se había creado un proyecto Alumnos con aplicación datos_per, en esta ocasión se le agregará cambios en el modelo.

Original

Código:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models

# Create your models here.
class Datospersonales(models.Model):
    Num_cont = models.CharField(max_length=10, primary_key=True)
    Nombre = models.CharField(max_length=50)
    Sexo = models.CharField(max_length=1)
    Edad = models.IntegerField()
    Fecha_nacimiento = models.DateField()
    Carrera = models.CharField(max_length=30)
    Telefono = models.CharField(max_length=12)
    email = models.EmailField()
    Domicilio = models.TextField()

Se creo un modelo en datos_per/models, con los siguientes tipos de campos, el modelo tiene lo siguiente:

Tipos de campos

• CharField se usa para definir cadenas de longitud corta a media. Debes especificar la max_length (longitud máxima) de los datos que se guardarán.
• TextField se usa para cadenas de longitud grande o arbitraria. Puedes especificar una max_length para el campo, pero sólo se usa cuando el campo se muestra en formularios (no se fuerza al nivel de la base de datos).
• IntegerField es un campo para almacenar valores de números enteros y para validar los valores introducidos como enteros en los formularios.
• DateField y DateTimeField se usan para guardar/representar fechas e información fecha/hora (como en los objetos Python datetime.date  y datetime.datetime, respectivamente). Estos campos pueden adicionalmente declarar los parámetros (mutuamente excluyentes) auto_now=True (para establecer el campo a la fecha actual cada vez que se guarda el modelo), auto_now_add (para establecer sólo la fecha cuando se crea el modelo por primera vez), y default (para establecer una fecha por defecto que puede ser sobreescrita por el usuario).
• EmailField se usa para validar direcciones de correo electrónico.
• FileField e ImageField se usan para subir ficheros e imágenes respectivamente (el ImageField añade simplemente una validación adicional de que el fichero subido es una imagen). Éstos tienen parámetros para definir cómo y donde se guardan los ficheros subidos.
• AutoField es un tipo especial de IntegerField que se incrementa automáticamente. Cuando no especificas una clave primaria para tu modelo, se añade -automáticamente- una de éste tipo.
• ForeignKey se usa para especificar una relación uno a muchos con otro modelo de la base de datos (ej. un coche tiene un fabricante, pero un fabricante puede hacer muchos coches). El lado "uno" de la relación es el modelo que contiene la clave.
• ManyToManyField se usa para especificar una relación muchos a muchos (ej. un libro puede tener varios géneros, y cada género puede contener varios libros). En nuestra aplicación de la biblioteca usaremos ésta de forma muy similar a ForeignKeys, pero pueden usarse de formas más complicadas para describir las relaciones entre grupos. Éstas tienen el parámetro on_delete para definir que ocurre cuando un registro asociado se borra (ej. un valor de models. SET_NULL establecería simplemente el valor a NULL).
• BooleanField: permite guardar información del tipo verdadero o falso, en la base de datos se guarda respectivamente un 1 (verdadero) o un 0 (falso) según corresponda. Este campo se despliega en pantalla como un checkbox.
• DurationField: permite agregar tiempos de duración en formato de Días horas: minutos: segundos eje 3 d 2:20:20 esto es 3 días con 20h con 20m y 20 segundos.
• EmailField: permite introducir correos electrónicos, este campo es verificado automáticamente por django
• URLField: permite almacenar direcciones de Internet.
• FilePathField: permite almacenar una ruta a un archivo en el disco local del servidor, en pantalla es mostrado como una lista desplegable donde aparecen los nombres de cada archivo.

Argumentos de los campos

• help_text: Proporciona una etiqueta de texto para formularios HTML (ej. en el sitio de Administración), tal como se describe arriba.
• verbose_name: Nombre de fácil lectura que se usa en etiquetas para el campo. Si no se especifica, Django inferirá el valor por defecto del verbose name a partir del nombre del campo. Establece el nombre de la etiqueta
• default: Valor por defecto para el campo. Puede ser un valor o un callable object (objeto que puede ser llamado como una función), en cuyo caso el objeto será llamado cada vez que se cree un nuevo registro.
• null: Si es True, Django guardará valores en blanco o vacíos como NULL en la base de datos para campos donde sea apropiado (un CharField guardará una cadena vacía en su lugar). Por defecto es False, permite que el campo sea guardado en la base sin contenido ingresado por el usuario y en la base de datos se guardara NULL como valor.
• blank: Si es True, se permite que el campo quede en blanco en tus formularios. El valor por defecto es False, lo que significa que la validación de formularios de Django te forzará a introducir un valor. Con frecuencia se usa con null=True, porque si vas a permitir valores en blanco, también querrás que la base de datos sea capaz de representarlos de forma apropiada.
• choices: Un grupo de valores de selección para este campo. Si se proporciona, el widget correspondiente por defecto del formulario será una caja de selección con estos valores de selección en vez del campo de texto estándar.
• primary_key: Si es True, establece el campo actual como clave primaria para el modelo (Una clave primaria es una columna especial de la base de datos, diseñada para identificar de forma única todos los diferentes registros de una tabla). Si no se especifica ningún campo como clave primaria, Django añadirá automáticamente un campo para este propósito.
• db_column: establece el nombre que puede ser asignado a la columna de la tabla en la base de datos
• unique: permite la verificación del campo en la BD, de manera que no puedan introducirse valores repetidos.

Para campos de texto:

• max_lenght: establece el maximo de caracteres que el campo puede admitir.

Para campos de archivo:

• upload_to: establece la ruta en disco donde el servidor deberá guardar los archivos subidos a la plataforma.

Para campos con numéricos decimales:

• max_digits: establece el máximo de cifras permitidas por el campo
• decimal_places: establece el máximo de cifras decimales permitidas por el campo.

Nuevo

Código:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models

# Create your models here.
class Datospersonales(models.Model):
    Num_cont = models.CharField(max_length=10, primary_key=True, verbose_name='Número de control')
    Nombre = models.CharField(max_length=50)

    SEXO = (('F', 'Femenino'), ('M', 'Masculino') )#arreglo
    #Sexo = models.CharField(max_length=1, choices=SEXO)
    Edad = models.IntegerField(help_text='Solo mayores de edad')
    Fecha_nacimiento = models.DateField()
    #Lista de Opciones en un Campo:
    #Carrera = models.CharField(max_length=30, choices=carrera_choices,default = IS,)
    IS = 'IS'
    LC = 'LC'
    LAE = 'LAE'
    CARRERA_CHOICES = (('IS', 'Ing. en Sistemas'),
   ('IS', 'Ing. en Sistemas'), ('LAE', 'Lic. en Administración de empresas'))
    carrera_choices = models.CharField(max_length=7, choices = CARRERA_CHOICES, default = IS)
    Telefono = models.CharField(max_length=12)
    email = models.EmailField()
    Domicilio = models.TextField()

Al correr el servidor.

Mensaje de help_text

Lista de carreras.

El modelo consta de los siguientes campos:

Num_cont es un campo CharField que guarda cadena de caracteres alfanuméricos, cuenta con el argumento max_length que establece la longitud del campo, primary_key = True establece como clave primaria y verbose_name = 'Nombre del campo etiqueta'.

En el campo sexo es una arreglo con dos opciones F y M.

Tenemos un arreglo con varias de las carreras, con choice para la selección, valor por default.

help_text permite dar un mensaje de restricciones o advertencia.

Después de haber realizado las modificaciones correspondientes, en consola, realizamos una migración con el comando, creamos el modelo :

python manage.py makemigrations

Se muestra que se removió Carrera, pero ahora esta establecida se agrego como arreglo carrera_choices, se realizo cambios en Edad y Num_cont.

Y finalmente creamos las tablas correspondientes en la base de dato que tengamos dada de alta en el apartado database en el archivo settings:

python manage.py migrate

Ahora podemos seguir agregando mas opciones de carrera, en el arreglo para dr

Ejecutamos el comando:

Vemos la actualización de carrera_choices. Ahora se migra lo últimos cambios.

Ahora corremos el servidor para ver los cambios.

Referencias:

https://developer.mozilla.org/es/docs/Learn/Server-side/Django/Models 

https://www.evernote.com/shard/s663/client/snv?noteGuid=fb8bb589-ac4e-47a1-820b-0c11ac1c5e0a&noteKey=8fccea01ec279129&sn=https%3A%2F%2Fwww.evernote.com%2Fshard%2Fs663%2Fsh%2Ffb8bb589-ac4e-47a1-820b-0c11ac1c5e0a%2F8fccea01ec279129&title=django%2BAlumnos

2.1.2 Estructuras Físicas de la Base de Datos

Áreas Globales de Programas PGA (Program Global Areas)

Un área global de programa (PGA) es una región de memoria que contiene datos e información de control para los procesos de servidores. Es una memoria no compartida creada por Oracle cuando un proceso de un servidor es iniciado. Solo el servidor del proceso puede acceder a él y se lee y escribe solamente por un código de Oracle que actúa en nombre del proceso.

Contenido de un PGA

El contenido de la memoria de un PGA varía dependiendo de dónde se está ejecutando la instancia y de si el tipo de servidor es compartido. Pero generalmente la memoria del PGA puede ser clasificada de la siguiente forma:

Memoria de Sesión: La memoria de sesión (Session Memory) se asigna para mantener las variables de una sesión (logon information) y otra información relativa a la sesión. Para un servidor compartido, la memoria de sesión es compartida y no privada.

Área SQL Privada: Un área SQL privada contiene datos como por ejemplo consultas de información de ejecuciones y consultas de ejecuciones en áreas de trabajo. Cada sesión que establece una sentencia tiene un área privada de SQL. Cada usuario que emite la misma sentencia tiene su propia área SQL privada que usa un área SQL compartida. Aunque, muchas áreas SQL privadas pueden ser asociadas con la misma área SQL compartida.

La ubicación de un área privada SQL depende del tipo de conexión establecida para una sesión. Si una sesión se conecta a través de un servidor dedicado, las áreas privadas SQL esta localizadas en el servidor del proceso del PGA. De cualquier forma, si una sesión se conecta a través de un servidor compartido, parte del área privada SQL se mantiene en el SGA.

Cursores y Áreas SQL

La aplicación de desarrollo de un programa precompilador Oracle o un programa OCI puede explícitamente abrir cursores, o manejar algún área privada SQL específica, y usarla como un recurso nombrado a través de la ejecución de un programa. Los cursores recursivos de Oracle que emiten implícitamente algunas sentencias SQL también usan áreas SQL.

Un área SQL privada continua existiendo hasta que el correspondiente cursor es cerrado o la sentencia es liberada. Aunque Oracle libera el área de ejecución después de que la sentencia se complete, el área persistente se mantiene en espera. Las aplicaciones de desarrollo cierran todos los cursores abiertos que no van a ser usados otra vez para liberar el área persistente y minimizar la cantidad de memoria requerida por el usuario de la aplicación.

Componentes del Área SQL Privada

El área SQL privada de un cursor se divide en 2 áreas cuya duración son diferentes:

• El área persistente (Persistent Area), que contiene, por ejemplo, información envuelta. Es liberada solamente cuando el cursor es cerrado.
•  El área de ejecución (Run-time Area), que es liberada cuando la ejecución, valga la redundancia, es terminada.

Oracle crea el área de ejecución en el primer paso que una ejecución es pedida. Para una sentencia INSERT, UPDATE y DELETE Oracle libera el área de ejecución después de que la sentencia ha sido ejecutada. Para las consultas, Oracle libera el área de ejecución solamente cuando todas las filas han sido recorridas, o la consulta ha sido cancelada.

Áreas de Trabajo SQL

Para las consultas complejas, una gran porción del área de ejecución es dedicada a áreas de trabajo asignadas por operadores de memoria-intensiva como los siguientes:

Operadores de base de clasificación “Sort-based” (order by, group by, rollup)

•  Hash-join 
•  Bitmap merge
•  Bitmap create

Por ejemplo, un operador de clasificación (sort operator) usa un área de trabajo (algunas veces llamado área de clasificación “sort area”) para la forma de distribución de la memoria interna (in-memory) de una serie de filas. Similarmente, un operador hash-join usa un área de trabajo (también llamada área hash) para construir una tabla hash desde su entrada izquierda. Si la cantidad de datos que deben ser procesados por estos dos operadores no entran en el área de trabajo, entonces los datos de entrada son divididos en piezas más pequeñas. Esto permite que alguna de las piezas se procesen en la memoria mientras el resto son distribuidos en un disco temporal para ser procesado luego. Aunque los operadores de bitmap no se distribuyen por el disco cuando su área de trabajo es muy pequeña, su complejidad es inversamente proporcional al tamaño de su área de trabajo. Estos operadores se ejecutan más rápido en áreas de trabajo más grandes.

El tamaño del área de trabajo puede ser controlado y modificado. Generalmente, áreas de bases de datos grandes pueden mejorar significativamente el rendimiento de un operador respecto al coste de consumo de memoria. Opcionalmente, el tamaño de un área de trabajo puede ser lo bastante grande como para almacenar los datos de entradas y las estructuras auxiliares de memoria asignadas por el operador SQL asociado. De lo contrario, el tiempo de respuesta aumenta, porque parte de los datos de entrada deben ser distribuidos por un disco de almacenamiento temporal. En caso extremo, si el tamaño del área de trabajo es muy pequeño comparado con el tamaño del dato de entrada, múltiples procesos se ejecutan sobre la parte de los datos. Esto puede aumentar el tiempo de respuesta de un operador considerablemente.

Administración de la Memoria del PGA para un Modo Dedicado

Se puede administrar el tamaño de las áreas de trabajo SQL globalmente y automáticamente. El administrador de la base de datos simplemente necesita que sea especificado el tamaño total dedicado a la memoria del PGA para las instancias de configurando el parámetro PGA_AGGREGATE_TARGET. El número especificado (por ejemplo 2G) es un objetivo global para la instancia, y se trata de asegurar que la cantidad total de memoria del PGA asignada por toda la base de datos de los procesos del servidor nunca exceda esa meta.

Con PGA_AGGREGATE_TARGET, modificar el tamaño de las áreas de trabajo para todas las sesiones dedicadas es automático, y todos los parámetros *_AREA_SIZE se ignoran en estas sesiones.

Área de Ordenaciones (Sort Areas)

Las áreas de ordenaciones (Sort Areas) de Oracle son las zonas de memoria en las que se ordenan los datos, es decir el espacio en memoria que necesita la organización y ordenación de las filas.

El tamaño por defecto, expresado en bytes, es específico de cada SO. Sin embargo, hay muchas razones importantes por las que este tamaño influye en el rendimiento. En el manual de Oracle 10i encontramos cuatro de ellas:

•  Aumentar el SORT_AREA_SIZE mejora la eficiencia de ordenaciones grandes.
• Cada ordenación en una consulta puede consumir la cantidad de memoria especificada en el SORT_AREA_SIZE, y pueden haber múltiples ordenaciones en una consulta. De esta forma, si otra consulta se ejecuta en paralelo, cada ordenación puede consumir la memoria especificada en este campo.
• El SORT_AREA_SIZE también se utiliza para selecciones y actualizaciones en los índices de las tablas. Seleccionar un valor apropiado aquí, puede dar como resultado que la tabla se actualice una única vez en cada operación DML, pudiendo incluso haber cambiado varias filas a la vez.
• Grandes valores en este campo nos permitirán realizar mayores búsquedas en memoria. Si se necesitase más espacio para la ordenación del que tenemos, los datos se dividirán en trozos y se utilizarán segmentos de disco temporales como apoyo en la ordenación.

Para un mejor rendimiento del SGBD, la mayoría de las ordenaciones deberían tener lugar únicamente en memoria ya que en caso de tener que escribir a disco, obtendremos un claro efecto adverso sobre éste. Si las aplicaciones que acceden a la base de datos suelen realizar búsquedas que no caben en el área de ordenaciones, o incluso si las aplicaciones realizan demasiadas búsquedas innecesarias, entonces sería conveniente modificar el parámetro de SORT_AREA SIZE.

 El SORT_AREA_SIZE es un parámetro que se puede inicializar y modificar dinámicamente y que especifica la cantidad de memoria que se tiene disponible al realizar las ordenaciones. Si una cantidad importante de ordenaciones requiere acceso a disco para almacenar segmentos temporales, entonces la aplicación se verá claramente beneficiada al ampliar el SORT_AREA_SIZE. De forma alternativa, en un entorno DSS, aumentar este parámetro no tiene por qué hacer que la ordenación se realice únicamente en memoria, pero sí es cierto que dependiendo del valor actual y del nuevo elegido, se puede aumentar drásticamente la velocidad de la ordenación.

Por lo tanto, como conclusión, alterar este parámetro, se puede considerar como un paso importante para asegurarnos el rendimiento en ciertas circunstancias y situaciones. Sin embargo, determinar qué valor es el más apropiado, es por supuesto, la parte más complicada.

Paginación

La paginación consiste en dividir los programas en pequeños bloques o páginas, de manera que sea más fácil moverlos de memoria a disco y viceversa. De la misma forma, la memoria se divide en marcos de página. De esta forma, la cantidad de memoria desperdiciada por un proceso es el final de su última página, minimizando así la fragmentación interna y evitando la externa.

En un momento cualquiera, la memoria se encuentra ocupada con páginas de diferentes procesos, mientras que algunos marcos están disponibles para su uso. El sistema operativo mantiene una lista de estos últimos marcos, y una tabla por cada proceso, donde consta en qué marco se encuentra cada página del proceso. De esta forma, las páginas de un proceso pueden no estar contiguamente ubicadas en memoria, y pueden intercalarse con las páginas de otros procesos.

En la tabla de páginas de un proceso, se encuentra la ubicación del marco que contiene a cada una de sus páginas. Las direcciones lógicas ahora se forman como un número de página y de un desplazamiento dentro de esa página (conocido comúnmente como offset). El número de página es usado como un índice dentro de la tabla de páginas, y una vez obtenida la dirección del marco de memoria, se utiliza el desplazamiento para componer la dirección real o dirección física. Este proceso se realiza en una parte del ordenador específicamente diseñada para esta tarea, es decir, es un proceso hardware y no software.

De esta forma, cuando un proceso es cargado en memoria, se cargan todas sus páginas en marcos libres y se completa su tabla de páginas.

Swapping

El Swapping es el procedimiento de mover los bloques de memoria en los que están algunos procesos que no se están utilizando, desde la memoria principal a un espacio Swap dejando así hueco libre para poder cargar en memoria otros procesos que sí se van a utilizar.

El espacio Swap o espacio de intercambio es una zona de disco (un fichero o una partición) que se usa para guardar las imágenes de los procesos que no han de mantenerse en memoria física.

Este procedimiento es muy similar a la paginación, con la diferencia principal de que el directorio Swap funciona exactamente igual que la memoria RAM, por lo que puede almacenar datos privados, contraseñas y todo lo que almacena ésta. Sin embargo, en la paginación, únicamente se sacan de memoria páginas pertenecientes a procesos que no se estén utilizando, además de que se pueden sacar solo algunas páginas de los procesos y no éstos enteros como se hace en el Swapping.

Con respecto al tamaño que debe tener el directorio Swap, hay muchas discusiones sobre ello como por ejemplo la antigua creencia de “El Swap debe tener el doble de tamaño que la RAM.” cosa que no es válida hoy día debido a la gran capacidad de la memoria RAM de la mayoría de ordenadores.

Como conclusión, hay que destacar que el uso de la memoria virtual por parte de Oracle, va a influir bastante en el rendimiento, disminuyéndolo drásticamente en comparación con el uso únicamente de la memoria RAM.

Área de Código de Software (Sca)

El área de código de software son zonas de memoria destinadas a almacenar el código de Oracle en ejecución o que puede ejecutarse. Este código de Oracle se almacena en una zona distinta, y más protegida, que las zonas dedicadas a almacenar los códigos de programas de usuarios.

La SCA suele ser de tamaño estático, cambiando únicamente cuando el software se reinstala o actualiza. El tamaño requerido para este área puede variar en función del SO. Son áreas de sólo lectura y pueden ser instalas de forma compartida o no compartida. Cuando es posible, el código de Oracle se comparte, por lo que todos los usuarios pueden acceder a él sin tener múltiples copias en memoria. El resultado es un ahorro considerable de memoria y una mejora del rendimiento general.

Por otra parte, los programas de usuario también pueden ser compartidos o no. Algunas utilidades y herramientas de Oracle (como ocurre con Oracle Forms y SQL*Plus) pueden ser instalados de forma compartida, pero otras no. Múltiples instancias de Oracle pueden usar la misma SCA con diferentes bases de datos si están corriendo en la misma máquina.

Hay que tener en cuenta que la opción de instalar software compartido puede no estar disponible en función del sistema operativo, como ocurre por ejemplo en máquinas con Windows.

Estructura de los Procesos

Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos módulos de código diferentes, que además el encargado de gestionar estos procesos es el sistema operativo, estos dos módulos diferentes son:

• Aplicación o Herramienta Oracle: normalmente son programas clientes que se conectan a la base de datos y permiten ejecutar sentencias SQL. Ej.: SQL*Plus, SQL developer
• 
  
• Código del Servidor de Oracle: son los diferentes procesos que se han de ejecutar en el servidor para atender las peticiones del usuario.

La base de datos Oracle es un sistema multiproceso, lo que significa que no toda la base de datos está corriendo en un mismo proceso, si no que varias partes de la base de datos se ejecuta concurrentemente. Permitiendo a múltiples usuarios conectarse a la misma vez, y mayor rapidez en el tiempo de respuesta, puesto que siempre que pueda va a utilizar al máximo al ordenador, por ejemplo si tiene ocho núcleos el servidor, y resulta que una petición se puede paralelizar se ejecutara esa petición por partes en cada núcleo.

De los procesos que se ejecutan en el servidor podemos hacer dos grandes grupos:

• Procesos de Usuarios: Cada vez que un usuario ejecuta una aplicación, ya sea propia o de Oracle se crea un proceso, que puede ser de dos tipos.
• Conexión: Que es la vía de comunicación entre la aplicación y la instancia de la base de datos a la que se ha conectado.
• Sesión: Es la conexión específica con la base de datos proporcionando un usuario y su contraseña.

Esto permite que desde un mismo equipo se puedan conectar varios usuarios simultáneamente, y que un usuario se pueda conectar desde diferentes equipos simultáneamente.

• Procesos de Oracle: Son propios de la base de datos, y el usuario no tiene control sobre ellos, pueden ser de dos tipos:
• Procesos de Servidor: Se crea cuando una aplicación intenta acceder a la base de datos, para atender a las peticiones de la aplicación y devolver los resultados que se precisen.
• Procesos de Background: Se crean cuando se inicia una instancia de la base de datos, solo hay un proceso de cada tipo de los que especificaremos a continuación, y no han de estar todos siempre presentes en el servidor. Se utilizan para realizar labores de mantenimiento, y para guardar la integridad de la base de datos. Los diferentes tipos de procesos son los siguientes:

• Database Writer Process (DBWn)

El (DBWn) escribe el contenido de los buffers en los archivos de datos. El proceso DBWn es responsable por la escritura de los buffers modificados del buffer cache al disco. El proceso DBWn escribe buffers modificados al disco bajo las siguientes condiciones:

Cuando un proceso no puede encontrar un buffer limpio reusable después de haber recorrido un número de determinado de buffers en el buffer caché, éste envía una señal al DBWn para la escritura. El DBWn escribe los buffers sucios al disco.

El DBWn periódicamente escribe los buffers cuando se lleva a cabo un checkpoint. Chekpoint es una posición en el hilo de redo (log) donde se iniciará luego la recuperación. La posición en el log está determinada por el último buffer sucio en el buffer caché.

• Log Writer Process (LGWR)

El proceso LGWR es responsable del manejo del redo log buffer, las escrituras del redo log buffer al archivo de redo log en el disco. El LGWR escribe todos los registros de redo que han sido copiados en el buffer desde la última vez que éste se escribió. El redo log buffer es un buffer circular. Cuando LGWR escribe los registros del redo log buffer al redo log file, el proceso servidor puede copiar nuevos registros sobre aquellos que se pasaron a disco. LGWR normalmente escribe lo suficientemente rápido para asegurar que el espacio esté siempre disponible en el buffer para nuevos registros, aun cuando la escritura al redo log file sea lenta.

LGWR escribe en porciones contiguas del buffer al disco. El LGRW escribe:

Un registro de commit cuando un usuario hace commit de una transacción

Redo log buffers:

• Cada tres segundos
• Cuando el redo log tenga un tercio lleno
• Cuando un proceso de DBWn escriba los buffers modificados a disco, si es necesario.

Cuando un usuario lleva a cabo una instrucción de commit, el LGWR coloca el registro de commit en el log buffer y escribe la transacción a disco inmediatamente en el redo log. Los cambios correspondientes a los bloques de datos en el buffer caché, son dejados hasta que se tenga una escritura más eficiente que hacer. Esto se denomina el mecanismo de fast commit. La escritura de un registro de redo del commit de la transacción es un evento atómico.

Existe un mito con respecto a la escritura en el redo log buffer, se dice que en el redo log buffer o redo log file aparecerán sólo las transacciones comprometidas. En el redo log file se escriben todas las transacciones, no sólo las comprometidas, es por ello que el redo log permite rehacer los segmentos de undo del cualquier punto en el tiempo cuando se hace recuperación incompleta (point in time recovery).

Redo Log Files

Los Redo Log Files se agrupan en grupos de Redo Log. Todos los miembros de un Redo Log Group son idénticos, es decir contendrán la misma información. Dentro de un grupo de Redo Log se "multiplexan" los archivos para evitar los puntos de fallas, es decir si se perdiera un archivo de Redo Log habría otro que contendría la información y que permitiera la recuperación de la base de datos.

Los redo log se utilizan de forma circular, mediante grupos de archivos. Por defecto la base de datos Oracle genera 3 grupos de archivos. Se considerará el grupo current (actual) aquel donde se esté utilizando para escribir las transacciones actuales de la base de datos. Se considera un grupo active (activo), aquel que no es el actual y que posea transacciones cuyos cambios no se han hecho permanentes en los archivos de datos e inactivo aquel que contenga transacciones que han sido completamente escritas a disco, finalmente también se puede tener que un grupo de redo log esté limpio porque nunca haya sido escrito.

Los archivos de redo log trabajan de forma circular porque se sobrescriben, generalmente con los tres grupos se tendrá que uno de ellos se encontrará activo, el siguiente en enumeración será el actual y el siguiente estará inactivo listo para que se escriba en él. Una vez llenado el grupo actual se comenzará a escribir en el inactivo, que ahora será el actual, el que anteriormente era el actual pasará a ser activo si aún no se han escrito todas sus transacciones a disco y eventualmente el que inicialmente estaba activo pasará a ser inactivo y permitirá que al llenarse el grupo actual se escriban las transacciones en él.

Si se llenara el grupo actual de los archivos de redo y el resto de los grupos se encontraran activos, la base de datos no permitiría ninguna transacción hasta que se escriban todas las transacciones a disco del siguiente grupo de redo log y que este quedase inactivo. Cuando se trabaja con una base de datos en modo ARCHIVELOG, antes de sobrescribir el archivo se hace una copia de ese grupo de redo log al destino de los archivos.

Checkpoint Process (CKPT)

El CKPT lleva a cabo un checkpoint, entendiéndose como tal a la escritura parcial o completa de los buffers de memoria a disco. El CKPT no es el responsable de escribir los bloques a disco, para ello llama al DBWn y como en esa escritura podrían almacenarse en disco buffers de transacciones no comprometidas el CKPT también llama al LGWR para que registre en los redo log files esta escritura que permita generar los segmentos de undo de transacciones no comprometidas cuando se realice una recuperación incompleta. También si en la escritura del checkpoint hay transacciones que no se habían terminado de escribir en disco se escriben, se actualiza la cola de transacciones activas y un grupo de redo log que estaba activo podría pasar a inactivo.

Cuando un checkpoint ocurre, Oracle debe actualizar todas las cabeceras de los archivos de datos con los detalles del checkpoint, ésta es una tarea del CKPT.

System Monitor Process (SMON)

El proceso SMON lleva a cabo la recuperación, si es necesaria, de la instancia en el inicio de la misma, es decir rehacer cualquier transacción comprometida en el redo log file que no haya sido escrita a disco. SMON también es responsable de limpiar los segmentos temporales que no estén en uso por algún tiempo y de desfragmentar si cree oportuno alguna zona de los discos.

Process Monitor (PMON)

PMON lleva a cabo procesos de recuperación cuando un proceso de usuario falla. Es responsable de la limpieza del buffer caché, también de deshacer los cambios que se hayan hecho desde el ultimo commit y de la liberación de recursos que el proceso estaba usando. Por ejemplo este restaura el status de la tabla de transacciones activas, libera los locks y remueve el ID del proceso de la lista de procesos activos, asociados a un proceso usuario que pudo haber perdido la conexión de red.

Recoverer (RECO)

Este proceso solo se observa cuando la base de datos ejecuta la opción distribuida de Oracle. La transacción distribuida es una en la que dos o más emplazamientos de datos deben mantenerse sincronizados, Por ejemplo cuando se tiene una copia de los datos en diferentes ciudades y por fallas en una línea telefónica se pierde una transacción en la mitad de su actualización. El proceso recuperador entonces resuelve las transacciones que hayan quedado inconsistentes en las dos ciudades.

Archiver Processes (ARCn)

El ARCn copia los archivos de redo log llenos a un espacio de almacenamiento distinto para no perderlos al ser sobreescritos. El ARCn sólo está habilitado cuando la base de datos está en el modo ARCHIVELOG. En Oracle 10g para colocar la base de datos en modo archive basta con colocarla en modo ARCHIVELOG y especificar los destinos de "archive". En Oracle 9i se distinguía entre el "archive" manual y automático. Con "archive" manual el DBA debía ordenar hacer la copia de los redo log a los "archives", en el modo automático se copiaban automáticamente antes de ser sobrescritos. En Oracle 10g al poner una base de datos en modo ARCHIVELOG automáticamente se coloca en el modo automático.

Lock (LCKn)

Es un proceso opcional, configurado para manejar los bloqueos entre bases de datos Oracle cuando estas se encuentran en distintos computadores y compartiendo el mismo conjunto de discos (es decir en modo servidor en paralelo).

Job Queue (SNPn)

Es un proceso opcional, que se encarga de planificar los procesos que se deben ejecutar y asegurar que todos deben de terminar en algún momento.

Queue Monitor (QMNn)

QMNn es un proceso opcional de background para el encolamiento avanzado de Oracle, que monitorea las colas de mensajes. El encolamiento avanzado se usa con comunicación asíncrona. Los procesos envían los mensajes y en lugar de esperar por la respuesta siguen con su trabajo.

Dispatcher (Dnnn)

Es un proceso opcional que permite a los usuarios compartir procesos de servidor. Permitiendo que se conecten múltiples usuarios al mismo servidor.

Shared Server (Snnn)

Este tipo de proceso se encarga de atender a cada uno de los clientes conectados a la base de datos compartiendo los procesos del servidor.

2.1 Estructura de memoria y procesos de la instancia

En una base de datos almacenamos información relevante para nuestro negocio u organización y desde el punto de vista físico, la base de datos está conformada por dos tipos de archivos:

Archivos de datos: contiene los datos de la base de datos internamente, está compuesto por páginas enumeradas secuencialmente que representa la unidad mínima de almacenamiento. Cada página tiene un tamaño de 8kb de información. Existen diferentes tipos de páginas, a tener en cuenta:

Páginas de datos: es el tipo principal de páginas y son las que almacenan los registros de datos.

Páginas de espacio libre (PFS Page Free Space): almacenan información sobre la ubicación y el tamaño del espacio libre.

Paginas GAM and SGAM: utilizadas para ubicar extensiones.

Páginas de Mapa de Ubicaciones de índices (IAM – IndexAllocationMap): contiene información sobre el almacenamiento de páginas de una tabla o índice en particular.

Páginas Índices: Utilizada para almacenar registros de índices.

Archivo de Registro de Transacciones: El propósito principal del registro de transacciones es la recuperación de datos a un momento en el tiempo o complementar una restauración de copia de respaldo completa (full backup). El registro de transacciones no contiene páginas, sino entradas con todos los cambios realizados en la base de datos, como son las modificaciones de datos, modificaciones de la base de datos y eventos de copia de seguridad y restauración. El acceso a datos es secuencial, ya que el registro de transacciones se actualiza en el mismo orden cronológico en el que se hacen las modificaciones.

Este archivo no puede ser leído por herramientas de usuario de SQL auqnue existen herramientas de terceros que leen este archivo para recuperar los cambios efectuados. Dependiendo de la versión el registro de transacciones se utiliza para otros propósitos como por ejemplo bases de datos espejo (mirror) y transporte remoto de transacciones (log shipping).

Para muchos de los administradores de bases de datos, la imagen anterior representa la parte lógica y la parte física, donde:

Data File:

Los datafiles son los archivos físicos en los que se almacenan los objetos que forman parte de un tablespace. Un datafile pertenece solamente a un tablespace y a una instancia de base de datos. Un tablespace puede estar formado por uno o varios datafiles. Cuando se crea un datafile, se debe indicar su nombre, su ubicación o directorio, el tamaño que va a tener y el tablespace al que va a pertenecer. Además, al crearlos, ocupan ya ese espacio aunque se encuentran totalmente vacíos, es decir, Oracle reserva el espacio para poder ir llenándolo poco a poco con posterioridad. Por supuesto, si no hay sitio suficiente para crear un archivo físico del tamaño indicado, se producirá un error y no se creará dicho archivo.

Cuando se van creando objetos en un tablespace, éstos físicamente se van almacenando en los datafiles asignados a dicho tablespace, es decir, cuando creamos una tabla y vamos insertando datos en ella, estos datos realmente se reparten por los archivos físicos o datafiles que forman parte del tablespace. No se puede controlar en qué archivo físico se almacenan los datos de un tablespace. Si un tablespace está formado por 2 datafiles y tenemos una tabla en ese tablespace, a medida que vamos insertando filas éstas se almacenarán en cualquiera de los dos datafiles indistintamente, es decir, unas pueden estar en un datafile y otras en otro.

El espacio total disponible en un tablespace es lógicamente la suma de los tamaños que ocupan los archivos físicos o datafiles que lo forman. Como hemos indicado estos datafiles, al crearlos, están totalmente vacíos, simplemente es un espacio reservado y formateado por Oracle para su uso. A medida que se van creando objetos en ellos como tablas, índices, etc. y se van insertando registros en estas tablas, los datafiles se van llenando o, lo que es lo mismo, el tablespace se va llenando.

Tienen las siguientes características:

Un archivo sólo puede estar asociado con una base de datos.

Los archivos de datos tienen atributos que permiten reservar automáticamente para ellos extensiones cuando se acaba el espacio.

Uno o más archivos de datos forman una unidad lógica de almacenamiento llamada tablespace.