|
ASE Quiz > ASE
Quiz 2007
ASE Quiz – 2007
Preguntas y Respuestas sobre temas de administración, solución a problemas, rendimiento,
afinamiento y monitoreo de Adaptive Server Enterprise.
Vea aquí preguntas y respuestas de otros años...
Temas
Diciembre
Pregunta: Habiendo ubicado el log de errores (ver la
pregunta de Noviembre), ¿cuál podría ser una
forma eficiente y rápida de manipular (truncar, consultar, etc.)
dicho archivo desde una sesión cliente (por ejemplo isql o
Interactive SQL), sin recurrir a herramientas de conexión remota
(por ejemplo, telnet)?
Respuesta:
Recordando que ASE 15.0 ahora incluye, como
parte del producto base, la opción de acceso a
archivos externos, podríamos hacer algo así:1> use master
2> go
1> sp_configure 'enable file access' ,1
2> go
1> create proxy_table ase_errorlog external file at @@errorlog
2> go
Los anteriores comandos crean una tabla “proxy”
llamada ase_errorlog asociada al log de
errores de ASE, el cual está ubicado en @@errorlog
(ver la
pregunta de Noviembre).
Una vez creada la tabla, podríamos fácilmente:
- Consultar el log de errores:
1> /* Muestra las líneas del archivo que contienen la palabra "error" o "Error": */
2> select record from ase_errorlog where record like "%[Ee]rror%"
3> go
- Truncar el log de errores (sin necesidad de
reiniciar ASE...):
1> truncate table ase_errorlog
2> go
Es importante tener en cuenta, que aún cuando la
tabla ase_errorlog se percibe como una tabla
local de ASE, los datos residen realmente en un
archivo texto, así que debemos evitar operaciones
como select * from ase_errorlog (sin cláusula
where), ya que esto obliga a ASE a realizar
una lectura secuencial del archivo completo (no es
posible indexar la tabla ase_errorlog); si el
archivo es muy grande, el tiempo de respuesta sería
exageradamente alto y además podríamos saturar la
red (ya que estaríamos enviando toda la información
del archivo, del servidor al cliente).
Nota: éste “truco” se podría
implementar en ASE 12.5.x, pero requeriríamos de una
licencia para habilitar el parámetro “enable
file access” de ASE. |
Noviembre
Usted acaba de asumir las labores de DBA de un servidor
ASE que originalmente fue instalado por otra persona.
Pregunta: ¿Cómo puede usted determinar rápidamente la
ubicación de log de errores de ASE?
Respuesta:
Tal vez no haya una sola respuesta para ésta
pregunta. En UNIX, por ejemplo, una forma rápida de
conocer la ubicación del log de errores de ASE es
observar el contenido del archivo RUNSERVER,
usualmente ubicado bajo $SYBASE/$SYBASE_ASE/install;
éste podría mostrar algo como lo siguiente:#!/bin/sh
# ASE page size (KB): 2048
# Master device path: /home/sybase/data/master.dat
# Error log path: /home/sybase/ASE-15_0/install/SYBASE.log
# Configuration file path: /home/sybase/ASE-15_0/SYBASE.cfg
# Directory for shared memory files: /home/sybase/ASE-15_0
# Adaptive Server name: SYBASE
#
/home/sybase/ASE-15_0/bin/dataserver \
-d/home/sybase/data/master.dat \
-e/home/sybase/ASE-15_0/install/SYBASE.log \
-c/home/sybase/ASE-15_0/SYBASE.cfg \
-M/home/sybase/ASE-15_0 \
-sSYBASE \
Claramente se observa la ruta completa del log de
errores: /home/sybase/ASE-15_0/install/SYBASE.log
Sin embargo, ésta alternativa puede no ser muy
obvia para el sistema operativo Windows, en donde no
es común usar un archivo RUNSERVER para arrancar ASE
y en donde, además, los argumentos de inicio de ASE
se encuentran en el Registriy.
Por lo anterior, sería más deseable un enfoque un
poco más “portable”, lo que nos permite traer al
escenario a la variable global @@errorlog.
Para muchos desconocida, ésta variable global de ASE
almacena la ruta del log de errores de ASE,
independientemente del sistema operativo. Por
ejemplo:
1> select @@errorlog
2> go
-------------------------------------
C:\Sybase\ASE-15_0\install\SYBASE.log
Obviamente, lo único que requeriríamos aquí es
una conexión a ASE. |
Octubre
La labor de desarrollo de una aplicación le exige que
Ud. pruebe diferentes versiones de un mismo procedimiento almacenado
de ASE.
Pregunta: ¿Cuál es la forma más fácil de conseguir esto
en ASE?
Respuesta:
Esta es, tal vez, una de las características más
antiguas pero menos conocidas de ASE: el
“versionamiento” o “agrupamiento” de procedimientos
almacenados. La idea es que es posible crear dos o
más procedimientos almacenados, con el mismo nombre,
pero diferentes versiones.
Por ejemplo, supongamos que usted está
desarrollando el procedimiento almacenado
proc_prueba y desea probar dos versiones del
mismo procedimiento. La primera versión la puede
crear usando el comando create procedure, tal
como usualmente lo hace:
create procedure proc_prueba
as
/* T-SQL */
Ahora, para crear la versión 2 del mismo
procedimiento, use el mismo nombre, pero añada el
sufijo “;2”; por ejemplo:
create procedure proc_prueba;2
as
/* T-SQL */
El resultado es que ahora usted cuenta con dos
versiones del mismo procedimiento, las cuales se pueden
ejecutar así:
exec proc_prueba
/* ejecuta la versión 1 */
o
exec proc_prueba;2
/* ejecuta la versión 2 */
Ahora bien, algo a tener en cuenta es que el
comando drop procedure no permite borrar
procedimientos agrupados; es decir, no se permite un
comando como el siguiente:
drop proc
proc_prueba;1
El siguiente comando borra todos los
procedimientos agrupados bajo el nombre
proc_prueba:
drop proc
proc_prueba
Lo anterior quiere decir que ésta característica
es sólo recomendable para ambientes de desarrollo;
una vez se decida cuál versión del procedimiento
almacenado irá a producción, se debe sacar el DDL
del procedimiento para crear allí una única versión
(la definitiva). |
Septiembre
Pregunta: ¿Qué resultado tiene la ejecución de la
siguiente sentencia SQL en ASE?
select *
into existing table t2
from t1
Respuesta:
El comando select into ... existing table
permite copiar datos de una tabla origen (t1)
hacia una tabla destino (t2), y es una
operación con mínimo registro de log.Sin embargo,
el comando select into ... existing table
estaba limitado, y t2 (la tabla destino)
debía ser una tabla proxy; al ejecutar dicho comando
usando una tabla local como destino, se generaba el
siguiente mensaje de error:
The target of a 'select into existing table'
statement must be a proxy table.
En ASE 15 y las últimas versiones de 12.5.x (como
la 12.5.4), el comando select into ...
existing table fue mejorado y se permite ahora
que la tabla destino (t2) sea una tabla local
o regular. Así que una sentencia SQL como la de la
pregunta permite copiar las filas de la tabla t1
a la tabla (local) t2, usando operaciones con
mínimo registro de log. Esta última condición
implica, además, que la tabla t2 no puede
repetirse dentro de la sentencia, y que no puede
tener índices; si, por ejemplo, la tabla t2
tiene índices, se genera el siguiente mensaje de
error:
An index was found on table 't2' created via
SELECT INTO. Parallel inserts into indexed tables is
unsupported. Drop the table and retry the
command.
Por último, hay que tener en cuenta que la
cláusula existing table es obligatoria
cuando la tabla t2 existe ya en la base de
datos; si se omite, y la tabla t2 ya existe
en la base de datos, ASE genera el siguiente mensaje
de error:
There is already an object named 't2' in the
database. |
Agosto
Pregunta: ¿Cuál es la manera más rápida de ejecutar un
checkpoint en todas las bases de datos del servidor?
Respuesta:
Hasta antes de la versión 12.5.1 de ASE, la forma
(tal vez) más fácil de ejecutar checkpoint en
todas las bases de datos era construyendo un
script y luego ejecutándolo con isql. Por
ejemplo:chkpt_all.sql:
use master
go
checkpoint
go
use db1
go
checkpoint
go
use db2
go
checkpoint
go
:
isql -Usa ... -ichkpt_all.sql
Sin embargo, con la versión 12.5.1 se introdujo
una nueva sintaxis para el comando checkpoint
la cual permite, con un solo comando, ejecutar
checkpoint en todas la bases de datos del
servidor:
1> checkpoint all
2> go
Esta nueva sintaxis incluso permite ejecutar
checkpoint sobre una base de datos específica,
sin tener que usar el comando use:
1> checkpoint db1
2> go |
Julio
Pregunta: ¿Qué comando ejecutaría usted como DBA de ASE para conocer los Trace Flags
que se encuentran activos en su servidor?
Respuesta
Los trace flags de ASE son
opciones que se pueden prender o apagar, y que
afectan el comportamiento de ASE a nivel de sesión o
a nivel de servidor.Para conocer qué trace
flags se encuentran activos, el DBA puede
utilizar el comando dbcc traceflags, así:
1> dbcc traceon(3604)
2> go
DBCC execution completed. If DBCC printed error
messages, contact a user with System Administrator
(SA) role.
1> dbcc traceflags
2> go
Active traceflags: 3604, 7717
Para conocer qué sesiones tienen trace flags
activos, especifique la opción “2” del comando
dbcc traceflags: 1> dbcc traceon(3604)
2> go
DBCC execution completed. If DBCC printed error
messages, contact a user with System Administrator
(SA) role.
1> dbcc traceflags(2)
2> go
Active traceflags: 3604
Processes with P2_DEBUG flag on: 20 Las versiones
12.5.4 y 15.0.2 introdujeron el comando set
switch, el cual pretende brindar una forma más
“amigable” de prender y apagar opciones, o trace
flags, y es posible que en un futuro reemplace
al comando dbcc traceon. Junto con el comando
set switch también se introdujo el comando
show switch, el cual permite ver las opciones
activas: 1> show switch
2> go
Local switches set : none.
Serverwide switches set : 302 (print_plan_index_selection),
3604 (print_output_to_client). Hay más información
sobre el comando set switch en
éste
documento. |
Junio
Pregunta: ¿Cómo puedo validar si una cadena de caracteres dada es una fecha válida?
Respuesta
Antes de la versión 15.0.1 la tarea de validar si una cadena de caracteres
es una fecha válida requería de cierta labor (compleja) de programación; básicamente
existían dos opciones:
- Crear un procedimiento almacenado que usando Transact-SQL procesara la cadena y
validara si ésta era o no una fecha válida, o
- Crear una función SQLJ que usando Java procesara la cadena y llevara a cabo dicha
validación.
La buena noticia es que a partir de la versión 15.0.1, ASE incorpora la función
isdate() la cual arroja 1 si la cadena dada es
una fecha válida, o 0 si no lo es. Por ejemplo:
1> select isdate('Esta no es una fecha')
2> go
-----------
0
(1 row affected)
1> select isdate('10/1/2005')
2> go
-----------
1
(1 row affected)
Cabe anotar que dicha versión de ASE (la 15.0.1) también introdujo la función
isnumeric() que permite validar si una expresión dada es un valor numérico
o no (vea la pregunta de Noviembre
de 2006) .
|
Mayo
Pregunta: ¿Cómo obtener la hora actual de la máquina en donde corre ASE?
Respuesta
Tradicionalmente una combinación de las funciones getdate() y
convert() resuelven éste problema:1> select convert( varchar, getdate(), 8)
2> go
retorna algo similar a:
-------------
08:59:05
Aunque ésta expresión es válida—y de hecho funciona en cualquier versión de
ASE—las últimas versiones de ASE han introducido nuevas funcionas que nos
simplifican la vida.
La versión 12.5.1 introdujo, por ejemplo, la función current_time:
1> select current_time()
2> go
---------------
9:03AM
De igual manera, existen otras funciones que evitan tener que escribir expresiones
más complicadas; algunas de ellas:
- getutcdate() – (12.5.3) Arroja la fecha y hora UTC (o GMT) del sistema
en donde corre ASE.
- current_date() – (12.5.1) Arroja la fecha actual del sistema en donde
corre ASE.
- current_time() – (12.5.1) Arroja la hora actual del sistema en donde
corre ASE.
|
Abril
Pregunta: ¿Cuál es el resultado del siguiente batch de comandos?
declare @i int
select @i = 1
exec ('select @i = @i + 1')
select @i
go
Respuesta
La respuesta es: depende – depende de la versión de ASE que se esté usando.
En versiones 12.5.3 y anteriores, éste batch de comandos retorna lo siguiente:Msg 137, Level 15, State 2:
Server 'SYBASE', Line 1:
Must declare variable '@i'.
-----------
1
(1 row affected)
Lo anterior se debe a que en la versión 12.5.3 y anteriores, ASE no es capaz de
pasar los valores de las variables locales (como @i en el ejemplo) al contexto del
comando exec().
A partir de ASE 12.5.4 y 15.0, los valores de variables locales pueden ser ahora
intercambiados directamente con el exec(), así que la ejecución del batch
anterior resultaría en algo como:
(1 row affected)
(1 row affected)
-----------
2
(1 row affected)
Esto quiere decir que ahora es posible, también, retornar valores del contexto del
exec() al batch que lo llama, entre otros beneficios.
|
Marzo
Pregunta: Tradicionalmente el valor de parámetros de configuración de ASE como "max
memory" o "procedure cache size", se ha especificado
en páginas de 2K, usando el parámetro sp_configure. ¿Existe alguna manera
de definir dichos parámetros con sp_configure, pero especificando unidades
más "amigables" (por ejemplo G, M o K)?
Respuesta
Para cambiar el valor de un parámetro de configuración como "max
memory" usando unidades más "amigables", use la siguiente
sintaxis del sp_configure:
sp_configure "parámtero", 0, "valorG|M|K"
Por ejemplo, para definir el parámetro "max memory" en 740 Mb,
ejecute el siguiente comando:
sp_configure "max memory", 0, "740M"
go
Esta sintaxis es soportada a partir de ASE 12.5.x
|
Febrero
Pregunta: ¿Qué comando de Adaptive Server Enterprise muestra información sobre diferentes
límites a nivel de servidor, base de datos y objeto?
Respuesta
Esta información se puede obtener usando el comando dbcc serverlimits.
Este es un ejemplo de salida para ASE 15.0.1:1> dbcc traceon(3604)
2> go
DBCC execution completed. If DBCC printed error messages,
contact a user with System Administrator (SA) role.
1> dbcc serverlimits
2> go
Limits independent of page size:
================================
Server-wide, Database-specific limits and sizes
Max engines per server : 128
Max number of logins per server : 2147516416
Max number of users per database : 2146484223
Max number of groups per database : 1032193
Max number of user-defined roles per server : 1024
Max number of user-defined roles per (user) session : 127
Min database page size : 2048
Max database page size : 16384
Initial master database logical page count : 6656
Initial model database logical page count : 1536
Default logical pages in a new database : 1536
Min size of sybsystemprocs, in MB : 124
Recommended size of sybsystemprocs, in MB : 132
Database page-specific limits
APL page header size : 32
DOL page header size : 44
Max reserved page gap : 255
Max fill factor : 100
Table, Index related limits
Max number of columns in a table/view : 1024
Max number of indexes on a table : 250
Max number of user-keys in a single index on an unpartitioned table : 31
Max number of user-keys in a single local index on a partitioned table : 31
Max number of user-keys in a single global index on a partitioned table : 30
Max number of referential constraints per table : 192
Max number of keys in a referential integrity constraint : 16
Partition related limits
Max number of partitions in a table : 2147483646
Max number of keys in a partition condition : 31
Cache manager related limits
Default number of buffers in a named cache : 256
General SQL related
Max size of character literals, sproc parameters : 16384
Max size of local @variables in T-SQL : 16384
Max number of arguments to stored procedures : 2048
Max number of arguments to dynamic SQL : 2048
Max number of aggregates in a COMPUTE clause : 254
Max number of arguments to Java methods : 31
Max number of user tables in a single SQL statement : 512
Max number of internal work tables in a single SQL statement : 46
Max number of subqueries in a single statement : 50
Max number of user-supplied expressions in select list : 4096
Max number of referential integrity user tables per query : 192
Max number of referential integrity work tables per query : 192
Maximum lengths of different Identifiers
Max length of server name : 30
Max length of host name : 30
Max length of login name : 30
Max length of user name : 30
Max length of password : 30
Max length of role name : 30
Max length of a device name : 30
Max length of a database name : 30
Max length of a segment name : 30
Max length of cursor name : 30
Max length of engine group name : 30
Max length of dump file name : 30
Max length of network name : 32
Max length of IPv4 or IPv6 network address name : 64
Max length of physical name for a device : 127
Max length of manifest filename used during mount/unmount : 127
Max length of table name : 255
Max length of partition name : 255
Max length of column name : 255
Max length of index name : 255
Max length of procedure name : 255
Max length of named-cache name : 255
Max length of user-defined type name : 255
Max length of webservice name and its alias : 255
Max size of Java method signature in bytes : 16384
Limits as a function of the page size:
======================================
Item dependent on page size : 2048 4096 8192 16384
--------------------------------------------------------------------------------------------
Server-wide, Database-specific limits and sizes
Min number of virtual pages in master device : 11780 22532 45060 90116
Default number of virtual pages in master device : 23556 45060 90116 180228
Min number of logical pages in master device : 11776 11264 11264 11264
Min number of logical pages in tempdb : 2048 1536 1536 1536
Table-specific row-size limits
Max possible size of a log-record row on APL log page : 2014 4062 8158 16350
Physical Max size of an APL data row, incl row-overheads : 1962 4010 8106 16298
Physical Max size of a DOL data row, incl row-overheads : 1964 4012 8108 16300
Max user-visible size of an APL data row : 1960 4008 8104 16296
Max user-visible size of a DOL data row : 1958 4006 8102 16294
Max user-visible size of a fixed-length column in an APL table : 1960 4008 8104 16296
Max user-visible size of a fixed-length column in a DOL table : 1958 4006 8102 16294
Max user-visible size of a variable-length column in an APL table: 1948 3988 8068 16228
Max user-visible size of a variable-length column in a DOL table: 1954 4002 8098 16290
Max number of rows per APL data page : 256 256 256 256
Max number of rows per DOL data page : 166 337 678 1361
Index-specific row-size limits
Max index row-size, including row-overheads : 650 1300 2700 5400
Max user-visible index row-size : 600 1250 2600 5300
OAM-manager related limits
Max number of OAM entries per OAM page : 250 506 1018 2042
Text-manager related limits
Max text size available for user data : 1800 3600 7650 16200
Cache manager related limits
Min size of named cache (KB) : 512 1024 2048 4096
Default size of named cache (KB) : 1024 2048 4096 8192
|
Enero
Pregunta: ¿Cuál es la forma más fácil y rápida de dejar un parámetro de configuración
en su valor original predeterminado, sin conocer dicho valor?
Respuesta
Si usted no conoce el valor predeterminado de una parámetro de configuración
de ASE, pero desea dejar ése parámetro en su valor original predeterminado, la forma
más rápida de hacerlo es ejecutando el siguiente comando:
sp_configure "nombre del parámetro", 0, "default"
go
Por ejemplo, si quiero dejar el parámetro number of user connections en su
valor predeterminado, ejecutaría el siguiente comando:
sp_configure "number of user connections", 0, "default"
go
Obviamente hay que recordar que si el parámetro es estático, el cambio requeriría
un reinicio del servidor.
|
|
|
