Bases de datos

Teradata, siendo como es una Base de Datos para Data Warehousing (con todo lo que ello supone), se sumó un poco tarde a la implementación de la integridad referencial (‘RI Referencial Integrity‘) que otros fabricantes implementaban ”desde siempre’. Esto no es de extrañar, ya que las Data Warehouses buscan hacer las consultas (y cargas) lo más rápidas posibles, y esto es algo que la RI penalizaría o haría imposible. Por otra parte, los datos deberían llegar ya depurados (provienen de OLTP’s que ya implementan RI) o se depuran una sola vez en el proceso ETL (no suele haber muchas modificaciones ‘transaccionales’ en un Data Warehouse).

No obstante, como hemos dicho, Teradata se subió al carro de la RI y lo hizo adoptando el criterio ‘más general’, aunque a su manera.

La RI en teradata se presenta en tres opciones: ‘Standard‘, ‘Batch‘ y ‘Soft‘.

La RI ‘standard‘ es la de toda la vida: verifica fila a fila la existencia de una Primary Key/Alternate Key en la tabla referida para cada fila de la tabla referente según la columna de relación.

La RI ‘batch‘ hace lo mismo que la anterior, pero en vez de hacerlo fila a fila lo hace a nivel de transacción para todas las filas implicadas en la misma (esto es lo mismo que hace Oracle con las ‘constraints’ ‘DEFERRABLE/DEFERRED’).

la RI ‘soft‘ es una RI virtual: no hace ningún tipo de verificación de integridad (se confía en la integridad de los datos) y sólo sirve para indicar al optimizador relaciones ‘virtuales’ y que éste las tome en cuenta al generar los ‘query plans‘ y sus costes. (Oracle implementa esto con ‘constraints’ ‘DISABLED NOVALIDATE RELY’).

Así pues, las diferencias entre las dos primeras sólo deberían ser a nivel ‘transaccional’, no ‘formal’. Es decir, CUANDO se efectúa la validación (por fila o al terminar la transacción) y no CÓMO se efectúa.

¿Es esto así? Vamos a ver cómo funciona (en este caso en Teradata 12).

Creamos la tabla ‘padre’ y la llenamos:

BTEQ -- Enter your DBC/SQL request or BTEQ command: CREATE SET TABLE MY_DB.LETTERS_ESP , NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT ( ID_C CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL, C_TEXTO VARCHAR(25) CHARACTER SET LATIN NOT CASESPECIFIC ) UNIQUE PRIMARY INDEX ( ID_C ); *** Table has been created. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ESP(ID_C, C_TEXTO) VALUES ('A','Letra A'); *** Insert completed. One row added. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ESP(ID_C, C_TEXTO) VALUES ('E','Letra E'); *** Insert completed. One row added. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ESP(ID_C, C_TEXTO) VALUES ('I','Letra I'); *** Insert completed. One row added. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ESP(ID_C, C_TEXTO) VALUES ('O','Letra O'); *** Insert completed. One row added. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ESP(ID_C, C_TEXTO) VALUES ('U','Letra U'); *** Insert completed. One row added. *** Total elapsed time was 1 second.

Ahora creamos una tabla ‘hija’ con RI ‘standard’:

BTEQ -- Enter your DBC/SQL request or BTEQ command: CREATE SET TABLE MY_DB.LETTERS_ENG , NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT ( ID_C CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL, C_TEXTO VARCHAR(25) CHARACTER SET LATIN NOT CASESPECIFIC, ID_C_SP CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC, CONSTRAINT ENG_ESP_FK_FK FOREIGN KEY ( ID_C_SP ) REFERENCES MY_DB.LETTERS_ESP ( ID_C ) ) UNIQUE PRIMARY INDEX ( ID_C ); *** Table has been created. *** Total elapsed time was 1 second.

Vamos ahora a insertar tres filas en la tabla ‘hija’: una con un valor RI existente, otra con un valor RI inexistente, y una tercera con un valor RI nulo. La primera debería insertarse OK, la segunda debería fallar y la tercera debería insertarse, pues un valor nulo (NULL) no viola las ‘constraints‘ de RI:

BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ENG (ID_C, C_TEXTO, ID_C_SP) VALUES ('A','Letter A','A'); *** Insert completed. One row added. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ENG (ID_C, C_TEXTO, ID_C_SP) VALUES ('B','Letter B','B'); *** Failure 2700 Referential constraint violation: invalid Foreign Key value. Statement# 1, Info =0 *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ENG (ID_C, C_TEXTO, ID_C_SP) VALUES ('C','Letter C',NULL); *** Insert completed. One row added. *** Total elapsed time was 1 second.

En efecto, todo ha sido como se esperaba.

En teoría, un cambio de ‘standard‘ a ‘batch‘ no debería suponer ningún cambio:

DROP TABLE MY_DB.LETTERS_ENG; *** Table has been dropped. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: CREATE SET TABLE MY_DB.LETTERS_ENG , NO FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL, CHECKSUM = DEFAULT ( ID_C CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC NOT NULL, C_TEXTO VARCHAR(25) CHARACTER SET LATIN NOT CASESPECIFIC, ID_C_SP CHAR(1) CHARACTER SET LATIN NOT CASESPECIFIC, CONSTRAINT ENG_ESP_FK_FK FOREIGN KEY ( ID_C_SP ) REFERENCES WITH CHECK OPTION MY_DB.LETTERS_ESP ( ID_C ) ) UNIQUE PRIMARY INDEX ( ID_C ); *** Table has been created. *** Total elapsed time was 1 second.

(Nótese la opción WITH CHECK OPTION en la definición de la FK).

Si repetimos las tres inserciones, deberíamos esperar los mismos resultados (la documentación no habla de ninguna diferencia en ese sentido, o al menos yo no he encontrado ninguna referencia al respecto). Pero sorprendentemente Teradata devuelve un error en el valor NULL para la RI ‘WITH CHECK OPTION’:

BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ENG (ID_C, C_TEXTO, ID_C_SP) VALUES ('A','Letter A','A'); *** Insert completed. One row added. *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ENG (ID_C, C_TEXTO, ID_C_SP) VALUES ('B','Letter B','B'); *** Failure 3513 RI violation. Statement# 1, Info =0 *** Total elapsed time was 1 second. BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ENG (ID_C, C_TEXTO, ID_C_SP) VALUES ('C','Letter C',NULL); *** Failure 2620 The format or data contains a bad character. Statement# 1, Info =0 *** Total elapsed time was 1 second.

¡No hay diferencias en los tipos de datos de las tablas ni en los datos insertados, pero se produce un extraño error que se subsana con un simple ‘CAST’ al tipo de datos definido para la tabla!:

BTEQ -- Enter your DBC/SQL request or BTEQ command: INSERT INTO MY_DB.LETTERS_ENG (ID_C, C_TEXTO, ID_C_SP) VALUES ('C','Letter C',NULL(CHAR(1))); *** Insert completed. One row added. *** Total elapsed time was 1 second.

¿Desde cuándo es necesario hacer un ‘CAST’ para insertar un ‘NULL’, sea cual sea el tipo?  (El texto de error indicaba algún problema en el formato, lo que suele ser habitual en los problemas de la transformación de tipos) Y además sólo ocurre en el caso de que la FK haya sido definida con la opción WITH CHECK OPTION -batch RI-.

Esto para mí tiene todo el aspecto de un ‘bug‘…

Saludos.

Carlos.

El parámetro max worker threads se utiliza para configurar la cantidad de worker threads disponibles para los procesos de SQL Server, esto ayuda a optimziar el desempaño cuando gran cantidad clientes están conectados al servidor. La opción max worker threads permite que SQL Server cree un pool de worker threads para atender a gran cantidad de peticiones, lo cual mejora el desempeño. La opción por omisión es 0 y permite que SQL Server configure automáticamente el número de worker threads al inicio del servicio. Algunas veces para mejorar el desempeño es mejor especificar un valor directamente, usted puede utilizar la siguiente tabla como referencia:

 

Cantidad de CPUs

servidor 32-bit

servidor 64-bit

<= 4 procesadores

256

512

8 procesadores

288

576

16 procesadores

352

704

32 procesadores

   

Fuente: http://technet.microsoft.com/en-us/library/ms187024.aspx

 

Con base en el blog de Bob Duffy http://blogs.msdn.com/b/boduff/archive/2008/05/17/configuring-max-worker-threads-in-sql-2005.aspx se puede determinar la cantidad de threads que está utilizando SQL Server con la siguiente DMV:

select max_workers_count From sys.dm_os_sys_info

select count(*) from sys.dm_os_threads

Además Bob recomeinda la siguiente fórmula para calcular los worker threads:

 

1. Para sistemas  x86 donde el total de procesadores lógicos es <=4
• # max worker threads = 256
2. Sino :
• # max worker threads = 256 + ((# Procs – 4) *
3. Para sistemas x64 donde el total de procesadores lógicos es <= 4
• # max worker threads = 512
4. Sino
• # max worker threads = 512 + ((# Procs – 4) * 16)

 

Hay que tomar en cuenta que Hyper-threading causa que SQL Server crea que tiene más procesadores físicos disponibles, puesto que aparecen como si fuesen dos cores distintos y SQL Server podría crear demasiados threads, en ese caso usted podría especificar directamente la cantidad de worker threads.

 

Saludos,

Ing. Eduardo Castro Martínez, PhD – Microsoft SQL Server MVP

http://mswindowscr.org

http://comunidadwindows.org

Costa Rica

Technorati Tags: SQL Server

LiveJournal Tags: SQL Server

del.icio.us Tags: SQL Server

http://ecastrom.blogspot.com

http://ecastrom.wordpress.com

http://ecastrom.spaces.live.com

http://universosql.blogspot.com

http://todosobresql.blogspot.com

http://todosobresqlserver.wordpress.com

http://mswindowscr.org/blogs/sql/default.aspx

http://citicr.org/blogs/noticias/default.aspx

http://sqlserverpedia.blogspot.com/

Note: Cross posted from Eduardo Castro.

Permalink

The parameter max worker threads is used to configure the number of worker threads available to Microsoft SQL Server processes, this helps optimize performance when large numbers of clients are connected to the server. The max worker threads option enables SQL Server to create a pool of worker threads to service a larger number of query request, which improves performance. The default value of this options is 0, and allows SQL Server to automatically configure the number of worker threads at startup. Sometimes to improve performance is better to specify a specific value, you can use the following table as reference:

 

Number of CPUs

32-bit computer

64-bit computer

<= 4 processors

256

512

8 processors

288

576

16 processors

352

704

32 processors

   

Source: http://technet.microsoft.com/en-us/library/ms187024.aspx

 

Based on Bob Duffy blog http://blogs.msdn.com/b/boduff/archive/2008/05/17/configuring-max-worker-threads-in-sql-2005.aspx you can determine the maximum number of threads SQL Server has actually configured and how many it is currently using by the following DMVs:

select max_workers_count From sys.dm_os_sys_info

select count(*) from sys.dm_os_threads

Bob also recommends a formula to determine the max worker processes as follows:

 

1. For x86 systems where total number of logical processors <=4
• # max worker threads = 256
2. Otherwise:
• # max worker threads = 256 + ((# Procs – 4) *
3. For x64 systems where total number of logical processors <= 4
• # max worker threads = 512
4. Otherwise
• # max worker threads = 512 + ((# Procs – 4) * 16)

 

Be aware that Hyper-threading causes SQL Server a lot of hassle is that it appears as two physical cores, so may result in SQL Server allocating too many threads, so in that case may need to set an specific value for the max worker threads option.

 

Regards ,

Ing. Eduardo Castro Martínez, PhD – Microsoft SQL Server MVP

http://mswindowscr.org

http://comunidadwindows.org

Costa Rica

Technorati Tags: SQL Server

LiveJournal Tags: SQL Server

del.icio.us Tags: SQL Server

http://ecastrom.blogspot.com

http://ecastrom.wordpress.com

http://ecastrom.spaces.live.com

http://universosql.blogspot.com

http://todosobresql.blogspot.com

http://todosobresqlserver.wordpress.com

http://mswindowscr.org/blogs/sql/default.aspx

http://citicr.org/blogs/noticias/default.aspx

http://sqlserverpedia.blogspot.com/

Note: Cross posted from Eduardo Castro.

Permalink

In this presentation we review the new features in SQL Server 2008 R2. SQL Server 2008 R2 comes up with many enhancements in Security, Availability, Performance, Management, Storage, Programmability, BI( Business Intelligence ) and SSRS (Reporting Services)

 

Introduction to microsoft sql server 2008 r2 View more presentations from Eduardo Castro.

Regards,

Ing. Eduardo Castro Martínez, PhD – Microsoft SQL Server MVP

http://mswindowscr.org

http://comunidadwindows.org

Costa Rica

Technorati Tags: SQL Server

LiveJournal Tags: SQL Server

del.icio.us Tags: SQL Server

http://ecastrom.blogspot.com

http://ecastrom.wordpress.com

http://ecastrom.spaces.live.com

http://universosql.blogspot.com

http://todosobresql.blogspot.com

http://todosobresqlserver.wordpress.com

http://mswindowscr.org/blogs/sql/default.aspx

http://citicr.org/blogs/noticias/default.aspx

http://sqlserverpedia.blogspot.com/