Particularidades de SQL Azure respecto a SQL ServerSQL Azure, construido sobre SQL Server, permite incluso migrar backend de datos a la nube si tener que tocar ni una sola línea de código de nuestras aplicaciones en un gran número de escenarios. Es cierto que hay ciertas características de SQL Server que SQL Azure no soporta, pero si soporta todas las más usadas:
Entre las características no soportadas cabe destacar:
Listado completo de las limitaciones de SQL Azure. A la hora de conectar desde nuestras aplicaciones clientes, podemos elegir varios tipos de conexión:
Soporte T-SQLAunque SQL Azure está basado en SQL Server no dispone de un soporte completo a las sentencias T-SQL de SQL Server. Antes de migrar una aplicación a SQL Azure es conveniente revisar en profundidad las limitaciones para poder determinar la viabilidad de la migración. Es importante indicar que la evolución de SQL Azure dentro de la plataforma está siendo bastante importante, ya que algunas limitaciones de la misma pueden ir superándose en versiones futuras. Sentencias T-SQL soportadas parcialmente Sentencias T-SQL no soportadas. Índices clusterUna peculiaridad interesante respecto a SQL Azure es que todas las tablas necesitar tener obligatoriamente un índice clúster. Los índices clúster se encargan de guardar y ordenar los datos por el valor del índice. Sólo puede haber un índice clúster por tabla porque los datos sólo pueden estar almacenados en un orden. CREATE TABLE SampleTable (Id int NOT NULL IDENTITY,[Name] nvarchar(max), Si en el momento de la creación no se especifica un índice clúster SQL Azure no avisará del error pero sí se producirá un error si se intentan insertar datos en una tabla sin índice clúster . Esta característica afecta únicamente a las tablas "permanentes" de la base de datos, no afectando por tanto a las tablas temporales. Modelo de seguridadLas base de datos de SQL Azure puede contener información confidencial por lo que es esencial para controlar cuidadosamente el acceso. Este aspecto se hace especialmente importante debido a que una base de datos de una cuenta puede compartir el mismo servidor con otras base de datos de otras cuentas. SQL Azure debe poder ofrecer un nivel de aislamiento adecuado para asegurar la confidencialidad de los datos. SQL Azure se basa en los mismos mecanismos de seguridad existentes en SQL Server.
Tamaño de SQL AzureUna de las restricciones de SQL Azure es el tamaño. A día de hoy existen dos versiones de SQL Azure; Web Edition y Business Edition. La versión Web Edition tiene un máximo de 5Gb, mientras que la versión Bussiness tiene un máximo de 50 Gb. En la creación de una base de datos SQL Azure es posible elegir el tamaño de la misma, siempre teniendo en cuenta el máximo permitido. Los rangos que pueden elegirse son 1, 5, 10, 20, 30, 40 y 50 GB.
Este comportamiento puede suscitar múltiples preguntas sobre cómo SQL Azure se comporta al llegar a los límites establecidos. Por ejemplo ¿Qué pasaría si se elije una base de datos de 1 Gb y alcanza 1 Gb de espacio usado? ¿ Qué pasaría si se elije una base de datos de 50 Gb y se llega al máximo permitido? ¿Si se crea una base de datos de 50 Gb y sólo se hace uso de 1 Gb? ¿Cómo se realiza la facturación? El primero punto a tener en cuenta es que sea cuál sea el tamaño elegido, el tamaño de la base de datos se puede modificar, ya sea aumentando tamaño o disminuyéndolo, lógicamente, 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. El segundo aspecto tener en cuenta, es que la facturación no se realiza por el tamaño de la base de datos elegida al crearla. Si crea una base de datos de 50 Gb y se usan 12 Gb, no se factura por una de 50 Gb, sino por una de 20 Gb. En la facturación se tienen en cuenta los rangos posibles; si la base de datos ocupa 200mb, se pagará por el precio de la de 1 Gb, si la base de datos ocupa 19 Gb se pagará por el precio de la de 20 Gb. Para saber el rango en el que se encuentra la base de datos y por tanto lo que se factura por el uso, puede lanzarse 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, se mostrará el siguiente 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 Anteriormente comentábamos que una base de datos Azure puede aumentar de tamaño pero no siempre lo puede hacer de manera automática. Si la base de datos es una versión Web Edition de 1Gb y se necesita aumentar el tamaño, SQL Azure, de manera automática, aumenta la base de datos y la coloca en el siguiente rango, hasta un máximo de 5 Gb. Si la base de datos 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 se necesitan más de 5 Gb, la base de datos no aumentará de forma automática a 10 Gb. SQL Azure no lo hace de manera automática pero sí se puede hacer de forma manual. ALTER DATABASE MyDDBB MODIFY (EDITION='BUSINESS', MAXSIZE=10GB) El collation de SQL AzureOtra de las peculiaridades de SQL Azure están en el collation que emplea. SQL Azure dispone de una configuración a nivel de servidor y base de datos que no puede ser modificada. El collation del servidor es siempre SQL_Latin1_General_CP1_CI_AS. El collation de todas las base de datos es siempre SQL_Latin1_General_CP1_CI_AS. Si se desea comprobar que realmente esa configuración puede lanzarse este comando: SELECT SERVERPROPERTY('Collation')
A nivel de servidor o de base de datos no puede cambiarse la configuración, pero sí se podría cambiar a nivel de columna. Al definir una columna es posible 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 Las DMVs en SQL AzureDesde su aparición en SQL Server 2005 las DMVs han sido una herramienta muy necesaria para poder detectar y solucionar problemas de rendimiento en SQL Server. SQL Azure está basado en SQL Server, pero muchas de las DMVs no están disponibles en esta primera versión de Azure. El principal problema por el cuál no están soportadas todas las DMVs es porque en SQL Server éstas funcionan a nivel de instancia mientras que en SQL Azure tendrían que funcionar a nivel de base de datos. Un ejemplo clarificador puede ser el permiso que hay que tener para trabajar con DMVs. En SQL Azure es VIEW DATABASE STATE, mientras que en SQL Server es VIEW SERVER STATE. A continuación se muestra algún ejemplo de algunas acciones disponibles en SQL Azure. Identificar los planes de ejecución que provocan excesivas recompilaciones: select top 25 sql_text.text, sql_handle, plan_generation_num, Identificar planes de ejecución ineficientes:
|
.png)
.png)