Udostępnij za pośrednictwem

Parametry serwera w usłudze Azure Database for MySQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for MySQL — serwer elastyczny

Ten artykuł zawiera zagadnienia i wskazówki dotyczące konfigurowania parametrów serwera na serwerze elastycznym usługi Azure Database for MySQL.

Uwaga

Ten artykuł zawiera odwołania do terminu slave (element podrzędny), który nie jest już używany przez firmę Microsoft. Po usunięciu terminu z oprogramowania usuniemy go z tego artykułu.

Co to są zmienne serwera?

Aparat MySQL udostępnia wiele różnych zmiennych/parametrów serwera, które mogą służyć do konfigurowania i dostrajania zachowania aparatu. Niektóre parametry można ustawiać dynamicznie w czasie wykonywania, podczas gdy inne są "statyczne", co wymaga ponownego uruchomienia serwera w celu zastosowania.

Serwer elastyczny usługi Azure Database for MySQL uwidacznia możliwość zmiany wartości różnych parametrów serwera MySQL przy użyciu witryny Azure Portal i interfejsu wiersza polecenia platformy Azure w celu dopasowania ich do potrzeb twojego obciążenia.

Konfigurowalne parametry serwera

Konfigurację serwera elastycznego usługi Azure Database for MySQL można zarządzać przy użyciu parametrów serwera. Parametry serwera są konfigurowane z wartością domyślną i zalecaną podczas tworzenia serwera. Blok parametrów serwera w witrynie Azure Portal zawiera zarówno modyfikowalne, jak i niemodyfikowalne parametry serwera. Parametry serwera niezmodyfikowalnego są wyszarzone.

Lista obsługiwanych parametrów serwera stale rośnie. Użyj karty Parametry serwera w witrynie Azure Portal, aby wyświetlić pełną listę i skonfigurować wartości parametrów serwera.

Zapoznaj się z poniższymi sekcjami, aby dowiedzieć się więcej na temat limitów kilku często aktualizowanych parametrów serwera. Limity są określane przez warstwę obliczeniową i rozmiar (rdzenie wirtualne) serwera.

Uwaga

  • Jeśli zmodyfikujesz parametr serwera statycznego przy użyciu portalu, musisz ponownie uruchomić serwer, aby zmiany zaczęły obowiązywać. Jeśli używasz skryptów automatyzacji (przy użyciu narzędzi, takich jak szablony usługi ARM, terraform, interfejs wiersza polecenia platformy Azure itp.), skrypt powinien mieć aprowizację, aby ponownie uruchomić usługę, aby ustawienia zaczęły obowiązywać, nawet jeśli zmieniasz konfiguracje w ramach środowiska tworzenia.
  • Jeśli chcesz zmodyfikować niemodyfikowalny parametr serwera dla środowiska, otwórz element UserVoice lub zagłosuj, jeśli opinia już istnieje, co może pomóc nam określić priorytety.

lower_case_table_names

W przypadku programu MySQL w wersji 5.7 wartość domyślna to 1 na serwerze elastycznym usługi Azure Database for MySQL. Należy pamiętać, że chociaż można zmienić obsługiwaną wartość na 2, przywrócenie wartości z 2 z powrotem do 1 nie jest dozwolone. Skontaktuj się z naszym zespołem pomocy technicznej, aby uzyskać pomoc w zmianie wartości domyślnej. W przypadku programu MySQL w wersji 8.0 lub nowszej lower_case_table_names można skonfigurować tylko podczas inicjowania serwera. Dowiedz się więcej. Zmiana ustawienia lower_case_table_names po zainicjowaniu serwera jest zabroniona. W przypadku programu MySQL w wersji 8.0 wartość domyślna to 1 na serwerze elastycznym usługi Azure Database for MySQL. Obsługiwana wartość programu MySQL w wersji 8.0 to 1 i 2 na serwerze elastycznym usługi Azure Database for MySQL. Skontaktuj się z naszym zespołem pomocy technicznej, aby uzyskać pomoc w zmianie wartości domyślnej podczas tworzenia serwera.

innodb_tmpdir

Parametr innodb_tmpdir w usłudze Azure Database for MySQL — serwer elastyczny służy do definiowania katalogu dla tymczasowych plików sortowania utworzonych podczas operacji ALTER TABLE w trybie online, które są ponownie kompilowane. Wartość domyślna innodb_tmpdir to /mnt/temp. Ta lokalizacja odpowiada dyskowi SSD magazynu tymczasowego dostępnego w giB z każdym rozmiarem obliczeniowym serwera. Ta lokalizacja jest idealna w przypadku operacji, które nie wymagają dużej ilości miejsca. Jeśli potrzebna jest większa ilość miejsca, możesz ustawić innodb_tmpdir na /app/work/tmpdirwartość . Wykorzystuje to magazyn, pojemność dostępną na serwerze elastycznym usługi Azure Database for MySQL. Może to być przydatne w przypadku większych operacji wymagających większego magazynu tymczasowego. Należy pamiętać, że użycie /app/work/tmpdir wyników zapewnia niższą wydajność w porównaniu z domyślnym magazynem tymczasowym (SSD). /mnt/temp Wybór powinien być oparty na określonych wymaganiach dotyczących operacji.

Podane informacje innodb_tmpdir dotyczą parametrów innodb_temp_tablespaces_dir, tmpdir i slave_load_tmpdir , gdzie wartość /mnt/temp domyślna jest wspólna, a alternatywny katalog /app/work/tmpdir jest dostępny do konfigurowania zwiększonego magazynu tymczasowego z kompromisem wydajności na podstawie określonych wymagań operacyjnych.

log_bin_trust_function_creators

Na serwerze elastycznym usługi Azure Database for MySQL dzienniki binarne są zawsze włączone ( log_bin jest to ustawienie WŁĄCZONE). log_bin_trust_function_creators jest domyślnie włączona na serwerach elastycznych.

Format rejestrowania binarnego jest zawsze wierszem i wszystkie połączenia z serwerem zawsze używają rejestrowania binarnego opartego na wierszach. W przypadku rejestrowania binarnego opartego na wierszach problemy z zabezpieczeniami nie istnieją, a rejestrowanie binarne nie może zostać przerwane, więc można bezpiecznie zezwolić na log_bin_trust_function_creators pozostanie włączone.

Jeśli parametr [log_bin_trust_function_creators] ma wartość WYŁĄCZONE, jeśli spróbujesz utworzyć wyzwalacze, mogą wystąpić błędy podobne do tego, że nie masz uprawnień ADMINISTRATORA, a rejestrowanie binarne jest włączone (możesz użyć mniej bezpiecznej log_bin_trust_function_creators zmiennej).

innodb_buffer_pool_size

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru. Rozmiar pamięci fizycznej (GB) w poniższej tabeli reprezentuje dostępną pamięć losową (RAM) w gigabajtach (GB) na serwerze elastycznym usługi Azure Database for MySQL.

Warstwa cenowa Rdzenie wirtualne Rozmiar pamięci fizycznej (GiB) Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Możliwość serii (B1s) 1 1 134217728 33554432 268435456
Z możliwością serii (B1ms) 1 2 536870912 134217728 1073741824
Z możliwością zwielokrotnienia wydajności 2 4 2147483648 134217728 2147483648
Ogólnego przeznaczenia 2 8 4294967296 134217728 5368709120
Ogólnego przeznaczenia 100 16 12884901888 134217728 12884901888
Ogólnego przeznaczenia 8 32 25769803776 134217728 25769803776
Ogólnego przeznaczenia 16 64 51539607552 134217728 51539607552
Ogólnego przeznaczenia 32 128 103079215104 134217728 103079215104
Ogólnego przeznaczenia 48 192 154618822656 134217728 154618822656
Ogólnego przeznaczenia 64 256 206158430208 134217728 206158430208
Krytyczne dla działania firmy 2 16 12884901888 134217728 12884901888
Krytyczne dla działania firmy 100 32 25769803776 134217728 25769803776
Krytyczne dla działania firmy 8 64 51539607552 134217728 51539607552
Krytyczne dla działania firmy 16 128 103079215104 134217728 103079215104
Krytyczne dla działania firmy 20 160 128849018880 134217728 128849018880
Krytyczne dla działania firmy 32 256 206158430208 134217728 206158430208
Krytyczne dla działania firmy 48 384 309237645312 134217728 309237645312
Krytyczne dla działania firmy 64 504 405874409472 134217728 405874409472

innodb_file_per_table

Baza danych MySQL przechowuje tabelę InnoDB w różnych przestrzeniach tabel na podstawie konfiguracji podanej podczas tworzenia tabeli. Systemowa przestrzeń tabel to obszar przechowywania słownika danych InnoDB. Przestrzeń tabel dla pliku na tabelę zawiera dane i indeksy dla pojedynczej tabeli InnoDB i jest przechowywana w systemie plików we własnym pliku danych. To zachowanie jest kontrolowane przez innodb_file_per_table parametr serwera. Ustawienie innodb_file_per_table powoduje, że OFF usługa InnoDB tworzy tabele w przestrzeni tabel systemowych. W przeciwnym razie usługa InnoDB tworzy tabele w przestrzeniach tabel dla plików na tabelę.

Serwer elastyczny usługi Azure Database for MySQL obsługuje co najmniej 4 TB w jednym pliku danych. Jeśli rozmiar bazy danych jest większy niż 4 TB, należy utworzyć tabelę w przestrzeni tabel innodb_file_per_table. Jeśli masz jeden rozmiar tabeli większy niż 4 TB, należy użyć tabeli partycji.

innodb_log_file_size

innodb_log_file_size jest rozmiarem w bajtach każdego pliku dziennika w grupie dzienników. Łączny rozmiar plików dziennika (innodb_log_file_size innodb_log_files_in_group * ) nie może przekraczać maksymalnej wartości, która jest nieco mniejsza niż 512 GB). Większy rozmiar pliku dziennika jest lepszy pod kątem wydajności, ale ma wadę, że czas odzyskiwania po awarii jest wysoki. Należy zrównoważyć czas odzyskiwania w rzadkim przypadku odzyskiwania awaryjnego w porównaniu z maksymalizacją przepływności podczas szczytowych operacji. Mogą one również powodować dłuższy czas ponownego uruchamiania. Można skonfigurować innodb_log_size do dowolnej z tych wartości — 256 MB, 512 MB, 1 GB lub 2 GB dla elastycznego serwera usługi Azure Database for MySQL. Parametr jest statyczny i wymaga ponownego uruchomienia.

Uwaga

Jeśli zmieniono parametr innodb_log_file_size z domyślnego, sprawdź, czy wartość "pokaż stan globalny, taki jak "innodb_buffer_pool_pages_dirty", pozostaje na 0 przez 30 sekund, aby uniknąć opóźnienia ponownego uruchamiania.

max_connections

Wartość max_connection jest określana przez rozmiar pamięci serwera.

Warstwa cenowa Rdzenie wirtualne Rozmiar pamięci (GiB) Wartość domyślna Minimalna wartość Wartość maksymalna
Możliwość serii (B1s) 1 1 85 10 171
Z możliwością serii (B1ms) 1 2 171 10 341
Z możliwością zwielokrotnienia wydajności 2 4 341 10 683
Ogólnego przeznaczenia 2 8 683 10 1365
Ogólnego przeznaczenia 100 16 1365 10 2731
Ogólnego przeznaczenia 8 32 2731 10 5461
Ogólnego przeznaczenia 16 64 5461 10 10923
Ogólnego przeznaczenia 32 128 10923 10 21845
Ogólnego przeznaczenia 48 192 16384 10 32768
Ogólnego przeznaczenia 64 256 21845 10 43691
Krytyczne dla działania firmy 2 16 1365 10 2731
Krytyczne dla działania firmy 100 32 2731 10 5461
Krytyczne dla działania firmy 8 64 5461 10 10923
Krytyczne dla działania firmy 16 128 10923 10 21845
Krytyczne dla działania firmy 32 256 21845 10 43691
Krytyczne dla działania firmy 48 384 32768 10 65536
Krytyczne dla działania firmy 64 504 43008 10 86016

W przypadku przekroczenia limitu połączeń może zostać wyświetlony następujący błąd:

BŁĄD 1040 (08004): Zbyt wiele połączeń

Ważne

Aby uzyskać najlepsze środowisko, zalecamy użycie modułu puli połączeń, takiego jak ProxySQL, do wydajnego zarządzania połączeniami.

Tworzenie nowych połączeń klienckich z bazą danych MySQL wymaga czasu i po ustanowieniu tych połączeń zajmują zasoby bazy danych, nawet jeśli są bezczynne. Większość aplikacji żąda wielu krótkotrwałych połączeń, co komplikuje tę sytuację. Wynikiem jest mniejsza liczba zasobów dostępnych dla rzeczywistego obciążenia, co prowadzi do zmniejszenia wydajności. Moduł puli połączeń, który zmniejsza bezczynne połączenia i ponownie używa istniejących połączeń, pomaga tego uniknąć. Aby dowiedzieć się więcej o konfigurowaniu serwera ProxySQL, odwiedź nasz wpis w blogu.

Uwaga

ProxySQL to narzędzie społeczności typu open source. Jest ona obsługiwana przez firmę Microsoft na zasadzie najlepszych starań. Aby uzyskać pomoc techniczną w środowisku produkcyjnym za pomocą autorytatywnych wskazówek, możesz ocenić i skontaktować się z pomocą techniczną produktu ProxySQL.

innodb_strict_mode

Jeśli wystąpi błąd podobny do "Rozmiar wiersza jest zbyt duży (> 8126)", możesz wyłączyć parametr innodb_strict_mode. Nie można globalnie zmodyfikować parametru serwera innodb_strict_mode na poziomie serwera, ponieważ jeśli rozmiar danych wierszy jest większy niż 8 tys., dane są obcinane bez błędu, co może prowadzić do potencjalnej utraty danych. Zalecamy zmodyfikowanie schematu w celu dopasowania go do limitu rozmiaru strony.

Ten parametr można ustawić na poziomie sesji przy użyciu polecenia init_connect. Aby ustawić innodb_strict_mode na poziomie sesji, zapoznaj się z ustawieniem parametru, który nie ma na liście.

Uwaga

Jeśli masz serwer repliki do odczytu, ustawienie innodb_strict_mode wartość OFF na poziomie sesji na serwerze źródłowym spowoduje przerwanie replikacji. Zalecamy zachowanie parametru ustawionego na WŁĄCZONE, jeśli masz repliki do odczytu.

time_zone

Podczas początkowego wdrażania wystąpienie serwera elastycznego usługi Azure Database for MySQL zawiera tabele systemowe informacji o strefie czasowej, ale te tabele nie są wypełniane. Tabele stref czasowych można wypełnić, wywołując procedurę mysql.az_load_timezone składowaną z narzędzia, takiego jak wiersz polecenia MySQL lub MySQL Workbench. Zapoznaj się z artykułami witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure, aby dowiedzieć się, jak wywoływać procedurę składowaną i ustawiać strefy czasowe na poziomie globalnym lub sesji.

binlog_expire_logs_seconds

Na serwerze elastycznym usługi Azure Database for MySQL ten parametr określa liczbę sekund oczekiwania usługi przed przeczyszczeniem pliku dziennika binarnego.

Dziennik binarny zawiera zdarzenia opisujące zmiany bazy danych, takie jak operacje tworzenia tabel lub zmiany danych tabeli. Zawiera również zdarzenia dla instrukcji, które potencjalnie mogły wprowadzić zmiany. Dziennik binarny jest używany głównie do dwóch celów, replikacji i odzyskiwania danych. Zazwyczaj dzienniki binarne są czyszczone, gdy tylko dojście jest wolne od usługi, kopii zapasowej lub zestawu replik. Jeśli istnieje wiele replik, dzienniki binarne czekają na najwolniejszą replikę, aby odczytać zmiany, zanim zostaną przeczyszczone. Jeśli chcesz utrwalać dzienniki binarne przez więcej czasu, możesz skonfigurować parametr binlog_expire_logs_seconds. Jeśli binlog_expire_logs_seconds jest ustawiona na 0, która jest wartością domyślną, przeczyszcza je natychmiast po uwolnieniu dojścia do dziennika binarnego. Jeśli binlog_expire_logs_seconds > 0, poczeka to na skonfigurowanie sekund przed przeczyszczeniem. W przypadku serwera elastycznego usługi Azure Database for MySQL funkcje zarządzane, takie jak tworzenie kopii zapasowych i przeczyszczanie replik binarnych, są obsługiwane wewnętrznie. W przypadku replikowania danych z serwera elastycznego usługi Azure Database for MySQL ten parametr należy ustawić w podstawowym, aby uniknąć przeczyszczania dzienników binarnych przed odczytem repliki ze zmian z serwera podstawowego. Jeśli ustawisz binlog_expire_logs_seconds na wyższą wartość, dzienniki binarne nie zostaną wyczyszczone wystarczająco szybko i mogą prowadzić do zwiększenia rozliczeń magazynu.

event_scheduler

Na serwerze event_schedule elastycznym usługi Azure Database for MySQL parametr serwera zarządza tworzeniem, planowaniem i uruchamianiem zdarzeń, czyli zadaniami uruchamianymi zgodnie z harmonogramem i są uruchamiane przez specjalny wątek harmonogramu zdarzeń. event_scheduler Gdy parametr jest ustawiony na WŁ., wątek harmonogramu zdarzeń jest wyświetlany jako proces demona w danych wyjściowych SHOW PROCESSLIST. Zdarzenia można tworzyć i planować przy użyciu następującej składni SQL:

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;

Uwaga

Aby uzyskać więcej informacji na temat tworzenia zdarzenia, zobacz dokumentację usługi MySQL Event Scheduler tutaj:

Konfigurowanie parametru serwera event_scheduler

Poniższy scenariusz ilustruje jeden ze sposobów użycia parametru event_scheduler na serwerze elastycznym usługi Azure Database for MySQL. Aby zademonstrować ten scenariusz, rozważmy następujący przykład: prosta tabela:

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field     | Type        | Null | Key | Default | Extra          |
+-----------+-------------+------+-----+---------+----------------+
| id        | int(11)     | NO   | PRI | NULL    | auto_increment |
| CreatedAt | timestamp   | YES  |     | NULL    |                |
| CreatedBy | varchar(16) | YES  |     | NULL    |                |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)

Aby skonfigurować parametr serwera na serwerze elastycznym event_scheduler usługi Azure Database for MySQL, wykonaj następujące kroki:

  1. W witrynie Azure Portal przejdź do wystąpienia serwera elastycznego usługi Azure Database for MySQL, a następnie w obszarze Ustawienia wybierz pozycję Parametry serwera.

  2. W bloku Parametry serwera wyszukaj ciąg event_scheduler, na liście rozwijanej WARTOŚĆ wybierz pozycję WŁĄCZONE, a następnie wybierz pozycję Zapisz.

    Uwaga

    Zmiana konfiguracji parametru serwera dynamicznego zostanie wdrożona bez ponownego uruchomienia.

  3. Następnie, aby utworzyć zdarzenie, połącz się z wystąpieniem serwera elastycznego usługi Azure Database for MySQL i uruchom następujące polecenie SQL:

    CREATE EVENT test_event_01
ON SCHEDULE EVERY 1 MINUTE
STARTS CURRENT_TIMESTAMP
ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
COMMENT ‘Inserting record into the table tab1 with current timestamp’
DO
INSERT INTO tab1(id,createdAt,createdBy)
VALUES('',NOW(),CURRENT_USER());

  4. Aby wyświetlić szczegóły harmonogramu zdarzeń, uruchom następującą instrukcję SQL:

    SHOW EVENTS;

    Wyświetlane są następujące dane wyjściowe:

    mysql> show events;
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| Db  | Name          | Definer     | Time zone | Type      | Execute at | Interval value | Interval field | Starts              | Ends                | Status  | Originator | character_set_client | collation_connection | Database Collation |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| db1 | test_event_01 | azureuser@% | SYSTEM    | RECURRING | NULL       | 1              | MINUTE         | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1               | latin1_swedish_ci    | latin1_swedish_ci  |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
1 row in set (0.23 sec)

  5. Po kilku minutach wykonaj zapytanie o wiersze z tabeli, aby rozpocząć wyświetlanie wierszy wstawionych co minutę zgodnie ze skonfigurowanym parametrem event_scheduler :

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
+----+---------------------+-------------+
4 rows in set (0.23 sec)

  6. Po godzinie uruchom instrukcję Select w tabeli, aby wyświetlić pełny wynik wartości wstawionych do tabeli co minutę przez godzinę, zgodnie z event_scheduler konfiguracją w naszym przypadku.

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
|  5 | 2023-04-05 14:51:04 | azureuser@% |
|  6 | 2023-04-05 14:52:04 | azureuser@% |
..< 50 lines trimmed to compact output >..
| 56 | 2023-04-05 15:42:04 | azureuser@% |
| 57 | 2023-04-05 15:43:04 | azureuser@% |
| 58 | 2023-04-05 15:44:04 | azureuser@% |
| 59 | 2023-04-05 15:45:04 | azureuser@% |
| 60 | 2023-04-05 15:46:04 | azureuser@% |
| 61 | 2023-04-05 15:47:04 | azureuser@% |
+----+---------------------+-------------+
61 rows in set (0.23 sec)

Inne scenariusze

Zdarzenie można skonfigurować na podstawie wymagań konkretnego scenariusza. Poniżej przedstawiono kilka podobnych przykładów planowania instrukcji SQL do uruchamiania w różnych interwałach czasu.

Uruchom teraz instrukcję SQL i powtórz raz dziennie bez końca

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Uruchamianie instrukcji SQL co godzinę bez końca

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

Uruchamianie instrukcji SQL codziennie bez końca

CREATE EVENT <event name>
ON SCHEDULE 
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

Ograniczenia

W przypadku serwerów ze skonfigurowaną wysoką dostępnością, gdy nastąpi przejście w tryb failover, możliwe, że event_scheduler parametr serwera zostanie ustawiony na wartość "OFF". Jeśli tak się stanie, po zakończeniu pracy w trybie failover skonfiguruj parametr , aby ustawić wartość na wartość "WŁ.".

Parametry serwera niezmodyfikowalne

Blok parametrów serwera w witrynie Azure Portal zawiera zarówno modyfikowalne, jak i niemodyfikowalne parametry serwera. Parametry serwera niezmodyfikowalnego są wyszarzone. Jeśli chcesz skonfigurować niemodyfikowalny parametr serwera na poziomie sesji, zapoznaj się z witryną Azure Portal lub artykułem interfejsu wiersza polecenia platformy Azure, aby ustawić parametr na poziomie połączenia przy użyciu polecenia init_connect.

Następne kroki