{"id":854,"date":"2020-08-04T09:14:20","date_gmt":"2020-08-04T13:14:20","guid":{"rendered":"https:\/\/www.aynitech.com\/tu-base-de-datos-esta-creciendo-demasiado-parte-ii\/"},"modified":"2020-08-04T09:14:20","modified_gmt":"2020-08-04T13:14:20","slug":"tu-base-de-datos-esta-creciendo-demasiado-parte-ii","status":"publish","type":"post","link":"https:\/\/www.aynitech.com\/es\/tu-base-de-datos-esta-creciendo-demasiado-parte-ii\/","title":{"rendered":"\u00bfTu Base de Datos est\u00e1 creciendo demasiado? Parte II"},"content":{"rendered":"

Ampliando el art\u00edculo anterior un problema bastante com\u00fan con el que nos encontramos d\u00eda a d\u00eda es el limitado espacio de almacenamiento en disco. Ya sea por temas de presupuesto o de infraestructura, no siempre es posible incrementar el espacio de almacenamiento de nuestros servidores de una manera r\u00e1pida, por lo que la implementaci\u00f3n de buenas pr\u00e1cticas y acciones preventivas pueden ahorrarnos el downtime de una base de datos por falta de espacio.<\/p>\n

Aqu\u00ed te dejamos tres sencillas recomendaciones para poder controlar el crecimiento r\u00e1pido de tus archivos log (*.ldf) en SQL Server:<\/p>\n

a. Escoge el recovery model adecuado:<\/h3>\n

En SQL Server, una base de datos puede tener uno de los tres recovery model (modelos de recuperaci\u00f3n) existentes: Simple, Bulk-Logged y Full. Esta opci\u00f3n determina con que precisi\u00f3n se puede restaurar una base de datos. Por ejemplo: tener un modelo de recuperaci\u00f3n Full es ideal para ambientes de producci\u00f3n cr\u00edticos porque nos permite realizar copias de seguridad del log de transacciones, (los cuales podemos utilizar despu\u00e9s para restaurar la base de datos a un punto especifico en el tiempo). Aqu\u00ed se debe tener en cuenta que, si escogemos este modelo de recuperaci\u00f3n, debemos contar con un proceso automatizado de respaldo del log de transacciones, de lo contrario este crecer\u00e1 hasta ocupar todo el espacio existente.<\/p>\n

Por otro lado, si no es necesario que la base de datos tenga un plan de recuperaci\u00f3n de desastres (como en ambientes de pruebas o desarrollo), se puede configurar con un modelo de recuperaci\u00f3n Simple, el cual registrar\u00e1 un m\u00ednimo de las transacciones ocurridas en el log y tambi\u00e9n nos permitir\u00e1 recuperar el espacio ocupado por el mismo, haciendo un shrink al archivo log.<\/p>\n

b. Comprimir el archivo log:<\/h3>\n

En algunos casos, el log de transacciones se podr\u00e1 comprimir debido a que no todo el espacio asignado en disco esta siendo utilizado. Para verificar si podemos liberar espacio del log de transacciones podemos ejecutar el siguiente comando en la instancia SQL: DBCC SQLPERF(LOGSPACE). N\u00f3tese aqu\u00ed la columna \u2018Log Space Used (%)\u2019, a menor porcentaje mayor es el espacio que podemos liberar. Si este es el caso, podemos aplicar un \u2018Shrink\u2019 (Reducci\u00f3n) sobre el archivo log respectivo.<\/p>\n

c. Mover de ubicaci\u00f3n los archivos log:<\/h3>\n

De acuerdo con las mejores pr\u00e1cticas de SQL Server, se recomienda almacenar los archivos de datos (.mdf) y los archivos de logs (.ldf) en discos separados. De esta manera podemos evitar que los problemas de crecimiento inesperado de los archivos log impacten en el espacio asignado para los archivos de datos. De no ser el caso, recomendamos que se reubiquen los archivos de datos y logs respectivamente. Esto requerir\u00e1 de un reinicio del servicio de SQL Server para que los cambios surtan efecto.<\/p>\n

En ambientes donde contamos con suficientes discos de almacenamiento, es recomendable tener un disco para cada base de datos y para cada tipo de archivo de datos (.mdf y .ldf). De esta manera, podemos aislar los problemas de espacio de una base de datos y prevenir que esos problemas afecten a otras bases de datos dentro de la misma instancia\/servidor.<\/p>\n

\"\"<\/figure>\n","protected":false},"excerpt":{"rendered":"

Ampliando el art\u00edculo anterior un problema bastante com\u00fan con el que nos encontramos d\u00eda a d\u00eda es el limitado espacio de almacenamiento en disco.<\/p>\n","protected":false},"author":0,"featured_media":852,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[62],"class_list":["post-854","post","type-post","status-publish","has-post-thumbnail","hentry","category-optimizacion-de-procesos"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/posts\/854","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/comments?post=854"}],"version-history":[{"count":0,"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/posts\/854\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/media\/852"}],"wp:attachment":[{"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/media?parent=854"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aynitech.com\/es\/wp-json\/wp\/v2\/categories?post=854"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}