Migrando a SQL Azure (I)

En varios post hemos os he hablado ya sobre SQL Azure.

El objetivo de este post es ver qué opciones tenemos para migrar una base de datos que tengamos en SQL Server a SQL Azure.

Como ya os comenté, desde mi punto de vista la forma más adecuada de trabajar en tiempo de desarrollo es trabajar con un servidor de base de datos que tengáis vosotros, que no esté en la nube. Entre otras, las razones son el coste que esto supondría, ya que habría que pagar el “SQL Azure de desarrollo” y el hecho de que hay mejores herramientas para trabajar contra SQL Server y somos más productivos.

Pero luego cómo pasamos nuestra base de datos a la nube? Pues la verdad es que el proceso es bastante sencillo. En este post os hablaré de dos alternativas.

La primera. A partir de la base de datos que tenemos en nuestras instalaciones, generamos un script de datos que contenga todos los pasos necesarios para crear la base de datos en Azure.

Creamos el script, nos conectamos a SQL Azure con el Management Studio y lo lanzamos con una base de datos de Azure.

Lo único que tenemos que tener en cuenta a la hora de generar el script de datos, es que tenemos que indicarle que queremos que genere un script de datos compatible con SQL Azure!

Os pongo unos pantallazos del proceso para generar un script de datos:

image

image

image

image

Y con esto ya tenemos el script.

/****** Object:  Table [dbo].[SampleTable]    Script Date: 06/20/2010 20:10:51 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[SampleTable](
    [MyRowID] [int] NOT NULL,
PRIMARY KEY CLUSTERED 
(
    [MyRowID] ASC
)WITH (STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF)
)
GO

 

 

 

Ahora nos conectamos a nuestra base de datos de Azure como veíamos en el post anterior y ya está, tablas creadas!!

Y recordad, a nivel de aplicación “sólo” tendremos que cambiar la cadena de conexión para que apunte a la nueva base de datos. La aplicación puede estar o no estar en la nube pero ya sabéis que el tráfico si es desde fuera se paga 🙂

En el próximo post os explicaré otra manera de migrar a SQL Azure, que a mí personalmente me gusta más!…en cuanto pueda lo publico.

Welcome IIS Express

Post corto, pero creo interesante comentar este post de ScottGu’s dónde presenta IIS Express, un producto que intentará coger lo bueno de los das opciones que teníamos hasta ahora para probar nuestras aplicaciones web; ASP.NET Development Server e IIS Web Server.

En el post se comentan los pros y contras de cada alternativa y lo que aportará este nuestro producto.

Podéis leer el post completo aquí. Muy interesante!

El collation de SQL Azure

En una de las sesiones que hecho sobre la plataforma Windows Azure, uno de los asistentes me preguntaba sobre los collations disponibles en SQL Azure.

La respuesta es bastante sencilla.

El collation del servidor es siempre SQL_Latin1_General_CP1_CI_AS.

El collation de todas las base de datos que creamos es siempre SQL_Latin1_General_CP1_CI_AS.

Si queréis comprarlo, no tenéis más que conectaros una base de datos SQL Azure y lanzar estos dos comandos:

SELECT SERVERPROPERTY('Collation')
SELECT DATABASEPROPERTYEX('GeeksDDBB', 'Collation')

¿Podemos cambiarlos? NO.

A nivel de servidor o de base de datos no podemos cambiarlo, pero sí podríamos cambiar a nivel de columna. Al definir una columna, podemos establecer un collation diferente al de la base de datos.

Campo    nvarchar(20) COLLATE SQL_Latin1_General_CP1_CI_AS,

Las expresiones usando un collation diferente también está permitidas, como por ejemplo…

SELECT LastName FROM Person.Person
ORDER BY LastName
COLLATE Traditional_Spanish_ci_ai ASC;

Nuevas capacidades para SQL Azure ya disponibles!

Desde ayer, día 25 de junio, ya tenemos disponible una nueva versión de SQL Azure con nuevas características!

En primer lugar, lo ya comentado del aumento de tamaño máximo de una base de datos. La versión Web Edition tendrá un máximo de 5Gb, mientras que la versión Bussinnes tendrá un máximo de 50 Gb.

image

image

Además de esta característica tan esperada, tenemos alguna otra:

Soporte a los datos espaciales (tipos geométricos y geoespaciales), tipos que existen en SQL Server 2008, pero hasta el día de hoy no existían en SQL Azure.

Soporte al tipo de datos HierarchyID, disponible también en SQL Server 2008, y que permite representar estructuras jerárquicas.

Se ha publicado la primera preview de SQL Azure Data Sync Service (la release para el TechEd).

Hasta ahora haciendo uso de Microsoft Sync Framework podíamos sincronizar una base de de datos SQL Server, que estuviera fuera de la nube, con una base de datos SQL Azure….pero no podríamos sincronizar dos base de datos SQL Azure…

Ahora ya podemos, con SQL Azure Data Sync Services podremos sincronizar dos base de datos de SQL Azure, aunque estén en datacenters diferentes.

Soporte de SQL Azure para Office 2010, lo que nos permite conectarnos desde Office 2010, de forma nativa, a una base de datos de Azure.

SQL Azure estará disponible en dos nuevos datacenters; East Asia and the West Europe Region.

Conectándonos a SQL Azure

En un post anterior os hablaba de SQL Azure. En este post quiero entrar en más detalle sobre cómo podemos conectarnos a una base de datos de Azure.

Como ya os comenté, nos podemos conectar haciendo uso de SQL Server 2008 R2 Management Studio o desde una aplicación, simplemente cambiado la cadena de conexión. El protocolo por el cuál nos comunicamos es el mismo protocolo que usa SQL Server, el protocolo TDS.

Lógicamente, el primer paso es crear el servidor de base de datos desde el portal de la plataforma Windows Azure para cual necesitamos disponer de una cuenta de Azure.

Una vez que tenemos la cuenta, nos pedirá las credenciales para el usuario administrador, lo que sería el usuario sa de SQL Server, pero afortunadamente, no nos dejará meter como usuario algo como “sa”, “admin” o “administrador”.

image

El nombre del servidor no lo elegimos nosotros, nos lo da SQL Azure. Ese en el nombre que usaremos desde Management Studio o desde nuestra aplicación para conectarnos a ella.

Lógicamente, no habría ni que decirlo, es conveniente que creemos usuarios adicionales al usuario administrador para nuestras aplicaciones y que éstos usuarios tengan los privilegios mínimos. No es nada recomendable dar la cuenta de administrador “a cualquiera”.

image

Una vez creado el servidor, ya podremos crear una base de datos…dónde sólo podremos elegir el tamaño, de 1Gb o de 10 Gb. Recordad que dentro de poco el tamaño aumentará a 50Gb.

image

Y el último paso…el firewall!! Por defecto no se puede conectar nadie a SQL Azure, ni desde aplicaciones que están en la nube, ni desde fuera de la nube.

Si queremos habilitar la conexión desde fuera de la nube, tendremos que incluir la IP o rangos de IPs válidas.

Si queremos habilitar la conexión para aplicaciones que están en la nube, tendremos que marcar el check “Allow Microsoft Services access to this server”

image

Y una vez hecho, ya nos podemos conectar. El único aspecto a tener en cuenta, si queremos conectarnos desde Management Studio, es que cuando nos conectamos no nos conectamos al servidor de base de datos, sino que nos conectamos a una base de datos concreta del servidor.

Una vez nos hemos conectado, no podemos cambiar la base de datos con el comando “use”. Tendremos que crear una nueva conexión, cambiando la base de datos a la que nos conectamos.

Desde las opciones, en las propiedades de la conexión, se puede establecer la base de datos a la que nos conectaremos.

Una vez conectados, ya podéis crear tablas, relaciones, procedimientos almacenados…todo desde scripts T-SQL, nada visual. Por este motivo, a mí me resulta mucho más cómodo trabajar con SQL Server para crear mi base de datos y posteriormente migrarla a SQL Azure, como veremos en el siguiente post.

image

image

image

Y para conectarnos desde una aplicación?? Pues simplemente cambiando la cadena de conexión. Desde el portal, seleccionando la base de datos sobre la que queremos trabajar, podemos obtener la cadena conexión que debemos poner en nuestra aplicación.

Eso sí, recordad configurar las reglas de firewall!

 

 

 

 

 

 

 

 

image

 

 

Y para el próximo post, cómo migrar una base de datos que ya tengamos a SQL Azure, que como veréis, es muy muy fácil.

Bienvenidos a SQL Azure

Como seguro que todo ya sabréis, SQL Azure es uno de los componentes que forman parte de la plataforma Windows Azure.

A lo largo de este post intentaré haceros un resumen de los principales aspectos a tener en cuenta de este producto, que considero que os puede venir bien si estáis empezando a conocer esta plataforma.

image

La idea es muy sencilla: si sabes SQL Sever sabes SQL Azure.

Y esto justamente es uno de los aspectos clave. Hasta ahora Microsoft es el único proveedor que ofrece un almacenamiento relacional en la nube, con los consiguientes beneficios que esto genera.

Generalmente la mayoría de las aplicaciones que desarrollamos usan en mayor o menor medida un almacenamiento relacional. Si no tuviéramos este tipo de almacenamiento en la nube y quisiéramos migrar nuestras aplicaciones, nos veríamos obligados a cambiarlas, para posteriormente subirlas a la nube….malo!

Tener que cambiar mi aplicación o mi forma de trabajar para adaptarme la nube, hace que la adopción de la plataforma sea mucho más lenta y sobre todo, mucho más costosa para la empresa “que quiere ir al nube”.

Saber SQL Server te hace que prácticamente sepas SQL Azure….pero ¿Todo lo que hace SQL Server lo hace SQL Azure?

Pues no, ahí está clave para saber si podemos o no usar SQL Azure. Trabajando con SQL Azure, el principal aspecto a tener en cuenta son las limitaciones que SQL Azure tiene.

Conocer las limitaciones de SQL Azure es clave para saber si podríamos usarla o no. Eso sí, que tenga una serie de limitaciones ahora no significa que las vaya tener a futuro.

La plataforma Windows Azure es una plataforma nueva, recordad que la primera versión Release es de este año, y tenemos que tener en cuenta que en los próximos meses irá evolucionando. Por ejemplo, dentro de poco el tamaño máximo de una base de datos pasará de 10Gb a 50Gb o se espera que en breve exista la posibilidad de hacer backups.

Las siguientes características de SQL Server no están soportadas a día de hoy en SQL Azure:

Backup and Restore
Replication
Extended Stored Procedures
Common Language Runtime (CLR) and CLR User-Defined Types
Database Mirroring
Service Broker
Table Partitioning
Typed XML and XML indexing is not supported. The XML data type is supported by SQL Azure.
Change Data Capture
Data Auditing
Data Compression
Extended Events
External Key Management / Extensible Key Management
FILESTREAM Data
Integrated Full-Text Search
Large User-Defined Aggregates (UDAs)
Large User-Defined Types (UDTs)
Performance Data Collection (Data Collector)
Policy-Based Management
Resource Governor
Sparse Columns
Spatial data with GEOGRAPHY and GEOMETRY data types
SQL Server Replication
Transparent Data Encryption

Por lo tanto, ya sabemos que si nuestra aplicación necesita alguna de estas características no podremos usar SQL Azure, salvo que nos busquemos una alternativa.

Por ejemplo, el tema de backup, que estará disponible durante los próximos meses. No tenemos la opción backup pero no significa que podemos buscar otras alternativas, como usar la sincronización con Microsoft Sync Framework.

Es importante tener en cuenta, que esto no es blanco ni negro. SQL Azure nos podrá servir para una serie de aplicaciones y para otras no. Esto es extensible a toda la plataforma. No por el hecho de existir Windows Azure Platform, ahora tenemos que llevar todo  a la nube. Unas cosas nos interesarán y otras no…

 

¿Cómo podemos hacer uso de SQL Azure?

Como administradores, podemos conectarnos a SQL Azure haciendo uso de SQL Server 2008 R2 Management Studio.  Eso sí, olvidaros de interfaz visual a la hora de crear tablas, relaciones y demás. Todo a base de scripts, aunque veremos que hay otras alternativas…

Desde el punto de vista de nuestra aplicación, como regla general, no vamos a tener que cambiar nada, salvo la cadena de conexión.

Nos podemos conectar por ADO.NET, ODBC y desde aplicaciones PHP. No soporta conexiones OLEDB.

Si estamos usando Entity Framework tampoco tenemos por qué preocuparnos, cambiamos la cadena de conexión y punto.

¿Cómo se factura?

Espacio y tráfico. Si creo una base de datos de 10 Gb, estaré pagando por esos 10Gb. Si creo una de 1 Gb estaré pagando por ese Giga. Una base de datos de 10 Gb podría llegarse a contratar por $74.95 al mes.

También se factura por el tráfico, pero por el tráfico que sale y entra de Azure. Si nos conectamos desde una aplicación que también está en la nube, nos se pasa por el tráfico entre la aplicación y SQL Azure, todo está en la nube.

Si nos conectamos desde una aplicación que está fuera de la nube (Management Studio, una aplicación nuestra, Reporting Services etc…) estaremos pagando por el tráfico que generamos. Un select * from table, aparte de poco recomendable, ahora cuesta más 🙂

El coste del tráfico es un aspecto a tener en cuenta, porque a priori podemos hacer que nuestra aplicación corra fuera de la nube y se conecte a SQL Azure….pero tened en cuenta, que el tráfico se paga (aun así en algunos escenarios nos puede interesar) y lógicamente, la latencia de la red!.

Espero que este resumen os haya sido de utilidad…en los próximos post espero poder ir entrando en más detalles y por ejemplo, escribir sobre cómo podemos migrar una base de datos a SQL Server, cómo podemos conectarnos desde nuestra aplicación o cómo podemos hacer uso de Microsoft Sync Framework para sincronizar SQL Azure con otro origen de datos.

Consumir un servicio de Dallas desde Excel 2010

En un post anterior os hablaba de Dallas y de cómo se pueden consumir servicios de Dallas desde una aplicación.

Esta vez os comentaré otra forma de consumir servicios de Dallas, que no es más que desde Microsoft Excel 2010…sí, versión 2010.

La idea es muy sencilla. Si somos capaces de consumir servicios de información de Dallas desde Excel, éstos servicios podrán llegar a muchos más usuarios. Excel nos permite explotar la información de una manera bastante potente y en más de una ocasión esta alternativa puede ser suficiente.

A parte de disponer de Excel 2010, será necesario instalar el componente PowerPivot, que nos permitirá consumir los datos del servicio y poder analizarlos.

Lo primero, lógicamente, es subscribirnos a un servicio de Dallas, como ya veíamos en el post anterior e ir a explorar el dataset desde el portal.

Entre las acciones que tenemos disponible está opción “Analyze”.

image

Si pinchamos sobre esta opción y seleccionamos la opción “Open”, se nos abrirá Excel 2010, permitiéndoos importar los datos del servicio a Excel.

image

image

image

image

image

Y ya está, ya tenemos los datos en Excel…Una vez que los tenemos aquí, ya podemos aprovechar todos nuestros conocimientos de Excel para explotarlos cómo nos apetezcan.

image

Consumiendo un servicio de Dallas (I)

En un post anterior os presentaba Dallas, un componente de Windows Azure.

En este veremos cómo podemos consumir un servicio expuesto en Dallas desde nuestra aplicación, integrando de esta manera la información que éste ofrece.

Lo podemos consumir desde cualquier tipo de aplicación, ya que los servicios se exponen haciendo uso de estándares (REST/ATOM), pero cierto es, que si lo hacemos desde .NET nos va a resultar más sencillo.

Lo primero, lógicamente, es subscribirnos a un servicio de Dallas, como ya veíamos en el post anterior e ir a explorar el dataset desde el portal.

En la parte inferior izquierda de la página de exploración nos aparecerá información muy útil para conectarnos al servicio desde nuestra aplicación; La url del servicio, las credenciales del acceso y si queremos acceder desde .NET,el proxy que tenemos que añadir a nuestra aplicación.

image

Os comentaba que acceder desde .NET es lo más productivo porque la plataforma ya nos genera el proxy de acceso al servicio, el cual sólo tenemos que incluirlo en nuestro proyecto para poder tener acceso al servicio.

Si no tuviéramos el proxy podríamos acceder, pero tendríamos que construirnos las peticiones REST nosotros mismos.

Un valor necesario es disponer de esta cuenta. A través del portal podemos crear todas las cuentas que queremos.

image 

Si nos descargamos el proxy y lo añadimos a una aplicación de consola de .NET, sólo tendremos que hacer uso del mismo..(FAO3510Service es el nombre de la clase proxy que nos hemos descargado)

            string accountKey = "XXXXXX";
            string uniqueUserId = "XXXXXX";

            // Creamos el proxy
            FAO3510Service service = new FAO3510Service(accountKey, new Guid(uniqueUserId));

            // Invocamos el servicio y no le pasamos ningún parámetro.
            // Por defecto, devuelve los 100 primeros elementos
            List<FAO3510Item> results = service.Invoke(null, null);

            // Establecemos una cabecera para el listado
            Console.WriteLine("{0,13}{1,24}{2,18}{3,7}{4,10}", "Series Code", "Country or Area Code",
                "Country or Area", "Year", "Value");

            // Recorremos el resultado, de forma tipada!
            foreach (FAO3510Item item in results)
            {
                Console.WriteLine("{0,13}{1,24}{2,18}{3,7}{4,10}", item.SeriesCode, item.CountryOrAreaCode, 
                    item.CountryOrArea, item.Year, item.Value);
            }

            Console.ReadLine();

Si tuviésemos que hacernos la petición REST, sin el proxy, el resultado sería algo parecido a esto:

            string url = "https://api.sqlazureservices.com/UnService.svc/FAO/3510?$format=atom10";
            string accountKey = "XXX";
            string uniqueUserId = "XXX";

            WebRequest request = WebRequest.Create(url);
            request.Headers.Add("$accountKey", accountKey);
            request.Headers.Add("$uniqueUserID", uniqueUserId);

            HttpWebResponse response = (HttpWebResponse)request.GetResponse();
            Console.WriteLine(response.StatusDescription);
            Console.ReadLine();

            // Get the stream containing content returned by the server.
            Stream dataStream = response.GetResponseStream();

            // Open the stream using a StreamReader for easy access.
            StreamReader reader = new StreamReader(dataStream);
            
            // Read the content.
            string responseFromServer = reader.ReadToEnd();

            // Load the response into an XDocument
            XDocument data = XDocument.Parse(responseFromServer);
            // Specify the namespaces required to query the document
            XNamespace ns0 = "http://www.w3.org/2005/Atom";
            XNamespace ns1 = "http://schemas.microsoft.com/ado/2007/08/dataservices";
            XNamespace ns2 = "http://schemas.microsoft.com/ado/2007/08/dataservices/metadata";

            // Specify the Linq query
            var result = (from q in data.Descendants(ns0 + "entry")

            where q.Element(ns0 + "title").Value == "Agricultural production index, 1999-2001=100 (FAO/SYB)"
            where q.Element(ns0 + "content").Element(ns2 + "properties").Element(ns1 + "seriesCode").Value == "3510"
            where q.Element(ns0 + "content").Element(ns2 + "properties").Element(ns1 + "year").Value == "2006"
            select q.Element(ns0 + "content").Element(ns2 + "properties").Element(ns1 + "value").Value).FirstOrDefault();

            // Display the content to the Console.
            Console.WriteLine(result);

            reader.Close();
            dataStream.Close();
            response.Close();

¿Qué es Dallas?

Dallas es el codename de un componente de Windows Azure, aún en CTP.

La idea es muy sencilla y os va a resultar muy familiar; Un punto de unión para que los que quieran ofrecer servicios puedan ofrecerlos y los que quieran consumirlos, lo consuman. Lógicamente, pudiendo establecer el tipo de relación entre el que ofrece y consume; gratis, subscripción de pago…

Dallas se puede definir como un marketplace de información.

Realmente Dallas forma parte de Microsoft PinPoint, que es un marketplace, una visión más amplia que Dallas, ya que es una marketplace de aplicaciones e información.

Como consumidores de información nos permitirá tener acceso a multitud de servicios de información, pudiendo navegar por ellos a través de un catálogo, poder subscribirnos y poder integrar esta información dentro de nuestras aplicaciones.

El servicio puede ofrecerse en modalidad de pago, en este caso, todo el sistema de facturación también lo ofrecerá la plataforma.

Los servicios son expuestos usando estándares (REST/ATOM) para que puedan ser consumidos desde todas las plataformas.

Al portal de Dallas podéis acceder desde aquí.

image

A través de la pestaña de catálogo, podréis navegar por todos los servicios que ofrece la plataforma y subscribiros a los que necesitéis. Para pruebas hay una serie de servicios que se ofrecen de forma gratuita que nos pueden servir para evaluar la plataforma.

image

Una vez subscritos al servicios, desde el portal podremos acceder a toda la información que éste ofrece. En esta misma pantalla nos aparecerá una enlace a “Click here to explore the dataset”.

image

Se puede jugar con los diferentes filtros del servicio, con la paginación y ver cómo no va a llegar la información:

image

Otro aspecto importante del portal es que nos ofrece datos sobre el uso que hacemos de los servicios de Dallas.

Por cada cuenta que tenemos en nuestro portal (podemos tener muchas) podemos saber a qué servicios han accedido y cuántas veces. Lógicamente este dato es muy importante de cara a la facturación.

image

Y ahora a consumir servicios…bueno, en el siguiente post.

SQL Azure se hace mayor

Bueno, más bien se hará mayor, porque ya hay fecha para que el tamaño máximo de SQL Azure aumente.

A partir del 28 de junio, el tamaño máximo será de 50 Gb, una cantidad bastante más sería y en dónde la gran mayoría de nuestra aplicaciones podrían estar.

La versión SQL Azure Business Edition pasará de 10 gb a 50 Gb, mientras que la versión SQL Azure Web Edition pasará de 1 a 5 Gb.

No se pasará directamente de 10gb a 50 Gb. Se podrá contratar en tramos de 10 Gb hasta el máximo comentado.

Si ya tienes una base de datos creada podrás aumentarle su tamaño pero claro está, con el siguiente aumento en la tarifa. Recuerda, pago por uso.

Si estás interesado en los precios te recomiendo que visitas esta página (Windows Azure Platform Offer Comparison Table) y esta otra de aquí. (Pricing).

Otra cosa a tener en cuenta, es que a partir del 1 de agosto van a tener una serie de ofertas en SQL Azure que para aquellos que estéis interesados en hacer algo en Azure os podrá venir muy bien. Leía que una base de datos de 10 Gb podría llegarse a contratar por $74.95 al mes.

Os dejo aquí la información de esta oferta (Windows Azure Platform SQL Azure Development Accelerator Core)