hogar › Teléfono › Compresión de datos en SQL Server (COMPRESIÓN). II) Soluciones "tecnológicas" a los problemas. Si aplicar compresión o no es una gran pregunta.

Compresión de datos en SQL Server (COMPRESIÓN). II) Soluciones "tecnológicas" a los problemas. Si aplicar compresión o no es una gran pregunta.

La compresión de datos sólo está disponible en servidor SQL Enterprise Edition, pero a partir de SQL Server 2016 SP1, se agregó a todas las ediciones. No es tan fácil responder a la pregunta "si el uso de la compresión de datos será beneficioso en un caso particular o no". Propongo considerar esto con más detalle.

pros

La compresión de datos le permite almacenar más filas en una sola página, lo que en última instancia ahorra espacio. además de ahorrar Espacio del disco(no solo para la base de datos en sí, sino también para la copia de seguridad), obtenemos ahorros de memoria, ya que incluso en la memoria los datos se almacenan comprimidos.

Será más útil utilizar la compresión de datos en los llamados "datos fríos", que rara vez se utilizan y normalmente no se almacenan en la memoria, sino que se leen desde el disco.

Desventajas

Sólo se pueden comprimir los datos almacenados en filas (in-row). Esto significa que las cadenas largas (más de 8 KB) y los datos LOB (grandes) no se pueden comprimir, ya que no se almacenan en cadenas, sino que se colocan en un almacenamiento especial y el enlace a ellos permanece en la cadena.

Si aplicar compresión a las páginas no ahorra espacio, esas páginas se almacenarán sin aplicar compresión.

Cada acceso a datos comprimidos requiere Recursos adicionales UPC. Los datos se comprimen no solo en el disco, sino también en la memoria, por esta razón, cada vez que se accede a ellos se requiere descompresión. No debe aplicar compresión a datos muy importantes, ya que el acceso a ellos será más lento debido al paso de descompresión adicional.

Principio de funcionamiento en palabras sencillas.

Compresión a nivel de fila: convierte un tipo de datos fijo en una variable. Por ejemplo, un int generalmente ocupa 4 bytes fijos, pero si almacena 123, entonces este valor puede caber en 1 byte + metadatos para un almacenamiento de longitud variable.

Compresión a nivel de página: En primer lugar, aplica compresión a nivel de fila, luego se compara la página con algún diccionario y se aplican algoritmos que encuentran secuencias repetidas. Esto le permite comprimir los datos con mucha más fuerza.

Si aplicar compresión o no es una gran pregunta.

Considerar mesas grandes. No deberías mirar cientos de tablas pequeñas que no se beneficiarán de la compresión.
Asegúrese de que los objetos no estén fragmentados antes de aplicar la compresión (use sys.dm_db_index_physical_stats). La fragmentación puede provocar graves errores de compresión y no obtendrá suficiente ganancia.
Compruebe cuántos datos del objeto seleccionado hay en la memoria (use sys.dm_os_buffer_descriptores). Si La mayoría de Los objetos están en la memoria, no se beneficiará al aplicar compresión porque pueden estar calientes. Pero si dichos datos se utilizan con poca frecuencia, aún puede beneficiarse de la compresión; los datos comprimidos ocuparán menos espacio en la memoria.
Puedes ver con qué frecuencia se utilizan los objetos de memoria usando sys.dm_db_index_operative_stats. Cuanto más a menudo se utilicen los objetos, más recursos de CPU se consumirán.
Compruebe el posible porcentaje de compresión con sys.sp_estimate_data_compression_ Savings. Si la ganancia es pequeña, no aplique compresión, de lo contrario desperdiciará su recursos de CPU a nada. La ganancia de la compresión a nivel de fila debe ser de al menos el 15%, para la compresión a nivel de página de al menos el 30%.
Considere la posibilidad de utilizar índices de columnas. La compresión a nivel de página normalmente produce una tasa de compresión del 50%, pero los índices en columnas se comprimen significativamente más (hasta 10 veces la compresión). Los índices de columnas son bastante diferentes de los índices normales, así que no los utilice sin aprender cómo funcionan.

Conclusión

A partir de SQL Server 2016, la compresión está disponible en todas las ediciones, lo que permite su uso en cualquier aplicación. Además de la compresión, otras funciones de Enterprise Edition están disponibles en SQL Server 2016; este es un maravilloso regalo de Microsoft.

EN condiciones modernas A veces es muy extraño escuchar "necesitamos colapsar la base de datos 1C: su volumen supera los 50 GB". Si los administradores de SAP R3 u Oracle e Business Suite o incluso los sistemas MS Dynamics Ax hicieran esto, probablemente serían despedidos. Sin embargo, para 1C esta es una "práctica estándar".

Para versiones de archivos La historia se remonta a la versión 1C 7.7 con un límite de 2 GB en el tamaño de la base de datos. Ahora el límite de 2 GB está sólo en el tamaño de la tabla; el tamaño del archivo ya puede resultar muy, muy pequeño. Es cierto que si su base de datos ha crecido a tal tamaño, entonces probablemente los datos se ingresaron activamente allí; ¿tal vez deba pensar en un cliente-servidor?

En realidad, el propósito de este artículo es "disuadir" a los usuarios de realizar un resumen de la base de datos. versión cliente-servidor 1C, debido al uso de tecnologías algo más “avanzadas”.

La cifra final es de 30-40 toneladas, mínimo frente a 20-25 en caso de compra. disco duro y recibe 500 GB de espacio adicional

Por eso productos como
Probablemente sean buenos productos y cumplen sus objetivos. Es solo que la estructura de las tablas cambia de una versión a otra de la plataforma. 1C nos habló de esto más de una vez. Un separador de datos apareció en la versión 14 y eso es todo... lo más probable es que este procesamiento ya no sea adecuado para la versión 14. Y de alguna manera da miedo, sin mencionar la violación del acuerdo de licencia.

E incluso después de esto, habrá usuarios que "de repente necesitaron" datos borrados, que "solo querían corregir" algún número que "no afecta las secuencias" en un documento de un período cerrado. Y es peor si resulta que alguien estaba mirando constantemente estos documentos con algún propósito que sólo él conocía. Por supuesto, estos son solo errores en la metodología operativa, pero aún así habrá insatisfacción del usuario.

- Abra Management Studio en la lista de bases de datos, seleccione la que necesita y abra sus propiedades.
- Vaya a la pestaña "Grupos de archivos" como se muestra en la figura y agregue otro grupo de archivos (en el ejemplo se llama SECUNDARIO)

- Vaya a la pestaña "Archivos" y agregue archivo nuevo, para lo cual seleccionamos el grupo de archivos creado. Este archivo SE PUEDE UBICAR EN OTRO DISCO

- Ahora, usando el procesamiento, por ejemplo: determinamos qué tablas podemos "donar" de manera segura a un medio más lento (o viceversa, todo a un medio más lento, el resto a uno más rápido). Aquí se aplica la regla 80/20. El 80% de las operaciones se realizan con el 20% de los datos, así que piensa qué placas necesitas rápidamente y cuáles no tanto. "Almacenamiento" información adicional", documentos para ingresar saldos iniciales, documentos que ya no utiliza, identifíquelos inmediatamente como aquellos que se pueden transferir a un grupo de archivos “lento”.

Seleccione la tabla que desea mover a otro grupo de archivos; seleccione el menú para cambiar la tabla (proyecto) y cambie el grupo de archivos en las propiedades:

los índices de la tabla también se transfieren a este grupo de archivos.
Un mecanismo bastante conveniente para distribuir tablas en una matriz de discos diferentes velocidades. Acuerdo de licencia esto no se contradice, porque en la solución no utilizamos el acceso a los datos y base de información por medios distintos a la plataforma 1C. Organizamos el almacenamiento de estos datos únicamente de forma cómoda.

TRACEÓN DBCC (1807)

Nosotros escribimos este comando En Management Studio realizamos y podemos crear exitosamente bases de datos a través de la red. Por supuesto, esta instancia servidor SQL debe iniciarse en nombre del dominio cuenta, y esta entrada debe tener derechos sobre el deseado carpeta de red.
Pero tenga mucho cuidado al usar este comando si su red se cae mientras trabaja con la base de datos, no se podrá acceder a toda la base de datos durante su ausencia. No en vano Microsoft cerró esta oportunidad para uso masivo. En general, esta posibilidad está destinada a crear bases de datos sobre Almacenamientos NAS, que recomiendo mucho. Adecuado como estable y confiable servidor de archivos teniendo conexión directa al servidor que ejecuta MS SQL DBMS.
Puede leer más sobre otros indicadores de seguimiento en el artículo http://msdn.microsoft.com/ru-ru/library/ms188396.aspx
Aquellos. Parte del grupo de archivos se puede incluso almacenar en la red y allí se puede ampliar el espacio en disco sin problemas.

Por supuesto, es bueno dividir las tablas en diferentes grupos de archivos... pero dirás que aquí hay un par de tablas... que han estado funcionando desde 2005... y ya ocupan una docena de gigabytes. Ojalá pudiera poner todos los datos en ellos y poner un disco aparte, pero dejar los actuales.
No lo creerás, pero esto también es posible, aunque no muy sencillo:

Cree una función para particionar por fecha:

crear función de partición YearSection (fecha y hora)
como rango derecho para valores ("20110101");

Todo lo anterior a 2011 caerá en una sección, todo lo posterior irá a otra.

Creando un esquema de partición

crear esquema de partición YearScheme
como partición YearSection a (SECUNDARIO, PRIMARIO);

Con esto decimos que todos los datos hasta el año 11 terminarán en el grupo de archivos "Secundario" y luego en el grupo "Primario".

Ahora solo queda reconstruir la tabla dividiéndola en secciones. La forma más sencilla de hacer esto es utilizar estudio de gestión, porque el proceso no es sencillo. Debe reconstruir el índice agrupado en la tabla (que es esencialmente la tabla misma), eligiendo el esquema de partición creado para el índice:

En la imagen se ve que la opción no está disponible: todo está correcto. La partición de tablas sólo es posible en Versiones empresariales Servidor MS SQL. El índice de conglomerados es fácil de distinguir: una imagen entre paréntesis. Está creado para RN y todos los objetos 1C. Para RN, siempre hay un índice de conglomerado por período. Para documentos y directorios, sería bueno, por supuesto, crear otro que incluya los detalles mediante los cuales se realizará la sección... pero esto ya sería una violación del acuerdo de licencia.

Pero para hacer esto, no es necesario colapsar la base de datos, sino hacer lo siguiente:
a) Explicar a todos cómo usar las selecciones, cómo se guardan, cómo usar los intervalos de registro, cómo se guardan.
b) Marcar los datos innecesarios para su eliminación si no tienen ningún significado (contrapartes y elementos con los que ya no trabaja); esto traerá más beneficios a los usuarios que una reducción. Si hay recursos disponibles, configure el marcado automático para eliminar objetos no utilizados y realice una selección predeterminada en código de programa para que no se muestre por defecto necesitado por los usuarios objetos - marcados para su eliminación
c) Configurar otras “selecciones predeterminadas” útiles, por ejemplo, para que cada administrador vea sólo sus propios documentos de forma predeterminada. Y si quiere ver los documentos de un "camarada", debe desactivar la selección.

Para conocer todos los detalles que participan en la selección, no olvide marcar la casilla "Índice con pedidos adicionales"; entonces dichas "comodidades" no afectarán el rendimiento del sistema.

Compresión de datos en SQL Server 2008.

Recientemente tuve que migrar mi almacén de datos de SQL Server 2005 a SQL Server 2008. Como saben, una de las innovaciones de SQL Server 2008 es la compresión de datos. Esta característica está diseñada para mejorar el rendimiento de la base de datos al comprimir datos e índices en tablas y vistas indexadas, lo que resulta en una E/S reducida. Además, gracias a la compresión se puede reducir significativamente el tamaño de la base de datos, lo que facilita la administración y gestión. Todo esto sonaba tentador, así que decidí aprovechar esta oportunidad.

La razón que me impulsó a examinar más de cerca esta funcionalidad y finalmente escribir este artículo fue que obtuve un resultado completamente diferente al esperado :)

Decidí comprimir las tres tablas de hechos más grandes, que son estructuras con columnas lo más compactas posible, que hacen referencia a dimensiones y contienen una serie de indicadores que se agregan en informes. A continuación se muestra una estructura típica de una tabla de hechos y una consulta típica a esta tabla, en forma simplificada.

Pero para mi sorpresa, después de la compresión, no solo no obtuve ninguna mejora en el rendimiento, sino que, por el contrario, la ejecución de la consulta se ralentizó. En algunos casos, el rendimiento siguió siendo el mismo.

Se decidió investigar el efecto de la compresión de datos y realizar pruebas para responder a la pregunta sobre la caída del rendimiento.

Examen de preparación.

Entonces, hay una tabla, llamémosla ProductMMR, que contiene ciertos datos en varias secciones.

Aquí está su estructura:

Existencias

Producto

fecha

Tipo de almacén

Cantidad

El tamaño inicial de la tabla es de 16 GB, los índices son de 18 GB (usé el sistema HPsp_spaceused para determinar tamaños e índices de datos).

Ahora es el momento de decidir qué criterios utilizaremos para evaluar la eficiencia de la compresión.

Dado que casi todos los desarrolladores o administradores se preocupan por el rendimiento de sus servidores y aplicaciones, es obvio que el criterio principal para evaluar la efectividad de la compresión será el tiempo dedicado a ejecutar consultas, la cantidad de operaciones de E/S y la cantidad de CPU. tiempo usado. También se tendrá en cuenta el espacio en disco liberado como resultado de la compresión.

Aquí hay una consulta de prueba para seleccionar esta tabla:

ESTABLECER TIEMPO DE ESTADÍSTICAS: para medir el tiempo de ejecución de la consulta

SET STATISTICS IO ON - para medir operaciones de E/S lógicas y físicas

SELECCIONAR

hecho.DateID,

hecho.StockID,

SUMA(Cant.hecho) COMO Cant.

DE hecho.ProductMMR hecho

DONDE (fact.DateID ENTRE @DateIDBegin Y @DateIDEnd)

GRUPO POR hecho.ID de fecha, hecho.ID de stock

Se especificó un período de 30 días (en la tabla de hechos esto corresponde a más de 150 millones de registros).

Definición de estrategia de compresión y su implementación.

Detalles sobreimplementación de compresión Puedes leerlo en MSDN. La implementación de la compresión parapaginas y paralíneas . El efecto de la compresión depende de los datos de la tabla: cuántos valores duplicados hay y cuál es el tipo de datos.

Pasemos ahora a implementar la compresión, habiendo definido previamente su estrategia.

Sunil Agarwal en suBlog proporciona una serie de recomendaciones al respecto, permítanme resumirlas y presentarlas aquí:

1. No tiene sentido comprimir datos o índices pequeños. Si la tabla tiene 10 páginas y se comprimirá en una, esto no proporcionará ningún beneficio en en este caso. Es importante recordar que los datos comprimidos deben descomprimirse cada vez que se accede a ellos. Antes de aplicar la compresión, debe estimar el tamaño actual de la tabla/índice y el tamaño proyectado después de la compresión.

2. Si la tabla es muy utilizada por declaraciones DML y SELECT, entonces, como resultado de la compresión, es posible que obtenga carga excesiva a los procesadores como resultado de descomprimir cada vez que se accede a estos datos. En este caso, debe tener especial cuidado con la posibilidad de comprimir la tabla/índice.

3. Si los ahorros derivados de la compresión son bajos, entonces no se recomienda la compresión. Hay casos en los que el tamaño de los datos comprimidos es mayor que el de los datos sin comprimir. Esto indica que la tabla utiliza los tipos de datos más compactos.

4. Si tiene una aplicación OLTP típica, caso general debe elegir el tipo de compresión FILA. Este tipo de compresión es menos costosa en términos de descompresión de datos. Sin embargo, como regla general, la compresión de PÁGINAS es más eficiente en términos de espacio libre potencial.

Puede evaluar los beneficios de la compresión mediante un asistente o mediante un procedimiento almacenado.sp_estimate_data_compression_ Savings.

En mi caso obtuve estos resultados:

Tabla 1.

Eficiencia de compresión de datos.

Tipo de compresión	Tamaño antes de la compresión	Tamaño después de la compresión	% de compresión
FILA	33,4GB	22,7GB	32 %
PÁGINA	33,4GB	18,3GB	45 %

Como puede verse en la tabla, es posible obtener el efecto de la compresión de datos. Aunque en este caso no es lo más buen indicador, en muchos casos los datos se comprimen entre un 70% y un 80%.

En muchos casos, la relación de compresión será mayor, y en algunos casos mucho mayor, que la que obtuve en esta prueba. Todo depende de los tipos de datos y de la cantidad de datos duplicados que tenga en sus tablas.

Puede ver que en la tabla de prueba, la compresión a nivel de fila no será tan efectiva como la compresión de página. Tenga en cuenta que la compresión de PÁGINA es un superconjunto de la compresión de FILA.

Puede implementar la compresión de una tabla PÁGINA/FILA usando el asistente de compresión, que genera código como este:

ALTERAR TABLA. RECONSTRUIR PARTICIÓN = TODOS

CON

(COMPRESIÓN_DATOS = FILA

)

Puede aplicar compresión de tipo PÁGINA utilizando el parámetro DATA_COMPRESSION = PAGE.

Al especificar DATA_COMPRESSION = NONE puede cancelar la compresión de datos.

No daré aquí la sintaxis para comprimir índices y particiones; cualquiera que esté interesado puede encontrarlos fácilmente en BOL.

Recuerde que antes de habilitar o deshabilitar la compresión de filas o páginas, necesita la misma cantidad de espacio en disco que necesitaría para crear o reconstruir un índice.

Resultados de la prueba.

Entonces, antes y después de la compresión usando el tipo PÁGINA, se ejecutó una solicitud de prueba.

Aquí están sus resultados, en un caché de "calentamiento":

Tabla 2.

Resultados de la prueba No. 1*.

Tipo de compresión	Tiempo de ejecución de la consulta (ms)	Operaciones de lectura lógica**	Tiempo de CPU invertido (ms)
Sin compresión	26 147	1 419 113	308 736
Compresión de PÁGINA	41 104	709 360	486 453

*La solicitud se ejecutó en un servidor de 12 núcleos y 32 GB de RAM, subsistema de 10 discos RAID.

** Sólo se muestran operaciones de lectura lógica, porque no hubo lectura física: los datos estaban en el caché.

Al ver estos resultados, es posible que se sorprenda: después de todo, las operaciones de lectura lógica en datos comprimidos se realizaron dos veces menos, pero el tiempo de ejecución de la consulta fue un 36% más largo. Y el punto parece ser que, aunque hay menos operaciones de lectura y todo se lee desde la memoria, la sobrecarga para descomprimir los datos es alta. Después de todo, no se descomprime la página completa, sino cada registro por separado.

Se puede suponer que si los datos no se almacenan en caché, en este caso se puede lograr una ganancia de rendimiento reduciendo el número de costosas operaciones de lectura física en el caso de datos comprimidos.

Por lo tanto, se decidió realizar otra ronda de pruebas, pero esta vez en un caché frío.

Se ejecutó la misma solicitud de prueba, pero el caché y el búfer del procedimiento se borraron primero usando los comandosDBCC FREEPROCCACHE Y DBCC DROPCLEANBUFFERS .

Estos son los resultados de una solicitud de prueba antes y después de la compresión, en un caché "frío":

1 419 105

1 420 868

235 266

Compresión de datos de PÁGINA

48 887

707 495

710 105

416 689

Estos resultados confirman la suposición anteriormente expuesta. Como puede ver, el tiempo de ejecución difiere en un 12%, en lugar del 36% de la primera prueba.

Las estadísticas para las operaciones de lectura lógica son las mismas, pero en esta prueba hay una lectura física, lo que afecta significativamente el rendimiento de la consulta (compare el tiempo de ejecución con la primera prueba). Y, aparentemente, la compresión de datos dará Efecto positivo en términos de rendimiento, cuando las consultas se ejecutarán en grandes matrices de datos raramente utilizadas, cuya compresión permitiráahorrar en operaciones lectura fisica , en comparación con el cual descomprimir datos del grupo de búfer es una operación menos costosa. Un buen ejemplo Esto podría ser la compresión de particiones con datos de los primeros períodos en el almacenamiento o la compresión de otras tablas grandes y raramente utilizadas. Permítame recordarle que puede comprimir datos tanto a nivel de tabla como a nivel de particiones e índices. Además, puede combinar tipos de compresión.

Logré asegurarme de que en la mesa de prueba, el muestreo de datos comprimidos durante un período más largo comenzara a realizarse aproximadamente al mismo nivel que el muestreo de datos no comprimidos durante el mismo período, es decir. Cuanto mayor sea la matriz de datos a la que accedió la solicitud, mayor fue el efecto positivo de la compresión, porque el servidor primero tuvo que contactar para obtener una gran cantidad de datos sistema de disco y no el grupo de buffer.

Pero la mayoría razón principal La razón por la que el rendimiento de las consultas disminuyó en mi caso es la relación de compresión relativamente baja, menos del 50%. Ejecuté algunas pruebas más y descubrí que las tablas que estaban comprimidas entre un 60% y un 75% habían mejorado el rendimiento de las consultas en comparación con las tablas sin comprimir.

Obviamente, cuanto mayor sea el porcentaje de compresión, mayor será el impacto en las ganancias de rendimiento.

En cualquier caso, antes de iniciar esta operación, es necesario realizar pruebas y evaluar el efecto de la compresión de datos.

Sergey Kharybin, MCTS SQL Server.

El propósito de este artículo es "disuadir" a los usuarios de la versión cliente-servidor de 1C de realizar un resumen de la base de datos mediante el uso de tecnologías algo más "avanzadas".

1) Aumentar el tamaño de la base de datos.

2) Bajo rendimiento ejecución de solicitudes

3) Gran volumen"datos innecesarios" que interfieren con la experiencia del usuario

II) Soluciones "tecnológicas" a los problemas

c) Compresión de tablas de bases de datos.

d) Partición de tablas de bases de datos

En las condiciones modernas, a veces resulta muy extraño escuchar "necesitamos colapsar la base de datos 1C; su volumen supera los 50 GB". Si los administradores de SAP R3 u Oracle e Business Suite o incluso los sistemas MS Dynamics Ax hicieran esto, probablemente serían despedidos. Sin embargo, para 1C esta es una "práctica estándar".

Para las versiones de archivos, la historia se remonta a la versión 1C 7.7 con un límite de 2 GB en el tamaño de la base de datos. Ahora el límite de 2 GB está sólo en el tamaño de la tabla; el tamaño del archivo ya puede resultar muy, muy pequeño. Es cierto que si su base de datos ha crecido a tal tamaño, entonces probablemente los datos se ingresaron activamente allí; ¿tal vez deba pensar en un cliente-servidor?

En realidad, el propósito de este artículo es "disuadir" a los usuarios de la versión cliente-servidor de 1C de realizar un resumen de la base de datos, mediante el uso de tecnologías algo más "avanzadas".

I) Problemas que intentamos solucionar con el colapso de la base de datos

1) Aumentar el tamaño de la base de datos.

De hecho pregunta principal: ¿por qué reducir el tamaño de la base de datos?

Apliquemos un poco de matemáticas:

Servidor disco duro por 500 GB cuesta unos 10 mil rublos. Combinarlo en RAID 1 para mayor confiabilidad costará 20 mil rublos.

Naturalmente, puede haber problemas de falta de espacio para nuevas discos duros en el propio servidor...

Pero comprar una matriz de discos externa no será tan barato. ¿Qué hacer?

Sí, es simple: coloque los archivos de la base de datos en unidad de red, ¿pero como? Bueno, más sobre este artículo más adelante.

Aumentar el espacio en disco disponible para la base de datos nos costará 20 mil rublos. + 10 minutos de trabajo especializado. ¿Cuántas horas de trabajo especializado se necesitarán para desarrollar la base de datos? ¿Cuánto tiempo de inactividad puede haber? Según las estimaciones más conservadoras, para la convolución de una UPP con un volumen de 60 gigabytes, con un número promedio de errores, la contabilidad por lotes con verificación de los resultados de la convolución, la corrección de la misma contabilidad por lotes costará entre 30 y 40 mil. .

Es poco probable que el procesamiento universal colapse todo de una vez, especialmente si su base prácticamente “nunca se detiene”. La contabilidad de los partidos debería corregirse en cualquier caso. En general hay mucho trabajo allí. Y lo más importante es que la comprobación final debe ser muy exhaustiva, y seguirá habiendo errores...

Además, si la base de datos ya no tiene un tamaño de 60 GB, sino, por ejemplo, de 120 GB... el más mínimo error en el código 1C durante la convolución y listo... el procedimiento no finaliza con éxito. Y definitivamente habrá errores. Al igual que "no hay suficiente memoria" cuando se trabaja con especificaciones técnicas y errores como

http://img180.imageshack.us/img180/656/1c3y.jpg

La cifra final es de 30 a 40 toneladas, mínimo frente a 20-25 si compras un disco duro y obtienes 500 GB de espacio adicional.

Por eso aparecen productos como http://infostart.ru:8080/public/78934/

Probablemente sean buenos productos y cumplen sus objetivos. Es solo que la estructura de las tablas cambia de una versión a otra de la plataforma. 1C nos habló de esto más de una vez. Un separador de datos apareció en la versión 14 y eso es todo... lo más probable es que este procesamiento ya no sea adecuado para la versión 14. Y de alguna manera da miedo, sin mencionar la violación del acuerdo de licencia.

2) Rendimiento deficiente de las consultas

Bueno, ¿quién dijo que "que menos temas más rápido"? Para un SI correctamente desarrollado, esta afirmación no es cierta.

La siguiente figura muestra brevemente y “en lenguaje de pájaro” ejemplo más simple seleccionando por índice de tipo B-Tree de una entrada en la tabla de direcciones:

No quiero profundizar en el tema de los índices, sobre todo porque allí todo es algo más complicado. Lo más importante es que la búsqueda no se realiza “horizontalmente” a través de la tabla, sino “verticalmente” a través de los “niveles” del índice.

Analogía - Computadora portátil: Cada página comienza con su propia letra, solo que en cada página también hay el mismo cuaderno en el que puedes seleccionar la segunda letra de la palabra, y así sucesivamente hasta encontrar una página en la que habrá una o más entradas. ¿Cómodo? Por supuesto, es conveniente si tiene más de varios cientos de contactos. ¿Qué pasa si sólo tienes diez de ellos? ¿No es más fácil escribirlas en una hoja de papel que puedas mirar con los ojos? Lo mismo se aplica a los índices. Es eficaz si hay varios miles de registros en la tabla, pero si sólo hay uno, no es muy eficaz. Afortunadamente, los DBMS han aprendido a seleccionar de forma independiente un "plan de consulta" y decidir si utilizar o no tal o cual índice. Pero en el caso de "traer" todas las filas de una tabla sin un índice, el DBMS muy a menudo bloquea toda esta tabla y se observan "bloqueos que provienen inexplicablemente" después del colapso de la seguridad de la información.

Generalmente colapsamos tablas de saldos. En la tabla de saldos, el primer campo en todos los índices será el período. Es decir, para cualquier solicitud, en realidad. nivel superioríndice, los saldos calculados para el período requerido ya estarán seleccionados. Por lo tanto, el colapso de la base de datos tendrá el menor impacto en las consultas de saldos, repito, cuando organización adecuada sistemas.

3) Una gran cantidad de “datos innecesarios” que interfieren con la experiencia del usuario

Primero envíe un boletín informativo a sus usuarios sobre esto. Y recibirá un montón de mensajes que le dirán que "los datos nunca son innecesarios". Sin embargo, a muchas personas no les gusta “ver documentos históricos” y “datos de archivo”; ¿Pero la reconciliación resuelve estos problemas? ¿Elimina elementos innecesarios del directorio de nomenclatura? ¿Contrapartes con las que ya no trabajará? Y como muestra la práctica, aquí es donde residen la mayoría de los problemas. II) Soluciones "tecnológicas" a los problemas

a) Dividir la base de datos en grupos de archivos

Abra Management Studio en la lista de bases de datos, seleccione la que necesita y abra sus propiedades.

Vaya a la pestaña "Grupos de archivos" como se muestra en la figura y agregue otro grupo de archivos (en el ejemplo se llama SECUNDARIO)

Vaya a la pestaña "Archivos" y agregue un nuevo archivo, para lo cual seleccionamos el grupo de archivos creado. Este archivo PUEDE ESTAR UBICADO EN OTRO DISCO

Ahora, usando el procesamiento, por ejemplo: http://infostart.ru/public/78049/ determinamos qué tablas podemos "donar" de manera segura a un medio más lento (o viceversa, todo a un medio lento, el resto a uno más rápido). Aquí se aplica la regla 80/20. El 80% de las operaciones se realizan con el 20% de los datos, así que piensa qué placas necesitas rápidamente y cuáles no tanto. “Almacenamiento de información adicional”, documentos para ingresar saldos iniciales, documentos que ya no utiliza, identifíquelos inmediatamente como aquellos que se pueden transferir a un grupo de archivos “lento”.

los índices de la tabla también se transfieren a este grupo de archivos.

Un mecanismo bastante conveniente para distribuir tablas entre matrices de discos de diferentes velocidades. Esto no contradice el acuerdo de licencia, porque En la solución, no utilizamos el acceso a la base de datos e información por medios distintos a la plataforma 1C. Organizamos el almacenamiento de estos datos únicamente de forma cómoda.

b) Colocar la base de datos o parte de ella en una unidad de red

TRACEÓN DBCC (1807)

Escribimos este comando en Management Studio, lo ejecutamos y podemos crear bases de datos con éxito a través de la red. Por supuesto, la instancia de SQL Server debe iniciarse bajo una cuenta de dominio y esta cuenta debe tener derechos sobre la carpeta de red deseada.

Pero tenga mucho cuidado al usar este comando si su red se cae mientras trabaja con la base de datos, no se podrá acceder a toda la base de datos durante su ausencia. No en vano Microsoft cerró esta posibilidad de uso masivo. En general, esta función está destinada a crear bases de datos en almacenamientos NAS, lo cual recomiendo encarecidamente. También es adecuado un servidor de archivos estable y confiable que tenga una conexión directa con el servidor que ejecuta MS SQL DBMS.

Puede leer más sobre otros indicadores de seguimiento en el artículo http://msdn.microsoft.com/ru-ru/lipary/ms188396.aspx

c) Compresión de tablas de bases de datos.

EXEC sp_MSforeachtable "¿ALTERAR ÍNDICE TODO EN? RECONSTRUIR CON (COMPRESIÓN_DATOS = PÁGINA)" IR

Después de ejecutar este código, se comprimirán todas las tablas de la base de datos. Obviamente, también puedes comprimir tablas individualmente... es tu elección. ¿Qué hace la compresión?

Ahorrar espacio en disco

Reducir la carga en el subsistema de disco.

¿Qué se está consumiendo? - Tiempo de CPU.

Entonces, si su procesador está cargado al 70% o más todo el tiempo, no puede usar la compresión. Si la carga del procesador es del 20-30% y la cola de discos crece a 3-4... entonces la compresión de tablas es la “cura” para usted. Más información sobre la compresión de tablas de bases de datos: http://msdn.microsoft.com/ru-ru/lipary/cc280449(v=sql.100).aspx

La función de compresión de tablas solo está disponible para propietarios de la versión Enterprise de SQL Server.

d) Partición de tablas de bases de datos

No lo creerás, pero esto también es posible, aunque no muy sencillo:

Cree una función para particionar por fecha: crear función de partición YearSection (fecha y hora)

como rango derecho para valores ("20110101");

Todo lo anterior a 2011 caerá en una sección, todo lo posterior irá a otra.

Creando un esquema de partición

crear esquema de partición YearScheme

como partición YearSection a (SECUNDARIO, PRIMARIO);

Con esto decimos que todos los datos hasta el año 11 terminarán en el grupo de archivos "Secundario" y luego en el grupo "Primario".

En la imagen se ve que la opción no está disponible: todo está correcto. La partición de tablas solo es posible en la versión Enterprise de MS SQL Server. El índice de conglomerados es fácil de distinguir: una imagen entre paréntesis. Está creado para RN y todos los objetos 1C. Para RN, siempre hay un índice de conglomerado por período. Para documentos y directorios, sería bueno, por supuesto, crear otro que incluya los detalles mediante los cuales se realizará la sección... pero esto ya sería una violación del acuerdo de licencia.

2) El problema del bajo rendimiento de las consultas.

Todas las acciones descritas anteriormente no deberían afectar la velocidad de ejecución de consultas básicas. Además, el uso de grupos de archivos y secciones de tablas le permitirá colocar los datos utilizados con más frecuencia en matrices de discos rápidas y le permitirá cambiar la configuración. matrices de discos, utilice un acelerador de E/S de tamaño pequeño. Esto sólo aumentará la velocidad de ejecución de la consulta. Y la compresión de tablas le permitirá aliviar aún más el subsistema de disco si fuera un cuello de botella. En general, si hablamos de la velocidad de ejecución de consultas, analizar sus planes de ejecución y optimizar las consultas para el uso adecuado de los índices dará un aumento de rendimiento mucho más significativo que todos los "trucos" a nivel de MS SQL.

3) Problema gran volumen"datos innecesarios" que interfieren con la experiencia del usuario

Pero para hacer esto, no es necesario colapsar la base de datos, sino hacer lo siguiente:

a) Explicar a todos cómo usar las selecciones, cómo se guardan, cómo usar los intervalos de registro, cómo se guardan.

b) Marcar los datos innecesarios para su eliminación si no tienen ningún significado (contrapartes y elementos con los que ya no trabaja); esto traerá más beneficios a los usuarios que una reducción. Si hay recursos disponibles, configure el marcado automático para la eliminación de objetos no utilizados y realice una selección predeterminada en el código del programa para que los objetos que los usuarios no necesitan (aquellos marcados para su eliminación) no se muestren de forma predeterminada.

c) Configurar otras “selecciones predeterminadas” útiles, por ejemplo, para que cada administrador vea sólo sus propios documentos de forma predeterminada. Y si quiere ver los documentos de un "camarada", debe desactivar la selección.

Para conocer todos los detalles que participan en la selección, no olvide marcar la casilla "Índice con pedidos adicionales"; entonces dichas "comodidades" no afectarán el rendimiento del sistema.

¿Olvidémonos del resumen de la base de datos? Grupos de archivos y secciones tablas SQL,compresión de tablas SQL. 10 de octubre de 2011

La cifra final es de 30 a 40 toneladas, mínimo frente a 20-25 si compras un disco duro y obtienes 500 GB de espacio adicional.

Por eso aparecen productos como http://infostart.ru:8080/public/78934/
Probablemente sean buenos productos y cumplen sus objetivos. Es solo que la estructura de las tablas cambia de una versión a otra de la plataforma. 1C nos habló de esto más de una vez. Un separador de datos apareció en la versión 14 y eso es todo... lo más probable es que este procesamiento ya no sea adecuado para la versión 14. Y de alguna manera da miedo, sin mencionar la violación del acuerdo de licencia.

Abra Management Studio en la lista de bases de datos, seleccione la que necesita y abra sus propiedades.
- Vaya a la pestaña "Grupos de archivos" como se muestra en la figura y agregue otro grupo de archivos (en el ejemplo se llama SECUNDARIO)

- Vaya a la pestaña “Archivos” y agregue un nuevo archivo, para lo cual seleccionamos el grupo de archivos creado. Este archivo SE PUEDE UBICAR EN OTRO DISCO

- Ahora, usando el procesamiento, por ejemplo: http://infostart.ru/public/78049/ determinamos qué tablas podemos "donar" de manera segura a un medio más lento (o viceversa, todo a un medio lento, el resto a uno más rápido). Aquí se aplica la regla 80/20. El 80% de las operaciones se realizan con el 20% de los datos, así que piensa qué placas necesitas rápidamente y cuáles no tanto. “Almacenamiento de información adicional”, documentos para ingresar saldos iniciales, documentos que ya no utiliza, identifíquelos inmediatamente como aquellos que se pueden transferir a un grupo de archivos “lento”.

Seleccione la tabla que desea mover a otro grupo de archivos; seleccione el menú para cambiar la tabla (proyecto) y cambie el grupo de archivos en las propiedades:

los índices de la tabla también se transfieren a este grupo de archivos.
Un mecanismo bastante conveniente para distribuir tablas entre matrices de discos de diferentes velocidades. Esto no contradice el acuerdo de licencia, porque En la solución, no utilizamos el acceso a la base de datos e información por medios distintos a la plataforma 1C. Organizamos el almacenamiento de estos datos únicamente de forma cómoda.

EXEC sp_MSforeachtable "¿ALTERAR ÍNDICE TODO EN? RECONSTRUIR CON (COMPRESIÓN_DATOS = PÁGINA)" IR

Después de ejecutar este código, se comprimirán todas las tablas de la base de datos. Obviamente, también puedes comprimir tablas individualmente... es tu elección. ¿Qué hace la compresión?
- Ahorrar espacio en disco
- Carga reducida en el subsistema de disco.
¿Qué se está consumiendo? - Tiempo de CPU.
Entonces, si su procesador está cargado al 70% o más todo el tiempo, no puede usar la compresión. Si la carga del procesador es del 20-30% y la cola de discos crece a 3-4... entonces la compresión de tablas es la “cura” para usted. Más información sobre la compresión de tablas de bases de datos: http://msdn.microsoft.com/ru-ru/library/cc280449(v=sql.100).aspx
Nota IMPORTANTE - La función de compresión de tablas solo está disponible para propietarios de la versión Enterprise de SQL Server.

d) Partición de tablas de bases de datos
Por supuesto, es bueno dividir las tablas en diferentes grupos de archivos... pero dirás que aquí hay un par de tablas... que han estado funcionando desde 2005... y ya ocupan una docena de gigabytes. Ojalá pudiera poner todos los datos en ellos y poner un disco aparte, pero dejar los actuales.
No lo creerás, pero esto también es posible, aunque no muy sencillo:

Cree una función para particionar por fecha:

crear función de partición YearSection (fecha y hora)
como rango derecho para valores ("20110101");

Todo lo anterior a 2011 caerá en una sección, todo lo posterior irá a otra.

Creando un esquema de partición

crear esquema de partición YearScheme
como partición YearSection a (SECUNDARIO, PRIMARIO);

Con esto decimos que todos los datos hasta el año 11 terminarán en el grupo de archivos "Secundario" y luego en el grupo "Primario".

Ahora solo queda reconstruir la tabla dividiéndola en secciones. La forma más sencilla de hacerlo es utilizar Management Studio, porque el proceso no es sencillo. Debe reconstruir el índice agrupado en la tabla (que es esencialmente la tabla misma), eligiendo el esquema de partición creado para el índice:

2) Bajo rendimiento de consultas.
Todas las acciones descritas anteriormente no deberían afectar la velocidad de ejecución de consultas básicas. Además, el uso de grupos de archivos y secciones de tablas le permitirá colocar los datos utilizados con más frecuencia en matrices de discos rápidas, cambiar la configuración de las matrices de discos y utilizar aceleradores de E/S de tamaño pequeño. Esto sólo aumentará la velocidad de ejecución de la consulta. Y la compresión de tablas le permitirá aliviar aún más el subsistema de disco si fuera un cuello de botella. En general, si hablamos de la velocidad de ejecución de consultas, analizar sus planes de ejecución y optimizar las consultas para el uso adecuado de los índices dará un aumento de rendimiento mucho más significativo que todos los "trucos" a nivel de MS SQL.

Una gran cantidad de “datos innecesarios” que interfieren con la experiencia del usuario

Pero para hacer esto, no es necesario colapsar la base de datos, sino hacer lo siguiente:
a) Explicar a todos cómo usar las selecciones, cómo se guardan, cómo usar los intervalos de registro, cómo se guardan.
b) Marcar los datos innecesarios para su eliminación si no tienen ningún significado (contrapartes y elementos con los que ya no trabaja); esto traerá más beneficios a los usuarios que una reducción. Si hay recursos disponibles, configure el marcado automático para la eliminación de objetos no utilizados y realice una selección predeterminada en el código del programa para que los objetos que los usuarios no necesitan (aquellos marcados para su eliminación) no se muestren de forma predeterminada.
c) Configurar otras “selecciones predeterminadas” útiles, por ejemplo, para que cada administrador vea sólo sus propios documentos de forma predeterminada. Y si quiere ver los documentos de un "camarada", debe desactivar la selección.

Para conocer todos los detalles que participan en la selección, no olvide marcar la casilla "Índice con pedidos adicionales"; entonces dichas "comodidades" no afectarán el rendimiento del sistema.

Popular en la categoría: