Nowa baza danych w chmurze — zarządzanie usługą Azure SQL Database po migracji

Dotyczy:Azure SQL Database

Migracja ze środowiska zarządzanego do rozwiązania PaaS, takiego jak usługa Azure SQL Database, może być złożona. W tym artykule przedstawiono najważniejsze możliwości usługi Azure SQL Database dla pojedynczych baz danych i baz danych w puli, co ułatwia zapewnienie dostępności aplikacji, wydajnej, bezpiecznej i odpornej na błędy.

Podstawowe cechy usługi Azure SQL Database obejmują:

• Monitorowanie bazy danych za pomocą witryny Azure Portal
• Ciągłość biznesowa i odzyskiwanie po awarii (BCDR)
• Zabezpieczenia i zgodność
• Inteligentne monitorowanie i konserwacja bazy danych
• Przenoszenie danych

Uwaga

Microsoft Entra ID był wcześniej znany jako Azure Active Directory (Azure AD).

Monitorowanie baz danych za pomocą witryny Azure Portal

Aby zapoznać się z metrykami i alertami usługi Azure Monitor, w tym zalecanymi regułami alertów, zobacz Monitorowanie usługi Azure SQL Database za pomocą metryk i alertów. Aby uzyskać więcej informacji na temat warstw usług, zobacz Przegląd modelu zakupów opartego na jednostkach DTU i przegląd modelu zakupów opartego na vCore.

Alerty dotyczące metryk wydajności można skonfigurować. Wybierz przycisk Dodaj alert w oknie Metryka. Użyj kreatora, aby skonfigurować alert. Możesz otrzymywać alerty, jeśli metryki przekraczają określony próg lub jeśli metryka spadnie poniżej określonego progu.

Jeśli na przykład spodziewasz się, że obciążenie bazy danych wzrośnie, możesz skonfigurować alert polegający na wysłaniu wiadomości e-mail, gdy dowolna z metryk wydajności osiągnie 80%. Możesz użyć tego jako wczesnego ostrzeżenia, aby ustalić, kiedy może być konieczne przełączenie się do następnego najwyższego rozmiaru obliczeniowego.

Metryki wydajności mogą również pomóc w ustaleniu, czy można obniżyć poziom do niższego rozmiaru obliczeniowego. Należy jednak pamiętać o obciążeniach, które wzrosły lub wahały się przed podjęciem decyzji o przejściu do niższego rozmiaru obliczeniowego.

Ciągłość biznesowa i odzyskiwanie po awarii (BCDR)

Możliwości ciągłości działania i odzyskiwania po awarii umożliwiają kontynuowanie działalności biznesowej w przypadku wystąpienia awarii. Awaria może być zdarzeniem na poziomie bazy danych (na przykład ktoś błędnie popadnie w kluczową tabelę) lub zdarzeniem na poziomie centrum danych (katastrofa regionalna, na przykład tsunami).

Jak tworzyć kopie zapasowe w usłudze SQL Database i zarządzać nimi?

Usługa Azure SQL Database automatycznie wykonuje kopie zapasowe baz danych. Platforma wykonuje pełną kopię zapasową co tydzień, różnicową kopię zapasową co kilka godzin, a kopia zapasowa dziennika co 5 minut w celu zapewnienia wydajności odzyskiwania po awarii, a utrata danych jest minimalna. Pierwsza pełna kopia zapasowa jest wykonywana zaraz po utworzeniu bazy danych. Te kopie zapasowe są dostępne przez określony okres nazywany okresem przechowywania, który różni się w zależności od wybranej warstwy usługi. Możesz przywrócić do dowolnego punktu w czasie w tym okresie przechowywania przy użyciu funkcji Punkt w czasie odzyskiwania (PITR).

Ponadto funkcja tworzenia kopii zapasowych przechowywania długoterminowego umożliwia przechowywanie plików kopii zapasowych przez maksymalnie 10 lat i przywracanie danych z tych kopii zapasowych w dowolnym momencie w tym okresie. Kopie zapasowe bazy danych są przechowywane w magazynie replikowanym geograficznie w celu zapewnienia odporności z powodu katastrofy regionalnej. Możesz również przywrócić te kopie zapasowe w dowolnym regionie świadczenia usługi Azure w dowolnym momencie w okresie przechowywania. Aby uzyskać więcej informacji, zobacz Ciągłość działania w usłudze Azure SQL Database.

Jak zapewnić ciągłość działania w przypadku awarii na poziomie centrum danych lub katastrofy regionalnej?

Kopie zapasowe bazy danych są przechowywane w magazynie replikowanym geograficznie, aby upewnić się, że podczas awarii regionalnej można przywrócić kopię zapasową do innego regionu świadczenia usługi Azure. Jest to nazywane przywracaniem geograficznym. Aby uzyskać więcej informacji i harmonogram przywracania geograficznego, zobacz Przywracanie geograficzne dla usługi Azure SQL Database.

W przypadku baz danych o krytycznym znaczeniu usługa Azure SQL Database oferuje aktywną replikację geograficzną, która tworzy pomocniczą kopię replikowanej geograficznie oryginalnej bazy danych w innym regionie. Jeśli na przykład baza danych jest początkowo hostowana w regionie Zachodnie stany USA platformy Azure i chcesz mieć regionalną odporność na awarie, utwórz aktywną replikę geograficzną bazy danych w regionie Zachodnie stany USA do wschodnich stanów USA. Gdy nieszczęście uderza w Zachodnie stany USA, możesz przejść w tryb failover w regionie Wschodnie stany USA.

Oprócz aktywnej replikacji geograficznej, grupy przełączania awaryjnego ułatwiają zarządzanie replikacją i przełączaniem awaryjnym dla grupy baz danych. Możesz utworzyć grupę trybu failover zawierającą wiele baz danych w tych samych lub różnych regionach. Następnie można zainicjować tryb failover wszystkich baz danych w grupie trybu failover do regionu pomocniczego. Aby uzyskać więcej informacji, zobacz Omówienie i dobre praktyki dotyczące grup przełączania awaryjnego (Azure SQL Database).

Aby zapewnić odporność na awarie centrum danych lub strefy dostępności, upewnij się, że dla bazy danych lub elastycznej puli włączono nadmiarowość strefy.

Aktywnie monitoruj aplikację pod kątem awarii i inicjuj przejście w tryb failover do pomocniczej wersji. W różnych regionach świadczenia usługi Azure można utworzyć maksymalnie cztery takie aktywne repliki geograficzne. Staje się jeszcze lepiej. Dostęp do tych pomocniczych aktywnych replik geograficznych można również uzyskać w celu uzyskania dostępu tylko do odczytu. Pomaga to zmniejszyć opóźnienie scenariusza aplikacji rozproszonej geograficznie.

Jak wygląda odzyskiwanie po awarii w usłudze SQL Database?

Konfigurację i zarządzanie odzyskiwaniem po awarii można wykonać za pomocą kilku kroków w usłudze Azure SQL Database, gdy używasz aktywnej replikacji geograficznej lub grup trybu failover. Nadal musisz monitorować aplikację i jej bazę danych pod kątem awarii regionalnej i przejść w tryb failover do regionu pomocniczego w celu przywrócenia ciągłości działania.

Aby uzyskać więcej informacji, zobacz Odzyskiwanie po awarii usługi Azure SQL Database 101.

Zabezpieczenia i zgodność

Zabezpieczenia w usłudze SQL Database są dostępne na poziomie bazy danych i na poziomie platformy. Możesz kontrolować i zapewnić optymalne zabezpieczenia aplikacji w następujący sposób:

• Tożsamość i uwierzytelnianie (uwierzytelnianie SQL i uwierzytelnianie przy użyciu Microsoft Entra ID).
• Działanie monitorowania (inspekcja i wykrywanie zagrożeń).
• Ochrona rzeczywistych danych (Transparent Data Encryption [TDE] i Always Encrypted).
• Kontrolowanie dostępu do poufnych i uprzywilejowanych danych (zabezpieczenia na poziomie wiersza i dynamiczne maskowanie danych).

Microsoft Defender dla Chmury oferuje scentralizowane zarządzanie zabezpieczeniami między obciążeniami działającymi na platformie Azure, lokalnie i w innych chmurach. Możesz sprawdzić, czy podstawowa ochrona bazy danych SQL, taka jak Inspekcja i Przezroczyste szyfrowanie danych [TDE] są skonfigurowane na wszystkich zasobach, i tworzyć zasady na podstawie własnych wymagań.

Jakie metody uwierzytelniania użytkowników są oferowane w usłudze SQL Database?

Istnieją dwie metody uwierzytelniania oferowane w usłudze SQL Database:

• Uwierzytelnianie Microsoft Entra
• Uwierzytelnianie SQL

Uwierzytelnianie systemu Windows nie jest obsługiwane. Microsoft Entra ID to scentralizowana usługa zarządzania tożsamościami i dostępem. Microsoft Entra ID zapewnia jednokrotne logowanie (SSO) dla personelu w Twojej organizacji. Oznacza to, że poświadczenia są współużytkowane przez usługi platformy Azure w celu łatwiejszego uwierzytelniania.

Microsoft Entra ID obsługuje uwierzytelnianie wieloskładnikowe i można je łatwo zintegrować z usługą Active Directory systemu Windows Server. Dzięki temu usługi SQL Database i Azure Synapse Analytics mogą oferować uwierzytelnianie wieloskładnikowe i konta użytkowników-gości w domenie firmy Microsoft Entra. Jeśli używasz już lokalnej usługi Active Directory, możesz sfederować ją z identyfikatorem Microsoft Entra ID, aby rozszerzyć katalog na platformę Azure.

Uwierzytelnianie SQL obsługuje tylko nazwę użytkownika i hasło do uwierzytelniania użytkowników w dowolnej bazie danych na danym serwerze.

Jeśli...	SQL Database / Azure Synapse Analytics
Używane usługi AD w środowisku lokalnym programu SQL Server	Federuj usługę AD z identyfikatorem Entra firmy Microsoft i użyj uwierzytelniania Microsoft Entra. Federacja umożliwia korzystanie z logowania jednokrotnego.
Należy wymusić uwierzytelnianie wieloskładnikowe	Wymagaj uwierzytelniania wieloskładnikowego jako zasady za pośrednictwem dostępu warunkowego i używaj Microsoft Entra uwierzytelnianie wieloskładnikowe.
Jesteś zalogowany do systemu Windows za pomocą poświadczeń Microsoft Entra z domeny federacyjnej.	Skorzystaj z uwierzytelniania Microsoft Entra.
Zalogowani do systemu Windows przy użyciu poświadczeń z domeny, która nie jest sfederowaną z platformą Azure	Użyj zintegrowanego uwierzytelniania firmy Microsoft Entra.
Posiadanie usług warstwy środkowej, które muszą łączyć się z usługą SQL Database lub Azure Synapse Analytics	Użyj zintegrowanego uwierzytelniania firmy Microsoft Entra.
Wymaganie techniczne dotyczące korzystania z uwierzytelniania SQL	Korzystanie z uwierzytelniania SQL

Jak ograniczyć lub kontrolować dostęp do łączności z moją bazą danych?

Istnieje wiele technik, których można użyć do uzyskania optymalnej organizacji łączności dla aplikacji.

• Reguły zapory
• Punkty końcowe usługi dla sieci wirtualnej
• Zastrzeżone adresy IP

Firewall

Domyślnie wszystkie połączenia z bazami danych na serwerze są niedozwolone, z wyjątkiem (opcjonalnie) połączeń przychodzących z innych usług platformy Azure. Za pomocą reguły zapory można otworzyć dostęp do serwera tylko dla podmiotów (na przykład maszyny deweloperskiej), które zatwierdzasz, zezwalając na adres IP tego komputera przez zaporę. Umożliwia również określenie zakresu adresów IP, które chcesz zezwolić na dostęp do serwera. Na przykład adresy IP maszyny deweloperów w organizacji można dodać jednocześnie, określając zakres na stronie Ustawienia zapory.

Reguły zapory można tworzyć na poziomie serwera lub na poziomie bazy danych. Reguły zapory adresów IP na poziomie serwera można utworzyć przy użyciu witryny Azure Portal lub programu SSMS. Aby uzyskać więcej informacji na temat ustawiania reguły zapory na poziomie serwera i na poziomie bazy danych, zobacz Tworzenie reguł zapory adresów IP w usłudze SQL Database.

Punkty końcowe usługi

Domyślnie baza danych jest skonfigurowana tak, aby zezwalała usługom i zasobom platformy Azure na dostęp do tego serwera, co oznacza, że każda maszyna wirtualna na platformie Azure może próbować nawiązać połączenie z bazą danych. Te próby nadal muszą być uwierzytelnione. Jeśli nie chcesz, aby baza danych była dostępna dla żadnych adresów IP platformy Azure, możesz wyłączyć opcję Zezwalaj usługom i zasobom platformy Azure na dostęp do tego serwera. Ponadto można skonfigurować punkty końcowe usługi sieci wirtualnej.

Punkty końcowe usługi umożliwiają udostępnianie krytycznych zasobów Azure tylko dla własnej prywatnej sieci wirtualnej w Azure. Ta opcja eliminuje publiczny dostęp do zasobów. Ruch między siecią wirtualną a platformą Azure pozostaje w sieci szkieletowej platformy Azure. Bez punktów końcowych usługi, routing pakietów odbywa się poprzez wymuszone tunelowanie. Sieć wirtualna wymusza ruch internetowy do organizacji, a ruch usługi platformy Azure przechodzi przez tę samą trasę. Za pomocą punktów końcowych usługi można to zoptymalizować, ponieważ pakiety przepływają bezpośrednio z sieci wirtualnej do usługi w sieci szkieletowej platformy Azure.

Zastrzeżone adresy IP

Inną opcją jest aprowizacja zarezerwowanych adresów IP dla maszyn wirtualnych i dodanie tych określonych adresów IP maszyn wirtualnych w ustawieniach zapory serwera. Przypisując zastrzeżone adresy IP, możesz zaoszczędzić problemy z koniecznością zaktualizowania reguł zapory przy użyciu zmieniających się adresów IP.

W jakim porcie nawiązujem połączenie z usługą SQL Database?

Usługa SQL Database komunikuje się za pośrednictwem portu 1433. Aby nawiązać połączenie z sieci firmowej, musisz dodać regułę ruchu wychodzącego w ustawieniach zapory organizacji. Zgodnie z wytycznymi unikaj uwidaczniania portu 1433 poza granicą platformy Azure.

Jak monitorować i regulować aktywność na serwerze i bazie danych w usłudze SQL Database?

Inspekcja bazy danych SQL

Inspekcja usługi Azure SQL Database rejestruje zdarzenia bazy danych i zapisuje je w pliku dziennika inspekcji na koncie usługi Azure Storage. Inspekcja jest szczególnie przydatna, jeśli zamierzasz uzyskać wgląd w potencjalne naruszenia zabezpieczeń i zasad, zachować zgodność z przepisami itp. Umożliwia definiowanie i konfigurowanie określonych kategorii zdarzeń, które uważasz za potrzebne inspekcje i na podstawie tego, że można uzyskać wstępnie skonfigurowane raporty i pulpit nawigacyjny, aby uzyskać przegląd zdarzeń występujących w bazie danych.

Te zasady inspekcji można stosować na poziomie bazy danych lub na poziomie serwera. Aby uzyskać więcej informacji, włącz inspekcję usługi SQL Database.

Wykrywanie zagrożeń

Dzięki wykrywaniu zagrożeń można wykonywać działania w przypadku naruszeń zabezpieczeń lub zasad wykrytych przez inspekcję. Nie musisz być ekspertem ds. zabezpieczeń, aby rozwiązać potencjalne zagrożenia lub naruszenia w systemie. Wykrywanie zagrożeń ma również pewne wbudowane funkcje, takie jak wykrywanie iniekcji SQL, co jest dość typowym sposobem ataku na aplikację bazy danych. Wykrywanie zagrożeń uruchamia wiele zestawów algorytmów, które wykrywają potencjalne luki w zabezpieczeniach, ataki polegające na SQL injection oraz nietypowe wzorce dostępu do bazy danych, takie jak dostęp z nietypowej lokalizacji lub przez nieznanego użytkownika.

Funkcjonariusze zabezpieczeń lub inni wyznaczeni administratorzy otrzymają powiadomienie e-mail, jeśli w bazie danych zostanie wykryte zagrożenie. Każde powiadomienie zawiera szczegółowe informacje o podejrzanych działaniach i zaleceniach dotyczących dalszego badania i ograniczania zagrożenia. Aby dowiedzieć się, jak włączyć wykrywanie zagrożeń, zobacz Włączanie wykrywania zagrożeń.

Jak mogę ogólnie chronić dane w usłudze SQL Database?

Szyfrowanie zapewnia silny mechanizm ochrony i zabezpieczania poufnych danych przed intruzami. Zaszyfrowane dane nie są używane do intruza bez klucza odszyfrowywania. W związku z tym dodaje dodatkową warstwę ochrony na podstawie istniejących warstw zabezpieczeń wbudowanych w usługę SQL Database. Istnieją dwa aspekty ochrony danych w usłudze SQL Database:

• Dane przechowywane w plikach danych i dziennika
• Dane w locie

W usłudze SQL Database dane przechowywane w plikach danych i dziennika podsystemu magazynu są domyślnie całkowicie i zawsze szyfrowane za pośrednictwem funkcji Transparent Data Encryption [TDE]. Kopie zapasowe są również szyfrowane. W przypadku funkcji TDE nie są wymagane żadne zmiany po stronie aplikacji, które uzyskują dostęp do tych danych. Szyfrowanie i odszyfrowywanie jest wykonywane w sposób niewidoczny; stąd nazwa.

W celu ochrony poufnych danych w trakcie przesyłania i w spoczynku, usługa SQL Database udostępnia funkcję o nazwie Always Encrypted. Always Encrypted jest formą szyfrowania po stronie klienta, która szyfruje poufne kolumny w bazie danych, co oznacza, że są w postaci zaszyfrowanej dla administratorów bazy danych i nieautoryzowanych użytkowników. Serwer odbiera zaszyfrowane dane na początek.

Klucz funkcji Always Encrypted jest również przechowywany po stronie klienta, więc tylko autoryzowani klienci mogą odszyfrować poufne kolumny. Administratorzy serwerów i danych nie widzą poufnych danych, ponieważ klucze szyfrowania są przechowywane na kliencie. Always Encrypted szyfruje poufne kolumny w tabeli od początku do końca, od nieautoryzowanych klientów do dysku fizycznego.

Funkcja Always Encrypted obsługuje porównania równości, więc administratorzy baz danych mogą nadal wykonywać zapytania dotyczące zaszyfrowanych kolumn w ramach poleceń SQL. Funkcja Always Encrypted może być używana z różnymi opcjami magazynu kluczy, takimi jak usługa Azure Key Vault, magazyn certyfikatów systemu Windows i lokalne moduły zabezpieczeń sprzętu.

Charakterystyka	Zawsze szyfrowane	Transparentne szyfrowanie danych
Zakres szyfrowania	Kompleksowe	Dane magazynowane
Serwer może uzyskiwać dostęp do poufnych danych	Nie.	Tak, ponieważ szyfrowanie dotyczy danych magazynowanych
Dozwolone operacje T-SQL	Porównanie równości	Dostępny jest cały obszar powierzchni języka T-SQL
Zmiany aplikacji wymagane do korzystania z funkcji	Minimalny	Minimalny
Stopień szczegółowości szyfrowania	Poziom kolumny	Poziom bazy danych

Jak ograniczyć dostęp do poufnych danych w mojej bazie danych?

Każda aplikacja ma poufne dane w bazie danych, które muszą być chronione przed widocznością dla wszystkich. Niektórzy pracownicy w organizacji muszą wyświetlać te dane, jednak inni nie powinni mieć możliwości wyświetlania tych danych. W takich przypadkach poufne dane muszą być maskowane lub nie są w ogóle widoczne. Usługa SQL Database oferuje dwa takie podejścia, aby uniemożliwić nieautoryzowanym użytkownikom wyświetlanie poufnych danych:

• Dynamiczne maskowanie danych to funkcja maskowania danych, która umożliwia ograniczenie ujawnienia poufnych danych przez maskowanie ich użytkownikom niebędącym uprzywilejowanymi w warstwie aplikacji. Zdefiniuj regułę maskowania, która może utworzyć wzorzec maskowania (na przykład w celu wyświetlania tylko czterech ostatnich cyfr krajowego identyfikatora SSN: XXX-XX-0000 i maskowania większości z nich z X znakiem) i identyfikowania użytkowników, którzy mają zostać wykluczeni z reguły maskowania. Maskowanie odbywa się na bieżąco i istnieją różne funkcje maskowania dostępne dla różnych kategorii danych. Dynamiczne maskowanie danych umożliwia automatyczne wykrywanie poufnych danych w bazie danych i stosowanie do niej maskowania.

• Zabezpieczenia na poziomie wiersza umożliwiają kontrolowanie dostępu na poziomie wiersza. Oznacza to, że niektóre wiersze w tabeli bazy danych na podstawie użytkownika wykonującego zapytanie (członkostwo w grupie lub kontekst wykonywania) są ukryte. Ograniczenie dostępu odbywa się w warstwie bazy danych zamiast w warstwie aplikacji, aby uprościć logikę aplikacji. Zacznij od utworzenia predykatu filtru, odfiltrowania wierszy, które nie są uwidocznione, a następnie zasady zabezpieczeń definiujące, kto ma dostęp do tych wierszy. Na koniec użytkownik końcowy uruchamia zapytanie, a w zależności od uprawnień użytkownika wyświetla te wiersze z ograniczeniami lub w ogóle nie może ich wyświetlić.

Jak zarządzać kluczami szyfrowania w chmurze?

Istnieją opcje zarządzania kluczami dla funkcji Always Encrypted (szyfrowanie po stronie klienta) i przezroczystego szyfrowania danych (szyfrowanie danych w stanie spoczynku). Zaleca się regularne obracanie kluczy szyfrowania. Częstotliwość rotacji powinna być zgodna zarówno z wewnętrznymi przepisami organizacji, jak i wymaganiami dotyczącymi zgodności.

Transparent Data Encryption (TDE)

W funkcji TDE istnieje hierarchia dwóch kluczy — dane w każdej bazie danych użytkownika są szyfrowane za pomocą symetrycznego klucza szyfrowania bazy danych AES-256 (DEK), który z kolei jest szyfrowany przez unikatowy asymetryczny klucz główny RSA 2048 serwera. Klucz główny można zarządzać:

• Automatycznie według usługi Azure SQL Database
• Lub za pomocą usługi Azure Key Vault jako magazynu kluczy

Domyślnie klucz główny dla funkcji TDE jest zarządzany przez usługę Azure SQL Database. Jeśli Twoja organizacja chce kontrolować klucz główny, możesz użyć usługi Azure Key Vault jako magazynu kluczy. Za pomocą usługi Azure Key Vault organizacja przejmuje kontrolę nad kluczowymi kontrolkami aprowizacji, rotacji i uprawnień. Rotacja lub przełączanie typu klucza głównego TDE jest szybkie, ponieważ tylko ponownie szyfruje klucz szyfrowania danych. W przypadku organizacji z separacją ról między zabezpieczeniami i zarządzaniem danymi administrator zabezpieczeń może aprowizować materiał klucza głównego TDE w usłudze Azure Key Vault i udostępnić administratorowi bazy danych identyfikator klucza usługi Azure Key Vault do szyfrowania magazynowanych na serwerze. Usługa Key Vault została zaprojektowana tak, aby firma Microsoft nie widziała ani nie wyodrębniła żadnych kluczy szyfrowania. Uzyskujesz również scentralizowane zarządzanie kluczami dla organizacji.

Zawsze szyfrowane

Istnieje również hierarchia dwóch kluczy w funkcji Always Encrypted — kolumna poufnych danych jest szyfrowana za pomocą klucza szyfrowania 256-kolumnowego AES (CEK), który z kolei jest szyfrowany za pomocą klucza głównego kolumny (CMK). Sterowniki klienta podane dla funkcji Always Encrypted nie mają ograniczeń dotyczących długości kluczy cmks. Zaszyfrowana wartość klucza CEK jest przechowywana w bazie danych, a klucz zarządzania kluczami jest przechowywany w zaufanym magazynie kluczy, takim jak magazyn certyfikatów systemu Windows, usługa Azure Key Vault lub sprzętowy moduł zabezpieczeń.

• Można obracać zarówno klucz CEK, jak i cmK .

• Rotacja klucza CEK jest rozmiarem operacji danych i może być czasochłonna w zależności od rozmiaru tabel zawierających zaszyfrowane kolumny. W związku z tym rozsądne jest odpowiednio zaplanowanie rotacji CEK.

• Rotacja cmK nie zakłóca jednak wydajności bazy danych i może być wykonywana z oddzielnymi rolami.

Na poniższym diagramie przedstawiono opcje przechowywania dla kluczy głównych kolumn w funkcji Always Encrypted.

Jak mogę zoptymalizować i zabezpieczyć ruch między organizacją a usługą SQL Database?

Ruch sieciowy między organizacją a usługą SQL Database jest zwykle kierowany przez sieć publiczną. Można jednak zoptymalizować tę ścieżkę i zwiększyć bezpieczeństwo za pomocą usługi Azure ExpressRoute. Usługa ExpressRoute rozszerza sieć firmową na platformę Azure za pośrednictwem połączenia prywatnego. W ten sposób nie przechodzisz przez publiczny Internet. Uzyskujesz również wyższe zabezpieczenia, niezawodność i optymalizację routingu, co przekłada się na mniejsze opóźnienia sieciowe i szybsze prędkości niż zazwyczaj podczas korzystania z publicznego internetu. Jeśli planujesz przeniesienie znacznego fragmentu danych między organizacją a platformą Azure, korzystanie z usługi ExpressRoute może przynieść korzyści kosztowe. Możesz wybrać spośród trzech różnych modeli łączności dla połączenia między organizacją a platformą Azure:

• Kolokacja programu Cloud Exchange
• Dowolne-dowolne
• Point-to-point

Usługa ExpressRoute umożliwia również tymczasowe zwiększenie przepustowości do 2 razy więcej niż zakupiony limit, bez dodatkowych opłat. Istnieje również możliwość skonfigurowania łączności między regionami przy użyciu usługi ExpressRoute. Aby uzyskać listę dostawców połączeń usługi ExpressRoute, zobacz ExpressRoute Partners and Peering Locations (Partnerzy usługi ExpressRoute i lokalizacje komunikacji równorzędnej). W poniższych artykułach opisano usługę Express Route bardziej szczegółowo:

• Wprowadzenie do usługi Express Route
• Wymagania wstępne
• Przepływy pracy

Czy usługa SQL Database jest zgodna z wszelkimi wymaganiami prawnymi i w jaki sposób pomaga to we zgodności mojej organizacji?

Usługa SQL Database jest zgodna z szeregiem zgodności z przepisami. Aby wyświetlić najnowszy zestaw współzależności, które zostały spełnione przez usługę SQL Database, odwiedź Centrum zaufania Firmy Microsoft i przejrzyj informacje o współzależnościach, które są ważne dla Twojej organizacji, aby sprawdzić, czy usługa SQL Database jest uwzględniona w zgodnych usługach platformy Azure. Chociaż usługa SQL Database jest certyfikowana jako zgodna, wspiera zgodność usług Twojej organizacji, ale nie gwarantuje jej automatycznie.

Inteligentne monitorowanie i konserwacja bazy danych po migracji

Po przeprowadzeniu migracji bazy danych do usługi SQL Database należy monitorować bazę danych (na przykład sprawdzać, jak wygląda wykorzystanie zasobów lub wykonywać kontrole DBCC) i przeprowadzać regularną konserwację (na przykład ponownie zbudować lub zreorganizować indeksy, statystyki itp.). Usługa SQL Database używa historycznych trendów i zarejestrowanych metryk i statystyk, aby aktywnie ułatwić monitorowanie i konserwowanie bazy danych, dzięki czemu aplikacja działa optymalnie zawsze. W niektórych przypadkach usługa Azure SQL Database może automatycznie wykonywać zadania konserwacji w zależności od konfiguracji. Istnieją trzy aspekty monitorowania bazy danych w usłudze SQL Database:

• Monitorowanie i optymalizacja wydajności
• Optymalizacja zabezpieczeń
• Optymalizacja kosztów

Monitorowanie i optymalizacja wydajności

Korzystając ze szczegółowych informacji o wydajności zapytań, możesz uzyskać dostosowane zalecenia dotyczące obciążenia bazy danych, aby aplikacje mogły działać na optymalnym poziomie. Można go również skonfigurować tak, aby te rekomendacje były stosowane automatycznie i nie trzeba przejmować się wykonywaniem zadań konserwacji. Usługa SQL Database Advisor umożliwia automatyczne implementowanie zaleceń dotyczących indeksów na podstawie obciążenia. Jest to nazywane dostrajaniem automatycznym. Zalecenia ewoluują wraz ze zmianami obciążenia aplikacji, aby zapewnić najbardziej odpowiednie sugestie. Możesz również ręcznie przejrzeć te zalecenia i zastosować je według własnego uznania.

Optymalizacja zabezpieczeń

Usługa SQL Database udostępnia zalecenia dotyczące zabezpieczeń, które ułatwiają zabezpieczanie danych i wykrywania zagrożeń w celu identyfikowania i badania podejrzanych działań bazy danych, które mogą stanowić potencjalny wątek dla bazy danych. Ocena luk w zabezpieczeniach to usługa skanowania i raportowania bazy danych, która umożliwia monitorowanie stanu zabezpieczeń baz danych na dużą skalę oraz identyfikowanie zagrożeń bezpieczeństwa i dryfowanie od punktu odniesienia zabezpieczeń zdefiniowanego przez Użytkownika. Po każdym skanowaniu zostanie udostępniona niestandardowa lista kroków możliwych do wykonania i skryptów korygowania oraz raport oceny, który może służyć do spełnienia wymagań dotyczących zgodności.

Dzięki Microsoft Defender dla Chmury można zidentyfikować zalecenia dotyczące zabezpieczeń w całej tablicy i szybko je zastosować.

Optymalizacja kosztów

Platforma Azure SQL analizuje historię wykorzystania w bazach danych na serwerze, aby ocenić i zalecić opcje optymalizacji kosztów. Ta analiza zwykle trwa kilka tygodni, aby analizować i tworzyć zalecenia umożliwiające podejmowanie działań.

Możesz otrzymywać powiadomienia banerowe na serwerze usługi Azure SQL z zaleceniami dotyczącymi kosztów. Aby uzyskać więcej informacji, zobacz Elastyczne pule ułatwiają zarządzanie wieloma bazami danych i skalowanie ich w usłudze Azure SQL Database oraz Planowanie kosztów usługi Azure SQL Database i zarządzanie nimi.

Jak monitorować wydajność i wykorzystanie zasobów w usłudze SQL Database?

Wydajność i wykorzystanie zasobów w usłudze SQL Database można monitorować przy użyciu następujących metod:

obserwator bazy danych

Obserwator bazy danych zbiera szczegółowe dane monitorowania obciążenia, aby uzyskać szczegółowy widok wydajności, konfiguracji i kondycji bazy danych. Pulpity nawigacyjne w witrynie Azure Portal zapewniają widok z jednym okienkiem szkła dla majątku usługi Azure SQL i szczegółowy widok każdego monitorowanego zasobu. Dane są zbierane w centralnym magazynie danych w ramach subskrypcji platformy Azure. Możesz wykonywać zapytania, analizować, eksportować, wizualizować zebrane dane i integrować je z systemami podrzędnymi.

Aby uzyskać więcej informacji na temat obserwatora bazy danych, zobacz następujące artykuły:

• Monitorowanie obciążeń usługi Azure SQL za pomocą obserwatora bazy danych (wersja zapoznawcza)
• Szybki start: tworzenie obserwatora do monitorowania usługi Azure SQL (wersja zapoznawcza)
• Tworzenie i konfigurowanie obserwatora (wersja zapoznawcza)
• Zbieranie danych i zestawy danych obserwatora bazy danych (wersja zapoznawcza)
• Analizowanie danych monitorowania obserwatora bazy danych (wersja zapoznawcza)
• Obserwator bazy danych — często zadawane pytania

Azure Portal

W witrynie Azure Portal przedstawiono wykorzystanie bazy danych, wybierając bazę danych i wybierając wykres w okienku Przegląd. Możesz zmodyfikować wykres, aby wyświetlić wiele metryk, w tym procent procesora CPU, procent jednostek DTU, procent operacji we/wy danych, procent sesji i procent rozmiaru bazy danych.

Na tym wykresie można również skonfigurować alerty według zasobu. Te alerty umożliwiają reagowanie na warunki zasobów za pomocą wiadomości e-mail, zapisywanie w punkcie końcowym HTTPS/HTTP lub wykonywanie akcji. Aby uzyskać więcej informacji, zobacz Tworzenie alertów dla usług Azure SQL Database i Azure Synapse Analytics przy użyciu witryny Azure Portal.

Dynamiczne widoki zarządzania

Możesz wykonać zapytanie dotyczące dynamicznego widoku zarządzania sys.dm_db_resource_stats , aby zwrócić historię statystyk użycia zasobów z ostatniej godziny i widoku wykazu systemu sys.resource_stats w celu zwrócenia historii z ostatnich 14 dni.

Szczegółowe informacje o wydajności zapytań

Szczegółowe informacje o wydajności zapytań umożliwiają wyświetlenie historii zapytań zużywających najwięcej zasobów i długotrwałych zapytań dotyczących określonej bazy danych. Zapytania można szybko identyfikować TOP według użycia zasobów, czasu trwania i częstotliwości wykonywania. Możesz śledzić zapytania i wykrywać regresję. Ta funkcja wymaga włączenia i aktywowania magazynu zapytań dla bazy danych.

Widzę problemy z wydajnością: Jak moja metodologia rozwiązywania problemów z usługą SQL Database różni się od programu SQL Server?

Główna część technik rozwiązywania problemów, których należy użyć do diagnozowania problemów z wydajnością zapytań i bazy danych, pozostaje taka sama: ten sam aparat bazy danych obsługuje chmurę. Usługa Azure SQL Database może ułatwić rozwiązywanie i diagnozowanie problemów z wydajnością. Może również wykonywać niektóre z tych akcji naprawczych w Twoim imieniu i w niektórych przypadkach proaktywnie je automatycznie naprawiać.

Podejście do rozwiązywania problemów z wydajnością może znacznie przynieść korzyści dzięki użyciu inteligentnych funkcji, takich jak szczegółowe informacje o wydajności zapytań (QPI) i doradcy bazy danych w połączeniu, a więc różnica w metodologii różni się w tym zakresie — nie trzeba już wykonywać ręcznej pracy w celu zmielenia podstawowych szczegółów, które mogą pomóc w rozwiązaniu problemu. Platforma wykonuje ci ciężką pracę. Jednym z przykładów jest QPI. Za pomocą interfejsu QPI możesz przejść do szczegółów aż do poziomu zapytania i przyjrzeć się trendom historycznym i ustalić, kiedy dokładnie zapytanie ma regresję. Usługa Database Advisor udostępnia zalecenia dotyczące elementów, które mogą pomóc w zwiększeniu ogólnej wydajności, takich jak brakujące indeksy, porzucanie indeksów, parametryzowanie zapytań itp.

W przypadku rozwiązywania problemów z wydajnością ważne jest określenie, czy jest to tylko aplikacja, czy baza danych, która ma wpływ na wydajność aplikacji. Często problem z wydajnością leży w warstwie aplikacji. Może to być architektura lub wzorzec dostępu do danych. Rozważmy na przykład, że masz aplikację o czacie, która jest wrażliwa na opóźnienie sieci. W takim przypadku aplikacja doświadcza problemów, ponieważ między aplikacją a serwerem w zatłoczonej sieci będzie wiele krótkich żądań w tę i z powrotem, a te rundy szybko się sumują. Aby poprawić wydajność w tym przypadku, możesz użyć zapytań usługi Batch, które pomagają zmniejszyć opóźnienie dwukierunkowe i zwiększyć wydajność aplikacji.

Ponadto, jeśli zauważysz spadek ogólnej wydajności bazy danych, możesz monitorować sys.dm_db_resource_stats i sys.resource_stats dynamicznych widoków zarządzania, aby zrozumieć użycie procesora CPU, operacji we/wy i pamięci. Twoja wydajność może być obniżona, jeśli baza danych jest pozbawiona zasobów. Może zajść potrzeba zmiany rozmiaru obliczeniowego i/lub warstwy usługi w zależności od rosnących i zmniejszających się wymagań dotyczących obciążeń.

Aby uzyskać kompleksowy zestaw zaleceń dotyczących dostrajania problemów z wydajnością, zobacz Dostosowywanie bazy danych.

Jak upewnić się, że używam odpowiedniej warstwy usług i rozmiaru obliczeniowego?

Usługa SQL Database oferuje dwa różne modele zakupów: starszy model jednostek DTU i bardziej dostosowany model zakupów rdzeni wirtualnych. Aby uzyskać więcej informacji, zobacz Porównanie modeli zakupów opartych na rdzeniach wirtualnych i jednostkach DTU w usłudze Azure SQL Database.

Możesz monitorować użycie zasobów zapytań i baz danych w obu modelach zakupów. Aby uzyskać więcej informacji, zobacz Monitorowanie i dostrajanie wydajności. Jeśli okaże się, że zapytania/bazy danych stale działają na gorąco, możesz rozważyć skalowanie w górę do wyższego rozmiaru obliczeniowego. Podobnie, jeśli nie wydaje się używać zasobów tyle w godzinach szczytu, rozważ skalowanie w dół z bieżącego rozmiaru obliczeniowego. Możesz rozważyć użycie usługi Azure Automation do skalowania baz danych SQL zgodnie z harmonogramem.

Jeśli masz wzorzec aplikacji SaaS lub scenariusz konsolidacji bazy danych, rozważ użycie elastycznej puli na potrzeby optymalizacji kosztów. Elastyczna pula to doskonały sposób na osiągnięcie konsolidacji bazy danych i optymalizacji kosztów. Aby uzyskać więcej informacji na temat zarządzania wieloma bazami danych przy użyciu elastycznej puli, zobacz Zarządzanie pulami i bazami danych.

Jak często muszę uruchomić sprawdzanie integralności bazy danych dla mojej bazy danych?

Usługa SQL Database może automatycznie obsługiwać niektóre klasy uszkodzenia danych i bez utraty danych. Te wbudowane techniki są używane przez usługę w razie potrzeby. Kopie zapasowe bazy danych w usłudze są regularnie testowane, przywracając je i uruchamiając DBCC CHECKDB na nich. Jeśli występują problemy, usługa SQL Database aktywnie je rozwiązuje.

Automatyczna naprawa strony służy do naprawiania stron, które są uszkodzone lub mają problemy z integralnością danych. Strony bazy danych są zawsze weryfikowane przy użyciu ustawienia domyślnego CHECKSUM , które weryfikuje integralność strony. Usługa SQL Database aktywnie monitoruje i przegląda integralność danych bazy danych i rozwiązuje problemy w miarę ich wystąpienia. Opcjonalnie możesz uruchomić własne kontrole integralności zgodnie z potrzebami. Aby uzyskać więcej informacji, zobacz Integralność danych w usłudze SQL Database.

Przenoszenie danych po migracji

Jak wyeksportować i zaimportować dane jako pliki BACPAC z usługi SQL Database przy użyciu witryny Azure Portal?

• Eksportuj: bazę danych można wyeksportować w usłudze Azure SQL Database jako plik BACPAC z witryny Azure Portal:

  

• Importuj: możesz również zaimportować dane jako plik BACPAC do bazy danych w usłudze Azure SQL Database przy użyciu witryny Azure Portal:

  

Jak synchronizować dane między usługą SQL Database i programem SQL Server?

Istnieje kilka sposobów, aby to osiągnąć:

• Data Sync: ta funkcja ułatwia synchronizowanie danych dwukierunkowo między wieloma bazami danych programu SQL Server i usługą SQL Database. Aby przeprowadzić synchronizację z bazami danych programu SQL Server, należy zainstalować i skonfigurować agenta synchronizacji na komputerze lokalnym lub maszynie wirtualnej i otworzyć wychodzący port TCP 1433.

• Replikacja transakcji: przy użyciu replikacji transakcji możesz synchronizować dane z bazy danych SQL Server do Azure SQL Database, przy czym instancja SQL Server jest wydawcą, a Azure SQL Database subskrybentem. Na razie obsługiwana jest tylko ta konfiguracja. Aby uzyskać więcej informacji na temat migrowania danych z bazy danych programu SQL Server do usługi Azure SQL z minimalnym przestojem, zobacz Korzystanie z replikacji transakcji

Powiązana zawartość

• Monitorowanie i dostrajanie wydajności w usługach Azure SQL Database i Azure SQL Managed Instance