shrinkfile - reducir log sql server 2005

¿Qué es lógico lee en el servidor sql? cómo reducir no de lógica?

Question

De toda mi búsqueda para acelerar las consultas en el servidor sql, se dice que las fuentes reducen las lecturas lógicas utilizando la cláusula where apropiada. De hecho, necesito saber cómo fluyen los procedimientos almacenados en el servidor sql cuando recibe la solicitud del front end y algunos consejos para evitar en los procedimientos almacenados y cuáles no.

Answer 1

Las lecturas lógicas son los registros que está leyendo de la base de datos. Tomemos un pequeño y estúpido ejemplo:

select *
from
(
  select *
  from orders
  where client = 1234
)
where item = 9876;

Aquí selecciona todos los pedidos del cliente 1234. Luego, solo los toma para el artículo 9876. Entonces (siempre que el optimizador no vea esto y optimice su consulta internamente) selecciona muchos más registros en el primer paso de lo necesario. Reduzca las lecturas lógicas (y el resultado intermedio de gran tamaño) aplicando ambos criterios en un solo paso:

select *
from orders
where client = 1234
and item = 9876;

(Esto también puede afectar las lecturas físicas, pero no necesariamente tiene que hacerlo. Por ejemplo, la primera consulta puede acceder a 100 registros y luego reducir eso a 10, mientras que el segundo solo lee esos 10. Pero los 100 registros pueden estar en un bloque de disco , por lo que ambas instrucciones leen un bloque de disco, es decir, hacen una lectura física. Incluso puede ser cero lecturas físicas, por cierto, en caso de que los datos ya estén en la memoria caché dbms, es decir, en la memoria. las lecturas pueden variar para una consulta, mientras que las lecturas lógicas siguen siendo las mismas siempre que la consulta y los datos no se modifiquen).

Answer 2

Una lectura lógica es cuando el motor de consulta necesita leer datos, pero lo encuentra ya en la memoria del servidor SQL. No necesita ir al disco. Si necesita ir a recuperar los datos del disco, eso se llama lectura física. Una lectura lógica es básicamente un "golpe de caché".

Sin embargo, decirle qué debe hacer sin ver la consulta o saber qué contiene la tabla y cómo son los datos y cómo se indexan y organizan los datos es básicamente imposible.

Un gran número de lecturas lógicas puede no ser necesariamente malo o, mejor dicho, no necesariamente prevenible . Lo malo es un número desmesurado de lecturas lógicas. Si devuelve 3 filas de datos, pero el motor de consultas tuvo que escanear 200 millones de filas de la tabla para hacerlo, va a ser muy lento y probablemente pueda mejorarlo reescribiendo la consulta o agregando un índice.

Comenzaría por ver cuán complejas son las consultas en su procedimiento almacenado. En particular, buscaría índices faltantes. Si está ejecutando SELECT * FROM BigTable WHERE ProductDate >= ''01/01/2014'' , me gustaría ver que haya un índice en ProductDate . Sin embargo, si está ejecutando SELECT * FROM BigTable ORDER BY ProductDate DESC , sí, un índice seguirá siendo útil, pero igual tendrá que devolver todo el conjunto de datos para que tenga que leer toda la tabla de todos modos. Además, las lecturas lógicas se refieren a las lecturas de página , por lo que si el ProductDate en cuestión se distribuye de manera uniforme alrededor del disco, es posible que deba leer todas las páginas o casi todas las páginas de todos modos.

Más allá de eso, podría ser que las estadísticas en la tabla estén desactualizadas. Si ha agregado 20,000 filas a una tabla y SQL Server todavía piensa que solo hay 2000 allí, va a lanzar por completo la planificación de consultas.