La lliçó anterior va acabar amb una decisió escrita: les reserves i els vols de Contoso Airlines van a Azure SQL Database, perquè una plaça no es pot vendre dues vegades i això exigeix transaccions ACID i integritat referencial de debò. Avui s'executa aquesta decisió. Al final existiran el servidor lògic sql-contoso-reservas-pro i la base de dades db-reservas, amb el seu esquema, els seus índexs, la seva autenticació amb Microsoft Entra ID i el seu punt de connexió privat pe-sql-reservas dins de snet-datos, tancant el forat que el mòdul 2 va deixar dibuixat però buit. És el servei relacional més madur d'Azure i el que obliga a prendre més decisions —model de compra, nivell, redundància, autenticació i xarxa—, així que les veurem amb el criteri de quan triar cada cosa.

Avís de cost important: una base d'Ús general amb 2 vCore ronda els 370 € al mes i factura les 24 hores: no existeix l'estat «aturada» d'una màquina virtual. L'única manera de deixar de pagar còmput és el nivell sense servidor amb pausa automàtica o eliminar la base. Crític per a l'empresa multiplica el preu per tres. Per practicar, fes servir el nivell sense servidor a rg-contoso-reservas-dev i elimina el grup de recursos en acabar.

1. Què és, i per què el servidor no és una màquina
2. Models de compra i nivells de servei
3. Sense servidor, pausa automàtica i grups elàstics
4. Desplegament complet amb Azure CLI
5. Autenticació amb Microsoft Entra ID
6. Punt de connexió privat i tancament de l'accés públic
7. L'esquema de reserves i els seus índexs
8. Còpies de seguretat i restauració a un moment donat
9. Alta disponibilitat, rèpliques de lectura i commutació per error
10. Seguretat de la dada: xifratge, emmascarament i auditoria
11. Rendiment, escalat en calent i control de la despesa
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Azure SQL Database és el motor de SQL Server ofert com a plataforma gestionada, amb una diferència conceptual important: no hi ha cap instància de SQL Server que sigui teva. Hi ha una base de dades amb el seu propi còmput, les seves còpies i el seu cicle de vida.

Contoso tria Azure SQL Database perquè db-reservas és un esquema nou: no arrossega treballs de l'Agent SQL ni consultes entre bases, així que Managed Instance seria pagar una compatibilitat que ningú no farà servir. I aquí hi ha el punt on gairebé tothom s'equivoca: sql-contoso-reservas-pro no és una màquina. És un servidor lògic, un contenidor administratiu sense CPU ni memòria pel qual no es paga res. Hi viuen el nom DNS <nom>.database.windows.net, els administradors de SQL i de Microsoft Entra ID, les regles de tallafoc de servidor, la configuració de xarxa (accés públic, TLS mínim, punts de connexió privats) i les directives d'auditoria heretables. A cada base de dades hi viuen el nivell de servei i el seu cost, l'esquema i les dades, els seus usuaris, la retenció i redundància de còpies i l'emmascarament dinàmic. Conseqüència pràctica: dues bases del mateix servidor poden costar coses molt diferents, però comparteixen DNS, tallafoc i administradors; per això Contoso separa servidors per entorn en lloc de barrejar producció i desenvolupament.

Contoso tria vCore: necessita el nivell sense servidor per a desenvolupament i vol aplicar Azure Hybrid Benefit amb les seves llicències de SQL Server, cosa que es detalla a la lliçó 08-03. Dins de vCore hi ha tres nivells, els noms dels quals descriuen la seva arquitectura interna més bé del que sembla (en DTU els equivalents són Bàsic, Estàndard i Premium, amb el mateix ordre de preu):

Decisió de Contoso: Ús general, 2 vCore, amb redundància de zona en producció. El volum és de 40 GB creixent 12 GB l'any, molt lluny del sostre, i 5-10 ms de latència són irrellevants dins d'una petició HTTP de 200 ms. Crític per a l'empresa triplicaria el cost per resoldre un problema que no existeix.

El nivell sense servidor (a Ús general i Hiperescala) defineix un rang mínim i màxim de vCores, escala dins d'aquest rang i factura per segon consumit. Si la base passa un temps configurable sense connexions, es pausa i deixa de facturar còmput. Quatre matisos imprescindibles:

• L'emmagatzematge es paga sempre, estigui pausada o no; el que desapareix és la partida dominant.
• La primera connexió després de la pausa triga entre 30 i 60 segons i falla si el client no reintenta. L'aplicació necessita reintents amb espera exponencial, cosa obligatòria al núvol de totes maneres.
• El retard mínim de pausa és de 60 minuts: serveix entre jornades, no entre peticions.
• A plena ocupació resulta més car que l'aprovisionat. És per a càrrega intermitent.

Un grup elàstic és l'altra eina d'estalvi: un conjunt de vCores compartit per moltes bases els pics de les quals no coincideixen. Contoso el té previst per a un escenari concret: si cada agència associada acaba tenint la seva base aïllada —unes 40 bases petites, esporàdiques i en fusos horaris diferents—, el grup costaria una fracció de 40 bases aprovisionades. Regla: moltes bases petites amb pics no simultanis.

Primer el servidor lògic, recordant que no crea cap màquina ni genera cost per si mateix. La contrasenya no s'escriu mai a l'script: es demana per teclat o es llegeix de Key Vault (04-03).

Dos detalls separen un desplegament correcte d'un que caldrà arreglar: tancar l'accés públic abans que existeixi cap dada —obrir el just després és molt més fàcil que tancar el que ja funcionava— i posar les quatre etiquetes obligatòries des del minut zero, perquè sense centro-coste no es pot repartir la factura al mòdul 8.

L'usuari i contrasenya d'administrador és un mal mecanisme permanent: secret compartit, sense caducitat, sense MFA i, si es filtra, obre la base sencera. L'alternativa és designar un administrador de Microsoft Entra ID:

S'assigna un grup i no la Marta Ríos directament perquè les persones canvien de lloc de treball i els grups no. Amb ad-only-auth enable, l'usuari i contrasenya deixen de funcionar i tota l'autenticació passa per Entra ID, amb el seu MFA i el seu accés condicional. L'aplicació d'App Service s'hi connectarà amb la seva identitat administrada, sense cap contrasenya a la cadena de connexió: es munta a la lliçó 04-02, i els secrets restants es centralitzen a Key Vault (04-03).

Amb l'accés públic deshabilitat, la base només és accessible des de la xarxa. Es crea pe-sql-reservas a snet-datos (10.20.3.0/24) i, amb ell, la resolució de noms: l'aplicació continuarà demanant sql-contoso-reservas-pro.database.windows.net i aquest nom ha de resoldre a la IP privada.

Resultat: des de snet-app, el nom de sempre resol a una adreça 10.20.3.x. Des d'internet no resol a res útil i, encara que algú conegués la IP, el tallafoc rebutjaria la connexió. Per administrar des de fora hi ha tres camins i només dos són recomanables: la VPN de punt a lloc (02-06), una VM de gestió a snet-gestion a través de Bastion, o una regla de tallafoc temporal amb la teva IP, que és l'opció que acaba oblidada oberta durant mesos.

La restricció CHECK sobre PlazasLibres és la xarxa de seguretat que cap aplicació no es pot saltar: encara que el codi tingui un error de concurrència, el motor impedirà que les places baixin de zero, que és justament la garantia per la qual es va triar una base relacional. L'ordre de les columnes de l'índex no és decoratiu: el motor pot fer servir IX_Vuelos_Ruta_Salida filtrant per Origen, per Origen + Destino o pels tres, però no per buscar només per SalidaUtc. L'INCLUDE afegeix les columnes que la consulta retorna sense que formin part de la clau, de manera que es resol sense tornar a la taula: és un índex de cobertura. I l'avís contrari, que sempre s'oblida: cada índex es paga en espai i en velocitat d'escriptura. Tres índexs ben triats cobreixen el 95 % de la càrrega; quinze degraden la venda de bitllets.

Azure SQL Database copia automàticament i sense configuració: completes setmanals, diferencials cada 12-24 hores i del registre de transaccions cada 5-10 minuts. D'aquí surt poder restaurar a qualsevol instant del període de retenció. Hi ha dues retencions: la de curt termini, d'1 a 35 dies (7 per defecte), que cobreix els errors operatius, i la de llarg termini, de fins a 10 anys en còpies setmanals, mensuals i anuals, per a obligacions legals i auditoria.

El dimarts a la tarda. El Diego Salas executa a les 16:40 un script que havia d'actualitzar 300 reserves antigues i, per un WHERE mal copiat, marca com a anulada tota la taula. A les 16:52 comencen les trucades d'atenció al client. La resposta correcta no és reparar les dades a mà:

Tres coses que cal gravar: la restauració crea sempre una base nova i mai no sobreescriu l'original, cosa que permet comparar abans de decidir; l'hora és UTC, i a l'agost Espanya va dues hores per davant, així que equivocar-se aquí és restaurar a un punt inútil; i la base restaurada també factura, així que es recuperen les files, s'intercanvien noms i s'elimina el mateix dia.

La restauració geogràfica és diferent: fa servir les còpies replicades a North Europe i serveix quan tot West Europe està caigut. El seu objectiu de punt de recuperació arriba a una hora, així que pot perdre els últims minuts, i exigeix haver triat redundància de còpies Geo o GeoZone en crear la base.

Dins de la regió, l'alta disponibilitat ve inclosa: amb --zone-redundant true el còmput té rèpliques en diverses zones i l'SLA és del 99,99 %. Crític per a l'empresa hi afegeix un clúster de quatre nodes i una rèplica de lectura gratuïta, accessible amb ApplicationIntent=ReadOnly a la cadena de connexió: la manera neta que els informes del tauler d'operacions no competeixin amb la venda. Entre regions es fa servir un grup de commutació per error, que replica la base i aporta un nom DNS estable que sempre apunta al primari:

L'aplicació es connecta a fg-contoso-reservas.database.windows.net sense saber quina regió està activa. Coherentment amb la decisió de cost del mòdul 1, no és actiu-actiu: North Europe només serveix lectures i ascendeix si West Europe cau. Tot i així duplica el cost de còmput, perquè la rèplica és una base completa que factura; Contoso ho valorarà amb la resta del pla de continuïtat a la lliçó 07-05.

Quatre capes complementàries, de menys a més esforç:

• Xifratge de dades transparent (TDE): xifra fitxers de dades i còpies en repòs. Activat per defecte. Protegeix del robatori del mitjà físic, no d'un usuari amb permisos.
• Always Encrypted: xifra columnes concretes al client, amb una clau que el motor no té; ni un administrador no les pot llegir. El preu és alt: sobre una columna amb xifratge aleatori no es pot filtrar ni ordenar al servidor. Contoso ho reserva per a les dades de pagament, amb la clau a Key Vault (04-03).
• Emmascarament dinàmic de dades: no xifra; amaga el valor al resultat segons qui consulta.
• Auditoria: registra qui va executar què i quan, amb destinació a Log Analytics (mòdul 7).

L'emmascarament no s'aplica als administradors ni a qui tingui concedit UNMASK, i no substitueix els permisos: si algú no ha de veure una columna, el correcte és no donar-li accés. L'auditoria s'activa amb az sql server audit-policy update -g $GRUP -n $SERVIDOR --state Enabled --log-analytics-target-state Enabled --log-analytics-workspace-resource-id $WORKSPACE_ID, enviant cada esdeveniment a l'àrea de treball que s'explotarà amb KQL a la lliçó 07-02.

El magatzem de consultes està activat per defecte i desa consultes, plans i estadístiques d'execució. És el que converteix «la web va lenta des d'ahir» en un diagnòstic concret:

Ordenar per CPU total (execucions × temps mitjà) i no per durada és clau: una consulta de 8 ms llançada 400.000 vegades al dia fa molt més mal que un informe de 4 segons que s'executa una vegada. Al portal, Query Performance Insight presenta el mateix en gràfics i és el primer lloc on anar davant d'una queixa de lentitud; l'ajust automàtic pot a més crear índexs que falten i revertir plans que van empitjorar. Escalar, per la seva banda, és una sola ordre i s'aplica en calent, amb uns segons de desconnexió al final que l'aplicació absorbeix si reintenta:

Aquest escalat s'automatitza per calendari amb Azure Automation (07-04), igual que el perfil apertura-temporada-verano del mòdul 2.

• Creure que el servidor lògic costa diners o que és una màquina. No costa res i no té CPU: facturen les bases.
• Restaurar amb l'hora local. Les marques de temps són UTC; a l'estiu, dues hores de desfasament poden significar recuperar les dades ja destrossades.
• Oblidar la base restaurada. Factura igual que l'original. Esborra-la el mateix dia.
• Deixar activat «Permetre serveis d'Azure». No vol dir «els meus serveis»: vol dir qualsevol recurs d'Azure, inclosa la subscripció d'un tercer. Amb punt de connexió privat no cal.
• Posar Crític per a l'empresa «per si de cas». Triplica el cost. Puja-hi quan el magatzem de consultes demostri que l'E/S és el coll d'ampolla, i no abans.
• Crear un índex per cada consulta lenta, o confondre emmascarament amb xifratge. Revisa abans si un índex existent pot cobrir la consulta canviant l'ordre de columnes o l'INCLUDE; i recorda que l'emmascarament és cosmètic: qui és administrador ho veu tot.
• Consell: activa la retenció a llarg termini abans que l'exigeixi una auditoria; no s'aplica retroactivament a còpies ja caducades.
• Consell: implementa sempre reintents amb espera exponencial. En PaaS, les desconnexions breus durant manteniment o escalat són normals, no una fallada.

db-reservas en producció té 40 GB i 300 transaccions per segon en hora punta, disponible 24×7; en desenvolupament, 2 GB usats de dilluns a divendres de 9 a 18 h.

1. Tria model de compra, nivell i model de còmput per a cada entorn, justificant cada decisió.
2. Quina redundància de còpies posaries a cadascun i per què?

Un dimecres a les 09:15 hora peninsular (estiu), un script elimina 12.000 files de dbo.Reservas. Es detecta a les 11:30.

1. Quina ordre executaries i amb quina marca de temps exacta?
2. Per què no es restaura directament sobre db-reservas?
3. Què faries després amb la base restaurada?

Audites sql-contoso-reservas-pro i hi trobes: accés públic habilitat, una regla de tallafoc 0.0.0.0 - 255.255.255.255, la casella de serveis d'Azure activada, autenticació només per usuari i contrasenya, i auditoria desactivada.

1. Ordena les correccions de major a menor risc.
2. Escriu les ordres de les tres primeres.
3. Què cal verificar abans de deshabilitar l'accés públic per no deixar la web sense base de dades?

Solució 1:

1. Tots dos en vCore, que habilita sense servidor i Azure Hybrid Benefit. Producció: Ús general, 2 vCore Gen5, aprovisionat i amb redundància de zona, perquè la càrrega és sostinguda i 24×7 i 300 transaccions per segon amb 5-10 ms de latència hi caben de sobres. Desenvolupament: Ús general sense servidor, de 0,5 a 2 vCore amb pausa als 60 minuts, perquè es fa servir unes 45 h de les 168 de la setmana: elimina al voltant del 70 % de la partida de còmput sense canviar la manera de treballar de l'equip.
2. Producció, Zone com a mínim, i GeoZone si es vol poder fer restauració geogràfica, que n'és requisit. Desenvolupament, Local: les dades són sintètiques i regenerables, així que la redundància geogràfica és despesa pura.

Solució 2:

1. Les 09:15 peninsulars d'estiu són les 07:15 UTC; es pren un marge de seguretat cap enrere:

2. Perquè no es pot: la restauració a un moment donat crea sempre una base nova. I és una virtut, no una limitació: durant aquestes dues hores i quart s'han creat reserves legítimes que es perdrien en substituir la base sencera. El correcte és extreure de la restaurada només les files que ja no existeixen (WHERE NOT EXISTS sobre ReservaId) i inserir-les a l'original amb SET IDENTITY_INSERT ON; com que a Azure SQL Database no hi ha consultes entre bases, es fa exportant amb bcp o amb una canalització de dades.
3. Eliminar-la el mateix dia amb az sql db delete, després de verificar els recomptes. Si s'oblida, factura cada hora com una base més.

Solució 3:

1. Ordre per risc: (a) la regla 0.0.0.0-255.255.255.255, que exposa la base al món sencer; (b) l'accés públic habilitat; (c) la casella de serveis d'Azure, que admet connexions des de subscripcions alienes; (d) l'autenticació local sense Entra ID ni MFA; (e) l'auditoria desactivada, que no obre cap risc però impedeix investigar el que ha passat.
2. Ordres:

3. Que pe-sql-reservas estigui aprovisionat i aprovat, que la zona privatelink.database.windows.net estigui vinculada a vnet-contoso-pro, i que l'aplicació d'App Service tingui activada la integració amb la xarxa virtual (02-05); sense això resoldria el nom públic i perdria la connexió tan bon punt es tanqui l'accés.

db-reservas ja existeix de debò. Saps que sql-contoso-reservas-pro és un servidor lògic sense CPU ni cost, que agrupa DNS, tallafoc i administradors mentre la despesa viu a cada base. Has triat amb criteri entre DTU i vCore i entre Ús general, Crític per a l'empresa i Hiperescala, has aplicat el nivell sense servidor amb pausa automàtica a l'entorn de desenvolupament i coneixes l'escenari dels grups elàstics. Has desplegat servidor i bases amb Azure CLI, amb les quatre etiquetes obligatòries i l'accés públic tancat des de la primera ordre, has designat un administrador de Microsoft Entra ID sobre un grup i activat l'autenticació exclusiva d'Entra, i has connectat la base a snet-datos mitjançant pe-sql-reservas i la seva zona DNS privada, de manera que el nom de sempre resol a una IP 10.20.3.x.

A més has creat l'esquema de vols, passatgers i reserves amb una restricció CHECK que impedeix vendre places inexistents i dos índexs de cobertura justificats per consultes reals; has recuperat la plataforma de la migració fallida del dimarts amb una restauració a un moment donat en UTC; i has cobert la restauració geogràfica, l'alta disponibilitat amb redundància de zona, les rèpliques de lectura, el grup de commutació per error a North Europe amb el seu nom DNS estable i el seu cost duplicat, les quatre capes de seguretat de la dada —TDE, Always Encrypted, emmascarament de la targeta de fidelització i auditoria—, el magatzem de consultes i l'escalat en calent.

Però el motor relacional no ho resol tot. El catàleg de tarifes de Contoso té condicions diferents per a cada tipus de bitllet, canvia de forma cada temporada i es consulta milers de vegades per minut des de la web i des de l'API de Disponibilitat, amb clients a tot Europa i Amèrica. Normalitzar-lo significaria vint taules i consultes amb deu unions per respondre una cosa tan simple com «dona'm aquesta tarifa completa». A la lliçó següent, Azure Cosmos DB, veuràs l'altre extrem del mapa de dades: documents JSON, distribució global, la clau de partició com la decisió més irreversible del disseny, les unitats de sol·licitud que mesuren el que costa cada consulta i cinc nivells de consistència per triar, dada a dada, entre exactitud i latència.