SQL Server Express: Hacer backups programados y con retención

Post original en JASoft.org: http://www.jasoft.org/Blog/post/SQL-Server-Express-Hacer-backups-programados-y-con-retencion.aspx

SQL Server Express es una excelente opción para trabajar con SQL Server en proyectos pequeños y medianos sin tener que pagar licencias. Es una versión gratuita pero totalmente funcional del gestor de base de datos relacionales de Microsoft. A cambio tiene ciertas limitaciones. Por ejemplo, no permite utilizar más de 1 GB de RAM por instancia para caché de datos en memoria y el tamaño de cada base de datos gestionada no puede superar los 10 GB (que es un tamaño considerable para aplicaciones normales). Carece de otras características de alta disponibilidad y replicación, pero ofrece toda la funcionalidad habitual (incluyendo integración de datos y reporting) y las herramientas de administración. Aquí podrás encontrar una comparativa de todas las ediciones de SQL Server.

Una de las cosas que no están disponibles con SQL Server es el Agente SQL. El agente nos permite programar tareas que se ejecutarán sobre las bases de datos cuando nosotros queramos. Esta carencia dificulta un poco, por ejemplo, la realización de copias de seguridad, especialmente si queremos mantener un periodo de retención concreto (por ejemplo, las copias de los últimos 7 días).

Por suerte esta carencia en concreto es muy fácil de solucionar, y en este artículo voy a explicar cómo lograrlo de manera sencilla.

Lo primero que tenemos que saber es que todas las ediciones de SQL Server incluyen una utilidad de línea de comandos que nos permite ejecutar instrucciones T-SQL arbitrarias contra cualquier base de datos. Se trata de SQLCMD.exe, generalmente ubicada en esta ruta:

"C:Program FilesMicrosoft SQL Server110ToolsBinnSQLCMD.EXE"

en el caso de SQL Server 2012 Express.

Esta utilidad tiene muchos parámetros que nos permiten controlar su forma de trabajar. Dos que nos interesan especialmente son:

  • -S: nos permite especificar contra qué servidor/instancia se ejecutarán las sentencias T-SQL.
  • -i: permite especificar una ruta a un archivo (normalmente con extensión .sql) que contiene las instrucciones T-SQL que queremos ejecutar contra el servidor. Así podemos incluir scripts más complejos que una simple línea.

Sabiendo la existencia de esta herramienta, conseguir backups gracias a ella es muy sencillo.

1. Construir las instrucciones T-SQL base para hacer el backup

Lo primero es conseguir las comandos T-SQl para hacer un backup. Lo más sencillo es usar las herramientas integradas en el Microsoft SQL Server Management Studio (MSSMS). Ábrelo, busca la base de datos que te interesa copiar en el explorador de objetos y pulsa el botón derecho del ratón sobre ella. En el menú contextual elige la opción de "Tareas·backup…":

SQLServerExpressBackups1

Esto abre una nueva ventana desde la que podemos definir cómo queremos realizar el backup:

SQLServerExpressBackups2

Desde esta ventana elegimos la base de datos a copiar y la ruta en la que queremos guardar dicha copia de seguridad (normalmente le damos como extensión al archivo .bak, pero puede ser cualquiera o incluso no tener extensión).

Además si pulsamos en la página "Opciones" en el lateral podemos configurar algunas cosas más, como por ejemplo (muy recomendable) que se verifique el backup al terminar de hacerlo:

SQLServerExpressBackups3

OJO: la edición Express no soporta la compresión de los backups, así que si seleccionamos esta opción en la lista desplegable de la parte inferior de la figura anterior, se producirá un error al realizar el backup.

Una vez que tengamos seleccionadas todas las opciones que necesitemos, podemos obtener el código necesario para realizar el backup usando el botón "Script" de la parte superior de la ventana anterior. Por defecto nos copiará el código generado a una ventana del MSSMS, así:

SQLServerExpressBackups4

Con esto obtendríamos una base de datos que se sobrescribiría en cada nueva copia, Lo interesante de las copias de seguridad es tener copias con una retención de varios días, para poder comprobar datos anteriores o restaurar los datos a un estado anterior.

2. Retocar el script para darle una semana de retención

Supongamos que queremos hacer una copia de seguridad diaria y que queremos mantener las copias durante 7 días, de modo que podamos recuperar los datos desde cualquier copia de seguridad de la última semana. Para ello vamos a retocar el script anterior de modo que cada día le cambie el nombre al archivo de copia de seguridad. Para ello vamos a declarar una variable que servirá para guardar la ruta y el nombre del archivo de copia de seguridad, cambiándolo en función, en este caso, del día de la semana en el que nos encontremos. En este caso sería así:

DECLARE @dest nvarchar(255)

SET @dest = 'C:BackupsBBDDSELF_' + CAST(DATEPART(weekday, GETDATE()) AS nvarchar(1)) + '.bak'

La función DATEPART con el valor weekday para el primer parámetro nos devuelve un número para cada día de la semana, empezando por el domingo (un 1)  hasta el sábado (un 7). Como le pasamos la fecha actual (GETDATE) como segundo parámetro lo que obtendremos en la variable @dest es cada día un nombre diferente para la base de datos, añadiéndole el número de día de la semana para obtener nombres estilo: SELF_1.bak, SELF_2.bak, SELF_3.bak y así sucesivamente.

En el script generado por el MSSMS bastará ahora por sustituir la ruta por el nombre de esta variable y ya lo tendremos listo (ojo: hay que susituirlo en dos sitios: en el backup y en la verificación del backup en la parte inferior).

Dado que en caso de que un archivo exista de backup se sobrescribirá, en la práctica con este script lo que conseguimos es que siempre haya 7 copias como máximo en el histórico.

3. Crear un bat para realizar el backup

Ahora que ya tenemos el código necesario para crear las copias de seguridad lo que debemos hacer es crear un archivo .bat que nos permita ejecutar este código T-SQL cuando queramos. Para ello usaremos SQLCMD.EXE, escribiendo esta instrucción:

"C:Program FilesMicrosoft SQL Server110ToolsBinnSQLCMD.EXE" -S SERVIDORINSTANCIA -i "C:BackupsBBDDBackupSELF.sql" >> log.txt

Debemos sustituir SERVIDORINSTANCIA por el nombre de nuestro servidor y la instancia de SQL Server sobre la que queremos trabajar. En el parámetro -i debemos indicar la ruta al archivo .sql con las instrucciones para la copia de seguridad que acabamos de crear.

La última instrucción ">> log.txt" nos permite guardar el resultado de la ejecución en un archivo de texto que podemos consultar para ver cuándo se ha realizado cada copia, cuánto ha tardado y cualquier otro mensaje que se derive de la ejecución del script. E spor eso que me gusta colocarle al principio del script una instrucción más como esta:

PRINT CAST(GETDATE() AS nvarchar) + ' - COPIA DE SEGURIDAD INICIADA AL ARCHIVO: ' + @dest

De este modo aparecerá en el archivo Log.txt un mensaje al principio de cada copia de seguridad indicando la fecha de creación y el nombre del archivo. Podemos incluir del mismo modo cualquier otra información que consideremos relevante.

4. Programar la tarea

Ahora que ya tenemos un script para hacer la copia de seguridad, y además hemos creado un .bat para ejecutarlo, lo único que nos falta es crear una tarea programada para poder lanzarla con la periodicidad que nos convenga (en principio cada día).

Para ello abrimos el administrador de tareas programadas del sistema y creamos una nueva tarea. Lo único que tendremos que hacer es indicar que queremos ejecutar el archivo .bat del paso anterior así como a qué hora del día lo vamos a hacer:

SQLServerExpressBackups5

 

Con esto habremos conseguido que todos los días a las 2:00 de la mañana se realice una copia de seguridad de la base de datos, con una retención de 7 días:

SQLServerExpressBackups6

Cada uno de esos archivos se corresponde con la copia de seguridad del domingo (1), lunes (2), martes 83), etc…

Si quisiésemos un periodo de retención de un mes, por ejemplo, sería tan fácil como cambiar el parámetro de DATEPART por "day" de modo que se pusiera el número de día del mes. Podemos jugar con los distintos valores del primer parámetro de DATEPART para conseguir otros periodos, como por ejemplo, si hacemos más de una copia al día, añadirle la hora de modo que tengamos más de un archivo diario.

¡Espero que te resulte útil!

Si quieres aprender a programar bien SQL Server, no te pierdas estos dos cursos de campusMVP (en inglés):

del MVP italiano Alessandro Alpi. Aprenderás a sacarle todo el partido a SQL Server ya optimizar tus aplicaciones.

Cómo extender/aumentar la partición del sistema en Windows Server

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Como-extenderaumentar-la-particion-del-sistema-en-Windows-Server.aspx

Hoy he tenido que redimensionar el disco de sistema de un servidor virtual y me ha dado un poco más de trabajo del que preveía, por lo que os cuento aquí como lo he solucionado por si le sirve de ayuda a alguien.

Resulta que en una máquina virtual necesitaba duplicar el tamaño del disco principal virtualizado (con VMWare), así que simplemente desde la herramienta de administración le aumenté el espacio. Lo que yo esperaba ingenuamente era obtener el disco con el doble d eespacio ya disponible en C: pero por lógica esto no podía ser así. Lo que obtienes en realidad es una partición del disco con el espacio nuevo sin asignar, así:

RedimensionarDisco_1

Esto es lo que se ve desde el gestor de almacenamiento al que llegamos desde Inicio y luego pulsando en “Administrar” en el menú contextual del equipo:

RedimensionarDisco_2

Como vemos en la primera imagen, a la derecha y justo a continuación de la unidad actual, tenemos el espacio sin utilizar, por lo que cabría esperar que pulsando sobre C: con el botón derecho y eligiendo la opción “Extender” extenderíamos la unidad a la zona contigua disponible. Lo cierto es que no funciona y obtenemos un mensaje diciéndonos que ya tenemos el tamaño máximo ya que el disco no se ha podido convertir en dinámico o bien no hay espacio libre contiguo.

¿Qué podemos hacer para solucionarlo?

Muy sencillo. Abre una línea de comandos como administrador (inicio y botón derecho sobre “Ejecutar como administrador”):

RedimensionarDisco_3

En la línea de comandos vamos a lanzar la utilidad para gestionar particiones de disco que tiene el sistema, para lo cual debemos escribir:

diskpart

En la línea de comandos de la herramienta vamos a listar todas las particiones disponibles y en funcionamiento, escribiendo:

list volume

Se nos mostrará una lista similar a la que se ve en esta figura:

RedimensionarDisco_4

En ésta identificaremos cuál es nuestra unidad que queremos extender (en este caso el volumen 2), y a continuación la seleccionaremos con la herramienta escribiendo:

select volume 2

Ahora con él seleccionado lo único que tenemos quehacer es extenderlo para que ocupe todo el espacio contiguo disponible, para lo cual basta con escribir:

extend

Tras esto obtendremos un mensaje de confirmación y saldremos de la herramienta escribiendo “exit” (y nuevamente “exit” para salir de la línea de comandos).

Ahora si volvemos a abrir el gestor de discos veremos que nuestra unidad C: tiene el doble de tamaño y ya no queda espacio sin utilizar en el disco. Justo lo que queríamos 🙂

¡Espero que te resulte útil!

Cómo funcionan las cookies y por qué es importante saberlo

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Como-funcionan-las-cookies-y-porque-es-importante-saberlo.aspx

MonstruoGalletasDe todos los personajes de Barrio Sésamo, cuando era pequeño los que más me gustaban eran el Conde Draco (que contaba todo lo que se le ponía por delante) y sin duda Triki, el monstruo de las galletas. Triki se pasaba el día comiendo galletas de forma desmesurada, rompiéndolas en mil pedazos mientras lo hacía. Creo que se le salían de la boca más que las que era capaz de procesar. Era un personaje muy divertido.

Me he acordado de él hoy al pensar en escribir este post, ya que a algunos programadores web les pasa lo mismo que a Triki: procesan las cookies pero le sirven de bien poco o le hacen un flaco favor.

Más o menos todos los programadores web tienen una idea aproximada de qué son las cookies en un navegador web y para qué se utilizan. Pero hay algún concepto básico que todavía no es bien conocido y que me parece interesante aclarar, así que me he decidido a escribir un pequeño artículo sobre las cookies, cómo se usan y cómo funcionan por debajo.

Las cookies, como seguramente sabrás, son pares clave/valor que se almacenan es un archivo de texto plano en el lado cliente (en el navegador) y que guardan temporalmente información que es necesaria para nuestra aplicación. Para crearlas tenemos dos opciones:

  • Generarlas desde el lado servidor: en este caso se emplean métodos propios del lenguaje de servidor que estamos utilizando (por ejemplo en ASP.NET usando la colección HttpResponse.Cookies). Lo que ocurre realmente por debajo es que estamos usando cabeceras de tipo Set-Cookie para indicar al navegador que debe crear una nueva entrada en la cookie del dominio actual, y es éste el que se encarga de hacerlo.
  • Generarlas desde el lado cliente: usando JavaScript, de manera muy similar. En este caso se instruye directamente al navegador para crear el par clave/valor y almacenarlo en el archivo de cookies del dominio actual de la página. No se genera tráfico alguno con el servidor, siendo todo interacción de lado cliente.

El navegador almacena las cookies atándolas al dominio que las genera, y por cuestiones de privacidad no es posible leer desde un dominio las cookies de otro dominio.

Nota: Como sabrás, actualmente existen leyes en muchos países (y especialmente en la UE) que limitan el uso de las cookies para tratar de preservar la privacidad, y obligan a las páginas a avisar de que se están utilizando con fines de seguimiento. Pero, si son simples archivos de texto y si solo se pueden leer desde tu propio dominio ¿por qué tanto alarmismo por las cookies?.  El motivo es que muchos proveedores de publicidad (Google y sus empresas satélite sobre todo) trabajan en connivencia con las páginas en las que insertan publicidad para incluir un pequeño recurso embebido en todas ellas (llamado “beacon”) de manera que guardan cookies atadas siempre al mismo dominio. De ese modo, dado el poder que tienen, están presentes por toda Internet y por lo tanto van siguiendo tu pista en cada página que visitas. Dado que todos los “beacons” están en el mismo dominio pueden leerlo en todas las páginas y saber cuáles has visitado. Dependiendo del nivel de integración con el portal o medio de comunicación que visites pueden saber exactamente qué páginas has visitado, qué productos te interesan, y luego te venden publicidad mucho más enfocada. Así que sí: son peligrosas para tu privacidad, pero no porque te puedan introducir virus o sean peligrosas por si mismas, sino por el enorme tamaño y poder que tienen los señores de la publicidad on-line y el nivel de connivencia con los grandes medios y las grandes tiendas on-line. Si no me crees monitoriza la descarga de la página principal de un periódico cualquiera y alucinarás con la cantidad de tráfico “paralelo” que se genera sin que el usuario normal lo advierta 🙁

Según la RFC 2965 que regula entre otras cosas a las cookies, éstas podrían teóricamente tener un tamaño cualquiera. Sin embargo todos los navegadores imponen un tamaño máximo que pueden ocupar y a partir del cual “se niegan” a almacenar nada más. Este tamaño varía de un navegador a otro, e incluso entre una versión y otra. También existen límites en lo que se refiere al número de cookies (es decir, pares clave/valor) que podemos almacenar por cada dominio.

Para estar dentro de la seguridad y no “pillarnos los dedos” no deberíamos superar las 4 Kb de tamaño y las 50 cookies por dominio. En cualquier caso llegar siquiera cerca de estos límites es algo que desaconsejo vehementemente por lo que veremos a continuación….

Otra cuestión interesante son las cookies de sesión. Éstas no se almacenan en ningún lado ya que sólo existen mientras dura la sesión abierta con el servidor web. De esta manera si cerramos el navegador, se pierden para siempre ya que no están almacenadas físicamente en ningún archivo, y sólo las mantiene en memoria el navegador mientras lo tenemos abierto.

¿Cómo se leen las cookies y por qué debería importarnos?

A la hora de leer las cookies tenemos, nuevamente, dos posibilidades:

  • Leerlas en el lado cliente: para lo cual, al igual que antes, se utiliza JavaScript. El mayor problema que tiene esto es que, por defecto, las cookies establecidas desde el servidor (la manera más habitual) se protegen con el modificador HttpOnly, para evitar precisamente que se puedan leer por JavaScript y por lo tanto se puedan explotar para robar sesiones. En este post lo explico con detalle.
  • Leerlas en el lado servidor: en este caso se utiliza algún método del lenguaje de servidor que estemos empleando. Por ejemplo, con ASP.NET se utiliza la colección HttpRequest.Cookies. Esta es la manera habitual de leer las cookies.

Dado que la manera común de leer las cookies es en el servidor -que es donde además son más útiles- hay que tener cuidado con qué almacenamos y para qué. El motivo es que las cookies que tengamos almacenadas en el cliente se envían en cada una de las peticiones que el navegador hacer al servidor.

Vamos a verlo… Por ejemplo, he capturado con Fiddler el contenido de una cookie enviada a Doubleclick (agencia de publicidad online perteneciente a Google y quizá la mayor del mundo) y que se envía en cada petición a ese dominio (esta está sacada de la página principal de El País):

CookieDoubleClick_1
Click para aumentar

Si lo vemos con más detalle:

CookieDoubleClick_2

Vemos que todas las cookies van en la petición, y que éstas no son más que un archivo de texto con una colección de parejas de clave/valor separadas por puntos y comas. Así, por ejemplo vemos que hay una clave llamada “id” con un valor (que probablemente me identifique de manera única en toda Internet ante esta empresa de publicidad). Pues esto se enviará por parte del navegador en todas las peticiones que se hagan al dominio pubads.g.doubleclick.net, que es el dominio que utilizan.

Fíjate bien en las implicaciones de que la información completa de nuestras cookies vaya incluida en las cabeceras de todas y cada una de las conexiones que lancemos a nuestro dominio desde el navegador, y el hecho de que esto será así no sólo para las páginas sino también para las imágenes, las hojas de estilo, los scripts y cualquier otro archivo que se solicite al servidor.

Por ello, si tenemos una cookie que ocupe, por ejemplo, 2 Kb, y una página que descargue 4 scripts, 12 imágenes y 3 hojas de estilo, estamos añadiendo un peso de (4 scripts + 12 imágenes + 3 css + 1 página)*2Kb = 40 Kb de manera innecesaria a esa página. Eso significa más tráfico consumido innecesariamente y un cierto retardo en la descarga de la página, que si es una conexión lenta puede ser significativo (medio segundo o más), y si es una conexión 3G en la que se pague por consumo puede aumentar la tarifa del usuario.

Aprende ASP.NET rápido, online, paso a paso, y ¡tutelado por mi! 🙂
más información…

Conclusiones

Las cookies pueden ser muy útiles si las empleamos sabiamente, pero pueden ser un engorro innecesario y aumentar a lo tonto la cantidad de tráfico que existe entre el navegador y nuestro servidor. Así que:

  • Utiliza cookies solamente cuando sea necesario.
  • Emplea la menor cantidad de información posible, incluso si tienes que codificar de alguna manera los datos para que ocupen menos. Cuanto menor sea el tamaño de las cookies menos sobrecarga innecesaria añadirás a la conexión y más rápido cargarán las páginas y sus recursos. En cualquier caso procura que nunca sobrepasen unos pocos bytes.
  • Ten cuidado con el tamaño de las cookies que utilizas y de la cantidad de ellas que fijas, ya que existen límites en los navegadores.
  • Ojo con cookies asignadas a dominios de primer nivel solo y que puedan aparecer también en subdominios: si lo haces sin darte cuenta puedes estar recibiendo cookies innecesariamente incluso en subdominios del dominio principal, sin que las estés usando para nada.
  • Ponles fechas de caducidad apropiadas y no las dejes simplemente para que caduquen dentro de 120 años si no es necesario guardarlas para siempre. Una vez que una cookie caduca el navegador la elimina y ya no se enviará en las siguientes peticiones, así que una menos de la que preocuparse.

¡Espero que te sea útil!