Estas nuevas características se pueden concretar en los siguientes elementos:

IExecutionStrategy

Esta interfaz define el contrato para la pieza que tendrá como responsabilidad la ejecución de operaciones que potencialmente necesiten reintentarse,por ejemplo las operaciones sobre Sql Database. El contrato de esta interfaz no es nada complicado como podemos ver a continuación:

?namespace System.Data.Entity.Infrastructure
{
    using System.Diagnostics.CodeAnalysis;
    using System.Threading;
    using System.Threading.Tasks;

    public interface IExecutionStrategy
    {
        /// <summary>
        ///     Indicates whether this <see cref="IExecutionStrategy"/> might retry the execution after a failure.
        /// </summary>
        bool RetriesOnFailure { get; }

        /// <summary>
        ///     Executes the specified action.
        /// </summary>
        /// <param name="action">A delegate representing an executable action that doesn''t return any results.</param>
        void Execute(Action action);

        /// <summary>
        ///     Executes the specified function and returns the result.
        /// </summary>
        /// <typeparam name="TResult">The return type of <paramref name="func"/>.</typeparam>
        /// <param name="func">A delegate representing an executable action that returns the result of type <typeparamref name="TResult"/>.</param>
        /// <returns>The result from the action.</returns>
        TResult Execute<TResult>(Func<TResult> func);

#if !NET40

        /// <summary>
        ///     Executes the specified asynchronous action.
        /// </summary>
        /// <param name="taskAction">A function that returns a started task.</param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        Task ExecuteAsync(Func<Task> taskFunc);

        /// <summary>
        ///     Executes the specified asynchronous action.
        /// </summary>
        /// <param name="taskAction">A function that returns a started task.</param>
        /// <param name="cancellationToken">
        ///     A cancellation token used to cancel the retry operation, but not operations that are already in flight
        ///     or that already completed successfully.
        /// </param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        Task ExecuteAsync(Func<Task> taskFunc, CancellationToken cancellationToken);

        /// <summary>
        ///     Executes the specified asynchronous function and returns the result.
        /// </summary>
        /// <typeparam name="TResult">
        ///     The type parameter of the <see cref="Task{T}"/> returned by <paramref name="taskFunc"/>.
        /// </typeparam>
        /// <param name="taskFunc">A function that returns a started task of type <typeparamref name="TResult"/>.</param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        [SuppressMessage("Microsoft.Design", "CA1006:DoNotNestGenericTypesInMemberSignatures")]
        Task<TResult> ExecuteAsync<TResult>(Func<Task<TResult>> taskFunc);

        /// <summary>
        ///     Executes the specified asynchronous function and returns the result.
        /// </summary>
        /// <typeparam name="TResult">
        ///     The type parameter of the <see cref="Task{T}"/> returned by <paramref name="taskFunc"/>.
        /// </typeparam>
        /// <param name="taskFunc">A function that returns a started task of type <typeparamref name="TResult"/>.</param>
        /// <param name="cancellationToken">
        ///     A cancellation token used to cancel the retry operation, but not operations that are already in flight
        ///     or that already completed successfully.
        /// </param>
        /// <returns>
        ///     A task that will run to completion if the original task completes successfully (either the
        ///     first time or after retrying transient failures). If the task fails with a non-transient error or
        ///     the retry limit is reached, the returned task will become faulted and the exception must be observed.
        /// </returns>
        [SuppressMessage("Microsoft.Design", "CA1006:DoNotNestGenericTypesInMemberSignatures")]
        Task<TResult> ExecuteAsync<TResult>(Func<Task<TResult>> taskFunc, CancellationToken cancellationToken);

#endif

    }
}

La idea básica que hay detrás de esta interfaz es poder envolver una acción en un determinado ámbito capaz de decidir si las excepciones que se produzcan son o no candidatas para reintentarse, por ejemplo porque entendemos que es un fallo de Sql Database y no relacionado con el mapeo, consulta etc…, cada cierto tiempo. Por supuesto, decidir si una excepción  de una operación implica que la operación debe repetirse es algo configurable y no fijo, cuya implementación esta marcada por una nueva interfaz, que vemos a continuación.

IRetriableExceptionDetector

Mediante este contrato tendremos la posibilidad de especificar que excepciones son candidatas a “resolver” por medio de reintentos, el siguiente código representa este contrato

?// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. See License.txt in the project root for license information.

namespace System.Data.Entity.Infrastructure
{
    public interface IRetriableExceptionDetector
    {
        /// <summary>
        ///     Determines whether the specified exception represents a transient failure that can be compensated by a retry.
        /// </summary>
        /// <param name="ex">The exception object to be verified.</param>
        /// <returns><c>true</c> if the specified exception is considered as transient, otherwise <c>false</c>.</returns>
        bool ShouldRetryOn(Exception ex);
    }
}

IRetryDelayStrategy

Este es el último elemento que necesitamos, y probablemente el más sencillo puesto que tiene como única finalidad marcar el tiempo entre reintentos de operaciones fallidas.

// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. See License.txt in the project root for license information.

namespace System.Data.Entity.Infrastructure
{
    public interface IRetryDelayStrategy
    {
        /// <summary>
        ///     Determines whether the action should be retried and the delay before the next attempt.
        /// </summary>
        /// <param name="lastException">The exception thrown during the last execution attempt.</param>
        /// <returns>
        ///     Returns the delay indicating how long to wait for before the next execution attempt if the action should be retried;
        ///     <c>null</c> otherwise
        /// </returns>
        TimeSpan? GetNextDelay(Exception lastException);
    }
}

Bien, ahora que ya conocemos las piezas, ya podemos entender que tenemos para Sql Database, y esto, no es más que implementaciones concretas para estos contratos que podemos “inyectar” dentro de EF .

La implementación para el trabajo de Azure, Sql Database, se basa principalmente en la clase SqlAzureExecutionStrategy, que tendremos por defecto en el proveedor de Sql Server por defecto.

?// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. See License.txt in the project root for license information.

namespace System.Data.Entity.SqlServer
{
    using System.Data.Entity.Infrastructure;

    /// <summary>
    ///     An <see cref="ExecutionStrategy"/> that uses the <see cref="ExponentialRetryDelayStrategy"/> and
    ///     <see cref="SqlAzureRetriableExceptionDetector"/>.
    /// </summary>
    [DbProviderName("System.Data.SqlClient")]
    public class SqlAzureExecutionStrategy : ExecutionStrategy
    {
        public SqlAzureExecutionStrategy()
            : base(new ExponentialRetryDelayStrategy(), new SqlAzureRetriableExceptionDetector())
        {
        }
    }
}

Como observará, en realidad esto no tiene nada más que el marcador de tiempos, ExponentialRetryDelayStrategy, que cuyo nombre indica hace un incremento exponencial basado en la siguiente fórmula:min (minDelay + coefficient * random(1, maxRandomFactor) * (exponentialBase ^ retryCount – 1), maxDelay), y un detector de excepciones personalizado que permitirá reintentar las siguientes excepciones.

• SqlException con diferentes numberos de error, revisar el código siguiente para ver los casos concretos.
• Un TimeoutException.

Como se establece la estrategia que queremos usar? por ejemplo esta para Sql Database?, pues bien, tan simple como hacemos otras inyecciones, por medio de nuestro DbConfiguration y el método AddExecutionStrategy.

        /// <summary>
        ///     Call this method from the constructor of a class derived from <see cref="DbConfiguration" /> to add an
        ///     <see cref="IExecutionStrategy"/> for use with the associated provider.
        /// </summary>
        /// <remarks>
        ///     The <typeparamref name="T"/> type should have a <see cref="DbProviderNameAttribute"/> applied to it.
        ///     This method is provided as a convenient and discoverable way to add configuration to the Entity Framework.
        ///     Internally it works in the same way as using AddDependencyResolver to add an appropriate resolver for
        ///     <see cref="IExecutionStrategy" />. This means that, if desired, the same functionality can be achieved using
        ///     a custom resolver or a resolver backed by an Inversion-of-Control container.
        /// </remarks>
        /// <typeparam name="T"> The type that implements <see cref="IExecutionStrategy"/>. </typeparam>
        /// <param name="getExecutionStrategy"> A function that returns a new instance of an execution strategy. </param>
        protected internal void AddExecutionStrategy<T>(Func<T> getExecutionStrategy)
            where T : IExecutionStrategy
        {
            Check.NotNull(getExecutionStrategy, "getExecutionStrategy");

            _internalConfiguration.CheckNotLocked("AddExecutionStrategy");

            foreach (var providerInvariantNameAttribute in DbProviderNameAttribute.GetFromType(typeof(T)))
            {
                _internalConfiguration.AddDependencyResolver(
                    new ExecutionStrategyResolver<T>(providerInvariantNameAttribute.Name, /*serverName:*/ null, getExecutionStrategy));
            }
        }

Si nos fijamos un poco veremos como lo primero que hace este método es recuperar el proveedor para el que aplica esta estrategia, buscando un atributo, DbProviderName. Una vez localizado este atributo se establece el dependency resolver con la estrategia indicada. A partir de ese momento, ya tendremos disponible nuestra estrategia de reintentos..

Bueno, esto ha sido todo, espero que os sigan gustando las novedades de EF 6 y que sigáis viendo todo lo nuevo que poco a poco vamos teniendo…

Unai

En primero lugar, por fin, SQL Database ya tiene soporte para consultas distribuidas y “linked servers”.

Además de esta característica, hay más novedades igual de importantes:

• Trigers recursivos.
• Soporte a DBCC SHOW_STATISTICS
• Posibilidad las reglas de firewall a nivel de base de datos.

El detalle completo lo tenéis en este artículo y en la página de precios.

Así mismo también se presenta un ejemplo de uso, una herramienta cliente, que puede ser más que útil para poder importar el contenido exportado al storage (el bacpac) a un servidor SQL Server on-premise y que también permite generar un bacpac a partir de una base de datos on-premise para lugar poder importar el contenido de la misma a SQL Azure.

Las principales novedades son:

• El límite de tamaño de una base de datos de SQL Azure Business Edition se ha incrementado de 50 a 150 GB.

El coste máximo para una base de datos individual, establecido en 354.56 € estadounidenses por mes de facturación, no se modifica.

Este límite de 354.56 € estadounidenses para SQL Azure Business Edition por base de datos y mes se basa en los cargos acumulados para el mes de facturación completo por cada base de datos. El límite de facturación permite escalar la base de datos de 50 a 150 GB sin coste adicional, lo que reduce el precio efectivo para volúmenes mayores.Por ejemplo, un cliente que use una base de datos de 150 GB durante un mes de facturación completo observará una reducción efectiva del precio de un 67%.

• SQL Federation

SQL Azure Federation simplifica enormemente el escalado horizontal (sharding), posibilitando que el usuario pueda aumentar o disminuir las bases de datos de la aplicación de forma dinámica y sin que este hecho provoque una parada del servicio.

Es el usuario quién decide los miembros de la federación, es quién decide cuándo añadir o disminuir miembros y es quién decide en base a qué criterio debe realizarse la partición de la información.

Podéis encontrar más información aquí.

• Nuevo portal de administración, basado en SL5 y con información muy interesante para la monitorización de base de datos.

• Nueva CTP de la funcionalidad de export/import.

http://www.estoyenlanube.com/sql-azure-importexport/ 

• Posibilidad de especificar el collation de la base de datos.

Entre las principales novedades a destacar está el hecho que se ha incluido información que permite monitorizar ciertos aspectos de la base de datos, cosa que anteriormente se podría llegar a a hacer, pero no de una manera tan sencilla como ahora. Eso sí, esto no quita que se echen de menos algunas características adicionales de monitorización, pero este puede ser un primer paso.

Acabamos de publicar la segunda parte sobre los sistemas de almacenamiento en Windows Azure, dónde se habla de SQL Azure y WIndows Azure Storage.

Parte I – Introducción a Windows Azure

Parte II – Sistemas de almacenamiento, SQL Azure y Windows Azure Storage

Recordad que con este contenido lo que hemos intentado es hacer una labor de recopilación de toda la información que hemos ido realizando desde la primera versión de la plataforma, para una vez actualizada, poder presentarla de forma ordenada al lector y así simplificar el proceso de aprendizaje.

Espero que os sea de utilidad!

Uno de los grandes beneficios de la plataforma Windows Azure es la capacidad que ofrece a la hora de escalar aplicaciones. De manera muy sencilla y dinámica un usuario puede modificar el número de instancias de una aplicación.

Hablando de instancias de Windows Azure este punto es cierto, pero la base de datos podría convertirse en un cuello de botella, ya que ésta no tiene la capacidad de escalado que tienen las instancias de Azure. El usuario no dispone de la posibilidad de realizar un escalado horizontal y aumentar o disminuir las bases de datos SQL Azure en función de las necesidades de la aplicación.

Por ejemplo, este es un escenario típico en aplicaciones multi-tenant, dónde con un mismo despliegue se quiere ofrece el servicio a diferentes clientes.

Al implementar soluciones de este tipo la primera aproximación es usar una única base de datos capaz de contener la información de todos los clientes.

Esta solución es perfectamente viable, pero en algunos escenarios surgen problemas de escalabilidad en caso de que la aplicación crezca en el número de clientes.

Otra de las soluciones aportadas, buscando un alto grado de escalabilidad ha sido utilizar múltiples base de datos, en lugar de una única que contenga todos los datos de la aplicación.

La aplicación es capaz de gestionar múltiples clientes diferentes, cada uno con su información, pero a nivel de base de datos cada uno tiene su base de datos propia.

Este escenario es perfectamente viable, pero implica que si existen 1000 clientes existirán 1000 base de datos, lo que aumente la complejidad de administración de la aplicación y claro está, los costes de despliegue.

SQL Azure Federation viene a cubrir este tipo de escenario, ya que esta característica simplificará enormemente el escalado horizontal, posibilitando que el usuario pueda aumentar o disminuir las bases de datos de la aplicación de forma dinámica y sin que este hecho provoque una parada del servicio.

Es el usuario quién decide los miembros de la federación, es quién decide cuándo añadir o disminuir miembros y es quién decide en base a qué criterio debe realizarse la partición de la información (en la primera versión sólo soportará la partición por rangos, por ejemplo, por cierto valor de un determinado campo).

La sintaxis de la sentencia para crear una federación es la siguiente:

CREATE FEDERATION federation_name { <federation_distribution_scheme> } <federation_distribution_scheme> ::= <federation_distribution> <federation_distribution> ::= (distribution_name <data_type> <distribution_type>) <data_type> ::= [ system_type_name . ] type_name

Dentro de la federación existe un elemento que se conoce como “Federation Root”. Este elemento representa el nombre lógica de la base de datos y es quién conoce todos los miembros de la federación y qué información tiene cada uno de ellos.

Las aplicaciones siempre debe conectarse al “root”, y éste quién dirige las peticiones a la base de datos correspondiente.

SQL Azure Data Sync es una de las funcionalidades de SQL Azure accesible desde el portal de administración de Windows Azure, aunque esté todavía en CTP.

Básicamente, como se puede entender de su nombre, es un servicio de sincronización de datos, que permite sincronizar base de datos de SQL Azure que estén en el mismo o diferente datacenter o based de datos que se encuentren on-premise con base de datos que se encuentren hosteadas en Windows Azure.

La sincronización entre las base de datos se podrá hacer de forma bidireccional.

Como paso adicional que se verá posteriormente, la sincronización con una base de datos on-premise requiere la instalación de un agente de sincronización en el servidor on-premise. Este paso no es necesario en el caso de realizar el proceso entre base de datos que estén en Windows Azure.

Como se ha comentado anteriormente toda la funcionalidad está accesible desde el portal de administración de Windows Azure.

Una vez se accede a la característica de sincronización, el primer paso será realizar un aprovisionamiento del servicio. El proceso de aprovisionamiento pedirá que aceptar los términos de licencia e indicar en qué datacenter se quiere realizar dicho aprovisionamiento.

Una vez realizado el proceso se habilitarán las opciones de sincronización. En proceso de sincronización es un asistente en el cuál se guiará paso a paso sobre todas las acciones necesarias para configurar un proceso de sincronización.

Sincronización entre base de datos SQL Azure

Si se selecciona la opción de sincronización entre base de datos SQL Azure, el primer paso será dar un nombre a dicho proceso.

El siguiente paso será añadir una de las base de datos a sincronizar, indicando la ubicación de la misma y las credenciales de acceso.

El siguiente paso será elegir la base de datos con la cuál se realizar la sincronización.

En este paso, como se puede apreciar en la figura, se debe elegir la dirección del proceso de sincronización.

Una vez indicados los dos puntos de la sincronización el siguiente paso será indicar la periodicidad del proceso y el método de resolución detección de conflictos que quiere aplicarse.

Y en el último paso puede definirse con más detalle qué información es la que se desea sincronizar; qué tablas, qué columas etc…

Y por último,el asistente pedirá guardar los cambios seleccionando la opción de “deploy”.

Una vez configurado todo el proceso desde el portal de administración podrá verse toda la información del proceso y claro está,modificar cualquiera de los elementos configurados en el asistente.

Así mismo también el portal de administración nos ofrece la posibilidad de consultar un log con todas las operaciones que se realizan en los procesos de sincronización.

Comentar por último que aunque en este apartado el proceso de creación del grupo de sincronización se ha hecho a través de un asistente, existe también la posibilidad de no usarlo y de crear el proceso de sincronización de forma “manual” consiguiendo, claro está, el mismo resultado.

Sincronización con un servidor on-premise

El proceso de sincronización con un servidor on-premise es prácticamente igual al realizado entre servidores SQL Azure, salvo por el hecho que implica la instalación de un agente de sincronización en el servidor on-premise.

Aunque para realizar un proceso de este tipo se podría utilizar un asistente similar al visto anteriormente, en este ejemplo lo que se va a realizar es añadir un servidor on-premise al grupo creado anteriormente.

Para ello, sobre el diagrama de la Figura anterior puede seleccionarse la opción de añadir un servidor on-premise.

Dicha opción permite añadir un servidor que ya disponga del agente de sincronización o un nuevo servidor que no lo tenga. En este caso se optará por la segunda opción.

Después de este paso será necesario descargarse el agente de sincronización (msi) e instalarlo en el servidor on-premise. Una vez instalado hay que arrancar el agente (desde el menú inicio) e indicarle la clave de acceso generada en el paso 3.

Una vez hayamos configurado la clave, el siguiente paso será registrar la base de datos local que queremos sincronizar.

Una vez hecho este paso, se podrá ver cómo la base de datos registrada se muestra en el servidor y podemos seleccionarla para ser usada en el proceso de sincronización.

Una vez añadido el servidor, para que la modificación tenga efecto será necesario volver a realizar un despliegue, seleccionado la acción “deploy”.

Uno de los anuncios que ha hecho Microsoft con respecto a SQL Azure es que por fin tenemos la posibilidad de comenzar a usar SQL Azure Reporting (hasta ahora su uso estaba restringido). En mi caso, tenía ganas de ver de que va esto de SQL Azure Reporting y he de decir que me he quedado un tanto decepcionado ya que:

• Sólo se pueden crear informes para BD’s SQL Azure, no estando soportados otros orígenes de datos.
• A la hora de crear un informe de SQL Azure Reporting hay que dar más de una “vuelta” hasta darte cuenta del proceso.
• Relacionado con lo anterior, que no se pueda lanzar el generador de informes desde el portal de Azure para facilitar la creación del informe.

Dicho esto, vamos a ver un pequeño paso a paso de como crear un informe de SQL Azure Reporting:

• Nos conectamos al portal de Windows Azure y nos validamos con nuestra suscripción. Pulsamos sobre la opción “Informes” disponible en el menú vertical.
• Lo primero que tendremos que hacer es crear un servidor de SQL Azure Reporting a través de la opción correspondiente. A continuacón, se muestra la correspondiente ventana de Términos de uso…pulsamos “Siguiente” en la misma.
• En la nueva ventana del asistente, especificamos la suscripción de Azure a crear y la región de provisionaiento y pulsamos “Siguiente”.

Tras especificar usuario y contraseña para SQL Azure Reporting y pulsar Siguiente, comienza el provisionado del servicio.

• Cuando el proceso acaba, veremos que tenemos creado un nuevo servidor de SQL Azure Reporting bajo nuestra suscripción que podemos proceder a utilizar.
• Lo primero que necesitamos es un origen de datos que crearemos con la opción correspondiente en la sección Data Source. En esta ventana especificaremos la cadena de conexión que tiene que ser de la forma:

   1: Server=tcp:<Servidor_SQLAzure>.database.windows.net;Database=Customers;User ID=UsuarioSQLAzure;Password=ContraseñaSQLAzure;Trusted_Connection=False;

• Fijaros que a la hora de especificar la conexión, podemos indicar que o bien se soliciten las credenciales o que estas estén almacenadas de forma segura a nivel de base de datos. En mi caso, he escogido la primera opción aunque la buena práctica sería la segunda y usando un login de SQL Azure con los permisos mínimos para permitir la visualización del informe.

• Probamos que la conexión a nuestro SQL Azure es correcta.
• Una vez creado el origen de datos, este debería aparecer en el listado de objetos de reporting disponibles en el servidor de SQL Azure.
• A continuación,el objetivo es crear un informe a partir de ese origen de datos definido…y la clave para crearlo es la url del servidor de informes.

• Esa Url es la que tenemos que especificar en las opciones de configuración del generador de informes (aká Report Builder).
• De esta forma,cuando vayamos a crear un origen de datos podremos seleccionar el ya disponible en SQL Azure Reporting. Tened en cuenta que se os irán pidiendo credenciales de acceso al servidor según vayáis creando los sucesivos elementos que se necesitan en el informe.
• Una vez que tenemos disponible el origen de datos del informe, podemos crear un conjunto de datos a partir del mismo.

• Lo siguiente que haremos es diseñar la consulta del informe, ya sea visualmente o vía T-SQL.
• Probamos que la consulta está operativa.
• Y a continuación definimos un informe sencillo sobre la base de ese conjunto de datos.

• Para cargar el informe en el servidor de SQL Azure Reporting, simplemente usamos la opción de carga disponible en el portal de Windows Azure.
• Para visualizar el informe desde el servidor de SQL Azure Reporting, simplemente navegamos a la Url del servidor de informes y hacemos clic sobre el informe en cuestión.
• Cómo es lógico, y de acuerdo a mi configuración, se nos pedirán las credenciales de ejecución.

• Tras especificar dichas credenciales, el informe se muestra sin problemas:

Y hasta aquí llega este primer post sobre SQL Azure Reporting.

En los próximos días espero poder  mostraros con mayor detalle algunas de las características. Aunque seguro que algo más se anunciará, de momento el resumen de lo que se ha comentado hasta el momento:

• Se multiplicará por 3 el tamaño máximo de una base de datos SQL Azure, pasando de 50 GB a 150 Gb

• Llegará SQL Federation, que simplificará el escalado horizontal usando el patrón de “sharding” basado en el tamaño de la base de datos o la carga de ésta. Simplificará enormemente la posibilidad de crear y administrar un sistema de base de datos que hagan de sharding.

• Se añadirán más funcionalidades en el portal de administración para mejorar las capacidades de monitorización, navegar por los schemas de la base de datos, ver los planes de ejecución, datos espaciales, índices, keys u obtener estadísticas para conocer el rendimiento de las querys que se ejecuten contra la base de datos.

• Nueva CTP de SQL Azure DataSync

Esta CTP ya se encuentra integrada dentro del portal de administración y puede ser usada por todos los usuarios.

• Nueva CTP de SQL Azure Reporting Service

Se ha anunciado una nueva versión CTP de SQL Azure Reporting Services, versión que está disponible ya mismo desde el portal de administración. Esta versión ya a su vez también está disponible en todos los datacenters de Windows Azure,lo que hace que podamos desplegarlo en aquel que nos interese para nuestra aplicación.

Desde el portal de administración nos será muy fácil exportar una base de datos completa al Windows Azure Storage y volver a importarla.

Como podéis ver, si vamos al portal de administración tenemos dichas opciones en la barra superior.

Seleccionando la base de datos que nos interese podemos seleccionar la opción exportar, la cual nos pedirá la información necesaria para la operación.

En primer lugar nos pedirá las credenciales de nuestra base de datos y en segundo lugar le tendremos que indicar la ubicación dónde debe dejar el resultado de la operación.

La URL debe ser la URL de un blob que no exista. El contenedor sí debe existir.

Para acceder al contenedor podremos usar la clave del storage (Access Key) o una clave compartida (Shared Key).

Una vez realizada la operación nos indicará que dicho proceso se iniciará. El proceso no es inmediato, depende del tamaño de la base de datos.

Por este motivo el portal también ofrece una ventana de estado dónde podemos ver el estado de todas las operaciones de exportación e importación, ya que ambas operaciones se hacen de forma asíncrona.

Una vez hecha la operación podemos ver que se ha creado un nuevo blob en el contenedor especificado.

Y si queremos importarla, tan fácil como seleccionar la opción importar, indicar las credenciales, el nombre de la nueva base de datos dónde se importarán los datos y el blob dónde está la base de datos.

La ventana de estado mostrará el estado de todas las operaciones de importación y exportación.

https://blogs.technet.com/b/speschka/archive/2010/12/12/integrating-sql-azure-with-sharepoint-2010-and-windows-azure.aspx

Una de las novedades es que SQL Azure dispone ya de un API de administración REST que permitirá realizar por código labores de administración, como las tan necesarias labores de aprovisionamiento; crear servidores, base de datos, configurar el firewall. (

Otra de las novedades es que a partir de ahora se podrán crear más de 1 servidor de SQL Azure por subscripción, servidor que su vez puede tener múltiples base de datos. Cada servidor, lógicamente, podrá estar en una ubicación diferente.

Soporte del driver JDBC, más concretamente de la versión 3.0 del driver de JDBC para SQL Server y actualización del paquete de aplicación datos (DAC) que permite actualización in-place en SQL Azure.

La información detallada sobre las novedades la podéis encontrar aquí.

En este post os comento una herramienta muy interesante que permite simplificar el trabajo con éstas, ya que simplifica su utilización e interpretación; CSS SQL Azure Diagnostics.

Es una herramienta pensada para simplificar el trabajo con SQL Azure y ayudarnos a encontrar y solucionar problemas. La herramienta se basa única y exclusivamente en las DMVs soportadas por SQL Azure, no hace ninguna otra cosa, pero simplifica enormemente su uso.

En este post se comenta en detalle cómo es la herramienta y cómo es posible usarla.

Aquí os dejo unos pantallazos a modo de ejemplo de la herramienta:

Es una herramienta web hecha en Silverlight, que nos va a permitir conectarnos a una base de datos SQL Azure y realizar las labores típicas que se puede realizar; manejar tablas, vistas, procedimientos almacenados, lanzar querys, abrir y lanzar ficheros sql.

Con la nueva herramienta de administración éste se encuentra completamente integrada.

Si seleccionamos una base de datos que tengamos creada, tendremos disponible la opción “Manage” dentro de la barra de herramientas de la parte superior.

Una vez damos a la opción “Manage” se nos abrirá una nueva pestaña del navegador que nos llevará a Database Manager.

Si es la primera vez que entramos tendremos que aceptar los términos de licencia e indicar las credenciales de acceso a la base de datos. Es una pena que no haya un single sing-on y no vuelva a pedir credenciales.

Una vez conectamos la herramienta nos permite hacer la labores típicas; manejar tablas, vistas, procedimientos almacenados, lanzar querys, abrir y lanzar ficheros sql…

En este post os mostraré cómo es posible trabajar con SQL Azure

Lo primero que debemos hacer es crear un nuevo servidor de base de datos (recordad que no es un servidor físico dedicado) sobre la cuenta de Azure dónde deseemos crearlo. Una cuenta sólo puede tener un servidor asociado. Un mismo servidor puede tener múltiples base de datos asociadas.

Indicaremos la cuenta de administrador del servidor.

Han incluido como parte del proceso de creación del servidor la configuración del firewall.

Una vez creado el servidor, podemos acceder a la toda la información del mismo; base de datos asociadas, datos de conexión etc…

Como siempre, en la barra de herramientas superior tendremos disponibles todas las opciones habituales en función de lo que estemos viendo en la pantalla.

Podemos crear tantas base de datos como queramos asociadas al servidor de base de datos, indicando la edición que queremos y el tamaño de la misma.

Y ya por último, otro tema interesante, es que desde el mismo portal de administración tenemos disponible información interesante sobre cómo trabajar con SQL Azure.

El material incluye información de diferentes niveles (Awareness, principiante, intermedio y avanzado), ejemplos de código y videos para intentar ayudar a conocer mejor la plataforma.

Espero que os guste.

Awareness

1. Los retos de la escalabilidad y disponibilidad en las aplicaciones
2. La respuesta Cloud Computing ¿qué es la nube?
3. Aplicaciones prácticas de la nube
4. Windows Azure Platform
   1. Qué es Windows Azure Platform
   2. Windows Azure
   3. SQL Azure
   4. Windows Azure Platform AppFabric
   5. Microsoft codename “Dallas”
5. Plataformas de desarrollo soportadas por Windows Azure

Principiantes

1. Cómo crear una cuenta en Windows Azure
   1. La promoción especial de introducción a la Plataforma Windows Azure
   2. La promoción de beneficios para suscriptores MSDN
2. Puesta en marcha de Visual Studio 2010 para trabajar con Windows Azure
   1. Herramientas necesarias
   2. Hotfixes necesarios según tu sistema operativo y entorno
3. Mi primera aplicación con Windows Azure
   1. El entorno de ejecución de Windows Azure
   2. Arquitectura de una aplicación Windows Azure
   3. Crear un proyecto con las Visual Studio Tools for Windows Azure
   4. Development Fabric simulación de Azure en local para facilitar el desarrollo
      VIDEO Mi primera aplicación con Windows Azure
4. Introducción a SQL Azure para desarrolladores
   1. Arquitectura de SQL Azure
   2. Acceso a Datos en SQL Azure
   3. Modelo de aprovisionamiento de SQL Azure
5. SQL Azure crear mi primera base de datos en la nube
   1. VIDEO El portal de gestión de SQL Azure
6. Herramientas para trabajar con SQL Azure
   1. SQL Server Management Studio
   2. SQL Azure Migration Wizard
   3. Project Code-Named “Houston”
   4. Microsoft SQL Server Migration Assistant

Intermedio

1. Almacenamiento en Azure
   1. Tablas
      VIDEO Uso en la práctica de Tablas
   2. Blobs
      VIDEO Uso en la práctica de Blobs
   3. Colas
      VIDEO Uso en la práctica de Colas
   4. Windows Azure Drive
   5. Del Development Storage al almacenamiento en la nube
2. Herramientas extra para trabajar con almacenamiento Azure
   1. Windows Azure MMC
   2. Cerebrata CSS
   3. Cerebrata Cloud Storage Studioe
3. Worker Roles en Windows Azure
   1. Introducción al Worker Role
   2. Comunicación entre Web Role y Worker Role
   3. VIDEO Mi primera aplicación con Worker Role
4. Microsoft SQL Azure
   1. Particularidades de SQL Azure respecto SQL Server
   2. Acceso programático a SQL Azure (ADO.NET, ODBC, PHP)
   3. Administrar SQL Azure SQLCMD, despliegue, monitorización, diagnóstico, aprovisionamiento
5. VIDEO Mi primera aplicación con el Service Bus de AppFabric
6. Conceptos clave del Service Bus
   1. Nomenclatura y registro de servicios
   2. Mensajería
   3. Autenticación y autorización con Access Control
   4. Buffers de Mensajes
   5. Buenas prácticas. ¿Qué binding debo usar
7. Microsoft codename “Dallas”
   1. Consumir un servicio de Dallas
   2. Consumir un servicio de Dallas desde Excel 2010

Avanzado

1. Configuración de aplicaciones Azure
2. Cómo desplegar una aplicación en Windows Azure
3. Versionado de aplicaciones Windows Azure
4. Diagnóstico y trazas de aplicaciones
5. Autenticación federada de aplicaciones web en Azure con Windows Identity Foundation
6. Diseño de arquitectura para aplicaciones escalables con Azure
   1. Particionado de datos
   2. Estado de las aplicaciones
   3. Distribución de cargas
   4. Procesamiento asíncrono
   5. Windows Azure CDN
   6. Windows Azure Dashboard
   7. Azure Throughput Analyzer
7. AppFabric Access Control
   1. Introducción a la Identidad basada en Claims
   2. Mi primera aplicación con Access Control
8. Consejos prácticos para crear aplicaciones Azure seguras
   1. Partial-Trust y Full-Trust
9. Proceso de sincronización en SQL Azure

Entre una de esas funcionalidades está la opción de poder exponer por OData el contenido de una base de datos SQL Azure.

Como seguro que ya sabéis muchos, OData es un protocolo basado en REST cuyo objetivo principal es buscar la interoperabilidad entre las aplicaciones para el intercambio de datos, independientemente de la tecnología…bueno, que OData ahora está de moda

Para el ejemplo parto de un servidor de SQL Azure creado desde mi cuenta de Azure, desde el portal de producción de Windows Azure. Después de crear el servidor he dado permisos en el firewall para que puedan conectarse aplicaciones que residan en la nube de Microsoft. Si alguien no sabe cómo hacerlo le recomiendo revisar estos post.

Dentro del servidor también he creado una base de datos con diferentes tablas y datos.

Una vez que tengo la base de datos creada en mi servidor de Azure, ya puedo ir al SQL Azure Labs y exponer la información por OData. Para ello el primer paso que tendré que realizar es conectarme al servidor y seleccionar la base de datos sobre la que deseo realizar la operación, como se muestra a continuación:

A través de la URI que te proporciona tendrías expuesto por OData las tablas de la base de datos. Para hacer la prueba permitir el acceso anónimo poniendo dbo en la selección del combo.

Fijaros que si queremos usar seguridad, sería AppFabric Access Control el que se encargaría del proceso de autenticación.

Y ya está, ya podéis consultar sobre la información expuesta.

Si ponemos un ejemplo de una petición REST en el navegador, veríamos algo como esto…

Lógicamente, también podríamos consultar la información desde una aplicación, esté hecho con .NET o con otra tecnología.

A día de hoy existen dos versiones de SQL Azure; Web Edition y Business Edition. La versión Web Edition tendrá un máximo de 5Gb, mientras que la versión Businnes tendrá un máximo de 50 Gb.

Los rangos que podemos elegir para el tamaño de la base de datos son 1, 5, 10, 20, 30, 40 y 50 GB.

Pero…

¿Qué pasa si elijo una base de datos de 1 Gb y llego a 1 Gb de espacio usado?

¿ Qué pasa si elijo una base de datos de 50 Gb y necesito más?

¿Si tengo una base de datos de 50 Gb y sólo uso 1 Gb? ¿Cuánto se paga?

Lo primero, es que sea como cuál se el tamaño elegido, el tamaño de la base de datos se puede modificar, ya se aumentando tamaño o disminuyéndolo, teniendo en cuenta que el máximo es 50 Gb. Más allá de este tamaño sería necesario crear una segunda base de datos y particionar los datos de la misma.

Otro tema a tener en cuenta, es que la facturación NO se hace por el tamaño de la base de datos elegida al crear la base de datos. Si elijo una base de datos de 50 Gb y tengo ocupados 12 Gb, no pago por una de 50, sino por una de 20.

A la hora de facturar se tienen en cuenta los rangos posibles; si mi base de datos ocupa 200mb, pagaré por el precio de la de 1 Gb, si mi base de datos ocupa 19 Gb pagaré por el precio de la de 20 Gb.

A día de hoy el giga de datos cuesta $9.99 / mes.

Si quieres saber el rango en el que te encuentras y por tanto lo que pagarás, puedes lanzar la siguiente sentencia:

SELECT DATABASEPROPERTYEX ('MyDDBB' , 'MaxSizeInBytes' ) 

Tamaño real de la base de datos, que lógicamente siempre será inferior al tamaño devuelto por la sentencia anterior.

SELECT SUM(reserved_page_count) * 8192 FROM sys.dm_db_partition_stats

Si se llega al tamaño máximo de la base de datos y se intenta insertar más datos, tendremos un bonito error

Msg 40544, Level 20, State 5, Line 1

The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Code: 524289

Si necesitamos controlar el código de error en nuestra aplicación C#, el código devuelto es el 40544.

¿Pero no habíamos dicho que base de datos puede aumentarse de tamaño de la base de datos? Sí, pero…

Si estamos en una versión Web Edition de 1Gb y necesitamos más, de manera automática SQL Azure aumenta la base de datos y nos coloca en el siguiente rango, hasta un máximo de 5 Gb.

Si estamos es una versión Business Edition, podrá ir aumentando de manera automática en los rangos soportados dentro de esta versión; 1, 5, 10, 20, 30, 40 y 50.

Lo que no se hace de manera automática es el hecho de pasar de una versión Web Edition a una Business Edition. Si es una versión Web Edition y necesitamos más de 5 Gb, la base de datos NO aumentará de forma automática a 10 Gb.

No se hace de manera automática, pero SÍ se puede hacer de forma manual.

ALTER DATABASE MyDDBB MODIFY (EDITION='BUSINESS', MAXSIZE=10GB)

Desde mi punto de vista la principal mejora es una de las más esperadas…la opción de copiar una base de datos, que permite hacer un snapshot de una base de datos de SQL Azure en tiempo real en un servidor diferente del datacenter.

No es la opción backup de SQL Server, pero sí es un primer paso para tener esta característica dentro de SQL Azure.

Podéis leer toda la información completa sobre la característica en la MSDN; cómo copiar una base de datos en el mismo servidor, de un servidor a otro, cómo monitorizar el proceso etc…

CREATE DATABASE destination_database_name
    AS COPY OF [source_server_name.]source_database_name

Además de esta característica existen otras cosas que mencionar:

Han desplegado Houston en más datacenters, con el objetivo de minimizar la latencia de red a la hora de interactuar con Houston y una base de datos SQL Azure.

Para aquellos que no os suene Houston, es una herramienta web hecha en Silverlight, que nos permite conectarnos a una base de datos SQL Azure y realizar las labores típicas que se puede realizar; manejar tablas, vistas, procedimientos almacenados, lanzar querys, abrir y lanzar ficheros sql….

Y por último, han incluido más documentación en la MSDN, han creado una sección de “HOW-TO” bastante interesante.

En este post veremos paso a paso cómo podemos migrar una base de datos Access 2010 a SQL Azure.

Lo primero es descargar la herramienta e instalarla. Prácticamente con siguiente-siguiente es posible instalarla.

Una vez descargada, ya podemos empezar a utilizarla. Si es la primera vez que la ejecutamos necesitaremos registrarnos en la página de licencia, descargarnos la licencia que nos da de forma gratuita, copiarla en el directorio de licencia y dar al botón de refrescar la licencia.

Lo primero que nos aparecerá en el wizard de migración. Podríamos saltarnos este paso y no utilizar el wizard, pero por sencillez creo que merece la pena.

Como veis, nos da elegir el destino de la migración. En este ejemplo elegiremos SQL Azure.

Seleccionamos las base de datos a migrar.

Y configuramos los objetos a migrar. Recordad que es capaz de migrar tanto el schema como los datos.

E incluimos los datos de SQL Azure…

En el caso de Access 2010, podemos decirle que las tablas de la base de datos Access apunten a las nuevas tablas, las que se van a crear en SQL Azure….lógicamente, cambia tu fichero de base de datos para que apunte a la base de datos de Azure y te necesitarás introducir las credenciales de acceso a la base de datos de Azure.

Y ya está, migrada la base de datos!

Y si no nos gusta el asistente o queremos cambiar algo, siempre lo podemos hacer de otra manera