29
Abr/10
0

Calculando el tamaño de tu base de datos SQL Azure

Recojo dos sentencias que pueden ser muy útiles para conocer el tamaño total de nuestra base de datos SQL Azure (primera sentencia) y el tamaño de todas sus tablas (segunda sentencia):

 
select CONVERT(DECIMAL(5,2), ROUND(sum(reserved_page_count) * 8.0 / 1024, 2))
from sys.dm_db_partition_stats
 
GO
 
select sys.objects.name, CONVERT(DECIMAL(5,2),
ROUND(sum(reserved_page_count) * 8.0 / 1024, 2)) AS TAMAÑO
from sys.dm_db_partition_stats, sys.objects 
where sys.dm_db_partition_stats.object_id = sys.objects.object_id
group by sys.objects.name
ORDER BY TAMAÑO DESC

Los datos se presentan en MB.

vía blog de Ryan Dunn

Categoria: SQL Azure
4
Abr/10
2

Problema con entity framework y Sql Azure

EDIT: Desde el 9 de Abril de 2010 SQL Azure tiene soporte para MARS, asi que deja de existir este problema. http://blogs.msdn.com/sqlazure/default.aspx

Probando Entity Framework 4.0 en un desarrollo con SQL Azure me he encontrado un problema con la conexión. Si creas el Entity Data Model generado desde una base de datos local con el Wizard de Visual Studio, por defecto asigna una cadena de conexión de este estilo:

connectionString="metadata=res://*/Model2.csdl|res://*/Model2.ssdl|res://*/Model2.msl;provider=System.Data.SqlClient;provider connection string="Data Source=DataBaseServer;Initial Catalog=DataBaseName;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"

Si una vez que hayamos hecho nuestras pruebas, queremos apuntar la cadena de conexión a nuestra BD en SQL Azure, tenemos que indicarle al atributo MultipleActiveResultSets=False, ya que no está soportado en SQL Azure y si no lo deshabilitamos, nos fallará cada intento de conexión.

La cadena de conexión debería quedar así:

connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string="Data Source=xxxxxxxxxx.database.windows.net;Initial Catalog=DataBaseName;Persist Security Info=True;User ID=UserID;Password=Password;MultipleActiveResultSets=False"" providerName="System.Data.EntityClient"

* Si desde el Wizard de creación del Entity Data Model ya seleccionamos una conexión de SQL Azure, por defecto deja este parámetro en False.

3
Mar/10
0

Configurar el firewall de SQL Azure

Si estamos realizando un desarrollo con acceso a una base de datos de SQL Azure, tendremos que configurar una serie de parámetros para que nos funcione.

Para tener acceso a la base de datos remotamente desde nuestro entorno de desarrollo, debemos crear una nueva regla al firewall de SQL Azure – que por defecto está configurado para rechazar todas las peticiones – y habilitar el acceso a nuestra IP. Para esto vamos al portal de gestión de SQL Azure (http://sql.azure.com) y accedemos a la pestaña de Firewall Settings.

firewall settings

Añadimos una nueva regla indicándole nuestra IP, que nos facilita el mismo formulario en la parte inferior.
Si tenemos una IP variable, podemos agregar un rango de valores. Nos advierten que la nueva regla tardará unos 5 minutos en replicarse, y no mienten :D

sql azure add rule

Bien, con este cambio ya podemos acceder desde la maquina local, con el Management Studio o desde nuestra aplicación con la cadena de conexión específica, que debería ser de este tipo:

connectionString="Server=tcp:xxxxxxxxxx.database.windows.net;Database=DemoGlopez;User ID=MyUsername;Password=MyPassword;Trusted_Connection=False;Encrypt=True;"

Para verificar esto, en un rol de ASP.NET de un proyecto Cloud Service, ponemos un simple código de acceso a datos, podría servir este:

 
using (SqlConnection con = new SqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings["DemoConnectionString"].ConnectionString))
{
     using (SqlCommand com = new SqlCommand("select id, nombre from Demo", con))
     {
          con.Open();
          using (SqlDataReader reader = com.ExecuteReader())
          {
               while (reader.Read())
               {
                    Response.Write(reader["id"].ToString());
                    Response.Write(reader["nombre"].ToString());
                    Response.Write("<br/>");
               }
          }
     }
}

Ejecutamos y vemos que todo funciona bien (debemos crear una tabla en nuestra base de datos y modificar la consulta del command de este ejemplo para adaptarlo a nuestro entorno).

Ahora hacemos un Deploy de esta simple aplicación y veremos que falla (tendremos que deshabilitar los customErrors para que se nos muestre el mensaje de error).

Parece que seguimos teniendo problemas de acceso a SQL Azure, asi que volvemos al panel de gestión y hacemos un Test Connectivity (hay que tener seleccionada la base de datos), comprobamos que la conexión falla desde la IP del servidor dónde está alojada la aplicación.

Volvemos al Firewall Settings y marcamos el check de Allow Microsoft Services access to this server. Repetimos el Test Connectivity y ahora funciona.

test ok

Bien, volvemos a ejecutar nuestra aplicación, pero aún sigue fallando!

Cannot open server 'xxxxxxxxxx' requested by the login. Client with IP address '65.52.138.89' is not allowed to access the server.

Cannot open server 'xxxxxxxxxx' requested by the login. Client with IP address '65.52.138.89' is not allowed to access the server.

Esto es un problema de la plataforma, debería funcionarnos, pero parece que hay un fallo con los rangos de IP que tienen permitidos internamente (info: http://tinyurl.com/yf46fxk). Así que nos toca añadir la IP del servidor como regla en nuestro firewall de SQL Azure hasta que esto se solucione.

Debería quedarnos una configuración de firewall así:

sql azure firewall 2

Y ahora nuestra aplicación funcionará correctamente.

Existe la posibilidad de administrar las reglas del firewall mediante procedures de la base de datos si no queremos utilizar el portal de gestión. Accedemos a la base de datos master de nuestro SQL Azure y utilizamos las siguientes sentencias:

-- Reglas existentes
SELECT * FROM sys.firewall_rules
 
-- Añadir nueva regla de firewall
exec sp_set_firewall_rule N'DemoTSQL','0.1.1.0','0.1.1.255'
 
--Modificar una regla de firewall
exec sp_set_firewall_rule N'DemoTSQL','0.1.1.1','0.1.1.255'
 
--Eliminar una regla de firewall
exec sp_delete_firewall_rule N'DemoTSQL'
18
Feb/10
0

Cambiar la versión de la base de datos [SQL Azure]

Ayer publicaron en el SQL Azure Team Blog la noticia de la primera actualización al servicio de SQL Azure, esta actualización consiste en una serie de mejoras recogidas del feedback de la comunidad, toda la info.

Me parece interesante la posibilidad de cambiar la edición de la base de datos (Web edition – Business edition) con un simple comando:

ALTER DATABASE database_name
{
    MODIFY (MAXSIZE = {1 | 10} GB)
}
15
Ene/10
1

Migrar base de datos a SQL Azure

logo sql azure

Siguiendo con el tema de la nube, hoy toca comentar alguna cosa sobre SQL Azure.

Vuelvo a enlazar al blog de Gisela Torres como referencia a como configurar y conectarse con SQL Server 2008 R2 November CTP, lo de la versión no es que me haga ilusión, es que es necesario para disfrutar de todas las características.

Sql Azure con Management Studio

Cambios en SQL Azure

A mí me gustaría ampliar la información con un ejemplo de migrar una base de datos existente a SQL Azure.

Accedemos con el management studio a nuestra instancia local, seleccionamos la base de datos que queremos migrar a SQL Azure y vamos a la opción de Tasks -> Generate Scripts

generateScript

Nos salta un wizard, pasamos la introducción y en la siguiente pantalla nos da la opción de seleccionar que objetos de BD queremos incluir en el script, podemos marcar todos o seleccionar manualmente las tablas, vistas, procedures, etc…

selectObjects

Siguiente pantalla, seleccionamos dónde queremos guardar el resultado y nos vamos a la opción Advance.

scriptingOptions

Aquí lo más importante es marcar la opción Script for the database engine type a SQL Azure Database.

database type

Este cambio nos deshabilitará varias opciones que no están soportadas en SQL Azure.

Marcamos también la propiedad Types of data to script con a Schema and Data para que genere todos los INSERTS de los datos que contiene la BD y no sólo la estructura.

Con esto, el wizard ya tiene suficiente información, le damos next y nos genera nuestro fichero .sql que podemos utilizar para ejecutar en la BD de SQL Azure.

Recordad crear la BD desde la plataforma de SQL Azure, configurad el firewall!, al conectaros a SSMS especificad la BD a la que os queréis conectar y una vez ejecutado el script, tendremos la migración completa. Toda la información sobre cómo hacer lo descrito en este último párrafo con más detalles en los links mencionados al principio del post.

Better Tag Cloud