Práctica recomendada para el archivo de registro tempdb

He leído muchos blogs aquí y allá sobre cómo configurar archivos de datos tempdb pero no encontré ninguna información sobre el archivo de registro tempdb .

Aquí está la estrategia que estoy usando actualmente con mi tempdb:

He utilizado las recomendaciones de Paul Randal sobre cómo dividir mis archivos de datos tempdb
He establecido el tamaño de mis archivos de datos tempdb en su crecimiento automático máximo e inhabilitado. Por ejemplo, tengo 100 gb de espacio libre en disco y establezco el tamaño de mis 8 archivos de datos tempdb en 10 gb cada uno. Esto evita la fragmentación en el disco según lo recomendado por Brent Ozar y también tengo 20 gb libres para mi archivo de registro.

Pero como dije, nadie está hablando del archivo de registro tempdb . ¿Que debo hacer con eso? En mi configuración, este archivo está en el mismo lugar que los archivos de datos tempdb. ¿Cuál es el tamaño y el valor de crecimiento automático que debo usar con el archivo de registro tempdb?

sql-server sql-server-2012 tempdb

— Alexandre Jobin
fuente

No hay una respuesta mágica para esto, excepto que no deshabilitaría el crecimiento automático para datos o registros tempdb a menos que desee que el sistema se detenga por completo si se necesita el crecimiento automático. Nunca deshabilitaría el crecimiento automático en ningún archivo, porque no importa qué tan bien planifiques, siempre hay situaciones anormales.

— Aaron Bertrand

@AaronBertrand: habilitar el crecimiento automático en un tempdb de tamaño completo no ayudará. Ya están en su máximo pueden estar en el disco. No hay más espacio en disco que puedan usar de todos modos. Es por eso que he desactivado el crecimiento automático.

— Alexandre Jobin

Entonces no importa si está deshabilitado o no, ¿verdad? Si se requiere un crecimiento automático, fallará de cualquier manera. Si lo deja habilitado, eso es algo menos que debe cambiar cuando se da cuenta de que tal vez necesite moverlo a una unidad más grande.

— Aaron Bertrand

PS 8 x 20> 100

— Aaron Bertrand

Dividir sus archivos no es necesariamente "una buena configuración". Depende de su configuración de hardware; que no ha suministrado

— Paul

Respuestas:

Realmente depende de la cantidad de datos que fluirán a través del registro de transacciones. Mira qué tan grande se vuelve el registro hoy. Debe configurar el registro para que tenga al menos ese tamaño cuando se inicie SQL. Para la mayoría de mis clientes, terminan con un registro de transacciones de 3-4 Gig para tempdb, que contiene solo unos pocos VLF y todo funciona bien y sin problemas.

— mrdenny
fuente

Siempre me dijeron que almacenara los archivos de registro en una matriz física / de disco separada si su hardware puede escribir simultáneamente en los datos y registrar al mismo tiempo para mejorar el rendimiento. Supongo que la limitación que generó su límite de tempdb de 20G podría definir una respuesta para el tamaño. Para el crecimiento automático, eso puede depender de las transacciones que esté ejecutando, así como del espacio libre disponible y otros recursos en el disco. Normalmente elijo 1/6 del tamaño inicial arbitrariamente.

— Robert Gannon
fuente

Aaron tiene razón al configurar TempDB depende de muchas variables, como si planea usar o no el aislamiento de instantáneas, etc. Aquí hay un documento técnico anterior de SQL 2005 de MS / TN que podría ayudarlo, ya que una buena parte todavía se aplica. Específicamente, eche un vistazo al "Espacio requerido para el registro de tempdb" para que pueda ver qué tipos de transacciones se registran en el registro de tempdb para que pueda configurar las cosas en consecuencia. Es probable que sea el tipo de cosa que tendrá que monitorear y ajustar con el tiempo.

En cuanto al crecimiento automático de tempdb, lo desactivé a regañadientes en un servidor de informes en el pasado y el comportamiento que experimenté fue que causó que la transacción de larga ejecución se anulara y retrocediera, lo que instantáneamente liberó el espacio de registro, pero eso podría depender de tipo de transacción que en mi caso fue de tipo masivo y operaciones de unión (consultas de informes mal escritas). Estoy de acuerdo con Aaron y recomendaría evitar esto si es posible, especialmente en situaciones de alto volumen de transacciones.

— Miketk
fuente