Relacional (no tan) Básico. Crear una BB

Relacional (no tan) Básico. Crear una BB

Este post es realmente muy básico, aburrido para el 99% de los que lleven 2 semanas con SQL Server, pero , todos hemos pasado antes o despues por la necesidad de empezar de alguna forma,  con errores que ahora mirando hacia atrás nos parecen tontísimos, pero en los que caimos irremediablemente, de ahí, que escriba esto, me pareció que la pregunta de un amigo en el foro de noticias merecía esta reflexión.

Primero vamos a crear una base de datos, de 2 formas, con SQL Server Management Studio ambas.

1.- Creando la bbdd a través del tutorial

pulsando  botón derecho sobre la  carpeta bases de datos aparece el siguiente menú. lo que haremos será pulsar en nueva base de datos para crear una. Para los que necesitan conocimientos no tan básicos, haré algunos comentarios sobre lo que significan las opciones de creación.
newdb

createdb

Si nos fijamos al escribir demo ha escrito automaticamente los dos nombres lógicos que necesitamos, uno para la base de datos y otro para el fichero de transacciones.

¿porque hacen falta dos ficheros?. En el fichero de datos, se guardan las páginas con la información de las tablas, la agrupación fisica de esas páginas, si bien es interesante, está muy lejos del alcance de este artículo.

Los datos solo se guardan en estas páginas una vez que la transacción que los creo/modificó ha sido validada ( y además pasan otra serie de procesos que no vienen al caso). Entre tanto todas las operaciones se guardarán en el log de transacciones. Desde el log de transacciones los cambios validados irán a las páginas en memoria y de ahí en un proceso de baja prioridad se llevarán al fichero de datos.

¿porque tanta vuelta? os preguntareis algunos, para garantizar el ACID, atomicidad, consistencia, aislamiento y durabilidad. Por ejemplo si se fuese la luz cualquier transaccion confirmada ya estaría escrita en el log, de forma que aunque no esté en las páginas de datos, se puede volver a aplicar (de hecho es una de las cosas que se hacen al arrancar el sql server).

 

Por eso,

1.- NO se puede borrar el fichero de Log.

2.- Para el fichero de log los discos cuanto más rápidos mejor para escritura (nada de raid 5 ni cosas así)

3.- para el fichero de datos, no es tan importante el raid, (se lee pero la escritura es asincrona)

Ahora simplemente pulsando ok podríamos crear la base de datos, pero donde está la ruta de los ficheros?…. queda a la derecha en esta pantalla en la barra de desplazamiento.

Más consideraciones importantes, 1.- tamaño de los ficheros. 3 mb y 1 mb….  Si tenemos una estimación por aproximada que sea del tamaño de la base de datos…¡pongámoslo ahora!, si no lo hacemos, el fichero irá creciendo si lo dejamos por defecto de  1 mb en 1 mb el de datos?????? y  en un 10% el de log. Esto provocará un fichero muy particionado!! lo que redundará para mal en el rendimiento de mis lecturas.  así pues :

1.- Crear el fichero de datos con el tamaño suficiente para albergar la estimación inicial de tamaño,

2.- Crear el fichero de log, con al menos entre el 10% y el 30% del tamaño del fichero de datos.

3.- Ajustar el tamaño de crecimiento e intentar prevenir que crezca solo.

Hay una pestaña más , la de opciónes, veamos algunas de ellas
opciones creacionCollation. Parece que es una opción sin importancia, pero tiene mucha, indica el collation por defecto de la base de datos, es decir con el que se crearán por defecto los objetos. El colation marca la forma de ordenar strings, y en dos collations distintos pueden estar ordenados de forma diferente. me explico en el español tradicional la CH está despues de la C, así pues cueva está antes que choza, sin embargo en el español moderno la ch va despues de cg (aunque no haya ninguna palabra cg) así pues choza va antes que cueva. y esto puede tener muchas implicaciones, comparando strings.

Modo de recuperación. ¡Esto da para un post por si mismo!. En algunas ediciones por defecto pone full en otras por defecto es single. Como norma muy básica, seguid este consejo. Si tu backups lo vas a hacer diario y es suficiente para ti (en el peor de los casos perderías un dia de datos) pon el modo de recuperación simple. eso hará que tu log no crezca mas de lo que necesita estrictamente, y da igual si ese tamaño es el mismo que tu base de datos, eso es otra cuestión, pero si siempre ha estado en ese modo.. ese es el tamaño correcto. (notad que estoy obviando muchos conceptos porque no merece la pena liar al personal que está comenzando)

Si tus datos te importan lo suficiente como para que no te puedas permitir un dia de perdida de datos, entonces, usa el modo full, programa tus copias de seguridad, no solo de la base de datos sino del log de transacciones (por ejemplo, 1 vez a la semana copia completa, 1 vez cada noche diferencial, cada 2 horas del log) Ante un fallo deberás recuperar primero el backup completo del domingo (por ejemplo), el backup diferencial de la noche anterior, todos los logs que hayan pasado desde ese momento.

Nivel de compatibilidad: Algunas veces necesitamos en servers nuevos usar bases de datos que estan probadas solo en servers de versiones anteriores, aquí puedes bajar de vesión, aunque no resuelve el 100% de los problemas si que es una gran ayuda.

Containtment type: Este concepto es bastante avanzado y prefiero dejar solo el link a donde lo explica mejor. Queda fuera de lo básico de este post

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *