SAP ASE para Administradores

Curso para administradores de SAP ASE

1. NobleProg SAP ASE para Administradores de Bases de Datos 14-01-2021 NobleProg® Limited 2017 All Rights Reserved
2. Adaptive Server Enterprise 16.0 El componente servidor de ASE es un sistema multiusuario para la gestión de bases de datos relacionales, construido sobre un modelo de procesamiento distribuido • ASE es una base de datos completamente funcional que se acoge a ANSI • Puede dar soporte a terabytes de datos y a miles de usuarios simultáneos • Opera como una aplicación cliente/servidor NobleProg® Limited 2017 All Rights Reserved NobleProg
3. SAP ASE 16 Mayor escalabilidad optimizaciones en: y velocidad con amplias  Concurrencia de transacciones  Gestión  Ejecución de planes de consultas  Compresión de datos Los puntos de referencia OLTP internos preliminares en 80 núcleos de CPU muestran una escalabilidad lineal con rendimientos de transacciones tan altos como un millón de transacciones por minuto. NobleProg® Limited 2017 All Rights Reserved NobleProg
4. NUEVAS FUNCIONALIDADES Histogramasdinámicos Montaje / Desmontaje de basesde datoscifradas Índicescomprimidos Soporte paracomando "Select into" en transaccionesmulti-statement Bloqueo de partición Limite de consultasmasamplio Rendimiento de consultasmejorado Cifrado de Basesde datoscompleto Historiade configuración Util para tablas donde adicionan valores fueras de rango frecuentemente para evitar costosos escaneos de tablas para nuevos valores maximos de columna No es posible antes de SAP ASE16 Habilitar/deshabilitar compresión de índices (tabla, índice, partición) Lo soporta para aquellos que lo usan Mejores mecanismos de concurrencia con bloqueo a nivel de particion Para subconsultas con joins complejos, en caso de que sea realmente necesario Mejoras en paralelismo y acceso a valores comprimidos Una nueva funcionalidad para complementar el cifrado de columna Capacidad para registrar cambios de configuración en la base de datos sybsecurity NobleProg® Limited 2017 All Rights Reserved NobleProg
5. KERNEL • THREAD: Un solo proceso por “engine”. Usa los threads del sistema operativo. • PROCESS: Un proceso por “engine”. • El modo Thread proporciona un uso mas eficiente de los recursos, especialmente para cargas de trabajo que requieren múltiples conexiones activas. • A partir de versiones 15.7 el valor por defecto es Thread para soportar multi-thread hardware (SMT en AIX) • SAP asume que usa el modo de subprocesos (Thread) en su servidor de producción NobleProg® Limited 2017 All Rights Reserved NobleProg
6. OPCIONES SAP ASE Opción MemScale In memory-Database Always ON Workload Analyzer Encrypted Columns Partitions TSM Compression Descripción Se puede configurar memoria transaccional Se puede una base de datos completamente memoria Configuración de alta disponibilidad o DRP Permite la captura, el análisis y la reproducción de una carga de trabajo de producción de forma no disruptiva Aumenta los parámetros de seguridad y permite la adición de tipos de datos. Particionamiento semantico Permite configurar respaldos y restauraciones directamente a Tivoli Permite la compresión de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
7. Requerimientos de ASE 16 para Servidores AIX • • • • • Procesador– 64-bits Kernel – 64-bits User stack size por defecto– 148KB Máximas CPUs por servidor – 128 Input/Output Completion Port API (IOCP) – Debe estar disponible (lsdev -Cc iocp) • Memoria RAM mínima recomendada – 124MB • Memoria por usuario –stack size, packet size, and user log cache size, aproximadamente 312KB con valores por defecto. • Limite de recursos de procesos de usuario (Ilimitado) (ulimit) NobleProg® Limited 2017 All Rights Reserved NobleProg
8. Requerimientos para la Instalación de ASE 16 • Para instalar ASE, usted debe tener el mínimo espacio en disco requerido para las bases de datos del sistema (servidor de 2K): • • • • • • • • • master – 196 MB model – 3 MB tempdb – 100 MB sybsystemprocs – 196 MB sybsystemdb – 3 MB Un dispositivo es un recurso físico para almacenar bases de datos Dispositivos del sistema son creados durante la instalación El dispositivo master, almacena algunas bases de datos del sistema El dispositivo sysprocsdev, para almacenar la base de datos sybsystemprocs NobleProg® Limited 2017 All Rights Reserved NobleProg
9. Sistemas Operativos Soportados NobleProg® Limited 2017 All Rights Reserved NobleProg
10. Clientes SAP ASE SOPORTADOS CLIENTE Cliente Version SAP Open Client™/SAP Open Server™ 15.7, 16.0 SAP Adaptive Server Enterprise Extension Module for Python SAP Adaptive Server Enterprise Extension Module for PHP SAP Adaptive Server Enterprise Database Driver for PERL SAP jConnect™ for JDBC SAP ASE ODBC Driver SAP ASE OLE DB Provider ADO.NET SAP Replication Server 15.5 15.7, 16.0 15.7, 16.0 15.7, 16.0 7.0.x, 16.0 15.7, 16.0 15.5.x 15.7, 15.5.x 2.x, 4.x, 16.0 15.7, 15.7.1, 15.7.1 SP100, 15.7.1 SP200, 15.7.1 SP300 15.5, 15.6 NobleProg® Limited 2017 All Rights Reserved NobleProg
11. Editores de Texto Cliente • ASE 16.0 incluye los siguientes editores de texto cliente: • isql • Interactive-SQL (DBISQL) • Estos editores de texto pueden ser usados para tener acceso a ASE y ejecutar comandos NobleProg® Limited 2017 All Rights Reserved NobleProg
12. Uso de isql • Sintaxis isql [-U username] [-P password] [-S server] [-i input_file] [-o output_file] [-E editor] [-w column_width] • Ejemplo: isql –Uman101 –Psybase –SFTMAN1 • Para salir de isql: • Ejecute quit o exit NobleProg® Limited 2017 All Rights Reserved NobleProg
13. Uso de isql en Lotes • Use la bandera –i para especificar un archivo de entrada o un T-SQL por lotes. • Ejemplo: isql –Uman101 –Psybase –SFTMAN1 -i input.sql –o output.txt • El archivo de entrada debe contener la palabra “go” para cada comando, así como al final. NobleProg® Limited 2017 All Rights Reserved NobleProg
14. Uso de Interactive SQL • Arranque de Interactive SQL • Existen dos opciones: • Seleccione Start-> Programs-> Sybase-> ASE -> Interactive SQL (Windows) • Ejecute dbisql desde la línea de comandos (Windows/UNIX) • dbisql se encuentra bajo $SYBASE/DBISQL (UNIX) o %SYBASE%\DBISQL (Windows) • Conéctese a su servidor seleccionando SQL -> Connect del menú. Especifique el login, contraseña y nombre del servidor en la caja de diálogo, y luego haga click en Connect • Para salir de Interactive SQL • Seleccione File -> Exit del menú o haga click el botón Close NobleProg® Limited 2017 All Rights Reserved NobleProg
15. Otros Utilitarios Cliente • bcp – programa para copiar datos desde/hacia archivos • optdiag – programa para detectar uso ineficaz de espacio y gestionar estadísticas del optimizador • SQL Debugger (sqldbgr) – utilitario de línea de comandos para depurar procedimientos almacenados y triggers • ddlgen – herramienta basada en Java que genera definiciones para objetos a nivel de servidor y base de datos en ASE • sybmigrate – mueve el esquema y datos de un ASE a otro NobleProg® Limited 2017 All Rights Reserved NobleProg
16. Otros Programas Utilitarios • Utilitario para la instalación de servidores • srvbuild en plataformas UNIX • Server Config en plataformas Windows • dsedit – un editor para creación y modificación del archivo interfaces (archivo de conectividad cliente/servidor) NobleProg® Limited 2017 All Rights Reserved NobleProg
17. Otros Componentes Servidor de ASE • Backup Server – lleva a cabo respaldo/cargue de bases de datos para operaciones de respaldo y recuperación • XP Server – ejecuta procedimientos almacenados extendidos • Unified Agent – provee servicios de ejecución para administrar, monitorear y controlar recursos distribuidos Sybase NobleProg® Limited 2017 All Rights Reserved NobleProg
18. Bases de Datos de ASE • ASE maneja múltiples tipos de bases de datos • • • • Bases Bases Bases Bases de de de de datos datos datos datos requeridas (del sistema) de “funcionalidad adicional” de ejemplo de aplicación (de usuario) NobleProg® Limited 2017 All Rights Reserved NobleProg
19. Bases de Datos Requeridas • master contiene tablas del sistema que almacenan datos usados para la gestión de ASE • model es una base de datos “plantilla” usada cuando se crea un nueva • sybsystemprocs contiene las tablas en las que se almacenan los procedimientos almacenados del sistema • sybsystemdb contiene datos para el componentes de gestión de transacciones distribuidas • tempdb contiene tablas temporales NobleProg® Limited 2017 All Rights Reserved NobleProg
20. Bases de Datos de “Funcionalidad Adicional” • sybsyntax contiene ayuda de sintaxis para TransactSQL • dbccdb contiene entrada y salida para el comando dbcc checkstorage • La instalación de dbccdb permite al los Administradores del Sistema verificar la consistencia de las bases de datos • sybsecurity contiene información y configuración de la auditoría NobleProg® Limited 2017 All Rights Reserved NobleProg
21. Bases de Datos de Ejemplo y de Aplicación • pubs2 y pubs3 son bases de datos de ejemplo para un compañía ficticia de distribución de libros • La instalación de pubs2 o pubs3 permite a los usuarios practicar comandos Transact-SQL en un ambiente seguro y predecible • Las bases de datos de aplicación son definidas por los usuarios en ambientes de desarrollo o producción NobleProg® Limited 2017 All Rights Reserved NobleProg
22. Tablas del Sistema • Una tabla del sistema es una tabla creada y mantenida por el servidor; almacena información sobre el servidor y sus bases de datos • Los nombres de las tablas del sistema usualmente comienzan con “sys” o “spt_” • Ejemplos: sysobjects, sysusers NobleProg® Limited 2017 All Rights Reserved NobleProg
23. Tablas del Sistema en master • Algunas tablas del sistema sólo existen en la base de datos master • Almacenan información a nivel de servidor • Ejemplos: sysdatabases, syslogins, syscurconfigs NobleProg® Limited 2017 All Rights Reserved NobleProg
24. Tablas del Sistema en Todas las Bases de Datos • Algunas tablas del sistema existen en todas las bases de datos • Almacenan información específica de dicha base de datos • Ejemplos: sysobjects, sysusers, syscolumns NobleProg® Limited 2017 All Rights Reserved NobleProg
25. Procedimientos Almacenados del Sistema • La información de las tablas del sistema usualmente se puede visualizar y modificar con procedimientos del sistema • Los nombres de los procedimientos del sistema comienzan por “sp_” • Ejemplos: sp_help, sp_adduser • Cuando un procedimiento del sistema se ejecuta, ASE busca el procedimiento en múltiples ubicaciones: • • • • Primero, busca en la base de datos actual Si no está ahí, busca en la base de datos sybsystemprocs Si no está ahí, busca en la base de datos master Si no está ahí, genera un mensaje de error • Para otros procedimientos del sistema, sólo se busca en la base de datos actual NobleProg® Limited 2017 All Rights Reserved NobleProg
26. Responsabilidades del Administrador del Sistema • La administración del sistema típicamente involucra las siguientes responsabilidades: • Crear y configurar servidores • Instalar clientes y establecer conectividad entre clientes y servidores • Ajustar la configuración del servidor • Crear bases de datos y gestionar el uso de espacio en disco • Gestionar la seguridad a nivel de servidor • Llevar a cabo cargue/restauración de copias de respaldo • Monitorear y depurar el servidor • Mejorar el rendimiento del servidor NobleProg® Limited 2017 All Rights Reserved NobleProg
27. Documentación de ASE • Los siguientes manuales son de especial interés para administradores del sistema • • • • • System Administration Guide Reference Manual Troubleshooting and Error Messages Guide Performance and Tuning Guide Utility Guide https://help.sap.com/viewer/product/SAP_ASE/16.0.4.0/en-US? expandAll=true NobleProg® Limited 2017 All Rights Reserved NobleProg
28. Juego de Caracteres y Ordenamiento • ASE usa juegos de caracteres y ordenamiento predeterminados • El juego de caracteres predeterminado depende de la plataforma • El ordenamiento predeterminado es binario • También es posible cambiar los juegos de caracteres y el ordenamiento después de la instalación • Ya que estos cambios requieren una significativa manipulación de los datos existentes, no se recomiendan a no ser que sean obsolutamente necesarios • Ejecute sp_helpsort para ver el juego de caracteres y modo de ordenamiento actuales NobleProg® Limited 2017 All Rights Reserved NobleProg
29. Utilitarios de Instalación • Cada plataforma tiene su utilitario para la instalación de servidores • Para UNIX, es srvbuild • Para Windows, es Server Config • Al final de la ejecución del Instalador, el sistema activa el proceso de instalación de servidores • Usted puede instalar un servidor en ese momento o después • Usted puede iniciar el proceso de instalación de servidores en cualquier momento • UNIX • Vaya el directorio $SYBASE/$SYBASE_ASE/bin • Ejecute el comando srvbuild desde la línea de comandos • Windows • Seleccione Start->All Programs->Sybase->Adpative Server enterprise -> Server Config NobleProg® Limited 2017 All Rights Reserved NobleProg
30. Archivo de Recursos de Ejemplo • Permite instalar un servidor sin interacción del usuario. • Las plantillas de archivos de recursos son proveídos, y pueden ser editados para especificar las características del servidor a construir. • En UNIX, use el utilitario srvbuildres para crear un servidor a partir del archivo de recursos Syntaxis: srvbuildres [-v] [-rnombre_archivo] • En Windows, use el utilitario sybatch para crear servidores a partir de un archivo de recursos Syntaxis: sybatch [-rnombre_archivo] Ejemplo : cd %SYBASE%\%SYBASE_ASE%\sample\server\ sybatch -rsybatch_ase.res NobleProg® Limited 2017 All Rights Reserved NobleProg
31. Archivo de Recursos de Ejemplo NobleProg® Limited 2017 All Rights Reserved NobleProg
32. Estructura de Directorios: ASE 16.0 • Un directorio principal ($SYBASE o %SYBASE%) • Sub-directorios para cada componente, que incluyen: • Programas ejecutables para el componente • Herramientas de instalación y configuración para el componente • Otros archivos requeridos por el componente • El nombre del sub-directorio usa convenciones que incluyen un identificador del componente y su versión: • Ejemplos: • ASE-16_0/ (archivos de ASE) • OCS-16_0/ (archivos de Open Client/Open Server) • jConnect-7_0/ (archivos de jConnect 7.0) NobleProg® Limited 2017 All Rights Reserved NobleProg
33. Directorios de Instalación SAP ASE NobleProg® Limited 2017 All Rights Reserved NobleProg
34. Sub-directorios Importantes de ASE-15_0 • ASE-16_0 • Bin - Archivos ejecutables para utilitarios de servidor • Init - Archivos de registro de instalación de ASE • Install - Programas de instalación, archivos RUNSERVER, log de errores • Scripts - Scripts para la instalación de bases de datos opcionales • OCS-16_0 • Bin - Archivos ejecutables para utilitarios cliente NobleProg® Limited 2017 All Rights Reserved NobleProg
35. El Archivo Interfaces • El Archivo Interfaces lista el nombre y dirección de cada servidor en la red • Al conectarse a un servidor con un nombre dado, las aplicaciones cliente: • Buscan el nombre de servidor en el Archivo Interfaces • Se conectan al servidor usando la dirección dada • El nombre y ubicación del Archivo Interfaces varía entre sistemas operativos • UNIX : interfaces en $SYBASE • Windows : sql.ini en %sybase%\ini NobleProg® Limited 2017 All Rights Reserved NobleProg
36. Variables de Ambiente • $SYBASE (definida por el administrador) • Identifica el directorio principal de instalación para los productos Sybase • $SYBASE_ASE (definida por el sistema en ASE-16_x) • Identifica el sub-directorio de instalación de ASE • $DSLISTEN (definida por el administrador) • Identifica el nombre de servidor usado cuando el archivo RUNSERVER no especifica el nombre del servidor al arrancar • $DSQUERY (definida por el administrador) • Identifica el nombre de servidor al que se conectan los utilitarios cliente por defecto, al no especificar un nombre • $JAVA_HOME (definida por el administrador) • Identifica el sub-directorio en donde está ubicado el JDK • Requerido para clientes Java NobleProg® Limited 2017 All Rights Reserved NobleProg
37. El Archivo RUNSERVER de UNIX • El archivo RUNSERVER es un script UNIX usado para arrancar un servidor • Está ubicado en el directorio ASE-16_0/install • Contiene el comando dataserver usado para arrancar el servidor • Incluye la siguiente información: • • • • • Nombre del servidor Ubicación del dispositivo master Ubicación del log de errores Ubicación del archivo de configuración Ubicación del archivo interfaces NobleProg® Limited 2017 All Rights Reserved NobleProg
38. Arrancando Servidores en UNIX • Sintaxis simplificada: startserver [-f runserver_file] • Ejemplo: prompt% cd $SYBASE/$SYBASE_ASE/install prompt% startserver -f RUN_SYBASE • • Ejecute éste comando desde la línea de comandos del S.O. Este comando arranca el servidor especificado en el archivo RUNSERVER • Si no se especifica nombre de archivo, startserver busca un archivo llamado RUN_SYBASE NobleProg® Limited 2017 All Rights Reserved NobleProg
39. Verificando que el Servidor está Corriendo en UNIX • Sintaxis: showserver • Ejemplo: prompt% showserver F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 0 S syb204 2202 2201 0 75 0 - 23985 Aug18 ? 00:50:19 /home/usr/u/syb204/ase150/ASE-15_0/bin/dataserver -sSYB204_2K -d/home/usr/u/syb204/ASE-12_5/devices/2Kmaster.dat e/home/usr/u/syb204/ase150/ASE-15_0/install/SYB204_2K.log -c/home/usr/u/syb204/ase150/ASE-15_0/SYB204_2K.cfg -M/home/usr/u/syb20 0 S syb203 17269 17268 0 75 0 - 14431 09:29 ? 00:00:00 /home/usr/u/syb203/ase150/ASE-15_0/bin/backupserver -SSYB203_2K_BS -e/home/usr/u/syb203/ase150/ASE-15_0/install/SYB203_2K_BS.log -N25 -C20 -M/home/usr/u/syb203/ase150/ASE-15_0/bin/sybmultbuf • Ejecute éste comando desde la línea de comandos del S.O. • Lista todos los servidores en ejecución en la máquina local • Sólo aparecen los encabezados si no hay servidores en ejecución NobleProg® Limited 2017 All Rights Reserved NobleProg
40. Deteniendo Servidores en UNIX • Sintaxis T-SQL: shutdown [server_name] [with {wait nowait}] • Ejemplo: 1> shutdown 2> go Server SHUTDOWN by request. The SQL Server is terminating this process. • Ejecute éste comando desde un cliente Sybase • server_name se requiere al detener un servidor diferente a ASE (por ejemplo, Backup Server) • La opción nowait detiene el servidor inmediatamente, aún si hay comandos en ejecución • La opción wait permite que las transacciones en ejecución terminen antes de ejecutar el shutdown NobleProg® Limited 2017 All Rights Reserved NobleProg
41. Laboratorio 1 • Conectarse a los servidores y subir las instancias test_ASE157, test_ASE16 Usuario ase157 ase160 Password ase157 ase160 Instancia test_ASE157 test_ASE16 • Conectarse a las instancias y ejecutar el comando “sp_versión” NobleProg® Limited 2017 All Rights Reserved NobleProg
42. Configuración • ASE provee valores de configuración predeterminados • Usted puede ajustar los parámetros de configuración para que se ajusten a sus necesidades • El archivo de configuración es un archivo texto en el que se guardan los valores de configuración • Por defecto, se llama <server_name>.cfg y se ubica en la ruta: $SYBASE/$SYBASE_ASE/ NobleProg® Limited 2017 All Rights Reserved NobleProg
43. Tipos de Parámetros • Los cambios a los parámetros dinámicos entran en efecto de inmediato • Los cambios a los parámetros estáticos entran en efecto al reiniciar ASE • Parámetros de solo lectura muestran información pero no pueden ser cambiados NobleProg® Limited 2017 All Rights Reserved NobleProg
44. Comandos utilizados • sp_configure • • • • Muestra los valores de los parámetros de configuración Modificar los valores de los parámetros de configuración Restaura los valores de los parámetros de configuración Carga y verifica archivos de configuración • sp_helpconfig • Muestra información de ayuda sobre los parámetros de configuración NobleProg® Limited 2017 All Rights Reserved NobleProg
45. Componentes de la Memoria de ASE • Los componentes de alto nivel de la memoria de ASE incluyen: NobleProg® Limited 2017 All Rights Reserved NobleProg
46. Parámetro “max memory” • “max memory” es un parámetro de configuración que especifica el tamaño máximo de memoria en páginas de 2K que ASE puede asignar • El valor predeterminado depende de la plataforma • “max memory” es la máxima memoria compartida que puede ser usada por ASE • El parámetro es dinámico • Entre más memoria disponible, mejor será el desempeño de ASE • No hay penalidad por configurar ASE para que use la cantidad máxima de memoria disponible en el sistema • Estimativo inicial: 70%~80% de la memoria física NobleProg® Limited 2017 All Rights Reserved NobleProg
47. Memoria de ASE no Usada para Cachés • Ejecutables de ASE • No configurable • Estructuras de Kernel • Usada por el servidor en ejecución para guardar información interna • Estructuras de Servidor • Usada para almacenar información sobre conexiones de usuario, bases de datos en uso, candados disponibles, etc. NobleProg® Limited 2017 All Rights Reserved NobleProg
48. Data Cache (Caché de datos) • El caché de datos es una porción de la memoria de ASE en donde se almacenan páginas de datos, índices y log, actualmente en uso por el servidor • Cuando las páginas no están en uso, sólo se almacenan en disco NobleProg® Limited 2017 All Rights Reserved NobleProg
49. Procedure Cache (Caché de procedimientos) • SAP ASE usa la caché de procedimientos mientras ejecuta procedimientos almacenados • SAP ASE también usa espacio en la caché de procedimientos para compilar consultas mientras crea procedimientos almacenados NobleProg® Limited 2017 All Rights Reserved NobleProg
50. Statement cache (Caché de sentencias) Se utiliza para guardar sentencias SQL en caché. SAP ASE compara las sentencias SQL entrantes con sus sentencias SQL almacenadas en caché y, si son iguales, ejecuta el plan de las sentencias SQL ya guardadas. Esto permite que la aplicación minimice el costo de compilar la misma sentencia muchas veces. NobleProg® Limited 2017 All Rights Reserved NobleProg
51. Asignación de Memoria en el Arranque Durante el arranque, ASE lleva a cabo lo siguiente: 1.Verifica que haya memoria disponible para soportar la configuración actual • Si no hay suficiente memoria, el servidor no puede arrancar 2.Asigna memoria para el ejecutable del servidor 3.Asigna memoria para las estructuras de kernel 4.Asigna memoria para las estructuras de servidor especificadas en el archivo de configuración 5.Asigna memoria para cachés de datos y procedimientos NobleProg® Limited 2017 All Rights Reserved NobleProg
52. Crecimiento de la Memoria • El parámetro “allocate max shared memory” indica si la memoria asignada se basa en el valor configurado en el parámetro “max memory” o en los requerimientos de la configuración actual. El valor predeterminado es 0 (apagado); la asignación se hace según la configuración actual El parámetro es dinámico • “dynamic allocation on demand” se usa al modificar un parámetro de configuración, para indicar si se asigna memoria en un 100% para soportar el cambio, o si se asigna a medida que se requiere El valor predeterminado es 1 (prendido); la asignación se hace por demanda El parámetro es dinámico NobleProg® Limited 2017 All Rights Reserved NobleProg
53. Principales Usos de la Memoria de ASE • Los aspectos que típicamente usan más memoria en ASE son: • El código del ejecutable de ASE • El Administrador del Sistema no tiene control sobre ésto • • • • • Conexiones de usuario Bases de datos abiertas, índices y objetos en uso Número de candados Número de dispositivos de base de datos Cachés de datos y procedimientos NobleProg® Limited 2017 All Rights Reserved NobleProg
54. Parámetro “user connections” • Cada conexión de usuario requiere memoria • La memoria pro conexión varia de aceuerdo al S.O • Para sistemas de 64 bits, cada usuario requiere aprox. 160 KB • El parámetro “number of user connections” permite especificar el número máximo de conexiones de usuario • El predeterminado es 25 • El parámetro es dinámico NobleProg® Limited 2017 All Rights Reserved NobleProg
55. Bases de Datos, Índices y Objetos en Uso • Cuando el servidor abre una base datos o usa un índice u objeto, requiere información de las tablas del sistema apropiadas • Esta información se lee en cachés de “meta-datos” • Los cachés de meta-datos residen en la porción de memoria de estructuras de kernel y servidor • Tener información en el caché de meta-datos evita operaciones costosas de disco y mejora el rendimiento • El tamaño de los cachés de meta-datos se configura a través de éstos parámetros: • • • • “number “number “number “number of of of of open open open open databases” (predeterminado: 12, dinámico) indexes” (predeterminado: 500, dinámico) objects” (predeterminado: 500, dinámico) partitions” (predeterminado: 500, dinámico) NobleProg® Limited 2017 All Rights Reserved NobleProg
56. Número de Candados • Todos proceso en ASE comparte un “pool” único de estructuras de bloqueo (candados) • “number of locks” es un parámetro de configuración que especifica el número de candados disponibles en el “pool” • El valor predeterminado es 10000 • El parámetro es dinámico • Para estimar el numero de candados se sugiere: • Configurar un valor inicial alto, como 100.000 e ir midiendo su uso. • Cada candado usa aproximadamente 260 bytes NobleProg® Limited 2017 All Rights Reserved NobleProg
57. Dispositivos de Base de Datos El parámetro “number of devices” especifica el número de dispositivos disponibles • El valor predeterminado es 10 • El parámetro es dinámico NobleProg® Limited 2017 All Rights Reserved NobleProg
58. Otros Parámetros que Usan Memoria • Parámetros que usan una cantidad moderada de memoria o pocas veces usan memoria incluyen: • Procesamiento paralelo • El procesamiento paralelo requiere más memoria que el serial • Servidores remotos • La comunicación con otros servidores Sybase, como el Backup Server o XP Server, requiere memoria • Integridad referencial • Si las tablas de una base de datos usan un gran número de reglas de integridad referencial, es posible que ASE requiera memoria adicional para completar las lecturas asociadas al aseguramiento de éstas reglas NobleProg® Limited 2017 All Rights Reserved NobleProg
59. Estimativo del Tamaño de los Parámetros de Configuración • Sintaxis: sp_helpconfig "parameter_name" , "size" • Ejemplos: NobleProg® Limited 2017 All Rights Reserved NobleProg
60. Asignación de la Memoria Data Cache • El cache de datos consiste en múltiples estructuras llamadas caches con nombre. • Por defecto, existe un unico cache con nombre llamado deafult data cache • El default data cache puede ser modificado, o crear caches adicionales usando sp_cacheconfig NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
61. Asignación de la Memoria Data Cache NobleProg® Limited 2017 All Rights Reserved NobleProg
62. Cambiando la Configuración del Data Cache • Para mostrar la memoria usada por el caceh de datos, use sp_cacheconfig o sp_configure • Para modificar el tamaño del cache de datos, incremente el tamaño del default data cache NobleProg® Limited 2017 All Rights Reserved NobleProg
63. Asignación del Cache de Procedimientos • La memoria es asignada al cache de procedimientos usando sp_configure NobleProg® Limited 2017 All Rights Reserved NobleProg
64. Planeación de la Configuración de Memoria Al planear la configuración de memoria, hágalo en éste orden: 1.Memoria máxima • Determine la memoria total disponible para ASE* • Configure “max memory” con ese valor 2.Estructuras de servidor • Determine cómo definirá los parámetros de configuración que usan mayor cantidad de memoria • Configure dichos parámetros según sea apropiado 3.Cachés de procedimientos y de datos • Determine el tamaño apropiado para cada caché • Configure “procedure cache size” • Configure el caché de datos usando sp_cacheconfig NobleProg® Limited 2017 All Rights Reserved NobleProg
65. Paso 1: Configuración de la max memory • “max memory” es el parámetro que determina la cantidad máxima de memoria disponible para ASE • Para determinar el valor de “max memory”: 1. Determine la cantidad total de memoria física de su sistema 2. Reste la memoria requerida para el S.O. 3. Si la máquina no está exclusivamente dedicada a ASE, reste los requerimientos de memoria para otros usos (como aplicaciones cliente) 4. La memoria restante es el máximo de memoria disponible NobleProg® Limited 2017 All Rights Reserved NobleProg
66. Definición de los Parámetros de Memoria • Sintaxis: sp_configure "parameter_name", parameter_value NobleProg® Limited 2017 All Rights Reserved NobleProg
67. Paso 2: Configuración de Estructuras de Servidor • Recordemos los parámetros de configuración que más consumen memoria: • • • • • • number number number number number number of of of of of of user connections open databases open objects open indexes locks devices • Estime valores apropiados para estos parámetros • Defina los parámetros usando sp_configure • Reste la memoria usada por estos parámetros del valor de “max memory” para determinar la memoria restantes para los cachés NobleProg® Limited 2017 All Rights Reserved NobleProg
68. sp_monitorconfig • Muestra estadísticas de uso de algunos parámetrso de configuración Sintaxis: sp_monitorconfig [ ‘config name’ ‘all’ ] [,’table_name’] • ‘all’ muestra la lista de todos los parámetros soportados • Salida (columnas): • • • • • • Name: nombre del parámetro de configuración Num_free: recursos configurados pero no usados Num_active: recursos en uso Pct_act: % de usado vs. recursos configurados Max_Used: máximo de recursos usados Reused: si el recurso a sido reutilizado NobleProg® Limited 2017 All Rights Reserved NobleProg
69. Ejemplo de sp_monitorconfig : NobleProg® Limited 2017 All Rights Reserved NobleProg
70. Paso 3: Configuración de los Cachés de Procedimientos y Datos • Determine el tamaño actual del caché de procedimientos • Estime el espacio requerido para los cachés de procedimientos y datos • Reconfigure los cachés de procedimientos y datos, si es necesario NobleProg® Limited 2017 All Rights Reserved NobleProg
71. Determine el Tamaño Actual y Uso del Caché • Recuerde que hay varias maneras de encontrar esa información • sp_configure "procedure cache size" • sp_monitorconfig "procedure cache size" • Busque en el log de errores información sobre asignación de memoria • Durante el arranque: • En tiempo de ejecución, nuevas asignaciones: (Nota: La salida se abrevió, y se omitieron algunos datos). NobleProg® Limited 2017 All Rights Reserved NobleProg
72. Evaluando el Tamaño del Caché de Procedimientos • Use sp_monitorconfig para evaluar el tamaño actual del caché de procedimientos NobleProg® Limited 2017 All Rights Reserved NobleProg
73. Tamaño Inicial del Caché de Procedimientos • Tamaño predeterminado: • 7000 páginas • Calcular el tamaño del caché de procedimientos requiere monitoreo y algún grado de “prueba y error” • Use sp_monitorconfig para monitorear el ambiente general del caché de procedimientos • Inicialmente el caché de procedimientos debería ser suficiente para guardar los procedimientos más “usados”, que son ejecutados regularmente, y permitir algo de crecimiento para actividad no programada NobleProg® Limited 2017 All Rights Reserved NobleProg
74. Estimando Tamaño Inicial del Caché de Procedimientos • Determine un valor inicial para el caché de procedimientos basándose en: • (# usuarios concurrentes)* promedio tamaño de planes*1.25 • Para calcular el promedio del tamaño de los planes: use database_name go 1> select avg((count(*)/8)+1) "in pages" 2> from sysprocedures 3> group by id 4> go in pages ----------118 • Ejemplo: usando 125 conexiones de usuario: (125)*(118)*1.25 = 18437.5 páginas de 2K sp_configure "procedure cache size", 18438 • Monitoree el tamaño del caché usando sp_monitorconfig NobleProg® Limited 2017 All Rights Reserved NobleProg
75. Asignación Data Cache • El default data cache debera ser tan grande como sea posible, a saber: • • • • El valor de max memory La cantidad de memoria usada por las estructuras de kernel y de servidor El monto de memoria usado por el cache de procedimientos. Una reserva para asignaciones futuras. • Determine el tamaño del cache de datos • Diferencia entre la memoria máxima y la memoria lógica. Ejemplo: max memory – total logical memory = tamaño 1048576 KB – 409600 KB = 638976 KB El data cache podría ser incrementado hasta 600 MB NobleProg® Limited 2017 All Rights Reserved NobleProg
76. Notas Finales sobre Configuración de Memoria • Los estimativos descritos en éste módulo son tan sólo un punto de inicio • Es probable que usted requiera afinar sus estimativos iniciales una vez los implemente en un ambiente productivo, usando sp_monitorconfig y otras herramientas • Es posible que usted descubra que la memoria disponible no sea adecuada para los requerimientos que ha estimado NobleProg® Limited 2017 All Rights Reserved NobleProg
77. Labs Configurando Memoria • Determine la cantidad de memoria asignable para las instancias test_ASE157 y test_ASE16 • Analice el impacto en los cambios de parámetros se configuración. NobleProg® Limited 2017 All Rights Reserved NobleProg
78. Dispositivos • Un dispositivo de base de datos es un recurso físico que almacena objetos que componen una base de datos • El término “dispositivo” no necesariamente se refiere a un dispositivo (disco) físico particular • Puede ser una porción de un disco, tal como una partición • Puede ser un archivo del sistema operativo NobleProg® Limited 2017 All Rights Reserved NobleProg
79. Tipos de Dispositivos • Dispositivos definidos por el Administrador del Sistema • Estos dispositivos almacenan bases de datos de usuario • Estos dispositivos pueden almacenar bases de datos del sistema, excepto master • La base de datos master sólo puede residir en el dispositivo master • Dispositivo de respaldo • Estos dispositivos almacenan copias de respaldo de base de datos y de logs de transacciones NobleProg® Limited 2017 All Rights Reserved NobleProg
80. Tipos de Discos Físicos • Usted puede crear un dispositivo a partir de dos tipos de almacenamiento físico: • Particiones brutas de disco (“Raw Device” o “Raw Partition”) • Archivos del sistema operativo • La elección más apropiada depende de: • La versión de ASE que se esté usando • La plataforma sobre la que se esté ejecutando ASE NobleProg® Limited 2017 All Rights Reserved NobleProg
81. Inicialización de Dispositivos Los dispositivos se inicializan usando el comando disk init • Asocia el disco físico o archivo especificado a un nombre de dispositivo • Agrega el nuevo dispositivo a master..sysdevices • Prepara el dispositivo para almacenamiento • Sólo los Administradores del Sistema pueden ejecutar disk init NobleProg® Limited 2017 All Rights Reserved NobleProg
82. Sintaxis de disk init • Syntax: disk init name = "logical_device_name", physname = "physical_name", [vdevno = virtual_device_number,] size = [ number_of_pages K M G T ] [, vstart = virtual_address , cntrltype = controller_number] [,dsync = { true false }] [,directio = { true false }] [,skip_alloc = { true false }] NobleProg® Limited 2017 All Rights Reserved NobleProg
83. La Opción dsync • La opción dsync determina cómo se llevan a cabo las escrituras a los dispositivos “file system” • Al definirse en TRUE: • Las escrituras pasan por los “buffers” de UNIX y en seguida se llevan a disco • Se garantiza una completa recuperación • Al definirse en FALSE: • Las escrituras se hacen sobre los “buffers” de UNIX • No se garantiza una completa recuperación • Las operaciones de L/E pueden ser más rápidas • Si no se especifica un valor para dsync, el valor predeterminado es TRUE • La opción dsync se ignora al usarla con “Raw Devices” de UNIX o dispositivos en Windows NobleProg® Limited 2017 All Rights Reserved NobleProg
84. La Opción directio (ASE 15.0+) • La opción directio determina cómo se llevan a cabo las escrituras a los dispositivos “file system” • Al definirse en TRUE: • • • • Las escrituras se llevan directamente a disco (no pasan por los “buffers” de UNIX) Se garantiza una completa recuperación El rendimiento es similar al de un “Raw Device” Más rápido que un dispositivo con dsync=true • Al definirse en FALSE: • • • Las escrituras se hacen sobre los “buffers” de UNIX No se garantiza una completa recuperación Las operaciones de L/E pueden ser más rápidas • Si no se especifica un valor para directio, el valor predeterminado es FALSE • La opción directio se ignora al usarla con “Raw Devices” de UNIX • Las opciones directio y dsync son mutuamente exclusivas NobleProg® Limited 2017 All Rights Reserved NobleProg
85. Viendo Informacion del Dispositivo Sintaxis: sp_helpdevice [logical_device_name] • Con el nombre del dispositivo, retorna la informnacion de este dispositivo. • Sin esta, se retorna la información de todos los dispositivos. NobleProg® Limited 2017 All Rights Reserved NobleProg
86. sysdevices • sysdevices es la tabla del sistema que registra cada dispositivo • Sólo existe en la base de datos master • Ejemplo: (ver algunas columnas de la tabla sysdevices) select low, high, status, cntrltype, name, phyname, from sysdevices low high -------- ---------- ----------- 0 0 0 0 0 25599 67583 2559 20000 20000 status 3 16386 16386 16 16 cntrltype name phyname -------------- ------------------- -------------------------------- 0 0 0 2 3 master sysprocsdev systemdbdev tapedump1 tapedump2 /…/master.dat /…/sybprocs.dat /…/sybdb.dat /dev/nst0 /dev/nst1 NobleProg® Limited 2017 All Rights Reserved NobleProg
87. disk resize • Desde ASE 12.5.0.1, el comando disk resize permite aumentar dinámicamente el tamaño de un dispositivo inicializado • No se crean entradas adicionales en sysdevices • Puede ser sobre el dispositivo master • Puede ser usado sobre “raw devices” o archivos en UNIX y Windows • Se requiere rol de Administrador del Sistema para ejecutar el comando NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
88. disk resize • Syntax: disk resize name = <device_name>, size = <additional_size> • El dispositivo permanece en línea y asequible a los usuarios durante la operación • El dispositivo “espejo” (cubierto más adelante) debe ser deshabilitado permanentemente durante la operación • Después de aumentar el tamaño del dispositivo, ejecute alter create database para usar el espacio adicional NobleProg® Limited 2017 All Rights Reserved NobleProg
89. Borrando dispositivos Sintaxis: sp_dropdevice logical_devices_name Ejemplo: sp_dropdevice dev_dat_2 • Borrar dispositivos • Cuando se cambia, repara o agrega hardware. • Para decrementar el tamaño de un dispositivo. • Para hacer esto, borrar y recrear el dispositivo. • Una vez el dispositivo ha sido borrado, su vdevno queda disponible para su uso. • sp_dropdevice no borra el archivo físico del S.O. Este se deberá borrar manualmente. NobleProg® Limited 2017 All Rights Reserved NobleProg
90. Discos Espejo • Los discos espejo brindan funcionamiento continuo en el evento de fallas en los medios • El dispositivo espejo es “duplicado” • Todas las escrituras al dispositivo se copian a un dispositivo separado • Si un disco falla, el servidor evidencia esto en el log de errores y continúa con el otro NobleProg® Limited 2017 All Rights Reserved NobleProg
91. Creando el Dispositivo Espejo • Sintaxis: disk mirror name = "logical_device_name", mirror = "physical_device_name" [, writes = {serial noserial}] • Ejemplo en UNIX: disk mirror name = "dev_dat_2", mirror = "/dev/rxyld_mrr" NobleProg® Limited 2017 All Rights Reserved NobleProg
92. Desactivación del Disco Espejo Iniciada por el Usuario • Sintaxis: disk unmirror name = "logical_device_name" [, side = {"primary” secondary}] [, mode = {retain remove}] • Ejemplo: disk unmirror name = "dev_dat_2", mode = remove NobleProg® Limited 2017 All Rights Reserved NobleProg
93. Reglas para Espejos • Un dispositivo y su espejo solo aplica a un dispositivo no a dos. • El segundo dispositivo físico debe al menos ser tan grande como el dispositivo primario y debiera estar en un disco físico separado • Para poner en espejo una base de datos completa ponga en espejo todos los dispositivos de esta. • El uso de discos espejo no elimina la necesidad de Backup de base de datos. NobleProg® Limited 2017 All Rights Reserved NobleProg
94. Labs • Lab: • Cree un dispositivo llamado prueba_dat • Cree un espejo a ese dispositivo • Detenga el dispositivo primario y remueva el dispositivo NobleProg® Limited 2017 All Rights Reserved NobleProg
95. Resumen del Módulo • Después de que el Administrador ha inicializado los dispositivos requeridos, él puede crear bases de datos. Este módulo discute cómo dar tamaño, crear y ampliar bases de datos. • Al finalizar el módulo, el estudiante deberá ser capaz de: • Dar tamaño y crear bases de datos • Definir la propiedad y las opciones de la base de datos • Ampliar las bases de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
96. ¿Qué Pasa al Crear una Base de Datos? Al crear una base de datos: 1. El servidor reserva espacio en el(los) dipositivo(s) para los datos y log de transacciones • Si no se especifica dispositivo, se usa espacio del “pool” de dispositivos 3 predeterminados 2 4 2. El servidor copia todos los objetos de la base de datos model a la nueva base de datos 3. Las opciones de base de datos asociadas con model se aplican a la nueva base de datos 4. Se insertan entradas para la nueva base de datos en1 las siguientes tablas de master: • sysdatabases • sysusages NobleProg® Limited 2017 All Rights Reserved NobleProg
97. Prerrequisitos para la Creación de Bases de Datos • Antes de crear la base de datos, decida: • • • • El tamaño de la base de datos La ubicación y espacio requerido Si requiere un dispositivo separado para log y su tamaño Si la base de datos requiere tolerancia a fallas • Al planear el tamaño, considere principalmente tablas, índices y log de transacciones • Deje algo de especio para actividad no anticipada NobleProg® Limited 2017 All Rights Reserved NobleProg
98. Ejemplo de sp_estspace - 2K • Servidor de 2K: sp_estspace titles, 10000 name type idx_level ------- --------titles data 0 987 titleidind clustered titleidind clustered titleind nonclustered titleind nonclustered titleind nonclustered Pages Kbytes ----- -----1974 0 7 12 1 1 2 0 280 558 1 9 18 2 1 2 Total_Mbytes: 2.51 (followed by summary data for titleidind, titleind) NobleProg® Limited 2017 All Rights Reserved NobleProg
99. Tamaño para el Log • El tamaño del log depende de: • El tipo y cantidad de las transacciones • La frecuencia de los backups transaccionales • Un valor inicial adecuado es 10 a 20% del tamaño total de la base de datos • Toda operación de insert, delete y update queda en el log NobleProg® Limited 2017 All Rights Reserved NobleProg
100. Datos y Log en Dispositivos Físicos Separados • Para cada base de datos, Ud debe ubicar datos y log en dispositivos separados • Permite que se ejecuten respaldos de los logs • Permite establecer un tamaño máximo de log que no compite por espacio con otra actividad de la base de datos • Mejora el rendimiento • Disminuye la posibilidad de que tanto la base de datos como el log se dañen al mismo tiempo NobleProg® Limited 2017 All Rights Reserved NobleProg
101. Creación de Bases de Datos: Primera Aproximación • Este es el comando simplificado que será usado a traves de este curso. Sintaxis: create database database_name [ on { default database_device } [ = size [K M G T] ] [, database_device [ = size [K M G T] ] ] ...] [ log on database_device [ = size [K M G T] , ... ] [, database_device [ = size [K M G T] ] ]... ] [ with override ] [ for load ] NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
102. Creación de Bases de Datos • Ejemplos: 1.create database pubs2 on default = 400 2.create database salesdb on default = ’307200K’, dev_dat_1 = ’204800K’ 3.create database vendordb on dev_dat_1 = ’200M’ log on dev_log_2 = ’20M’ NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
103. Create Database : Avanzado • Comandos para usar las mejoras en ASE 15.7+ como bases de datos en Memoria y compresión de bases datos serán utilizados. NobleProg® Limited 2017 All Rights Reserved NobleProg Continúa …
104. Visualizando Información de Bases de Datos • Sintaxis: sp_helpdb [db_name] • Ejemplo: sp_helpdb salesdb name db_size owner dbid... ----------- ----- -----... salesdb 700.0 MB sa 6... device_fragments size usage... ---------------- ---- -----... dev_dat_1 500.0 MB data only dev_log_1 200.0 MB log only NobleProg® Limited 2017 All Rights Reserved NobleProg
105. Funciones de Identificación de Base de Datos • db_name, dado el dbid, arroja el nombres • Sintaxis: db_name([database_id]) • Ejemplo: select db_name(6) salesdb • db_id, dado el nombre de una base de datos, arroja el dbid • Sintaxis: db_id("database_name") • Ejemplo: select db_id("salesdb") 6 NobleProg® Limited 2017 All Rights Reserved NobleProg
106. Borrando Bases de Datos • Sintaxis: drop database database_name • Ejemplo: drop database pubs2 • Puede ser ejecutado por: • Dueño de la base de datos • Administrador del Sistema • La base de datos no puede estar en uso • Usted debe borrar una base de datos: • Para remover bases de datos antiguas o experimentales, recuperando así espacio • Antes de recuperar una base de datos dañada NobleProg® Limited 2017 All Rights Reserved NobleProg
107. Propiedad de la Base de Datos • El login que crea una base de datos es su dueño inicial • Los dueños de base de datos (DBO’s) pueden transferir la propiedad a otros usuarios • Sintaxis para transferir la propiedad de una base de datos: sp_changedbowner login_name • Ejemplo: use enterprise_db go sp_changedbowner Grace go NobleProg® Limited 2017 All Rights Reserved NobleProg
108. Opciones de Base de Datos • Las opciones de base de datos controlan varios aspectos del comportamiento a nivel de la base de datos • Ejemplos: • • • • • Comportamiento transaccional Valores predeterminados para columnas de tablas Restricciones al acceso de usuarios Rendimiento de la recuperación y de operaciones bcp Comportamiento del log • Las opciones de base de datos son similares a los parámetros de configuración, pero difieren en su alcance • Los parámetros de configuración afectan el comportamiento a nivel de servidor • Las opciones de base de datos afectan el comportamiento a nivel de base de datos • Las opciones set afectan la sesión o procedimiento en ejecución NobleProg® Limited 2017 All Rights Reserved NobleProg
109. “dbo use only” vs. “single user” • dbo use only • Todos los logins con rol SA, son DBO’s • Pueden tener acceso a la base de datos junto con el DBO • single user • El primer login, sin importar propiedad ni roles del sistema, en “usar” la base de datos, tiene acceso • Algunos comandos, como dbcc, requieren que la base de datos esté en modo “single user” NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
110. Visualización de las Opciones de Base de Datos • Sintaxis: sp_helpdb [db_name] • Ejemplo: sp_helpdb pubs2 name... status -------pubs2... select into/bulkcopy/pllsort, trunc log on chkpt (Nota: algunas columnas se omitieron) • Cualquier usuario puede ver las opciones de base de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
111. alter database • Sintaxis: alter database database_name [ on { default database_device } [ = size ] [, database_device [ = size ] ] ... ] [ log on { default database_device } [ = size ] [, database_device [ = size] ]...] [ with override ] [ for load ] • Ejemplos: alter database pubs2 alter database vendordb on dev_dat_1 = "300M" alter database employeedb on default = "20480K" • Ejemplo de una misma base de datos creada y ampliada: create database salesdb on dev_dat_1 = 500 alter database salesdb on dev_dat_1 = 200 alter database salesdb on dev_dat_1 = 100 NobleProg® Limited 2017 All Rights Reserved NobleProg
112. Labs • Crear dos dispositivos, uno de data y uno de log • Crea una base de datos usando los dispositivos creados • Asignar opción trunc log on chkpt NobleProg® Limited 2017 All Rights Reserved NobleProg
113. tempdb • La base de datos tempdb es un área temporal de trabajo disponible para el servidor y sus usuarios • Cualquier usuario puede crear objetos en tempdb • Muchos procesos del servidor usan tempdb para actividades como: • Almacenamiento de resultados intermedios, resultantes de sentencias de join • Ordenamiento de datos • Cálculo de funciones agregadas • El tamaño y ubicación de tempdb es critico para el buebn desempeño del servidor. • El servidor puede hacer bastante I/O relacionado con tempdb • tempdb puede llenarse rápidamente. NobleProg® Limited 2017 All Rights Reserved NobleProg
114. Rendimiento en tempdb • Problemas frecuentes: • Contención sobre tablas del sistema en tempdb • Los usuario y el servidor compiten por recursos de memoria y disco • Un proceso no controlado podría llenar tempdb, afectando a los demás usuarios de ASE • Solución • Múltiples bases de datos tempdb • Se distribuye la carga sobre múltiples tempdb • • • • Reduce la contención sobre tablas del sistema Reduce la contención sobre los recursos La distribución de cargas se hace automáticamente Usuarios o aplicaciones exigentes se pueden asociar a su propia base de datos tempdb NobleProg® Limited 2017 All Rights Reserved NobleProg
115. Bases de Datos Temporales Creados por Usuario • Todos los objetos en una base de datos temporal se pierden en el evento de un reinicio del sistema. • Las bases de datos temporales se sobrescriben con la base de datos model • Al contrario de la tempdb del sistema, una base de datos temporal de usuario se puede borrar y volver a crear • Usted puede crear una base de datos temporal ejecutando el siguiente comando create temporary database: create temporary database database_name [on {default database_device}[=size] [, database_device [=size]….] Ejemplo: create temporary database tempdb2 on device1 = 300 NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
116. Borrando una tempdb • Use el comando drop database de manera normal • Si existen asociaciones no se puede borrar • Elimine primero las asociaciones • No se puede borrar si hay sesiones activas asignadas a la base de datos tempdb que está siendo borrada • Espera a que las sesiones finalicen NobleProg® Limited 2017 All Rights Reserved NobleProg
117. Creando un grupo tempdb • Un grupo es un conjunto de zero o mas bases de datos temporales. • Se usa la política Round Robin para escoger la tempdb dentro del grupo. • Otras bases de datos pueden ser agregadas a este grupo. • El administrador de base de datos puede crear grupos de bases de datos temporales de usuario. NobleProg® Limited 2017 All Rights Reserved NobleProg
118. Usando sp_tempdb • sp_tempdb permite a los usuarios: • Crear y administrar el grupo default de bases de datos temporales • Asociar logins o aplicaciones al grupo default o a otro grupo de bases de datos temporales o a una base de datos temporal en particular. • Administrar los vínculos para bases de datos temporales y grupos de bases de datos temporales. NobleProg® Limited 2017 All Rights Reserved NobleProg
119. Sintaxis de sp_tempdb NobleProg® Limited 2017 All Rights Reserved NobleProg
120. Ejemplos de sp_tempdb • Agregar una tempdb al grupo default • sp_tempdb 'add', tempdb2, 'default' • Remover una tempdb del grupo default • sp_tempdb 'remove','tempdb2','default' • Mostrar todas las tempdbs • sp_tempdb show NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
121. Ejemplos de sp_tempdb • Muestre todos los miembros de un grupo • sp_tempdb show, gr, 'default' NobleProg® Limited 2017 All Rights Reserved NobleProg
122. Asociación de Logins: Ejemplo • Asocia al login sales_user1 al grupo default • sp_tempdb “bind”, “LG”, “sales_user1”,”DB”, “sales_tempdb” • Asocia el login sa al grupo rpt_tempdb_grp • sp_tempdb “bind”, “lg”, “sa”, “gr”, ‘rpt_tempdb_grp’ • Regresa sa al grupo default • sp_tempdb “unbind”, “lg”, “sa” NobleProg® Limited 2017 All Rights Reserved NobleProg
123. Visualización de Asociaciones • Sintaxis: sp_tempdb "show" [,"all" "gr" "db" "login" "app"] [,name] sp_tempdb “who”, tempdb_name • “show” muestra los grupos y la información de asociación • “all” muestra todo. Información específica puede ser visualizada con otras opciones • “who” se usa para ver las sesiones activas asignadas a una base de datos temporal NobleProg® Limited 2017 All Rights Reserved NobleProg
124. Ejemplos de ‘show’ • Muestre todas las tempdbs • sp_tempdb show • Muestre todos los miembros de un grupo • sp_tempdb show, gr, 'default‘ • Muestre todas las sesiones activas de una base de datos • sp_tempdb who, tempdb3 • Muestre todos los miembros y tempdbs de un grupo • sp_tempdb show,'all','default' NobleProg® Limited 2017 All Rights Reserved NobleProg
125. Lab • Crear una BD tempdb de usuario. • Asocia un login a la nueva base de datos tempdb NobleProg® Limited 2017 All Rights Reserved NobleProg
126. Acceso a los Datos de ASE • ASE tiene un enfoque de multiples capas para permitir que un usuario final tenga acceso a los datos almacenados en el servidor • El usuario final debe tener permiso de conectarse al servidor • Luego, el usuario debe tener permiso para llegar a una base de datos dada • Finalmente, el usuario debe tener permiso para usar un objeto dado NobleProg® Limited 2017 All Rights Reserved NobleProg
127. Asegurando el Acceso a ASE • Para asegurar esto, el sistema verifica que el usuario tenga acceso válido en cada capa • El usuario final debe tener un “login” válido en el servido • El usuario debe ser un “usuario” válido en la base de datos • El usuario debe tener “permisos” para usar el objeto • El acceso puede ser permitido o denegado en cada nivel NobleProg® Limited 2017 All Rights Reserved NobleProg
128. Roles del Sistema • Un rol del sistema es un conjunto de privilegios asignados a un login dado • Permiten que el usuario final de dicho login lleve a cabo tareas administrativas y de seguridad • Los roles del sistema de ASE incluyen: • Administrador del Sistema (SA) – sa_role • Oficial de Seguridad del Sistema (SSO) – sso_role • Operador (OPER) – oper_role • Un login dado puede tener ninguno, uno o varios roles • Entre más roles tenga, más autoridad tiene el login NobleProg® Limited 2017 All Rights Reserved NobleProg
129. Privilegios del Administrador del Sistema (SA) • Privilegios a nivel de servidor • Modificar parámetros de configuración no relacionados a la seguridad • Privilegios a nivel de recursos de disco • Administrar el almacenamiento en disco • Crear bases de datos de usuario y transferir su propiedad • Privilegios de acceso • Otorgar y revocar el rol SA a otros logins • Otorgar permisos a otros usuarios del servidor NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
130. Privilegios del Administrador del Sistema (SA) • Copias de respaldo y restauración • Copias de respaldo y restauración de cualquier base de datos • Copias de respaldo y restauración de cualquier log de transacciones • Privilegios de administración del sistema • “Bajar” el servidor o una de sus sesiones (kill) • Usar herramientas para diagnosticar problemas del sistema (dbcc) • Un login con sa_role se comporta como dbo (dueño) de todas las bases de datos, ignorando cualquier permiso otorgado o revocado. El sa_role supera restricciones de seguridad. NobleProg® Limited 2017 All Rights Reserved NobleProg
131. Privilegios del Oficial de Seguridad (SSO) • Privilegios de acceso • • • • • • • • • • Crear logins del servidor y asignar contraseñas iniciales Modificar logins Cambiar contraseñas Definir el intervalo de expiración de las contraseñas Crear y administrar roles de usuario Otorgar el uso de autorización proxy Otorgar/Revocar roles SSO y OPER a otros logins Administrar el sistema de auditoria Bloquear/desbloquear logins Borrar logins NobleProg® Limited 2017 All Rights Reserved NobleProg
132. Privilegios del Operador (OPER) • Privilegios de copia de respaldo/restauración • De todas las bases de datos • De todos los logs de transacciones • Los dueños de las bases de datos pueden crear copias de respaldo y restaurar bases de datos y logs de transacciones que les pertenezcan NobleProg® Limited 2017 All Rights Reserved NobleProg
133. Otorgando/Revocando Roles del Sistema • Sintaxis: grant role role_granted [,role_granted...] to {PUBLIC name_list role_name } revoke role role_granted [,role_granted...] from {PUBLIC name_list role_name } • Ejemplos: grant role sso_role to nyar revoke role sa_role from nyar • El parámetro role_granted puede ser: • sa_role • sso_role • oper_role • Recuerde que otorgar/revocar roles es un privilegio basado en roles • Sólo un SA puede otorgar/revocar el role SA • Sólo un SSO puede otorgar/revocar los roles SSO y OPER NobleProg® Limited 2017 All Rights Reserved NobleProg
134. Habilitando/Deshabilitando Roles del Sistema • Sintaxis: set role role_name {on off} • Ejemplo: set role sa_role off • Este comando es útil cuando se está probando la seguridad del sistema • Le permite asumir un nivel de acceso de un usuario típico sin tener que iniciar sesión como ese usuario • Los roles del sistema deshabilitados se reactivan cuando: • Se ejecuta set role … on, o • Se desconecta y se inicia una nueva sesión NobleProg® Limited 2017 All Rights Reserved NobleProg
135. Visualizando Roles para un Login Dado • Sintaxis: sp_displaylogin login_name • Ejemplo: sp_displaylogin nyar - Suid: 4 Loginame: nyar Fullname: Natasha Yar Default Database: sybsecurity Default Language: Auto Login Script: Configured Authorization: sso_role (default on) Locked: NO Date of Last Password Change: Oct 10 1999 8:44PM Password expiration interval: Password expired: NO ... NobleProg® Limited 2017 All Rights Reserved NobleProg
136. El Login sa • El login sa es un login especial creado cuando se instala ASE • Por defecto, el login sa: • Tiene los roles SA, SSO, y OPER roles • Tiene los roles sybase_ts_role • Es el dueño de la base de datos master • Tiene acceso a todas las bases de datos y sus objetos • El login sa no puede ser borrado • Pero, puede ser bloqueado NobleProg® Limited 2017 All Rights Reserved NobleProg
137. Generación de Contraseñas para Logins SSO • Es posible encontrar dificultades si todos los usuarios con rol SSO no están disponibles, o olvidan sus contraseñas • El único rol autorizado a cambiar contraseñas para otros usuarios es el rol SSO • Si esto ocurre: • Baje ASE (si es posible con shutdown) • Agregue la opción -p al comando dataserver del archivo RUNSERVER • Reinicie el servidor • La opción -p hace que el servidor genere una nueva contraseña para un login con rol SSO y muestra la contraseña en la consola • Conéctese usando el login con rol SSO (y la nueva contraseña) • Reasignes contraseñas y/o roles, según sea necesario NobleProg® Limited 2017 All Rights Reserved NobleProg
138. Tablas del Sistema Relacionadas con Roles • La información de roles está almacenada en la tabla sysloginroles • Esta tabla se encuentra sólo en la base de datos master • sysloginroles contiene las asignaciones configuradas de roles • Estas toman efecto en el siguiente inicio de sesión NobleProg® Limited 2017 All Rights Reserved NobleProg
139. Logins de ASE • Un login de ASE es una cuenta que permite a un usuario final conectarse con el servidor • Al crear un login, usted debe especificar los siguientes atributos: • Un nombre • Una contraseña NobleProg® Limited 2017 All Rights Reserved NobleProg
140. Creando Logins • Use el comando create login para agregar un login • Sintaxis: create login login_name with [encrypted] password password [attribute_value_pair_list] • Los parámetros asignados al usuario son asignados a la cuenta durante la creación: • • • • login_name - nombre de la cuenta encrypted – utiliza cifrado fuerte para el password password password_value – password para el nuevo login atribute_value_pair_list – lista de atributos y sus valores NobleProg® Limited 2017 All Rights Reserved NobleProg
141. La Base de Datos Predeterminada • La base de datos predeterminada es la base de datos en la que el usuario queda ubicado al iniciar su sesión • Si no se especifica una base de datos predeterminada, se usa la base de datos master • Si el login no es un usuario válido de su base de datos predeterminada, el login se ubica en master • Para limitar la actividad en la base de datos master: • Siempre especifique una base de datos predeterminada diferente a master • Siempre asegúrese de que cada login es un usuario válido de su base de datos predeterminada NobleProg® Limited 2017 All Rights Reserved NobleProg
142. Idioma Predeterminado • El idioma predeterminado es el idioma asignado a un usuario cuando el usuario inicia su sesión • Si no se especifica un idioma, el servidor usa el predeterminado del servidor • El parámetro de configuración “default language id” especifica el idioma predeterminado del servidor • • • • El valor predeterminado es 0 (us_english) La opción es dinámica (el cambio aplica de inmediato) A cada idioma se le asigna un ID numérico No se puede cambiar éste parámetro a un número de un idioma que no está ya instalado • Esta opción puede ser sólo definida por el Administrador del Sistema NobleProg® Limited 2017 All Rights Reserved NobleProg
143. Expiración de la Contraseña • La expiración de la contraseña se da en días • Para definir la expiración de contraseña para un usuario: • Especifique un valor ejecutando create login o alter login • Para definir la expiración de contraseñas en el sistema, modifique el parámetro de configuración “systemwide password expiration” • Especifica el número de días para los que la contraseña del usuario permanece en efecto antes de que expire • El valor predeterminado es 0 (las contraseñas no expiran) • La opción es dinámica (el cambio aplica de inmediato) • La opción puede ser sólo definida por un SSO • Ejemplo: create login pparker with password ItsA5secret password expiration 30 NobleProg® Limited 2017 All Rights Reserved NobleProg
144. Longitud Mínima de la Contraseña • Para definir una longitud mínima para la contraseña de un usuario: • Especifique un valor ejecutando create login o alter login • Para definir la longitud mínimo de las contraseñas a nivel de servidor, modifique el parámetro de configuración “minimum password length” • • • • Especifica el número mínimo de caracteres para las contraseñas El valor predeterminado es 6 La opción es dinámica (el cambio aplica de inmediato) La opción puede ser sólo definida por un SSO • Ejemplo: create login pparker with password ItsA5secret Min password length 10 NobleProg® Limited 2017 All Rights Reserved NobleProg
145. Exigiendo Dígitos en Contraseñas • “check password for digit” es un parámetro de configuración que especifica si las contraseñas requieren al menos un dígito • • • • El valor predeterminado es 0 (no se requieren dígitos) La opción es dinámica (el cambio aplica de inmediato) La opción puede ser sólo definida por un SSO Si el parámetro se cambia a 1, no afecta las contraseñas previamente definidas • Solo afecta las contraseñas que sean modificadas o creadas después del cambio de configuración NobleProg® Limited 2017 All Rights Reserved NobleProg
146. Número Máximo de Conexiones Fallidas • Número máximo de conexiones fallidas hace referencia al número de veces que un usuario puede intentar conectarse exitosamente antes de que su login sea bloqueado • Para definir el número máximo de conexiones fallidas para un usuario: • Especifique un valor ejecutando cretae login o alter login • Para definir el número máximo de conexiones fallidas a nivel del sistema, modifique el parámetro “maximum failed logins” • El valor predeterminado es 0 (los logins nunca se bloquean) • La opción es dinámica (el cambio aplica de inmediato) • La opción puede ser sólo definida por un SSO • Ejemplo: Alter login pparker modify max failed attemps 3 NobleProg® Limited 2017 All Rights Reserved NobleProg
147. Login Profile • Simplifica la administración de la seguridad permitiendo cambios a lo atributos del login Sintaxis • Contenedor definido con SQL que define características del login y sus valores • login profile – login_profile_name a ser creado • as default – define como predeterminado para todos los logins • with attributes from login_name – atributos tomados de un login especifico NobleProg® Limited 2017 All Rights Reserved NobleProg
148. Ejemplos • Crea un perfil de login para administradores de bases de datos create login profile sa_login_profile with athenticate with ASE • Crea un perfil de login para cuentas de usuario con una base de datos predeterminada y un periodo de inactividad create login profile acct_user_profile with deafult database accounting_db stale period “2D” • Cree un perfil de login basado en los atributos del login pparker y predeterminado para el servidor create login profie acct_user_profile as default with attibutes from pparqker NobleProg® Limited 2017 All Rights Reserved NobleProg
149. Usando Login Profiles • Para crear un nuevo login y utilizar login profile, haga lo siguiente: • • • • Cree un nuevo login (como sso) Cree un login profile (como sso) Asocie el login profile con el login (como sso) Agregue el login a la base de datos como usuario (como sa/dbo) • Conceda roles al login profile (como sso) • Conceda permisos a usuario / grupos / roles NobleProg® Limited 2017 All Rights Reserved NobleProg
150. Modificando Logins • Loguines existentes pueden ser modificados usando el comando alter login. • El procedimiento sp_modifylogin es obsoleto Sintaxis Ejemplo: NobleProg® Limited 2017 All Rights Reserved NobleProg
151. Cambiando una Contraseña • Un usuario puede cambiar su contraseña en cualquier momento Contraseña de quien ejecuta el procedimiento • Sintaxis: alter login login_name wirh password caller_password modify password [inmediately] new_login_password Ejemplo: alter login pparker with password ItsA5ecret modify password ItsAnew5secret NobleProg® Limited 2017 All Rights Reserved NobleProg
152. Bloqueando Logins • Sintaxis: sp_locklogin [login_name, {“lock” “unlock”} ] • Ejemplo: sp_locklogin pparker, "lock" • Al bloquear un login, el usuario no se puede conectar al servidor • Bloquear un login es más seguro que eliminarlo • Al bloquear el login, su “server user ID” (suid) se conserva, evitando que sea reutilizado • Al borrar un login, el valor del suid puede ser reutilizado • Sin parámetros, el comando muestra una lista de logins bloqueados • No se puede bloquear el último login desbloqueado con rol SA, ni el último login desbloqueado con rol SSO NobleProg® Limited 2017 All Rights Reserved NobleProg
153. Visualización de Información de Logins • Sintaxis: sp_displaylogin login_name • Ejemplo: NobleProg® Limited 2017 All Rights Reserved NobleProg
154. Funciones para Identificación de Logins • suser_name, dado el “login ID” (suid), muestra el nombre del login • Sintaxis: suser_name([server_user_id]) • Ejemplo: select suser_name(57) Cameron • suser_id, dado el nombre del login, muestra su “login ID” (suid) • Sintaxis: suser_id(["server_user_name"]) • Ejemplo: select suser_id(“Cameron") 57 NobleProg® Limited 2017 All Rights Reserved NobleProg
155. Borrando Logins • Use el comando drop login para remover logins de un servidor • Sintaxis: drop login login_name [, login_list] [with override] • Ejemplos: drop login pparker • Usted no puede borrar logins que: • • • • Sean usuarios de una base de datos Sean dueños de objetos de una base de datos Sean los últimos que quedan con roles SSO o SA Sea el login sa • Sólo puede ser ejecutado por el SSO NobleProg® Limited 2017 All Rights Reserved NobleProg
156. Borrando un Login Profile • Use el comando drop login profile para remover un login profile o lista de logins profile de un servidor • Use la opción with override para obligar el borrado de u8n login prfoile que esta vinculado a un login. Sintaxis Ejemplo NobleProg® Limited 2017 All Rights Reserved NobleProg
157. Administración de Logins y Roles del Sistema • El SSO se requiere para éstos procedimientos: • sp_addlogin • alter login … modify password • alter login modify para cambiar el intervalo de expiración y longitud mínima de contraseñas, y el número de conexiones fallidas • sp_configure "minimum password length", n • sp_configure "systemwide password expiration" • sp_configure "check password for digit", n • sp_configure "maximum failed logins" • sp_locklogin • drop login NobleProg® Limited 2017 All Rights Reserved NobleProg
158. Labs • • • • Crear nuevos logins y Logins Profiles Administrar los a traves de Roles del Sistema Bloquear logins Conectarse a ASE con diferentes logins. NobleProg® Limited 2017 All Rights Reserved NobleProg
159. Usuarios de Base de Datos • Para tener acceso a una base de datos, un login dado debe estar listado como “usuario” de esa base de datos particular • Los usuarios están listados en la tabla sysusers de cada base de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
160. Agregando usuarios de Base de Datos Sintaxis: sp_adduser login_name [, name_in_database [, group_name ] ] Ejemplos: sp_adduser William, William10 go sp_adduser pparker • Si no se especifica valor para name_in_database, se usa el valor de login_name para name_in_database NobleProg® Limited 2017 All Rights Reserved NobleProg
161. Borrando Usuarios de Base de Datos • Sintaxis: sp_dropuser name_in_database • Ejemplos: sp_dropuser William10 sp_dropuser Cameron • Un usuario no puede ser borrado de una base de datos si es dueño de objetos en la base de datos • A un usuario que es dueño de objetos se le puede negar el acceso bloqueando su login • Si hay un usuario “guest” en la base de datos, el usuario borrado aún podría tener acceso a la base de datos como invitado NobleProg® Limited 2017 All Rights Reserved NobleProg
162. Visualizando Información sobre Usuarios Sintaxis:  sp_helpuser [name_in_db ]  Ejemplos: sp_helpuser Users_name ID_in_db Group_name Login_name ---------- -------- ---------- ---------Sofia 16 public Sofia William10 17 public William Cameron 18 public Cameron  Si usted ejecuta el procedimientito con un parámetro, muestra información sobre el usuario específico NobleProg® Limited 2017 All Rights Reserved NobleProg
163. Alias • Un alias es un identidad asociada a un usuario de una base de datos • Un login que no es usuario de una base de datos puede ser asignado un alias, permitiéndole al login usar la base de datos como si fuera el usuario • Circunstancias en las que los alias son útiles: • Si un DBO quiere dar acceso a otros usuarios a los privilegios del DBO • Si un DBO quiere dar privilgios a un usuario, pero quiere asociar muchos logins a dicho usuario NobleProg® Limited 2017 All Rights Reserved NobleProg
164. Creando / Borrando Alias • Sintaxis para crear: sp_addalias login_name, name_in_database • Ejemplo: sp_addalias William, dbo • Sintaxis para borrar: sp_dropalias login_name • Ejemplo: sp_dropalias William • Al crear un alias, la información del alias se almacena en la tabla sysalternates • Ambos comandos deben ser ejecutados desde la base de datos destino NobleProg® Limited 2017 All Rights Reserved NobleProg
165. Verificaciones de Acceso a la Base de Datos ¿Está el login (suid) en sysusers? Si No ¿Está el login (suid) en sysalternates? Si No ¿Hay una cuenta guest en sysusers? Si No Acceso denegado Acceso concedido NobleProg® Limited 2017 All Rights Reserved NobleProg
166. Funciones de Identificación de Usuarios • user_name, dado un “user ID” (uid), arroja el nombre de usuario • Sintaxis: user_name([user_id]) • Ejemplo: select user_name(17) Sofia • user_id, dado un nombre de usuario, arroja el uid • Sintaxis: user_id(["user_name"]) • Ejemplo: select user_id(“Sofia") 17 NobleProg® Limited 2017 All Rights Reserved NobleProg
167. Resumen de Permisos Controla la creación de bases de datos Controla la creación de objetos Controla el uso de objetos NobleProg® Limited 2017 All Rights Reserved NobleProg
168. Permisos para Crear Objetos • Un DBO puede dar y revocar permiso para la creación de objetos • Un SA también puede dar y revocar estos permisos ya que él actúa como DBO • Los DBOs pueden: • Dar permiso para crear objetos • Revocar permiso para crear objetos • Estos permisos pueden ser otorgados/revocados a usuario, grupos o roles de usuario • Un permiso que tiene el DBO, pero que no puede otorgar es el de crear bases de datos • Éste sólo puede ser otorgado por un SA NobleProg® Limited 2017 All Rights Reserved NobleProg
169. Otorgando Permisos • Sintaxis: grant {all [privileges] command_list } to { public name_list role_name } • Ejemplos: grant create rule, create default to public grant create table, create view to William grant all to Sofia NobleProg® Limited 2017 All Rights Reserved NobleProg
170. Revocando Permisos • Sintaxis: revoke {all [privileges] command_list } from { public name_list role_name } • Ejemplos: revoke create rule, create default from public revoke create table, create view from Cameron revoke all from Sofia NobleProg® Limited 2017 All Rights Reserved NobleProg
171. Visualización de Permisos de Base de Datos • Sintaxis: sp_helprotect [user_name ] • Ejemplo: sp_helprotect Cameron grantor grantee type ------- ------- ---dbo Cameron Grant dbo Cameron Grant dbo public Grant action... -----Create Table... Create View... Select... • sp_helprotect muestra todos los permisos otorgados al usuario tanto explícitamente, como a través de un grupo como public • Si se ejecuta sin un nombre de usuario, sp_helprotect muestra todos los permisos asignados NobleProg® Limited 2017 All Rights Reserved NobleProg
172. Permisos para Usar Objetos • El dueño del objeto puede: • • • • Otorgar permiso para usar objetos Otorgar permiso para otorgar permiso Revocar permiso para usar objetos Revocar permiso para otorgar permiso • Estos permisos pueden ser otorgados o revocados de usuarios, grupos o roles de usuarios NobleProg® Limited 2017 All Rights Reserved NobleProg
173. Sintaxis de grant • Sintaxis: grant {all [privileges] permission_list } on { table_name [(column_list )] view_name [(column_list )] stored_procedure_name } to { public name_list role_name } [with grant option] • Ejemplo: grant all on vw_california_authors to public grant select on authors(au_id, au_lname, au_fname) to engineers NobleProg® Limited 2017 All Rights Reserved NobleProg
174. Otorgando Permisos para Otorgar Permisos • Solo debe ser usado cuando sea estrictamente necesario • Ejemplo: grant select on authors to Grace with grant option • Grace ahora puede consultar authors • Grace también puede dar a otros usuarios el permiso de consultar authors • Por ejemplo, Grace podría ejecutar éste comando: grant select on authors to Theodore • La opción with grant option sólo puede ser otorgada a usuarios • No puede ser dada a grupos ni roles NobleProg® Limited 2017 All Rights Reserved NobleProg
175. Sintaxis de revoke • Sintaxis: revoke [grant option for] {all [privileges] permission_list } on { table_name [(column_list )] view_name [(column_list )] stored_procedure_name } from { public name_list role_name } [cascade] • Ejemplo: revoke all on vw_california_authors from public revoke select on authors(au_id, au_lname, au_fname) from engineers NobleProg® Limited 2017 All Rights Reserved NobleProg
176. Revocando Permisos • Ejemplo: revoke select on authors from Grace • Grace no puede consultar authors • Grace no puede otorgar permiso a otros usuarios para consultar authors • Cualquier usuario que haya recibido de Grace permisos sobre authors, pierde dichos permisos • Esto aplica tanto a permisos de select como a permisos de grant NobleProg® Limited 2017 All Rights Reserved NobleProg
177. Revocando Sólo Permisos de Grant • Ejemplo (el usuario no le ha dado permisos a otros): revoke grant option for select on authors from Grace • Grace aún puede consultar la tabla authors • Grace no puede otorgar permisos a otros para consultar authors • Si el usuario le ha otorgado permisos a otros, se genera un error • Ejemplo (el usuario le ha dado permisos a otros): revoke grant option for select on authors from Grace cascade • Grace aún puede consultar la tabla authors • Grace no puede otorgar permisos a otros para consultar authors • Cualquier usuario que haya recibido de Grace cualquier permiso sobre authors, deja de tener dichos permisos NobleProg® Limited 2017 All Rights Reserved NobleProg
178. Permisos Idénticos de Múltiples Usuarios • Un usuario podría recibir el mismo permiso de varios usuarios • En el ejemplo de arriba, si el DBO le revoca los permisos al usuario user2, user4 aún tendrá permisos vía user3 NobleProg® Limited 2017 All Rights Reserved NobleProg
179. Visualizando Permisos de Objetos • Sintaxis: sp_helprotect [object_name ] • Ejemplo: sp_helprotect titles grantor grantee type action object...grantable ------- ------- ---- ------ ------ --------dbo Grace Grant Delete titles...TRUE dbo Grace Grant Insert titles...TRUE dbo Grace Grant Update titles...TRUE dbo public Grant Select titles...FALSE • La columna grantable indica si se usó with grant option • Si se ejecuta sin nombre de objeto, sp_helprotect lista todos los permisos asignados, incluyendo permisos de creación NobleProg® Limited 2017 All Rights Reserved NobleProg
180. Transfiriendo la Propiedad de un Objeto • En ASE 16, la instrucción alter … modify owner permite que la propiedad de un objeto sea transferida y es útil cuando: • El creador del objeto no sea quien mantiene el objeto • Hay cambios de empleados roles/responsabilidades. Sintaxis NobleProg® Limited 2017 All Rights Reserved NobleProg
181. Objetos Soportados • La propiedad de los siguintes objetos puede ser explicitamente transferida: • • • • • • • • Tables (user & proxy) Views Precedures Functions (definidas por el usuario) Defaults Rules Data Types Encryption key NobleProg® Limited 2017 All Rights Reserved NobleProg
182. Ejemplos • Transfiere la propiedad del la tabla titles de Gwen a Kay alter table gwen.titls modify owner kay • Transfiere la propiedad de la vista vw_titles_business de Rick a Emily sin remover todos los permisos existentes concedidos alter view rick.vw_titles_business modify owner emily preserve permissions • Altera la propiedad de todos los procediemientos almacenados de propiedad Cecile a Ernest alter procedure cecile.* modify owner ernest • Transfiere la propiedad de todos los objetos propiedad de Eric al DBO alter all eric.* modify owner dbo NobleProg® Limited 2017 All Rights Reserved NobleProg
183. Permisos sobre Procedimientos del Sistema • El SA controla el acceso a los procedimientos del sistema y las tablas del sistema en master • Características de un procedimiento del sistema • Residen en sybsystemprocs pero pueden ser ejecutados desde cualquier base de datos • Los permisos son definidos por el SA en sybsystemprocs..sysprotects • El script installmaster otorga permisos al grupo public para ciertos procedimientos del sistema • Los permisos pueden ser revocados por el SA • Para crear nuevos procedimientos del sistema que todos puedan usar: • Créelos en sybsystemprocs • Preceder el nombre del procedimiento con “sp_” • Otorgar los permisos apropiados y sacar copiar de respaldo de la base de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
184. Cadenas de Propiedad • Cuando un objeto hace referencia a otro objeto y un usuario tiene permiso para usar el primer objeto, el servidor verifica el permiso sobre el objeto subyacente sólo cuando los dos objetos tienen diferentes dueños NobleProg® Limited 2017 All Rights Reserved NobleProg
185. Creando y Borrando Grupos • Sintaxis: sp_addgroup group_name • Ejemplo: sp_addgroup engineers • Sintaxis: sp_dropgroup group_name • Ejemplo: sp_dropgroup engineers NobleProg® Limited 2017 All Rights Reserved NobleProg
186. Agregando Usuarios a Grupos • Un usuario puede ser agregado a un grupo cuando ese usuario se agrega a la base de datos • Sintaxis: sp_adduser login_name [, name_in_database [, group_name ] ] • Ejemplos: sp_adduser William, William10, engineers sp_adduser Cameron, Cameron, engineers • Un usuario existente también puede ser agregado a un grupo: • Sintaxis: sp_changegroup group_name, user_name • Ejemplo: sp_changegroup tech_support, Cameron NobleProg® Limited 2017 All Rights Reserved NobleProg
187. Eliminando Usuarios de un Grupo Creado por el DBO • Para eliminar un usuario de un grupo definido por el DBO, use el procedimiento sp_changegroup para asignar el usuario a public • Ya que la palabra “public” es reservada, úsela entre comillas al referirse al grupo public • Ejemplos: sp_adduser pparker, pparker, engineers go -- pparker pertenece a engineers y public sp_changegroup "public", pparker go -- pparker se elimina de engineers, -- y ahora sólo pertenece a public • Los usuarios no pueden ser eliminados del grupo public NobleProg® Limited 2017 All Rights Reserved NobleProg
188. Visualización de Información de Grupos • Sintaxis: sp_helpgroup ["group_name" ] • Ejemplo: sp_helpgroup "engineers" Group_name Group_id Users_in_group Userid ---------- -------- -------------- -----engineers 16390 William10 17 engineers 16390 pparker 9 • Si usted ejecuta el procedimiento sin un parámetro, muestra todos los grupos de la base de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
189. Roles de Usuario • Un rol de usuario es un colección de permisos • Su función es similar a la del grupo, pero no tiene muchas de sus limitantes • Los roles de usuario son globales • Se pueden otorgar múltiples roles de usuario a un usuario • Una vez definidos, los roles pueden ser dinámicamente activados/desactivados, siendo así más flexibles que los grupos • Un rol de usuario también puede incluir otros roles de usuario • Los roles de usuario pueden sacar provecho de crear: • Un acceso jerárquico • Acceso definido para una aplicación NobleProg® Limited 2017 All Rights Reserved NobleProg
190. Usando Roles de Usuario • Para que un rol de usuario tenga efecto, cuatro cosas deben ocurrir: • • • • Se crea el rol Se asignan permisos al rol El rol se asigna a logins Los logins habilitan el rol NobleProg® Limited 2017 All Rights Reserved NobleProg
191. Paso 1: Crear el Rol de Usuario • Sintaxis: create role role_name [with passwd password ] • Ejemplo: create role sales_clerk_role • Los roles pueden ser creado sólo por logins con el rol SSO • Si se especifica una contraseña, el usuario debe incluir esa contraseña al habilitar el rol • Ejemplo: create role regional_mgr_role with passwd bigbossman NobleProg® Limited 2017 All Rights Reserved NobleProg
192. Paso 2: Dar Permisos al Rol de Usuario • Sintaxis: grant permission_list to role_name [ ,role_name ] • Ejemplo: grant select on titles to sales_clerk_role • Los permisos a los roles de usuario pueden ser otorgados/revocados sólo desde la base de datos en donde residen los objetos referidos NobleProg® Limited 2017 All Rights Reserved NobleProg
193. Paso 3: Asignar Roles de Usuario a un Login • Sintaxis: grant role role_name [, role_name ] to login_name [, login_name ] • Ejemplo: grant role sales_clerk_role to Grace, Theodore, Cameron • Los roles pueden ser asignados sólo por logins con rol SSO • Los roles deben ser asignados desde la base de datos master NobleProg® Limited 2017 All Rights Reserved NobleProg
194. Paso 4: Habilitar Roles • Sintaxis: set role role_name [with passwd "password" ] {on off} • Example: set role sales_clerk_role on • El usuario debe habilitar el rol de usuario para obtener los privilegios asociados al rol • Por defecto, los roles de usuario están desactivados • El SA puede modificar logins de tal manera que automáticamente quede habilitado al conectarse • Sintaxis: sp_modifylogin login_name, "add default role", role_name • Ejemplo: sp_modifylogin Grace, "add default role", sales_clerk_role NobleProg® Limited 2017 All Rights Reserved NobleProg
195. Creación de Roles dentro de Roles • Sintaxis: grant role inner_role to outer_role • Ejemplo: grant role sales_clerk_role to department_lead_role grant role department_lead_role to store_manager_role NobleProg® Limited 2017 All Rights Reserved NobleProg
196. Roles con Contraseña • Si un rol se crea con contraseña, sólo puede ser habiliatado con la contraseña • Ejemplo: create role store_manager_role with passwd "desdemona" set role store_manager_role with passwd "desdemona" on NobleProg® Limited 2017 All Rights Reserved NobleProg
197. Eliminando y Agregando Contraseñas • Sintaxis: alter role role_name { add passwd password drop passwd } • Ejemplos: alter role store_manager_role drop passwd alter role store_manager_role add passwd elsinore • Los roles sólo pueden ser modificados por el rol SSO • Este comando puede ser usando tanto para roles de usuario como para roles del sistema NobleProg® Limited 2017 All Rights Reserved NobleProg
198. Deshabilitando Roles • Ejemplo: set role sales_clerk_role off • El rol queda deshabilitado hasta que: • Su sesión termine • Lo vuelva a habilitar NobleProg® Limited 2017 All Rights Reserved NobleProg
199. Eliminando Logins de Roles de Usuario • Sintaxis: revoke role role_name [, role_name ] from grantee [, grantee ] • Ejemplo: revoke role sales_clerk_role from Grace, Theodore, Cameron • Los logins sólo pueden ser eliminados por login con rol SSO • Los roles deben ser revocados desde la base de datos master • Un rol de usuario no puede ser revocado de un login si el login nunca tuvo el rol NobleProg® Limited 2017 All Rights Reserved NobleProg
200. Eliminando Roles de Usuario • Sintaxis: drop role role_name [with override] • Ejemplos: drop role department_lead_role drop role sales_clerk_role • Los roles sólo pueden ser eliminados por logins con rol SSO • Si se usa la opción override: • Los permisos otorgados por el rol en toda base de datos se eliminan • Si NO se usa la opción override: • Todos los permisos otorgados por el rol deben ser directamente revocados antes de ejecutar el comando NobleProg® Limited 2017 All Rights Reserved NobleProg
201. Precedencia de los Permisos • Los permisos tienen ésta precedencia: • Permisos del rol • Permisos de usuario y grupo (en orden de ejecución) • Si se da un permiso a un rol y luego se le revoca a un usuario con dicho rol, el usuario conserva el permiso • Los permisos de rol siempre tienen precedencia sobre los permisos del usuario • Si se da permiso a un grupo y luego se le revoca a un usuario del grupo, el usuario no conserva el permiso • Los permisos de grupo y usuario dependen del orden de ejecución NobleProg® Limited 2017 All Rights Reserved NobleProg
202. Reglas para Roles de Usuario • El comportamiento predeterminado para roles de usuario es que están deshabilitados el inicio de la sesión • Los roles del sistema están: • Habilitados al inicio de sesión, si no tienen contraseña • Deshabilitados por defecto si tiene contraseña • Para listar los roles activos use sp_activeroles • Sintaxis: sp_activeroles [expand_down] • Los requerimientos de contraseña (como longitud mínima y número máximo de conexiones fallidas) pueden ser asignados a roles de usuario NobleProg® Limited 2017 All Rights Reserved NobleProg
203. Utilitarios de Extracción de datos • ddlgen es un utilitario de línea de comandos que puede generar scripts DDL para objetos a nivel de base de datos y objetos • bcp es un utilitario de línea de comandos que puede copiar datos desde una archivo del sistema a una tabla y viceversa • bcp tiene dos velocidades: • bcp rápido, que se usa en tabla sin índices ni triggers y tiene mejor rendimiento • bcp lento, que se usa para tablas con índices o trigger y brinda mayor recuperabilidad NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
204. Utilitarios de Extracción de datos • transfer table permite exportar incrementalmente datos en un archivo del sistema operativo y cargarlos en una tabla • La tabla origen deberá ser elegible para transferencia. • Puede limitarse a la exportación de datos de solo aquellos datos que han sido cambiados. NobleProg® Limited 2017 All Rights Reserved NobleProg
205. Comandos DBCC • Las inconsistencias de base de datos ocurren cuando: • Una página es asignada pero no encadenada al objeto, o viceversa • Un página en la cadena del objeto apunta a la página siguiente/previa incorrecta • Los comandos dbcc identifican y corrigen inconsistencias • Las cadenas de páginas pueden ser verificadas con: • • • • dbcc dbcc dbcc dbcc checktable checkindex checkdb checkcatalog NobleProg® Limited 2017 All Rights Reserved Continúa… NobleProg
206. Comandos DBCC • La asignación de páginas puede ser verificada con: • dbcc tablealloc • dbcc indexalloc • dbcc checkalloc • El comando dbcc checkstorage lleva a cabo la mayor parte de verificaciones hechas por otros comandos: • Usa la base de datos espacial dbccdb para almacenar y procesar la información • Trabaja en paralelo • Brinda la verificación más exhaustiva con el menor impacto en el rendimiento NobleProg® Limited 2017 All Rights Reserved NobleProg
207. Resumen de Comandos • dbcc checktable • Verifica la cadena de páginas para un objeto dado • dbcc checkdb • Ejecuta dbcc checktable para todas las tablas en una base de datos • dbcc checkcatalog • Verifica integridad referencial entre tablas del sistema para una base de datos dada • dbcc tablealloc • Verifica la asignación de páginas para una tabla dada • dbcc indexalloc • Verifica la asignación de páginas para un índice dado • dbcc checkalloc • Ejecuta dbcc tablealloc y dbcc indexalloc para todas las tablas de una base de datos NobleProg® Limited 2017 All Rights Reserved Continúa… NobleProg
208. Resumen de Comandos • dbcc dbrepair • Borra una base de datos corrupta que no puede ser eliminada con el comando drop database • dbcc checkstorage • Verifica el encadenamiento y asignación de páginas para todas las tablas de una base de datos usando los recursos de la base de datos dbccdb • dbcc checkverify • Verifica las fallas registradas por la operación checkstorage más reciente sobre una base de datos dada NobleProg® Limited 2017 All Rights Reserved NobleProg
209. Velocidad vs. Exactitud Velocidad Exactitud checktable/checkdb Lenta Alta checktable/checkdb (usando skip_ncindex) Hasta 40% más rápido sin Alta skip_ncindex checkcatalog Moderada Media tablealloc/indexalloc (full) Lenta Alta tablealloc/indexalloc (optimized) Moderada Media tablealloc/indexalloc (fast) Rápida Lenta NobleProg® Limited 2017 All Rights Reserved NobleProg
210. Cuando Ejecutar Comandos dbcc • La consistencia de la base de datos se debería verificar: • Antes de una copia de respaldo, para verificar su consistencia • Si un error en el log de errores indica corrupción de una tabla • Si las consultas no se están comportando según lo esperado • Como parte de la labor continua de monitoreo NobleProg® Limited 2017 All Rights Reserved NobleProg
211. ¿Quién Puede Ejecutar Comandos dbcc? • Cualquier usuario con sa_role puede otorgar/revocar permiso para ejecutar algunos comandos dbcc • Principales comandos dbcc que se pueden otorgar: • • • • • • • • checkcatalog checktable checkdb checkalloc tablealloc indexalloc checkstorage checkverify NobleProg® Limited 2017 All Rights Reserved NobleProg
212. grant dbcc y revoke dbcc • Sintaxis: grant dbcc { dbcc_command [ on {all database_name} ] { , dbcc_command [ on {all database_name} ], ...] } to { user_list role_list } revoke dbcc { dbcc_command [ on {all database_name} ] { , dbcc_command [ on {all database_name} ], ...] } from { user_list role_list } • Ejemplo: grant dbcc checkalloc on test to bleu NobleProg® Limited 2017 All Rights Reserved Continúa… NobleProg
213. Sintaxis de dbcc checktable • Sintaxis: dbcc checktable ({table_name table_id } [, skip_ncindex] ) • Ejemplo: dbcc checktable (sales) Checking table sales ... The total number of data pages in partition 'salesind_672002394' (partition ID 672002394) is 1. The total number of data pages in this table is 1. Table has 30 data rows. DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role. NobleProg® Limited 2017 All Rights Reserved NobleProg
214. Sintaxis de dbcc checkdb • Sintaxis: dbcc checkdb [(database_name [, skip_ncindex] )] • Ejemplo: dbcc checkdb (pubs2) Checking ‘sysobjects’ ... The total number of data pages in partition 'sysobjects_1' (partition ID 1) is 4. The total number of data pages in this table is 4. Table has 58 data rows. Checking ‘sysindexes’ ... The total number of data pages in partition 'sysindexes_2' (partition ID 2) is 9. NobleProg® Limited 2017 All Rights Reserved Continúa… NobleProg
215. Opciones de dbcc tablealloc • Opciones de corrección: • fix – Corrige errores de asignación detectados • Este es el valor predeterminado para todas las tablas • nofix – Reporta, pero no corrige, los errores de asignación • Este es el valor predeterminado para tablas del sistema • Sintaxis: dbcc tablealloc ( {table_name table_id } [, {full optimized fast NULL} [ , {fix nofix} ] ] ) • Example: dbcc tablealloc (titles, optimized) NobleProg® Limited 2017 All Rights Reserved Continúa… NobleProg
216. Sintaxis de dbcc indexalloc • Sintaxis: dbcc indexalloc ( {table_name table_id }, index_id [, {full optimized fast NULL} [ , {fix nofix} ] ] ) • Ejemplo: dbcc indexalloc (authors, 1, full) NobleProg® Limited 2017 All Rights Reserved NobleProg
217. Sintaxis de dbcc checkalloc • Sintaxis: dbcc checkalloc [ (database_name [, fix nofix ] ) ] • Ejemplo: dbcc checkalloc (pubs2) NobleProg® Limited 2017 All Rights Reserved NobleProg
218. Prácticas Recomendadas de Producción • Para mejor rendimiento: • Use dbcc checkalloc para ubicar el error (pero no lo corrija) • Luego, use dbcc tablealloc para corregir errores • Mantenga registros de qué tanto le toma al servidor completar los comandos dbcc NobleProg® Limited 2017 All Rights Reserved NobleProg
219. Eliminando una Base de Datos Dañada • Si una base de datos tiene un gran número de inconsistencias, el servidor puede considerarla corrupta y la marca “suspect” • En ésta situación, la base de datos no puede ser borrada con el comando drop database • La base de datos sólo puede ser borrada con dbcc dbrepair • Sintaxis: dbcc dbrepair (database_name, dropdb) • Ejemplo: dbcc dbrepair (pubs2, dropdb) NobleProg® Limited 2017 All Rights Reserved NobleProg
220. dbcc checkstorage • dbcc checkstorage es un comando dbcc especial que combina la funcionalidad de los siguientes comandos: • • • • • dbcc dbcc dbcc dbcc dbcc checktable (cadenas de páginas para tablas, no índices) checkdb (cadenas de páginas para tablas, no índices) checkalloc indexalloc tablealloc • Otras ventajas de dbcc checkstorage: • • • • No bloquea tabla o páginas por largo tiempo Se ejecuta en paralelo usando múltiples “worker processes” Registra los errores en una base de datos; no en la consola A mayores recursos, escala casi linealmente NobleProg® Limited 2017 All Rights Reserved NobleProg
221. Configuración para dbcc checkstorage • Para ejecutar dbcc checkstorage, usted debe configurar ASE para procesamiento paralelo e instalar/configurar la base de datos dbccdb • Hay ocho pasos para configurar el servidor: 1. Planeara recursos para dbccdb 2. Configurar “number of worker processes” y “memory per worker process” en ASE 3. Instalar la base de datos dbccdb 4. Configurar un caché para dbccdb 5. Agregar segmentos de trabajo 6. Crear área de trabajo de dbccdb 7. Especificar los atributos de las bases de datos destino 8. Evaluar la configuración NobleProg® Limited 2017 All Rights Reserved NobleProg
222. Paso 1: Planee Recursos para dbccdb • Los recursos requeridos por dbcc checkstorage depende de: • Tamaño de las bases de datos a verificar • Número de bases de datos a verificar concurrentemente • El tiempo en que las verificaciones se deben completar • Recursos que se necesita configurar: • • • • Dispositivos “Workspaces” Cachés con nombre “Worker processes” • Use sp_plan_dbccdb para determinar exactamente qué tan grande debe ser cada recurso NobleProg® Limited 2017 All Rights Reserved NobleProg
223. sp_plan_dbccdb • Sintaxis: sp_plan_dbccdb [database_name] • Ejemplo: NobleProg® Limited 2017 All Rights Reserved NobleProg
224. Paso 2: Configure ASE • Los siguientes parámetros afectan dbcc checkstorage y se deben configurar a nivel de ASE: • “number of worker processes” • Defínalo por lo menos en 1 para permitir por lo menos un proceso padre y uno obrero • Defínalo suficientemente alto para permitir el máximo de procesos obreros especificado • Un número bajo limita el rendimiento y el consumo de recursos de dbcc checkstorage • Defina estos parámetros con sp_configure • Los cambios entran en efecto inmediatamente NobleProg® Limited 2017 All Rights Reserved NobleProg
225. Paso 3: Instale la Base de Datos dbccdb • Cree una base de datos llamada dbccdb usando el tamaño recomendado de sp_plan_dbccdb • Ejecute el script installdbccdb dentro de la base de datos dbccdb • Este script crea una serie de tablas y procedimientos del sistema especiales para dbccdb • Para mejor rendimiento, dbccdb debe residir en uno o más dispositivos dedicados NobleProg® Limited 2017 All Rights Reserved NobleProg
226. Paso 4A (Opcional): Configure un Caché para dbccdb • Dedique una porción del caché de datos a dbccdb creandole un “caché con nombre” • Asocia la base de datos dbccdb a dicho caché con nombre • Sintaxis: sp_cacheconfig cache_name, “cache_size[P K M G]” sp_bindcache cache_name, database_name • Ejemplo: sp_cacheconfig dbcc_cache, "1152K" go The change is completed. The option is dynamic and ASE need not be rebooted for the change to take effect. (return status = 0) sp_bindcache dbcc_cache, dbccdb go NobleProg® Limited 2017 All Rights Reserved NobleProg
227. Paso 4B (Requerido): Configure un Pool de Buffers de 16K • Configure un pool de buffers grandes de L/E para el caché de dbccdb, así sea un caché con nombre o el “default data cache” • Sintaxis: sp_poolconfig cache_name, “mem_size[P K M G]”, “config_poolK” • Ejemplos (para un servidor de 2K): sp_poolconfig dbcc_cache, "640K", "16K" go ** or ** sp_poolconfig “default data cache”, “640K”, “16K” go NobleProg® Limited 2017 All Rights Reserved NobleProg
228. Paso 5 (Opcional): Agregue Segmentos para los Workspaces • Un “workspace” es un tipo especial de tabla pre-asignada para dbcc checkstorage • La base de datos dbccdb requiere dos workspaces: • Un “scan workspace”, el cual contiene una fila para cada página en la base de datos destino • Un “text workspace” que contiene una fila por cada tabla en la base de datos destino que contenga columnas text o image • Se debe crear un segmento para cada workspace para controlar su ubicación, mejorando así el rendimiento • Ejemplo: sp_addsegment scanseg, dbccdb, dev_dbcc_dat1 go sp_addsegment textseg, dbccdb, dev_dbcc_dat2 go NobleProg® Limited 2017 All Rights Reserved NobleProg
229. Paso 6 (Opcional): Cree los Workspaces de dbccdb • El script de imnstalalcion installdbccdb crea dos workspaces por defecto • def$scan$ws – 256 K • def$text$ws – 128 K • Para usar el workspace predetermniando, el servidor necesita poder automaticamente expandir l workspace cuando sea necesario • El parametro ‘enable automatic workspace expansion’ permite al servidor expandir el workspace • Sintaxis: sp_dbcc_udateconfig database_name, “enable automatic workspace expansion”,”1” • Ejemplo: sp_dbcc_updateconfig pubs2,”enable automatic workspace expansión”,”1” NobleProg® Limited 2017 All Rights Reserved NobleProg Continúa …
230. Paso 6 (Opcional): Cree los Workspaces de dbccdb • Si mas de uno o mas operaciones chekstorage necesitan ser ejecutadas, cada base d e datos requiere su workspace • Para crear workspaces Sintax: Ejemplo: NobleProg® Limited 2017 All Rights Reserved NobleProg
231. Paso 7: Especifique los Atributos de las Bases de Datos Destino • En adición a configurar la base de datos dbccdb, actualice la tabla dbcc_config de dbccdb con la información de configuración de la base de datos destino • Configure esta información permite al dbcc checkstorage ejecutarse con la configuración recomendada. • Si no se definen estos valores, se usarán los predeteriminados • Especifique estos atributos para la base de datos destino: • Número máximo de procesos obreros a usar • El nombre y tamaño del caché con nombre a usar • Los nombres y tamaños de los workspaces a usar • Use sp_dbcc_updateconfig para definir estos atributos NobleProg® Limited 2017 All Rights Reserved NobleProg
232. sp_dbcc_updateconfig • Sintaxis: sp_dbcc_updateconfig database_name, type, "string1” [, “string2”] • Ejemplo: NobleProg® Limited 2017 All Rights Reserved NobleProg
233. Paso 8: Evalúe la Configuración • Es posible que sea necesario re-calcular la información de configuración para la base de datos destino y comparar los datos con la información de configuración actual • Esto se puede hacer después de correr dbcc checkstorage sobre la base de datos destino • Usa contadres guardados para la base de datos destino en la tabla dbcc_counters • Sintaxis sp_dbcc_evaluatedb [dbname] • Si no se especifica dbname, se comparan todas las bases de datos listadas en la tabla dbcc_config NobleProg® Limited 2017 All Rights Reserved NobleProg
234. Ejecutando dbcc checkstorage • Una vez configurada la base de datos dbccdb para cada base de datos destino, se puede ejecutar el comando dbcc checkstorage • Sintaxis: dbcc checkstorage [(database_name)] • Ejemplo: dbcc checkstorage (pubs2) NobleProg® Limited 2017 All Rights Reserved NobleProg
235. Cómo Funciona dbcc checkstorage • Esta es una explicación sencilla de cómo funciona dbcc checkstorage : 1. Inicialización: Verifica la configuración de la base de datos destino y la disponibilidad de los recursos 2. “Scan” de la Base de Datos: Lee la base de datos completa lo más rápido posible, lleva a cabo algunas verificaciones y escribe un resumen de cada página en el workspace en dbccdb 3. Las verificaciones restantes se llevan a cabo en dbccdb 4. Al encontrar una inconsistencia que no pueda ser atribuida a actividad concurrente, se registra en dbccdb NobleProg® Limited 2017 All Rights Reserved Continúa… NobleProg
236. Verificando Fallas con dbcc checkverify • Ejemplo: dbcc checkverify(pubs2) go • Opera sobre los resultados de la última operación completa de checkstorage sólo para la base de datos especificada • La verificación de fallas persistentes puede ubicar un fuente de corrupción antes de encontrar problemas más serios NobleProg® Limited 2017 All Rights Reserved NobleProg
237. Examinando los Resultados de dbccdb • sp_dbcc_summaryreport • Muestra información resumida, tal como número de fallas “hard” y “soft” reportadas • sp_dbcc_faultreport • Muestra información detallada para cada falla reportada • sp_dbcc_fullreport • Muestra información, estadísticas y fallas para una base de datos u objeto dado • sp_dbcc_differentialreport • Muestra resultados comparativos para las operaciones de dbcc checkstorage completadas para una base de datos en fechas específicas NobleProg® Limited 2017 All Rights Reserved NobleProg Continúa …
238. Examinando los Resultados de dbccdb • sp_dbcc_help_fault • Provee una descripcion del tipo de falla y la accion sugerida • sp_dbcc_recommendations • Analiza fallas reportadas por el checkstotrage para una fecha o ID de operación dado, y genera una lista de acciones correctvas recomendadas por objeto en la base de datos. NobleProg® Limited 2017 All Rights Reserved NobleProg
239. Ejemplo: sp_dbcc_faultreport sp_dbcc_faultreport short, pubs2 Database Name: pubs2 Table Inx Type Code Description Page ----- --- --------- ----------- ---titles 0 100002 page free offset err 313 titles 0 100002 page free offset err 313 titles 0 100022 chain start error 313 sales 2 100017 OAM ring error 376 sales 2 100031 page not allocated 376 sales 2 100022 chain start error 377 sales 2 100031 page not allocated 377 NobleProg® Limited 2017 All Rights Reserved NobleProg
240. Operaciones de “Dump” y “Load” • Una copia de respaldo, o “dump”, de una base de datos es una copia física de una base de datos completa • Una copia de respaldo, o “dump”, de un log de transacciones es una copia física del log de transacciones de una base de datos • Una operación de “load” restaura la base de datos y/o log a partir de un dispositivo de respaldo NobleProg® Limited 2017 All Rights Reserved NobleProg
241. ¿Porqué Efectuar Copias de Respaldo? • El proceso de recuperación automática de ASE protege contra fallas de la electricidad y del computador • ¿Qué hay de otras contingencias? • Fallas en los medios • Fallas en la máquina • Cuando la recuperación automática falla debido a una corrupción o inconsistencia interna • Fallas del sitio • Datos Corruptos • Errores de Aplicación • En éstas situaciones, usted debe restaurar sus bases de datos a partir de copias de respaldo • Lleve a cabo copias de respaldo regulares y frecuentes de sys bases de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
242. Métodos Adicionales de Recuperación • Discos “Espejo” o “Mirrorring” • Un método que provee una copia actualizada al minuto de los datos • “Warm Standby” • Un método que resulta en una copia relativamente actualizada De todas maneras, ¡se requieren las copias de respaldo! NobleProg® Limited 2017 All Rights Reserved NobleProg
243. Tipos de Copias de Respaldo • Respaldo de base de datos • Se respaldan tanto la base de datos como su log de transacciones • Respaldo del log de transacciones • Sólo se respalda el log de transacciones NobleProg® Limited 2017 All Rights Reserved NobleProg
244. Medios de Respaldo • Cintas • Crear una librería “fuera de línea” de respaldos de bases de datos y logs • Disco • Generalmente más rápidos • Fallas en el sistema o en el disco pueden evitar la restauración • Tivoli Storage Manager Option • Soporta integración con Backup Server NobleProg® Limited 2017 All Rights Reserved NobleProg
245. Backup Server • Las copias de respaldo de ASE son ejecutadas por el Backup Server • Programa basado en Open Server, que corre en la misma máquina de ASE • Características • • • • • Crea copias de respaldo con los usuarios activos Crea copias de respaldo sobre dispositivos locales o remotos Crea copias de respaldo de muchas bases de datos en un dispositivo Crea copias de respaldo sobre muchos dispositivos (“stripes”) Permite la ejecución automática de respaldos NobleProg® Limited 2017 All Rights Reserved NobleProg
246. Arquitectura Backup Server • La arquitectura de respaldo usa un paradigma cliente/servidor, con ASE actuando como cliente del Backup Server NobleProg® Limited 2017 All Rights Reserved NobleProg
247. Compatibilidad de las Copias de Respaldo • Cuando una instalación de ASE se actualiza a una nueva versión, todas sus bases de datos son automáticamente actualizadas a la nueva versión • Así mismo, una sola base de datos puede ser actualizada usando el componente de compatibilidad de copias de respaldo • Al cargar una copia de respaldo anterior a 12.5 en un servidor 16.0, ésta se actualizar sólo cuando la base de datos es puesta en línea NobleProg® Limited 2017 All Rights Reserved NobleProg
248. Soporte a Páginas Grandes • El servidor origen y el servidor destino, deben tener el mismo tamaño de página lógica NobleProg NobleProg® Limited 2017 All Rights Reserved
249. El Log de Transacciones se Llena • Cada base de datos tiene su propio log de transacciones, la tabla del sistema syslogs • El log de transacciones crece cada vez que la base de datos se modifica • Se puede llenar rápidamente • Si el log se llena, todas las modificaciones se suspenden • Truncar el log previene que el log se llene • Crea espacio para crecimiento futuro NobleProg® Limited 2017 All Rights Reserved NobleProg
250. Entendiendo el Comportamiento del Log • No se puede apagar el log de transacciones. • Por defecto, cuando el log se ha llenado el servidor suspende todas las escrituras en el. • Use la opcion abort tran on log full para cambiar este comportameinto. • Cuando se ajusta, esta opción aborta todas las escrituras de usuario en el log. • Es responsabilidad de los DBA’s ASE prevenir que el log se llene. NobleProg® Limited 2017 All Rights Reserved NobleProg
251. Desarrollando una Estrategia de Respaldo • Para desarrollar una estrategia efectiva de respaldo, un Administrador del Sistema debe responder las siguientes preguntas: • ¿Qué técnicas serán usadas para respaldar las bases de datos? • ¿Qué será respaldado? • ¿Cuándo serán llevados a cabo los respaldos? • ¿Cómo se harán los respaldos? NobleProg® Limited 2017 All Rights Reserved NobleProg
252. ¿Qué Técnicas serán Usadas? • Discos espejo • dump database • dump transaction, manteniendo el log sobre un disco físico separado • Copias de las tablas del sistema • El umbral de última oportunidad y sp_thresholdaction • Copias de respaldo remotas NobleProg® Limited 2017 All Rights Reserved NobleProg
253. ¿Qué Será Respaldado? • La base de datos master • Tablas críticas de la base de datos master • • • • • • sysdatabases sysdevices syslogins sysusages syssrvroles sysloginroles • La base de datos model, si fue modificada con respecto a su estado original • Bases de datos de usuario NobleProg® Limited 2017 All Rights Reserved NobleProg
254. Ejemplo de Programación de Respaldos • Base de datos activa • Base de datos todas las noches • Log de transacciones cada hora • Recuperación “al minuto” después de una crisis • Base de datos no activa • Base de datos siempre que sea posible • Trunque el log de transacciones antes de hacer el respaldo de base de datos • Programe pruebas de recuperación ante desastres una o dos veces por trimestre • Es importante verificar los respaldos antes de un desastre real NobleProg® Limited 2017 All Rights Reserved NobleProg
255. ¿Cómo se Harán los Respaldos? • Prácticas recomendadas: • Documente los procedimientos de recuperación • Pruebe los procedimientos de recuperación antes de una falla real • Guarde estadísticas de cuánto duran las operaciones de “dump”/”load”, y qué tanto espacio requieren NobleProg® Limited 2017 All Rights Reserved NobleProg
256. Recuperando Modificaciones Después de un Respaldo • Cuando ocurre una falla de medios, las modificaciones hechas entre el último respaldo del log y la falla se pierden por un momento • Hay 3 escenarios que describen qué tanta actividad se puede recuperar: • No hay recuperación • Recuperación completa • Recuperación parcial NobleProg® Limited 2017 All Rights Reserved NobleProg
257. No Hay Recuperación • Las modificaciones hechas después del último respaldo del log no se pueden recuperar: • Si el dispositivo no tenía espejo, y • La falla es sobre el dispositivo de log NobleProg® Limited 2017 All Rights Reserved NobleProg
258. Recuperación Completa • Las modificaciones hechas después del último respaldo se pueden recuperar: • Si el dispositivo tenía espejo, o • La falla no es sobre el dispositivo de log • Usted puede recuperar el log y restaurar todas las modificaciones • Esto se conoce como recuperación “al minuto” NobleProg® Limited 2017 All Rights Reserved NobleProg
259. Recuperación “Al Minuto” • La recuperación “al minuto” es una opción de dump transaction que permite respaldar un log de transacciones sin truncarlo • Aún si el disco que contiene los datos está inaccesible • Esto también se conocer como “recuperar el log” • Para poder recuperar el log • • • • • El log y los datos deben estar en discos físicos separados La base de datos master debe estar disponible Ya se ha hecho un respaldo de la base de datos La falla no es sobre el dispositivo de log No se ha ejecutado una transacción de mínimo registro de log en la base de datos desde el último respaldo de base de datos o log NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
260. Recuperación “Al Minuto” NobleProg® Limited 2017 All Rights Reserved NobleProg
261. Sintaxis para la Recuperación al Minuto • Sintaxis: dump transaction database_name to device_name with no_truncate • Ejemplo: dump transaction salesdb to dump_salesdb_log with no_truncate • no_truncate • Respalda el log de transacciones, aún si el disco que contiene los segmentos de datos para la base de datos se encuentra inaccesible , usando un apuntador al log de transacciones en la base de datos master NobleProg® Limited 2017 All Rights Reserved NobleProg
262. Recuperación Parcial • Bajo ciertas circunstancias, sólo es posible recuperar los datos parcialmente • También se conoce como recuperación “en un punto del tiempo” NobleProg® Limited 2017 All Rights Reserved NobleProg
263. Recuperación “En el Tiempo” • La recuperación en el tiempo es una opción de load transaction que le permite recuperar una base de datos aplicando las transacciones hasta un punto en el tiempo particular • Puede ser usado en cualquier base de datos en la que el log de transacciones pueda ser respaldado / restaurado • No aplica a bases de datos en donde los datos y el log estén en el mismo dispositivo • No puede ser usado sobre una base de datos en la que se haya truncado el log después del último respaldo de la base de datos NobleProg® Limited 2017 All Rights Reserved NobleProg
264. Sintaxis de la Recuperación en el Tiempo • Sintaxis: load transaction database_name from device_name with until_time = "date-time" • Ejemplo: load transaction salesdb from dump_salesdb_log with until_time = "Dec 31, 1999 11:59:59:650PM" • Formato de la fecha-hora: • Mes, día, año hh:mm:ss:ms [AM PM] • Aunque la hora se especifica en milisegundos, la resolución es más o menos 1/300 de segundo NobleProg® Limited 2017 All Rights Reserved NobleProg
265. Recuperación en el Tiempo: Ejemplo • Un usuario accidentalmente borra una tabla importante en la base de datos salesdb 1. Use sp_who para listar los usuarios que estén usando la base de datos y espere a que se desconecten sp_who go 2. Cambie la base de datos a modo mono-usuario: use master go sp_dboption salesdb, "single user", true go use salesdb go checkpoint go NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
266. Recuperación en el Tiempo: Ejemplo 3. Asegurese que la informacíon es fiable en el momento en que ha ocurrido el evento. Por ejemplo , si el objeto fue borrado usando programas SQL, verifique la huella de tiempo en el archivo de salida 4. Tome bacup de transacciones para la Base de Datos: use master go dump transaction salesdb to dump_salesdb_db go 5. Cargue las copias mas recientes de respaldo de Base de Datos use master go load database salesdb from dump_salesdb_db go NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
267. Recuperación en el Tiempo: 6. Cargue el log de transacciones que fue creado despues del cargue db Base de Datos load transaction salesdb from dump_salesdb_tran1 go load transaction salesdb from dump_salesdb_tran2 go 7. Cargue el log de transacciones que contiene el error usando la opcion until_time justo antes del error (basado en la información colectada en el punto 3) load transaction salesdb from dump_sales_log with until_time = “May 31, 2012 11:59:59:650PM” go 8. Verifique consisitencia online database salesdb go dbcc checkstaorage (salesdb) go NobleProg® Limited 2017 All Rights Reserved NobleProg
268. Recuperación en el Tiempo: 9. Tome una copia de respaldo de la Base de Datos dump database salesdb to dump_salesdb_dev go 10. Cambie la base de datos a multiusuario. use master go sp_dboption salesdb, “single user”,”false” go checkpoint go NobleProg® Limited 2017 All Rights Reserved NobleProg
269. La Base de Datos master • Mantenga copias de respaldo actualizadas de master, especialmente después de: • Agregar / borrar dispositivos • create database, alter database, y drop database • Agregar logins • Es posible que se requiere reconstruir master si: • El disco que almacena el dispositivo master falla • ASE no puede arrancar (por razones relacionadas a problemas con el dispositivo master) • Comandos dbcc que reportan corrupción en master • Usted también debe reconstruir master para duplicarla en otra máquina NobleProg® Limited 2017 All Rights Reserved NobleProg
270. Recuperando master con un Respaldo Actualizado • Si tiene copias de respaldo actualizadas: 1. Baje ASE 2. Ejecute el utilitario dataserver (UNIX) o sqlsrvr (Windows) para construir un nuevo dispositivo master dataserver –d /sybase/data/new_master.dat –b100M –z2K 3. Edite el archivo RUNSERVER o el Registry de Windows para que apunten al nuevo dispositivo master 4. Reinicie ASE en modo mono-usuario usando la opción -m 5. Amplíe master a su tamaño original 6. Manualmente actualice sysservers para registrar el Backup Server 7. Restaure la copia de master (esto baja ASE – reinícielo con -m) 8. Ejecute dbcc para asegurar la consistencia de las bases de datos 9. Ejecute los scripts T-SQL installmodel/instmodl TSQL 10.Reinicie ASE en modo normal NobleProg® Limited 2017 All Rights Reserved Continúa … NobleProg
271. Copias de Respaldo de las Tablas del Sistema • En adición a respaldar master, Sybase también recomienda hacer copias con bcp de las siguientes tablas del sistema de master: • • • • • • sysdatabases sysdevices syslogins sysusages syssrvroles sysloginroles • Tener copias de éstas tablas es útil durante un escenario de recuperación ante fallas NobleProg® Limited 2017 All Rights Reserved NobleProg
272. UPGRADE SAP ASE 15.0 A SAP ASE 16 Ejecutar preupgrade Instalar software SAP ASE 16. Ejecución preupgrade ($SYBASE/ASE-16_0/bin). Sacar listado sps hidde text. (el upgrade los ignorará). Corregir errores en caso de ser reportados por el preupgrade Ejecutar upgrade instalación15.Xdesde nuevainstalación16 Ejecutar un sp_configure en 15.0, guardar salida para luego compararla con 16 Copiar y/o actualizar archivos interfaces, cfg, RUN Actualizar variables de entorno Inicializar SAP ASE con el nuevo archivo RUN Ejecutar dbcc upgrade y recompilar objetos de ser necesario Ejecutar updatease Ejecutar dbcc gam(<dbname>,0,0,'check'). dbcc fix_text() Ejecutar dbcc rebuid_text. Nota: 2569335 Ejecutar script instmsgs.ebf Post Upgrade Validar parámetros que cambiaron luego del upgrade y hacer los cambios necesarios Ejecución sp_version para validar cambios en los scripts. (Validar ejecución de updatease). NobleProg® Limited 2017 All Rights Reserved NobleProg
No comments...
none