Respuesta
Una alternativa para lograr esto es valiéndose del Resource Governor de ASE; éste es un componente que permite establecer límites para el uso de recursos y acciones a tomar cuando alguno de esos límites es violado. Para comenzar, usted debe primero habilitar el uso del Resource Governor con un comando como el siguiente:

sp_configure 'allow resource limits',1
go

Éste parámetro es estático, así que usted debe reiniciar ASE para que el cambio tenga efecto.

Ahora, suponga que usted quiere monitorear el uso de espacio en la base de datos tempdb para todos aquellos usuarios que se conectan desde la aplicación isql. Usted podría ejecutar un comando como el siguiente:

sp_add_resource_limit NULL, isql, 'at all times', 
'tempdb_space', 200, 2, 1, 1
go

Si usted quiere ser más específico, podría controlar el uso de espacio para un login particular, por ejemplo usuario1:

sp_add_resource_limit usuario1, NULL, 'at all times', 
'tempdb_space', 200, 2, 1, 1
go

En estos comandos, el primer y segundo parámetros especifican el login o aplicación para el que se desea establecer el límite de uso de espacio (o el límite de un recurso en general); note que ambos no pueden ser NULL.

El tercer parámetro es el rango de tiempo durante el cuál se aplicará el límite; en éste ejemplo hemos usado 'at all times' que es un rango de tiempo predefinido del sistema; usted puede definir nuevos rangos con el procedimiento sp_add_time_range.

El cuarto parámetro es el tipo de límite que queremos controlar, en este caso tempdb_space, que es el espacio en la base de datos tempdb; otros posibles valores son row_count, elapsed_time y io_cost.

El quinto parámetro es el valor del límite; en este caso hemos definido 200 (páginas en tempdb).

Los tres últimos parámetros son:

• 2 = El límite se aplica durante la ejecución.

• 1 = Acción; sólo se genera una advertencia.

• 1 = Alcance; el límite aplica a nivel de consulta.

El resultado de esto es que cuando un usuario usa más de 200 páginas en tempdb, ASE genera mensajes de advertencia:

• En el log de errores:

User 'usuario1', application 'isql' exceeded tempdb 
space limit of 200 pages.

• En la sesión del usuario:

Msg 11056, Level 17, State 1:
Server 'SYBASE', Line 1:
Exceeded tempdb space limit of 200 pages.

Valiéndose de éstas herramientas usted podría establecer qué usuarios son los que más espacio consumen en la base de datos tempdb.

Respuesta
Hay varias formas de implementar una solución a ésta pregunta. Para algunos, la más obvia podría ser un procedimiento almacenado o incluso una función Java. Estos dos enfoques, sin embargo, requieren de esfuerzos de programación, son propensos a fallas y pueden requerir de tiempo.

La buena noticia es que en la versión ASE 15.0.1, Sybase incorporó la nueva función isnumeric() la cual retorna 1 si la expresión dada es un tipo de dato integer, float, money o decimal/numeric, y retorna 0 si no lo es, o si la expresión es NULL. Un valor de 1 garantiza que usted puede convertir la expresión a uno de estos valores numéricos. Sybase también incorporó en ésta versión la función relacionada isdate(), para determinar si una expresión dada es un valor datetime válido.

Respuesta
Desde versión 12.5 ASE incluye el utilitario de línea de comando ddlgen. Ésta herramienta puede realizar ingeniaría reversa de objetos individuales de la base de datos o de bases de datos enteras de un servidor ASE. Por ejemplo, para llevar a cabo la ingeniería reversa de toda la base de datos prod, uno ejecutaría el siguiente comando:

ddlgen -Ulogin -Ppassword -Sase_host:ase_port -Dprod -oprod.sql

Esto generaría en el archivo prod.sql algo similar a:

-------------------------------------------------
-- DDL for Database 'prod'
-------------------------------------------------
print 'prod'
use master
go
create database prod on pruebas_dat = 3
go
-------------------------------------------------
-- DDL for Rule 'prod.dbo.pub_idrule'
-------------------------------------------------
print 'Creating Rule pub_idrule'
go
use prod
go
setuser 'dbo'
go
create rule pub_idrule
as @pub_id in ("1389", "0736", "0877", "1622", "1756")
or @pub_id like "99[0-9][0-9]"
go
setuser
go
:
:

Así mismo, ddlgen cuenta con múltiples opciones para generar distintos tipos de sentencias de creación de objetos (DDLs).

El utilitario ddlgen se encuentra ubicado en $SYBASE/ASEP/bin (Unix y Linux) o %SYBASE%\ASEP\bin (Windows).

Para mayor información, vea el documento Generación de Sentencias DDL con ddlgen.

Respuesta
Hasta la versión 11.9.x de ASE, en UNIX la única opción recomendada para producción era la de usar raw particions para los dispositivos de base de datos de ASE; ésta opción era la única que garantizaba la recuperación del servidor en el evento de una falla del sistema y un adecuado nivel de rendimiento.

En la versión 12.0, Sybase introdujo la opción dsync. De acuerdo a la documentación, esta opción "especifica si las escrituras a un dispositivo de base de datos se llevan a cabo directamente al medio de almacenamiento o son puestas en buffers al usar archivos del sistema operativo". Según ésta definición, esto permitiría obtener un nivel de seguridad similar al de los raw devices; sin embargo, el rendimiento de ASE con la opción dsync ha probado no ser el mejor.

Más recientemente, en la versión 15.0, se introdujo la opción directio que "le permite configurar Adaptive Server para transferir datos directamente a disco, obviando el caché de buffers del sistema operativo". Esta nueva opción, según Sybase, brinda el mismo rendimiento y seguridad que los raw devices, pero con la facilidad de administración inherente a los archivos del sistema operativo.

De todas maneras, para ciertas bases de datos, en donde prima el rendimiento y no la "recuperabilidad" (como la base de datos tempdb), la recomendación continúa siendo la de usar archivos convencionales de UNIX con las opciones dsync y directio apagadas.

Las opciones dsync y directio son mutuamente exclusivas y se definen al momento de inicializar un dispositivo con disk init; también se pueden modificar con el procedimiento almacenado sp_deviceattr. Estas opciones no tienen efecto en Windows.

Respuesta
La diferencia entre los comandos update statistics y update index statistics es sutil, pero puede resultar importante. Supongamos que existe una tabla T con columnas a, b y c, y que creamos un índice sobre dichas columnas.

Veamos: por una parte, el comando update statistics genera estadísticas sólo para la columna líder de los índices de la tabla. En otras palabras, si ejecutamos update statistics T, sólo se generarían estadísticas para la columna a; no se generarían estadísticas para las columnas b ni c. 

Por otra parte, el comando update index statistics genera estadísticas para todas las columnas de los índices de la tabla. Al ejecutar un comando como update index statistics T, se generarían estadísticas para las columnas a, b y c.

Las estadísticas adicionales, generadas con update index statistics, pueden ser útiles para el optimizador de ASE a la hora de calcular el costo de un plan de consulta que involucre dichas columnas; más estadísticas implican más espacio en la base de datos, pero también dan al optimizador una mejor descripción de los valores de las columnas.

Respuesta
La tarea de integrar datos no relacionales a un sistema que corre sobre ASE puede ser resulta de varias maneras. Un primer enfoque puede ser el tradicional: crear una nueva tabla cuya estructura corresponda a la información del archivo plano, y luego subir los datos usando la opción in del utilitario bcp. Éste enfoque, aunque válido, podría tener algunos inconvenientes como disponibilidad de espacio en la base de datos, definición adecuada de la estructura de la tabla relacional, definición adecuada del archivo de formato del bcp (se puede necesitar uno si la opción -c no aplica), etc.

A partir de ASE 12.5, Sybase incorporó la nueva opción de "Content Management", la cual permite el acceso a archivos y directorios de un sistema de archivos, desde una base de datos, usando el concepto de "table proxy".

Una tabla proxy es una tabla local que se asocia a una fuente remota de datos (por ejemplo, un archivo plano). La tabla proxy contiene metadatos (no los datos reales) y es usada para tener acceso a los datos remotos, como si fuera una tabla local.

Entonces, una forma rápida de integrar nuestro archivo a una base de datos sería creando una tabla proxy asociada al mismo, usando el comando create existing table de T-SQL; por ejemplo:

create existing table Xitems
(
item_id char(5),
item_nombre varchar(50),
item_marca varchar(30),
item_precio money,
item_cantidad int
)
external file at "/home/javila/ase150-64/items.txt"
column delimiter ","
go

Note el uso de la cláusula column delimiter, la cual permite cambiar el delimitador de columna predeterminado (tabulador), por otro.

Una vez creada la tabla, ésta puede ser fácilmente consultada y/o modificada usando comandos T-SQL; por ejemplo:

insert into Xitems values('50331','Nuevo Item','N/D',150.00,300)
go

select * from Xitems
where item_precio >= $1500.00
go

item_id item_nombre                     item_marca item_precio item_cantidad
------- ------------------------------- ---------- ----------- -------------
10223   Disco 3.5 Pulgadas - Caja de 10 BONY       5,700.00    15
10501   Cinta para Maquina de Escribir  BEMINGTON  1,500.00    10
(2 rows affected)

Para poder usar el acceso a archivos, usted debe primero activar la opción, usando un comando como el siguiente:

sp_configure "enable file access", 1
go

La noticia mala es que en ASE 12.5.x esta opción se licencia por separado (cuesta dinero...) – la buena es que a partir de versión 15.0 viene como parte del producto base (sin costo adicional...)

Usted puede encontrar más información sobre el acceso a archivos y directorios en ASE, en éste documento.

Respuesta
A partir de ASE 12.5.2 se agregó el parámetro with statusonly al comando kill para reportar el progreso de un proceso de servidor que esté en estado de rollback. La sintaxis es:

kill spid with statusonly

Por ejemplo:

kill 13 with statusonly

produce la siguiente salida:

spid: 13 Transaction rollback in progress. Estimated rollback
completion: 27% Estimated time left: 1605 seconds

Antes de la versión 12.5.2, en realidad no había manera fácil de conocer ésta información...

Respuesta
En ASE hay varias maneras de convertir un conjunto resultado de una sentencia SQL a XML.

Para aquellos que no tienen licenciado el componente de Servicios XML de ASE (en ASE 12.5, por ejemplo, este componente se licenciaba por separado) una solución viable era la de construir el XML concatenando los diferentes elementos del documento al conjunto resultado. Por ejemplo, uno podría construir un procedimiento almacenado como el siguiente:

create proc authors_a_XML
as
set nocount on

select "<?xml version=""1.0""?>
<autores>" as xml
union
select "  <autor>
    <codigo>" + au_id + "</codigo>
    <apellidos>" + au_lname + "</apellidos>
    <nombres>" + au_fname + "</nombres>
  </autor>" as xml
from pubs3..authors
union
select "</autores>" as xml
return 0
go

Este procedimiento genera un documento XML a partir de un select sobre la tabla authors. El procedimiento usa el operador UNION de T-SQL y concatena al conjunto resultado diferentes elementos del documento XML. Al ejecutarlo, uno obtendría algo como:

exec authors_a_XML
go

xml 
--- 
<?xml version="1.0"?> 
<autores> 
  <autor> 
    <codigo>409-56-7008</codigo> 
    <apellidos>Bennet</apellidos> 
    <nombres>Abraham</nombres> 
  </autor> 
:
:
  <autor> 
    <codigo>648-92-1872</codigo> 
    <apellidos>Blotchet-Halls</apellidos> 
    <nombres>Reginald</nombres> 
  </autor> 
  <autor> 
    <codigo>341-22-1782</codigo> 
    <apellidos>Smith</apellidos> 
    <nombres>Meander</nombres> 
  </autor> 
</autores> 

Note que para lograr la "indentación" adecuada del documento XML, el procedimiento debe ser creado tal como se ilustra al comienzo, con los mismos espacios y divisiones de línea.

Este enfoque, sin embargo, es poco práctico ya que requeriría de un procedimiento para cada operación SQL que necesite ser convertida a XML.

La buena noticia es que a partir de la versión 15 de ASE, los Servicios XML vienen incluidos con el producto base, así que convertir el resultado de una sentencia SQL a XML se convertiría en algo tan sencillo como agregar una cláusula for xml:

select au_id, au_lname, au_fname
from pubs3..authors
for xml
option "rowname=autor,tablename=autores"
go

lo que produciría un documento como:

 
- 
<autores xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <autor>
        <au_id>409-56-7008</au_id>
        <au_lname>Bennet</au_lname>
        <au_fname>Abraham</au_fname>
    </autor>
:
:
    <autor>
        <au_id>648-92-1872</au_id>
        <au_lname>Blotchet-Halls</au_lname>
        <au_fname>Reginald</au_fname>
    </autor>
    <autor>
        <au_id>341-22-1782</au_id>
        <au_lname>Smith</au_lname>
        <au_fname>Meander</au_fname>
    </autor>
</autores>

Este enfoque es, obviamente, mucho más flexible y requiere de menor programación. Las opciones incluidas en la cláusula option permiten modificar el formato del documento XML resultante. Adicionalmente, se incluyen otra serie de funciones basadas en Java que permiten llevar a cabo, no solo generación de documentos XML, sino operaciones de consulta, validación, etc.

Por ejemplo, un resultado igual al anterior se podría obtener usando la función forxmlj:

select forxmlj('select au_id, au_lname, au_fname from pubs3..authors',
    'rowname=autor,tablename=autores')
go

Para habilitar los Servicios XML de ASE 15 usted debe ejecutar el siguiente comando:

sp_configure 'enable xml', 1
go

Respuesta
Hay diferentes maneras de lograr esto, dependiendo del objetivo que usted quiera alcanzar. Usualmente, usted desea remover la duplicidad de cierta llave debido a cambios en reglas del negocio o porque simplemente se encontró una regla de negocio que no fue aplicada cuando la base de datos fue construida originalmente.

Probablemente el método más rápido es construir una copia de la tabla original:

select *
into tabla_temp
from tabla_orig
where 1=0

Luego, crear un índice único sobre las columnas, que cubra las filas duplicadas con el atributo ignore_dup_key.

create unique index idx_temp
  on tabla_temp(col1, col2, ..., colN)
  with ignore_dup_key

Ahora, insertar las filas de tabla_orig en la tabla tabla_temp.

insert tabla_temp
select * from tabla_orig

Usted probablemente querrá asegurarse de tener una copia de respaldo de la tabla original, ya que el siguiente paso consiste en eliminarla. Usted también querrá verificar y asegurarse de que la tabla temporal incluye las filas que usted necesita. Usted también necesita asegurarse de que no hay triggers en la tabla original, ni reglas de integridad referencial. Usted probablemente no desea que ninguna de éstas reglas se dispare, o si lo hacen, lo mejor es que esté conciente de las implicaciones.

Por último, usted tiene un par de opciones. Usted puede simplemente borrar la tabla original y renombrar la tabla temporal con el mismo nombre de la tabla original. Otra alternativa es truncar la tabla original e insertar las filas de la tabla temporal. Usted podría hacer esto si requiere cosas como que se disparen reglas de integridad referencial sobre la tabla original, o algo así. En la mayor parte de los casos, borrar y renombrar es la mejor opción.

Respuesta
Aquí presentamos tres enfoques. Antes de intentar cualquiera de ellos, ¡cree copias de respaldo de sus bases de datos!

Enfoque 1 – dump / load

1. Usando dump database, cree copias de respaldo de las bases de datos que residen sobre el dispositivo, elimine las bases de datos y elimine el dispositivo.

2. Usando disk init, reconstruya el dispositivo sobre la nueva ubicación física.

3. Reconstruya las bases de datos asegurándose de volver a crear los fragmentos de manera correcta; de no hacerlo, existe el riesgo de que los segmentos de datos queden sobre los de log, o viceversa.

4. Usando load database, cargue las copias de respaldo de las base de datos.

Enfoque 2 – El truco del disk mirror

1. Usando el comando disk mirror, cree un dispositivo espejo del dispositivo que desea mover, usando la nueva ubicación física como ubicación para el dispositivo espejo.

2. Usando el comando disk unmirror, desactive el lado primario del dispositivo (que apunta a la ubicación física original); use las opciones side='primary', mode='remove' del comando disk unmirror.

3. Elimine el dispositivo físico original.

4. Si su versión de ASE es 12.5.0.3 o mayor, el parámetro 'disable disk mirroring' estará en 1 (indicando que la creación de discos espejo está deshabilitada en ASE), así que antes de usar éste método usted debe dar el valor 0 a dicho parámetro (que es estático), y dejarlo en 1 nuevamente, al final.

Enfoque 3 – Modifique los catálogos del sistema (¡sólo para los expertos y valientes!)

1. Baje el servidor usando el comando shutdown.

2. Cree una copia física del dispositivo usando dd o un utilitario similar; elimine el dispositivo físico.

3. Restaure la copia física del dispositivo sobre la nueva ubicación.

4. Suba el servidor y edite el diccionario de datos para que apunte a la nueva ubicación (sysdevices.physname).

5. Es importante anotar que al subir el servidor en el paso anterior, la base de datos (o bases de datos) que residen sobre el dispositivo que fue movido, no son recuperadas y son marcadas como "suspect", así que un paso adicional sería eliminar dicho estado para dejar el servidor en un estado coherente.

Nuevamente, recuerde que las copias de respaldo son un requisito en todos los casos (por si acaso...)

Respuesta
La función de holdlock es la de mantener todos los candados compartidos hasta el final de la transacción. Esto asegura el nivel 3 de aislamiento transaccional ANSI, el cual garantiza que si usted ejecuta la misma sentencia select dos veces, usted obtiene el mismo resultado (por ejemplo, otro usuario no puede cambiar o agregar filas durante ése tiempo). Entonces, para que holdlock tenga sentido, usted necesita usarlo dentro de una transacción, típicamente algo como esto:

begin tran
select * from Tabla holdlock
where ...alguna condición...
...otras operaciones que modifican filas del anterior conjunto resultado...
commit

En el ejemplo que se propuso al inicio de ésta pregunta, no había transacción presente, así que uno puede inclinarse a concluir que en ese caso, usar holdlock no tiene sentido. ¿Por qué? Porque la idea detrás del nivel de aislamiento 3 es asegurar que las filas que usted leyó en una sentencia no cambiarán hasta que se indique lo contrario (por ejemplo, con el final de la transacción).

Pero cuidado... ¿quién dijo que no hay transacción involucrada? Parece que hemos asumido que la sentencia al inicio de la pregunta fue ejecutada en modo transaccional "no encadenado" o "unchained" (el predeterminado de ASE). Si, por el otro lado, éste código hubiera sido ejecutado en modo encadenado (el predeterminado de ANSI), la imagen repentinamente habría cambiado: en este caso, la sentencia select habría iniciado una nueva transacción (implícitamente), si no hubiera habido ya alguna activa, y entonces un holdlock habría tenido más sentido. También, el código habría podido ser ejecutado con isql -Y, lo que habría activado el modo encadenado para ésa sesión. Así que las cosas no son tan simples como lo habíamos pensado.

El punto aquí es que puede haber más de lo que usted espera, detrás de una porción simple de código...

Respuesta
Simplemente basta con ejecutar el procedimiento sin parámetros, y ASE mostrará un mensaje de error diciéndole qué parámetros obligatorios se esperan. Los nombres de los parámetro usualmente indican, de manera clara, el propósito del parámetro. Por ejemplo:

1> sp_addsegment
2> go
Msg 201, Level 16, State 2:
Server 'SYBASE', Procedure 'sp_addsegment':
Procedure sp_addsegment expects parameter @segname, which was not supplied.
Msg 201, Level 16, State 2:
Server 'SYBASE', Procedure 'sp_addsegment':
Procedure sp_addsegment expects parameter @dbname, which was not supplied.
Msg 201, Level 16, State 2:
Server 'SYBASE', Procedure 'sp_addsegment':
Procedure sp_addsegment expects parameter @devname, which was not supplied.
(return status = -6)

Note que sólo los parámetros obligatorios son listados. Típicamente, estos son los primeros parámetros en la lista de argumentos; los parámetros opcionales usualmente vienen de últimos.

Un enfoque más amigable ha venido siendo introducido para un buen número de procedimientos almacenados del sistema introducidos en los últimos años. Procedimientos como sp_tempdb (12.5.0.3) y sp_dbextend (12.5.1), que proveen extensa funcionalidad, mostrarán una 'información de uso' al ser llamados sin parámetros, o con la opción 'help' como primer argumento. El mismo enfoque ha sido seguido para sp_webservices (12.5.2), sp_encryption (12.5.3a), y sp_metrics (15.0), entre otros. Por ejemplo:

1> sp_webservices
2> go
Help information for sp_webservices
sp_webservices 'add', 'wsdl uri' [, sds name] [, 'webMethod=proxyTable [, webMethod=proxyTable ]*' ]
sp_webservices 'list', ['wsdl uri'] [, sds name]
sp_webservices 'remove', 'wsdl uri' [, sds name]
sp_webservices 'modify', 'wsdl uri', 'timeout=value'
sp_webservices 'deploy', [ 'all' | 'udws name' ]
sp_webservices 'undeploy', [ 'all' | 'udws name' ]
sp_webservices 'addalias', aliasName, databaseName
sp_webservices 'dropalias', aliasName
sp_webservices 'listalias'
sp_webservices 'listudws' [, udws_name ]
sp_webservices help
(return status = 0)

A partir de 12.5.1, sp_monitor también mostrará información al ser llamado con 'help': por razones de compatibilidad con versiones anteriores (sp_monitor ya existía en versiones anteriores de ASE), el comportamiento predeterminado sin parámetros (mostrar información básica de uso de CPU, por ejemplo), no ha cambiado. La nueva versión de sp_monitor - con parámetros - es muy útil, ya que reporta cosas como las 10 consultas más pesadas; obtiene la información de las tablas MDA.