Ms sql linux log

Журналы (logs) в MySQL

В MySQL на данный момент существуют 4 вида журнала (лога) и при достаточно серьёзной работе с базами на MySQL необходимо за ними следить. Например, бинарный лог у нас за сутки набирает около гигабайта, а размер жёсткого диска на сервере ограничен и за ними надо следить. Однако следить следует не только за бинарным логом, так как логи (журналы) в MySQL могут принести немалую пользу.

Итак, какие логи ведёт MySQL? Это:
1. бинарный лог (binary log)
2. лог ошибок (error log)
3. лог медленный запросов (slow query log)
4. лог запросов (general query log)
5. лог репликаций (relay log)

Каждый из них по-своему полезен.

Бинарный лог

В первую очередь полезен с точки зрения репликаций. Можно его бэкапить, можно использовать для восстановления данных на более точное время при использовании бэкапов. Лог содержит все команды изменений базы данных, выборки (select, show) не сохраняет, для таблиц, поддерживающих транзакции (BDB, InnoDB) запись в лог выполняется только после выполнения команды COMMIT . Для лога можно указывать список баз данных, которые надо логировать и список баз данных, которые не надо логировать. В более ранних версиях вместо бинарного лога использовался лог обновлений. Использование бинарного лога снижает производительность базы данных, однако его польза настолько велика, что крайне не рекомендуется его отключать. Рекомендуется защищать бинарный лог паролем, так как он может данные также о паролях пользователей. При достижении максимально разрешённого размера (1 гиг по умолчанию) создаётся следующий файл. Каждый новый файл имеет порядковый номер после имени.

Содержание бинарного лога можно посмотреть с помощью утилиты mysqlbinlog.

Основные настройки в my.cnf

Местоположение лога:
log_bin = /var/log/mysql/mysql-bin.log

Максимальный размер, минимум 4096 байт, по умолчанию 1073741824 байт (1 гигабайт):
max_binlog_size= 500M

Сколько дней хранится:
expire_logs_days = 3

Наиболее часто использующиеся команды

Повторение действий после операции восстановления:
shell> mysqlbinlog log_file | mysql -h server_name

Удаление логов до определённого файла:
PURGE BINARY LOGS TO ‘mysql-bin.000’;

Удаление логов до определённой даты:
PURGE BINARY LOGS BEFORE ‘YYYY-MM-DD hh:mm:ss’;

Лог ошибок

Особенно полезен в случаях сбоев. Лог содержит информацию об остановках, запусках сервера, а также сообщения о критических ошибках. Может содержать сообщения с предупреждениями (warnings).

Основные настройки в my.cnf

Местоположение лога:
log_error = /var/log/mysql/mysql.err

Флаг, указывающий стоит ли записывать в лог в том числе предупреждения (записываются, если значение больше нуля):
log_warnings = 1

Наиболее часто использующиеся команды

Переход к новому файл лога:
shell> mysqladmin flush-logs

Копирование старой части лога (необходимо, так как в случае повторного выполнения fluch он будет удалён):
shell> mv host_name.err-old backup-directory

Лог медленных запросов

Если есть подозрение, что приложение работает медленно из-за неэффективных запросов к базе, то в первую очередь следует проверить лог медленных запросов. В случае оптимизации запросов этот лог поможет выяснить, что необходимо оптимизировать в первую очередь.

Основные настройки в my.cnf

Местоположение лога:
log_slow_queries = /var/log/mysql/mysql_slow.log

Со скольки секунд выполнения запрос считается медленным, минимальное значений — 1 секунда, по умолчанию 10 секунд:
long_query_time = 10

Если надо логировать запросы, которые не используют индексы, надо добавить строку:
log-queries-not-using-indexes

Если надо вести лог медленных команд, таких как OPTIMIZE TABLE , ANALYZE TABLE и ALTER TABLE :
log-slow-admin-statements

Лог запросов

Лог содержит информацию о подключениях и отключениях клиентов, а также все SQL запросы, которые были получены. Фактически, это временный лог. Обычно лог удаляется автоматически сразу после выполнения всех команд (т.е. как только он стал ненужным). Лог ведётся в соответствии с очередность поступления запросов. Этот лог содержит все запросы к базе данных (независимо от приложений и пользователей). Так что если есть желание (или необходимость) проанализировать, какие необходимы индексы, какие запросы могли бы оптимизированы, то этот лог как раз может помочь в таких целях. Лог полезен не только для случаев, когда необходимо знать, какие запросы выполняются с базой данных, но и в случаях, когда ясно, что возникла ошибка с базой данных, но неизвестно, какой запрос был отправлен к базе данных (например, в случае генерации динамического SQL-а). Рекомендуется защищать лог запросов паролем, так как он может данные также о паролях пользователей.

Основные настройки в my.cnf

Местоположение лога:
log = /var/log/mysql/mysql.log

Наиболее часто использующиеся команды

В отличии от других логов, перезагрузка сервера и команда fluch не инициирует создание нового лога. Но это можно сделать вручную:
shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> mv host_name-old.log backup-directory

Лог репликаций

Здесь логируются изменения, выполненные по инициации сервера репликаций. Как и бинарный лог, состоит из файлов, каждый из которых пронумерован.

Основные настройки в my.cnf

Местоположение лога:
relay-log = /var/log/mysql/mysql-relay-bin.log

Максимальный размер:
max_relay_log_size = 500М

Наиболее часто использующиеся команды

Начать новый файл лога можно только при остановленном дополнительном (slave) сервере:
shell> cat new_relay_log_name.index >> old_relay_log_name.index
shell> mv old_relay_log_name.index new_relay_log_name.index

Команда fluch logs инициирует ротацию лога.

Источник

Устранение неполадок в SQL Server на Linux

Применимо к: SQL Server (все поддерживаемые версии) — Linux

Этот документ описывает устранение неполадок в Microsoft SQL Server, работающих в Linux или контейнере Docker. При устранении неполадок SQL Server на Linux не забудьте ознакомиться с поддерживаемыми функциями и известными ограничениями в заметках о выпуске SQL Server на Linux.

Ответы на часто задаваемые вопросы об SQL Server на Linux см. в этой статье.

Устранение неполадок при сбоях подключения

Если у вас возникли трудности при подключении к SQL Server на базе Linux, нужно проверить следующее.

Если вы не можете подключиться локально с помощью localhost, попробуйте использовать вместо этого IP-адрес 127.0.0.1. Возможно, localhost не сопоставлен должным образом с этим адресом.

Убедитесь, что IP-адрес или имя сервера доступны с клиентского компьютера.

Чтобы найти IP-адрес своего компьютера Ubuntu, можно выполнить команду ifconfig, как показано в следующем примере.

Для Red Hat можно использовать ip addr, как показано в следующем примере.

Исключение из этой методики связано с виртуальными машинами Azure. Для виртуальных машин Azure найдите общедоступный IP-адрес для виртуальной машины на портале Azure.

Если это применимо, убедитесь, что открыт порт SQL Server (по умолчанию 1433) в брандмауэре.

Убедитесь, что имя пользователя и пароль не содержат опечатки, лишние пробелы или неверный регистр.

Попробуйте явно задать протокол и номер порта с именем сервера, как показано в следующем примере: tcp:имя_сервера,1433.

Проблемы с сетевым подключением также могут вызвать ошибки подключения и истечение времени ожидания. Проверив сведения о подключении и возможность сетевого подключения, повторите попытку подключения.

Управление службой SQL Server

В следующих разделах показано, как запустить, остановить, перезапустить службу SQL Server и проверить ее состояние.

Управление службой mssql-server в Red Hat Enterprise Linux (RHEL) и Ubuntu

Проверьте состояние службы SQL Server с помощью следующей команды.

Вы можете останавливать, запускать или перезапускать службу SQL Server по мере необходимости, используя следующие команды.

Управление выполнением контейнера Docker mssql

Вы можете получить состояние и идентификатор контейнера для последнего созданного контейнера Docker SQL Server, выполнив следующую команду (идентификатор находится в столбце CONTAINER ID).

Вы можете останавливать или перезапускать службу SQL Server по мере необходимости, используя следующие команды.

Дополнительные советы по устранению неполадок в Docker см. в статье Устранение неполадок с контейнерами Docker в SQL Server.

Доступ к файлам журнала

Подсистема SQL Server записывает данные журнала в файл /var/opt/mssql/log/errorlog в установках Linux и Docker. Для просмотра этого каталога вы должны находиться в режиме суперпользователя.

Установщик записывает данные журнала сюда: /var/opt/mssql/setup- . Вы можете просмотреть файлы журнала ошибок с помощью любого совместимого с UTF-16 средства, например vim или cat.

При желании можно также преобразовать файлы в UTF-8, чтобы прочесть их с помощью more или less, используя следующую команду.

Расширенные события

Расширенные события можно запрашивать с помощью команды SQL. Дополнительные сведения о расширенных событиях см. здесь.

Аварийные дампы

Дампы находятся в каталоге журналов в Linux. В каталоге /var/opt/mssql/log находятся дампы Linux Core (с расширением TAR.GZ2) или минидампы SQL (с расширением MDMP).

Для дампов Core

Запуск SQL Server с минимальной конфигурацией или в однопользовательском режиме

Запуск SQL Server с минимальной конфигурацией

Эта функция полезна в случае, если установленные значения конфигурации (например, слишком большой объем выделяемой памяти) не позволяют выполнить запуск сервера.

Запуск SQL Server в однопользовательском режиме

При определенных обстоятельствах экземпляр SQL Server нужно запустить в однопользовательском режиме, используя параметр запуска -m. Например, может понадобиться изменить параметры конфигурации сервера, восстановить поврежденную базу данных master или другую системную базу данных. Например, может понадобиться изменить параметры конфигурации сервера, восстановить поврежденную базу данных master или другую системную базу данных.

Запуск SQL Server в однопользовательском режиме

Запуск SQL Server в однопользовательском режиме с использованием SQLCMD

Чтобы избежать проблем с запуском в дальнейшем, SQL Server в Linux следует запускать с указанием пользователя «mssql». Пример: «sudo -u mssql /opt/mssql/bin/sqlservr [параметры запуска]»

Если вы случайно запустили SQL Server с другим пользователем, нужно изменить владельца файлов базы данных SQL Server обратно на пользователя mssql перед запуском SQL Server с использованием systemd. Например, чтобы изменить владельца всех файлов базы данных в /var/opt/mssql на пользователя mssql, выполните следующую команду.

Перестроение системных баз данных

В качестве крайней меры можно выбрать перестроение базы данных master и шаблона базы данных до версий по умолчанию.

Эти действия приведут к удалению всех системных данных SQL Server, которые вы настроили. Сюда входят сведения о пользовательских базах данных (но не сами пользовательские базы данных). Кроме того, будут удалены другие сведения, хранящиеся в системных базах данных, включая следующие: сведения о главном ключе, все сертификаты, загруженные в базу данных master, пароль для входа пользователя SA, сведения о заданиях из msdb, сведения о компоненте Database Mail из msdb и параметры sp_configure. Используйте эти возможности, только если осознаете последствия.

Остановите SQL Server.

Запустите sqlservr с параметром force-setup.

См. предыдущее предупреждение. Кроме того, необходимо запустить его от имени пользователя mssql, как указано здесь.

После появления сообщения «Восстановление завершено» нажмите клавиши CTRL+C. Это приведет к завершению работы SQL Server.

Перенастройте пользователя SA.

Запустите SQL Server и перенастройте сервер. Сюда входит восстановление или повторное подключение любых пользовательских баз данных.

Повышение производительности

Существует множество факторов, влияющих на производительность, в том числе структура базы данных, оборудование и требования к рабочим нагрузкам. Если вы хотите повысить производительность, начните с изучения рекомендаций, описанных в статье Рекомендации по производительности и рекомендации по конфигурации для SQL Server в Linux. Затем изучите некоторые из доступных средств для устранения проблем с производительностью.

Распространенные проблемы

Невозможно подключиться к удаленному экземпляру SQL Server.

См. раздел об устранении неполадок в статье Подключение к SQL Server в Linux.

ОШИБКА: длина имени узла не должна превышать 15 символов.

Это известная проблема, которая возникает каждый раз, когда имя компьютера, пытающегося установить пакет Debian с SQL Server, имеет длину более 15 символов. Сейчас способы обхода этой проблемы ограничены изменением имени компьютера. Один из способов добиться этого заключается в изменении файла имени узла и перезагрузке компьютера. Это подробно описано в следующем руководстве.

Сброс пароля системного администрирования (SA).

Если вы забыли пароль системного администратора или по какой-либо причине хотите сбросить его, выполните следующие действия.

Следующие действия временно приостанавливают работу службы SQL Server.

Войдите в терминал узла, выполните следующие команды и следуйте инструкциям на экране, чтобы сбросить пароль SA.

Использование специальных знаков в пароле.

Если в пароле для входа в SQL Server используются специальные знаки, может потребоваться экранировать их с помощью обратной косой черты при их использовании в команде Linux в терминале. Например, нужно всегда экранировать знак доллара ($) при его использовании в команде терминала/скрипте оболочки.

Источник

Troubleshoot SQL Server on Linux

Applies to: SQL Server (all supported versions) — Linux

This document describes how to troubleshoot Microsoft SQL Server running on Linux or in a Docker container. When troubleshooting SQL Server on Linux, remember to review the supported features and known limitations in the SQL Server on Linux Release Notes.

For answers to frequently asked questions, see the SQL Server on Linux FAQ.

Troubleshoot connection failures

If you are having difficulty connecting to your Linux SQL Server, there are a few things to check.

If you are unable to connect locally using localhost, try using the IP address 127.0.0.1 instead. It is possible that localhost is not properly mapped to this address.

Verify that the server name or IP address is reachable from your client machine.

To find the IP address of your Ubuntu machine, you can run the ifconfig command as in the following example:

For Red Hat, you can use the ip addr as in the following example:

One exception to this technique relates to Azure VMs. For Azure VMs, find the public IP for the VM in the Azure portal.

If applicable, check that you have opened the SQL Server port (default 1433) on the firewall.

Verify that the user name and password do not contain any typos or extra spaces or incorrect casing.

Try to explicitly set the protocol and port number with the server name like the following example: tcp:servername,1433.

Network connectivity issues can also cause connection errors and timeouts. After verifying your connection information and network connectivity, try the connection again.

Manage the SQL Server service

The following sections show how to start, stop, restart, and check the status of the SQL Server service.

Manage the mssql-server service in Red Hat Enterprise Linux (RHEL) and Ubuntu

Check the status of the SQL Server service using this command:

You can stop, start, or restart the SQL Server service as needed using the following commands:

Manage the execution of the mssql Docker container

You can get the status and container ID of the latest created SQL Server Docker container by running the following command (The ID is under the CONTAINER ID column):

You can stop or restart the SQL Server service as needed using the following commands:

For more troubleshooting tips for Docker, see Troubleshooting SQL Server Docker containers.

Access the log files

The SQL Server engine logs to the /var/opt/mssql/log/errorlog file in both the Linux and Docker installations. You need to be in ‘superuser’ mode to browse this directory.

The installer logs here: /var/opt/mssql/setup- You can browse the errorlog files with any UTF-16 compatible tool like ‘vim’ or ‘cat’ like this:

If you prefer, you can also convert the files to UTF-8 to read them with ‘more’ or ‘less’ with the following command:

Extended events

Extended events can be queried via a SQL command. More information about extended events can be found here:

Crash dumps

Look for dumps in the log directory in Linux. Check under the /var/opt/mssql/log directory for Linux Core dumps (.tar.gz2 extension) or SQL minidumps (.mdmp extension)

Start SQL Server in Minimal Configuration or in Single User Mode

Start SQL Server in Minimal Configuration Mode

This is useful if the setting of a configuration value (for example, over-committing memory) has prevented the server from starting.

Start SQL Server in Single User Mode

Under certain circumstances, you may have to start an instance of SQL Server in single-user mode by using the startup option -m. For example, you may want to change server configuration options or recover a damaged master database or other system database. For example, you may want to change server configuration options or recover a damaged master database or other system database

Start SQL Server in Single User Mode

Start SQL Server in Single User Mode with SQLCMD

Start SQL Server on Linux with the «mssql» user to prevent future startup issues. Example «sudo -u mssql /opt/mssql/bin/sqlservr [STARTUP OPTIONS]»

If you have accidentally started SQL Server with another user, you must change ownership of SQL Server database files back to the ‘mssql’ user prior to starting SQL Server with systemd. For example, to change ownership of all database files under /var/opt/mssql to the ‘mssql’ user, run the following command

Rebuild system databases

As a last resort, you can choose to rebuild the master and model databases back to default versions.

These steps will DELETE all SQL Server system data that you have configured! This includes information about your user databases (but not the user databases themselves). It will also delete other information stored in the system databases, including the following: master key information, any certs loaded in master, the SA Login password, job-related information from msdb, DB Mail information from msdb, and sp_configure options. Only use if you understand the implications!

Stop SQL Server.

Run sqlservr with the force-setup parameter.

See the previous warning! Also, you must run this as the mssql user as shown here.

After you see the message «Recovery is complete», press CTRL+C. This will shut down SQL Server

Reconfigure the SA password.

Start SQL Server and reconfigure the server. This includes restoring or re-attaching any user databases.

Improve performance

There are many factors that affect performance, including database design, hardware, and workload demands. If you are looking to improve performance, start by reviewing the best practices in the article, Performance best practices and configuration guidelines for SQL Server on Linux. Then explore some of the available tools for troubleshooting performance problems.

Common issues

You cannot connect to your remote SQL Server instance.

See the troubleshooting section of the article, Connect to SQL Server on Linux.

ERROR: Hostname must be 15 characters or less.

This is a known-issue that happens whenever the name of the machine that is trying to install the SQL Server Debian package is longer than 15 characters. There are currently no workarounds other than changing the name of the machine. One way to achieve this is by editing the hostname file and rebooting the machine. The following website guide explains this in detail.

Resetting the system administration (SA) password.

If you have forgotten the system administrator (SA) password or need to reset it for some other reason, follow these steps.

The following steps stop the SQL Server service temporarily.

Log into the host terminal, run the following commands and follow the prompts to reset the SA password:

Using special characters in password.

If you use some characters in the SQL Server login password, you might need to escape them with a backslash when you use them in a Linux command in the terminal. For example, you must escape the dollar sign ($) anytime you use it in a terminal command/shell script:

Источник