by ·Comments Off on SQL Server 2008 R2 – Intermedio – Manejo de Datasets

Asi como lo ven 86%

+ Confirmada
– Ok
= ERROR

La 5 y la 14 estan mal.

1. No todos los orígenes de datos son compatibles con los parámetros de la consulta, en esos casos se debe hacer el filtro en el origen:
-Verdadero
Falso

2. Las cadenas basadas en expresiones sirven para:
Manejo de datos dinámicos.
=Controlar caracteres inválidos.
-Especifica los datos de origen como parámetros.
Especifica los datos de origen como parámetros. Ninguna de las anteriores.

3. El origen de datos se divide en su definición en las siguientes partes:
Permisos
=Información de conexión
Permisos
-Todas la anteriores

4. El tipo de parámetro de relación es utilizado cuando se manejan sub reporte ya que se requiere una relación entre el reporte y el su reporte.
Verdadero
-Falso

5. Al filtrar los datos de la consulta se puede:
Agregar una clausula Where
Dinámicamente cambiar la fuente de datos
-Limitar los datos recuperados
-Mejorar en manejo de los índices

6. El diseñador gráfico de consultas MDX tiene dos modos:
+Modo diseño
Modo ejecución
+Modo de consultas
Modo Script

7. Las credenciales para orígenes de datos sirven para autenticarse en la red cuando se tiene datos de otras bases de datos:
Verdadero
-Falso

8. Una característica de los parámetros de Query es:
-Se procesan en el servidor de los orígenes de datos.
Es procesado en el cliente
Se usa ajax para ejecutar el reporte asíncrono
=La consulta no es un tipo de parámetro

9. Reporting service crea automáticamente los parámetros del informe que están conectados a los parámetros de consulta:
-Verdadero
Falso

10. Esta cadena de conexión “Data Source=localhost\MSSQL10.InstanceName; Initial Catalog=AdventureWorks” es una conexión para:
-SQL Server
Oracle
MySql
Access

11. Los parámetros de Dataset pueden determinar si los parámetros es de uno o varios valores.
Verdadero
-Falso

12. Los orígenes de datos que puedo acceder son:
+Oracle.
+XML.
+SAP NetWeaver BI
+Teradata

13. La variable UserID es:
Un parámetro de un procedimiento de almacenado del la base de datos sys
+Variable integrada
Identificador para autenticarse
Ninguna de las anteriores

14. Los tipos de parámetros en reporting service son:
-De Dataset
– De Reporte
–De relación
De Partición

15. Cuando se habla de datos jerárquicos y recuperación en cascada se habla de:
No existe este concepto
-El primer parámetro filtra el segundo para delimitar los datos que se desean escoger
Un dato obligatorio de búsqueda
Orden de llenado de los datos

by ·Comments Off on Determinar cómo está siendo utilizado el Log de transacciones de SQL Server

Problema:

Uno de los aspectos más importantes de una base es el log de transacciones. El log de transacciones se utiliza para escribir todas las acciones sobre los datos antes de ser confirmadas en los archivos de la base. En algunas circunstancias el log de transacciones puede llegar a ocupar un tamaño considerablemente grande y no saber cuál transacción es la causa o cuanto espacio es utilizado puede llegar a ser un problema. Entonces, ¿cómo determinar cuánto del registro de transacciones se está utilizando y qué partes se están utilizando?

Solución:

En la mayoría de las bases de datos, el log transaccional es un solo archivo LDF, pero dentro de este se encuentran archivos virtuales de registro como se muestra a continuación:

En cada archivo virtual se escriben los registros de las transacciones y cuando estas se confirman, se produce un punto de control y el espacio del ocupado se libera para poder volver a ser utilizado. Aunque esto depende del modelo de recuperación de la base, o se utlilizan replicas, o algún proceso de back up. Cuando no quedan más archivos virtuales SQL Server hace crecer el log de transacciones basado en la configuración de la misma para acomodarlos en el espacio obtenido.

El uso del archivo y de los registros virtuales depende principalmente de cómo es utilizada la base de datos. Si estas publicando datos de una base o si la base esta en modo de recuperación completo o Bulk-Logged, es probable que se vea afectada por los “loops back” de volver al principio del archivo o por la amplicacion del archivo de transacciones.

DBCC SQLPERF (logspace)

Un comando extremadamente útil para entender como está siendo utilizado el registro de transacciones es DBCC SQLPERF(logspace). Este comando muestra detalles sobre el tamaño actual de todas las transacciones de base de los registros, así como el porcentaje actualmente en uso. Ejecutando este comando en forma periódica te dará una buena idea de cómo los registros de transacciones están siendo utilizados y también te dará una idea de lo grande que realmente debe ser.
Es bastante frecuente que la gente que utiliza SQL Server que se pregunte como es que funciona, pero no hay una respuesta exacta ya que depende de un montón de criterios como:

– EL modo de recuperación de la base
– El tamaño de las transacciones
– Cuan grande sean las tablas y de cuantos índices disponga
– Cuan frecuente sean los back ups de los logs.
– etc…

Para ejecutar este comando:

 DBCC SQLPERF(logspace)

Salida:

Desde aquí podemos ver el tamaño de los registros de transacciones, así como la cantidad de espacio que utiliza. El espacio del registro actual utilizado te dirá el tamaño del registro de transacciones utilizado. Si este porcentaje es alto y el tamaño del registro es muy grande es probable que sea debido a uno de los puntos enumerados anteriormente.

DBCC LOGINFO

El siguiente comando para tener en cuenta es DBCC LOGINFO. Esto le dará información sobre sus registros virtuales dentro de su registro de transacciones. Lo principal a mirar es la columna Status. Dado que estos archivos se escriben secuencialmente y luego en bucle desde el principio, ver el valor 2. Las partes del registro que están en uso y las que no están en estado de uso tendrán Status = 0. Otra cosa a tener en cuenta es la columna FSeqNo. Este es el número de secuencia de registro virtual y el último es el último registro (el mayor) Si se ejecuta repetidas veces, se podrá ver que estos números cambian constantemente.

Para ejecutar este comando:

DBCC LOGINFO

Salida:

Al ejecutar alguno de los siguientes comandos se podrá apreciar el cambio

 BACKUP LOG DBUtil WITH NO_LOG

or

BACKUP LOG DBUtil TO DISK = C:\Backup\DBUtil.trn

Se ven los registros que tenían Status = 2 han cambiado a cero.

Una cosa a tener en cuenta es que si ejecutas un BACKUP LOG…WITH NO_LOG necesitaras ejecutar otro back up full, sino SQL Server reutilizara el espacio en el log de transacciones porque no hay forma de restaurar la copia de seguridad del registro de transacciones a no ser que sea completo.

DBCC OPENTRAN

Otro comando para mirar es DBCC OPENTRAN. Que muestra las transacciones abiertas que no han sido confirmadas, ya sean activas o que por alguna razón quedaron huérfanas, proporcionando información adicional sobre porque el registro de transacciones es tan grande o porque no es posible que reduzca de tamaño. También figuran las transacciones que aún no se han publicado en la réplica.

Para ejecutar este comando:

 DBCC OPENTRAN

Salida:

Bueno, ahora tienes una idea de cuánto de tu log de transacciones está siendo utilizado y por donde se puede empezar a mirar para tomar decisiones y cuán grande deben de ser estos.

Fuente: MSSqlTips.com

by ·Comments Off on Dos flags que no te pueden faltar cuando analizas un procedimiento en busca de errores.

Son SET STATISTICS IO ON y SET STATISTICS TIME ON

El primero muestra la información de estadísticas que disponen los objetos involucrados en la consulta a analizar, por ejemplo:

USE AdventureWorks2008R2;
GO
SET STATISTICS IO ON;
GO
SELECT *
FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;
GO
SET STATISTICS IO OFF;
GO

Muestra:

Table 'ProductCostHistory'. Scan count 1, logical reads 5, physical
reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0,
lob read-ahead reads 0.

Mientras que el segundo muestra el tiempo de ejecución, no el de análisis, de cada componente de la consulta en cuestión, por ejemplo:

USE AdventureWorks2008R2;
GO
SET STATISTICS TIME ON
GO
SELECT *
FROM Production.ProductCostHistory
WHERE StandardCost < 500.00;
GO
SET STATISTICS TIME OFF;
GO

Muestra:

SQL Server parse and compile time:
   CPU time = 0 ms, elapsed time = 1 ms.
SQL Server parse and compile time:
   CPU time = 0 ms, elapsed time = 1 ms.

(269 row(s) affected)

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 2 ms.
SQL Server parse and compile time:
   CPU time = 0 ms, elapsed time = 1 ms.

Después queda en ustedes interpretar cada valor, que no es muy complejo.

Por otro lado, y lo mejor, es que no se necesitan permisos especiales para establecer estos flags y no van a tener problemas con el administrador de la base ;P

En MSSQLTips.com esta esta nota que hace un analisis mas profundo.

Fuente, el MSDN: http://msdn.microsoft.com/en-us/library/ms184361.aspx y http://msdn.microsoft.com/en-us/library/ms190287.aspx