0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

NewSQL: SQL никуда не уходит

Содержание

10 распространенных ошибок программирования на SQL и как их избежать

Главное меню » Базы данных » 10 распространенных ошибок программирования на SQL и как их избежать

1. Забытые первичные ключи

Первичные ключи – ваш первый шаг к реляционным базам данных. Они ссылаются на внешние ключи в реляционных таблицах. Например, если у вас есть таблица со списком клиентов, столбец «CustomerId» будет уникальным для каждого клиента. Это может быть ваш столбец первичного ключа. Ваше значение CustomerId будет затем помещено в таблицу “Order”, ​​чтобы связать две таблицы вместе. Всегда используйте первичный ключ в каждой создаваемой вами таблице независимо от ее размера.

2. Плохо управляемая избыточность данных

Избыточность данных хороша для резервных копий, но не для табличных данных. Каждая таблица должна содержать уникальный набор данных, который не повторяет данные в других местах таблицы. Это одна из самых сложных идей для нового разработчика SQL. Очень просто забыть правила нормализации и повторить данные в нескольких таблицах для удобства, но это необязательно и представляет плохой дизайн таблицы.

Например, предположим, что у вас есть таблица клиентов, которая содержит адрес клиента. Поскольку адрес относится к клиенту, он находится в правильном месте. Затем вы создаете таблицу “Order” и добавляете адрес клиента в таблицу “Order”. Этот тип избыточности данных плохо спроектирован. Таблица Customer и “Order” могут связываться друг с другом, используя связи между первичным и внешним ключами. Что произойдет, если вы забудете обновить адрес клиента в таблице заказов? В результате у вас теперь есть два адреса для клиента, и вы не знаете, какой из них является точным.

Итог: всегда храните данные в одном месте и используйте отношения между первичным и внешним ключами для запроса данных.

3. Избегайте NOT IN или IN и используйте вместо этого JOIN

Операторы NOT IN и IN плохо оптимизированы. Они удобны, но обычно их можно заменить простым оператором JOIN. Посмотрите на пример запроса.

В приведенном выше заявлении возвращается набор данных всех клиентов, у которых нет заказа. В этом операторе база данных SQL извлекает все заказы из таблицы Order, а затем отфильтровывает набор записей на основе основного внешнего запроса в таблице Customer. Если у вас есть миллионы заказов, это чрезвычайно медленный запрос.

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

Оператор LEFT JOIN возвращает тот же набор данных, что и предыдущий оператор, но он гораздо более оптимизирован. Он объединяет две таблицы по первичному и внешнему ключу, что повышает скорость запроса и позволяет избежать предложений NOT IN и IN.

4. Забытые значения NULL и пустые строковые значения

Дискуссии между пустыми и пустыми строками между администраторами баз данных продолжались в течение десятилетий. Вы можете использовать значения NULL, если значения отсутствуют, или вы можете использовать фактические литеральные значения, такие как строки нулевой длины или 0 целочисленных значений. То, что вы используете в базе данных, должно быть одинаковым для всех таблиц, иначе запросы могут стать беспорядочными. Помните, что значения NULL не совпадают, например, со строкой нулевой длины, поэтому ваши запросы должны учитывать эти значения, если в дизайне таблицы нет стандарта.

Когда вы определите, что вы хотите использовать, убедитесь, что ваши запросы учитывают эти значения. Например, если вы разрешите NULL для фамилии пользователя, вы должны выполнить запрос с использованием фильтра NULL (NOT NULL или IS NULL) в ваших предложениях, чтобы включить или исключить эти записи.

5. Символ звездочки в операторах SELECT

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

Запрос возвращает все значения клиентов, включая любые конфиденциальные данные, которые вы можете хранить в таблице. Что если вы сохраните в таблице пароль клиента или номер социального страхования? Надеемся, что эти значения зашифрованы, но даже наличие хэшированного значения может помочь хакерам. Это также проблема производительности, если у вас есть десятки столбцов в таблице.

Вместо приведенного выше запроса всегда определяйте каждый столбец. Следующее утверждение является примером.

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

6. Цикл с слишком многими курсорами

Курсоры, циклические структуры в языке SQL, – это основа производительности базы данных. Они позволяют вам проходить через миллионы записей и запускать операторы для каждой из них в отдельности. Хотя это может показаться преимуществом, оно может снизить производительность базы данных. Циклы распространены в языках программирования, но они неэффективны в программировании SQL. Большинство администраторов баз данных отклоняют процедуры SQL с внедренными курсорами.

Читать еще:  Отъявленный программист: лайфхакинг из первых рук

Лучше всего написать процедуру по-другому, чтобы избежать негативного влияния на производительность базы данных, если это возможно. Большинство курсоров можно заменить хорошо написанным оператором SQL. Если вы не можете избежать этого, то курсоры следует сохранить для запланированных заданий, которые выполняются в непиковые часы. Курсоры используются в отчетах о запросах и заданиях на преобразование данных, поэтому их не всегда можно избежать. Просто ограничьте их как можно больше в производственных базах данных, которые ежедневно выполняют запросы к вашей базе данных.

7. Несоответствия данных в процедурах назначения на местах

Когда вы объявляете столбцы таблицы, вы должны назначить каждому столбцу тип данных. Убедитесь, что этот тип данных охватывает все необходимые значения, которые необходимо сохранить. Определив тип данных, вы можете хранить только этот тип значения в столбце.

Например, вам, вероятно, нужна десятичная точность на 2-3 пункта в столбце, в котором хранится общая стоимость заказа. Если вы назначите этот столбец как целое число, ваша база данных сможет хранить только целые числа без десятичных значений. Что происходит с десятичными знаками зависит от вашей платформы базы данных. Он может автоматически обрезать значения или выдать ошибку. Любая альтернатива может создать серьезную ошибку в вашем приложении. Всегда учитывайте то, что вам нужно хранить при разработке ваших таблиц.

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

8. Логические операции OR и AND

При написании ваших запросов легко упустить простой логический порядок. Операторы AND и OR могут значительно изменить набор данных. Вы можете избежать распространенных ошибок SQL, используя круглые скобки или организовав свои операторы для представления логики, которая должна применяться.

Давайте посмотрим на оператор SQL, который смешивает операторы AND и OR.

Цель приведенного выше утверждения состоит в том, чтобы получить любых клиентов с именем и фамилией «AndreyEx» и «Destroyer», а идентификатор клиента больше нуля. Однако, поскольку мы смешали оператор AND с OR, возвращаются все записи, в которых идентификатор клиента больше нуля. Мы можем преодолеть это логическое препятствие, используя круглые скобки. Давайте добавим их к приведенному выше утверждению.

Мы изменили логику для этого утверждения. Теперь первый набор скобок возвращает все записи, в которых имя клиента – AndreyEx или фамилия Destroyer. С помощью этого фильтра мы сообщаем SQL, чтобы он возвращал только те значения, где CustomerId больше нуля.

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

9. Подзапросы должны возвращать одну запись

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

Давайте посмотрим на пример.

В приведенном выше запросе мы получаем список идентификаторов клиентов из таблицы Customer. Обратите внимание, что мы получаем идентификатор заказа из таблицы заказов, где совпадает идентификатор клиента. Если есть только один заказ, этот запрос работает нормально. Однако, если для клиента существует более одного заказа, подзапрос возвращает более одной записи, и запрос не выполняется. Вы можете избежать этой проблемы, используя оператор «Top 1».

Давайте изменим запрос на следующий.

В приведенном выше запросе мы извлекаем только одну запись и упорядочиваем записи по дате. Этот запрос получает первый заказ, размещенный клиентом.

10. JOIN к индексам

Таблица всегда должна быть хорошо проиндексирована, и вы можете воспользоваться этими улучшениями производительности, используя оператор JOIN для столбцов, присвоенных индексу. В предыдущих примерах мы использовали первичный и внешний ключи таблицы. Столбец первичного ключа всегда является индексом, поэтому вам не нужно беспокоиться о производительности. Однако внешний ключ также должен иметь индекс.

Любые операторы JOIN, которые вы используете, должны иметь индекс для столбца. Если индекса нет, рассмотрите возможность добавления его в таблицу.

Заключение

Реляционные базы данных идеально подходят для большинства внутренних процедур, но вам необходимо создать правильный оператор SQL и оптимизировать таблицы и запросы для достижения максимальной производительности. Избегайте этих десяти ошибок SQL, и вы будете на пути к созданию быстрой и эффективной базы данных для любого малого, среднего или крупного онлайн-бизнеса.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Ошибки SQL-сервера

Содержание статьи:

    • SQL-сервер не найден или недоступен, ошибки соединения с SQL-сервером
      • Ошибка SQL-сервера 26
      • Ошибка SQL-сервера 18456
      • Не удалось запустить SQL-server — код ошибки 3417
    • Повреждена база данных
      • Код ошибки SQL-сервера 945
      • Код ошибки SQL-сервера 5172
      • Ошибка SQL-сервера 823
      • Ошибка SQL-сервера 8946

      SQL-сервер не найден или недоступен, ошибки соединения с SQL-сервером

      • Если SQL-сервер не найден, убедитесь, что ваш экземпляр SQL-сервера действительно установлен и запущен. Для этого зайдите на компьютер, где он установлен, запустите диспетчер конфигурации SQL и проверьте, есть ли там тот экземпляр, к которому вы пытаетесь подключиться и запущен ли он. Нелишним будет также получить отчет об обнаружении компонентов SQL-серверов.
      • Если вы проделали п1. и не обнаружили источник проблемы, возможно, неверно указан IP-адрес компьютера или номер порта TCP. Перепроверьте их настройки.
      • Причиной того, что невозможно подключиться к SQL-серверу, также может быть сеть, убедитесь, что компьютер с SQL-сервером доступен по сети.
      • Проверьте, может ли клиентское приложение, установленное на том же компьютере, что и сервер, подключиться к SQL-серверу. Запустите SQL Server Management Studio(SSMS), в диалоговом окне “Подключиться к серверу” выберите тип сервера Database Engine, укажите способ аутентификации “Аутентификация Windows”, введите имя компьютера и экземпляра SQL-сервера. Проверьте подключение.

      Обратите внимание, что многие сообщения об ошибках могут быть не показаны или не содержат достаточной информации для устранения проблемы. Это сделано из соображений безопасности, чтобы при попытке взлома злоумышленники не могли получить информацию об SQL-сервере. Полные сведения содержатся в логе ошибок, который обычно хранится по адресу C:Program FilesMicrosoft SQL ServerMSSQL13.MSSQLSERVERMSSQLLogERRORLOG, или там, куда его поместил администратор системы.

      Ошибка SQL-сервера 26

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

      • в SSMS в настройках SQL-сервера включите аутентификацию Windows
      • для брандмауэра Windows создайте новое правило, которое разрешает подключение для всех программ и протоколов с указанного IP-адреса
      • убедитесь, что запущена служба SQL Server Browser

      Ошибка SQL-сервера 18456

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

      Не удалось запустить SQL-server — код ошибки 3417

      Возникает в случае, если были изменены настройки Windows или перемещена папка с файлами MSSQL.

      • зайдите в C:Program FilesMicrosoft SQLServerMSSQL.1MSSqLData — БезопасностьНастройки доступа — Учетная запись сетевой службы — добавьте учетную запись сетевой службы
      • проверьте, что MDF-файл не сжимается. Если это не так, отключите “Сжимать содержимое для экономии места на диске” в свойствах файла

      Иногда ни один из этих способов не помогает, это значит, что файлы БД повреждены и ее придется восстанавливать из резервной копии.

      Повреждена база данных

      Код ошибки SQL-сервера 945

      Ошибка 945 возникает, когда БД SQL-сервера помечена как IsShutdown. Проверьте, достаточно ли места на диске, достаточно ли прав у учетной записи для операций с БД, файлы MDF и LDF не должны быть помечены “Только для чтения”.

      Код ошибки SQL-сервера 5172

      SQL-сервер хранит свою физическую БД в первичном файле, в котором информация разбита постранично. Первая страница содержит информацию о заголовке mdf-файла и называется страницей заголовка. Она состоит из разнообразной информации о БД, такой как размер файла, подпись и т.д. В процессе прикрепления MDF на SQL-сервере часто возникает ошибка 5172. Это в основном происходит, если MDF-файл поврежден, информация в его заголовке тоже и соответственно сложно добраться до данных. Причиной может быть вирус, аварийное выключение системы, ошибка оборудования.

      Ошибка SQL-сервера 823

      SQL использует API Windows для операций ввода-вывода, но кроме завершения этих операций SQL проверяет все ошибки обращений к API. Если эти обращения несовместимы с ОС, появляется ошибка 823. Сообщение об ошибке 823 означает, что существует проблема с базовым оборудованием для хранения данных или с драйвером, который находится на пути запроса ввода-вывода. Пользователи могут столкнуться с этой ошибкой, если в файловой системе есть противоречия или поврежден файл базы данных.

      Ошибка SQL-сервера 8946

      Основной причиной ошибки 8946 так же, как и для 5172, является повреждение заголовков страниц БД SQL вследствие сбоя питания, вирусной атаки, отказа оборудования — SQL-сервер больше не может прочесть эти страницы.

      • если у вас есть свежая резервная копия базы — восстановить базу из этой копии
      • можно попробовать использовать специализированное ПО, такое как SQL Recovery Tool, чтобы восстановить поврежденные файлы

      Желательно определить, что именно привело к возникновению ошибок и принять меры, чтобы это не повторялось — заменить плохо работающее оборудование, повысить информационную безопасность.

      Другие ошибки SQL

      Код ошибки SQL-сервера 1814

      SQL-сервер не может создать базу данных tempdb. Убедитесь, что на выделенном под нее диске достаточно места и что у учетной записи хватает прав для записи в указанную директорию.

      Код ошибки SQL-сервера 1067

      Эта ошибка может возникать по разным причинам. Наиболее часто оказывается, что повреждены или отсутствуют конфигурационные файлы, SQL-сервер обращается к поврежденным системным файлам, ошибочные данные пользователя, нет информации про лицензию. В самых тяжелых случаях придется переустанавливать SQL-сервер. Но иногда помогает восстановление поврежденных файлов или изменение настроек SQL-сервера — вы можете создать новую учетную запись в домене и использовать ее для службы MSSQL.

      SQL-сервер запускается, но работает слишком медленно

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

      Мы работаем с разными версиями SQL-сервера уже много лет, знакомы со всевозможными инструкциями SQL-сервера, видели самые разные варианты его настройки и использования на проектах у своих клиентов. В целом мы можем выделить четыре основных источника неполадок:

      • Индексы — причина проблем номер один. Неправильные индексы, отсутствующие индексы, слишком много индексов и подобное. Чаще всего при проблеме с индексами пользователи или администраторы базы данных не получают сообщения об ошибке, они просто видят, что база работает очень медленно и докопаться до причин бывает очень нелегко
      • изначально плохая архитектура сервера баз данных — ошибка, которую очень сложно и дорого исправлять на этапе, когда база уже используется
      • плохой код, в котором возможны блокировки и тупиковые места
      • использование конфигурации по умолчанию,

      Если у вас не получается устранить ошибки сервера SQL-server самостоятельно, если они появляются снова и снова, то скорее всего в основе лежит одна из этих причин. В таком случае — если у вас произошла ошибка с SQL сервером, ваше ПО не видит SQL-сервер, либо нужно развернуть кластер SQL-серверов — вы всегда можете обратиться за консультацией и технической поддержкой к специалистам Интегруса, отправив заявку с сайта, написав на e-mail, либо позвонив в колл-центр нашей компании.

      Настройка MSSQL для работы с 1С — мифы и реальность

      • 29 ноября

      Оптимизируем Microsoft SQL Server 2014 для работы с 1С. ОС — Windows Server 2012 R2. Напишу что нужно сделать, а что не нужно.

      Определяю мифичность очень просто, если мне пришлось применить настройку — реальность, не пришлось — миф.

      Устанавливаем последний Service Pack и Cumulative Update — реальность

      На текущий момент нужно обновиться до SP3.

      Обязательно нужно сделать.

      Выравнивание разделов — миф

      Рекомендуют выравнивать сектора дисков по границе 1024Кб и форматировать с размером блока 64Кб. Не заморачивайтесь, эта рекомендация устарела.

      HKLM SYSTEM CurrentControlSet Services VDS Alignment

      Эту настройку не применяем.

      Database instant file initialization — частично миф, частично реальность

      Рекомендуют включить возможность Database instant file initialization для пользователя, от которого запущена служба Microsoft SQL Server.

      Что это за штука?

      Во-первых, эта настройка влияет только на файл данных. Когда файл автоматически вырастает, то новый кусок заполняется нулями, в этот момент 1С может тормозить. Instant File Initialization (IFI) позволяет отключить это зануление.

      1. Запускаем Local Group Policy Editor:
      2. Слева выбираем Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assigment.
      3. Тыкаем в Perform volume maintenance tasks.
      4. Сюда добавляем юзера, от имени которого запускается SQL Server.

      Однако, у меня там уже прописана группа Administrators, а пользователь, под которым работает служба SQL Server уже в этой группе.

      Так что у меня ничего не пришлось настраивать. Но вы у себя проверьте.

      Давайте проверим, что всё работает. Рекомендуют создать новую БД размером 5 Гб и логом 1 Мб. Вот тут тоже нужно быть внимательным, нужно создавать под тем же пользователем, от которого запускается сервис SQL. Я создам от имени другого пользователя, который тоже в группе Administrators.

      База создалась мгновенно. На всякий случай попробую создать базу размером 50 Гб, место есть. Да, моментально на диске пропало 50 Гб и БД создалась быстро.

      Instant File Initialization (IFI) работает из коробки, если пользователь, под которым работает сервис SQL входит в группу Administrators сервера.

      Эту настройку применяем только при необходимости.

      Lock pages in memory — реальность

      Рекомендуют установить разрешение на Lock pages in memory (блокировку страниц в памяти) для пользователя, от которого запущена служба Microsoft SQL Server. Эта политика Windows определяет, какие учетные записи могут сохранять данные в физической памяти, чтобы система не отправляла страницы данных в виртуальную память на диске.

      1. Запускаем Local Group Policy Editor:
      2. Слева выбираем Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assigment.
      3. Тыкаем в Lock pages in memory.

    • Видим, что политика не настроена. Можно добавить сюда пользователя, от имени которого работает SQL Server, я просто добавляю сюда группу Administrators.
    • Эту настройку применяем. Нужно учитывать, что потребление оперативки возрастёт.

      Power Option: High performance — реальность

      Да, это реальность. По умолчанию план электропитания в Windows Server 2012 R2 — Balanced.

      В некоторых случаях, Microsoft не уточняет в каких, на сервере может из-за этого снижаться производительность. Переключаем план на High performance.

      Эту настройку применяем.

      Сжатие содержимого — миф

      Рекомендуют проверить, что галка, отмеченная на картинке выше, снята. Имеется в виду папка, где лежат файлы БД. По умолчанию она снята — рекомендация миф.

      Индексация файлов — миф

      По умолчанию галка Allow files in this folder to have contents indexed in addition to the file properties стоит:

      Казалось бы, надо снимать. Подумаем, эта галка указывает службе индексации, что содержимое нужно обработать. Зачем на сервере индексировать содержимое? А стоит ли вообще служба индексации по умолчанию? Проверяем:

      А служба поиска не установлена! Ну и забиваем на все эти галки. Эту настройку не применяем.

      Исключить файлы БД из систем резервного копирования — миф

      Это классика, не нужно ничего исключать, нужно просто нормально резервирование делать.

      Во-первых, не отделяйте мух от котлет. Не держите приложение 1С и SQL Server на одном сервере. MSSQL должен жить отдельно. И резервироваться он должен средствами MSSQL. И зеркалироваться.

      Эту настройку не применяем.

      Резервирование и обслуживание — реальность

      Эту настройку применяем.

      Настройка памяти — реальность

      Да, память для MSSQL нужно настраивать. По умолчанию сиквел жрёт всё что может, системе начинает не хватать. Как итог — тормоза. Нужно выделить SQL серверу строго определённое количество памяти и пусть не рыпается.

      Не держите приложение 1С и SQL Server на одном сервере. MSSQL должен жить отдельно.

      Это позволить избежать конкуренции за ресурсы.

      Эту настройку применяем.

      Настройка процессора — реальность

      Эту настройку применяем.

      Расположение файлов данных — реальность

      Файлы данных и файлы журналов транзакций желательно размещать на разных дисковых массивах. Если один из массивов быстрее, то лог нужно разместить там.

      Эту настройку по возможности применяем.

      Разбить tempdb на несколько файлов по количеству процессоров — миф

      Эту настройку не применяем.

      Перенести tempdb в RAM — реальность

      Сам протестировал, добился 10-кратного прироста скорости чтения-запись для tempdb.

      Эту настройку по возможности применяем.

      Установить параметр Max degree of parallelism = 1 — частично миф, частично реальность

      В закладке Advanced есть возможность установить параметр Max degree of parallelism. Кто-то рекомендует ставить 1, чтобы запретить параллельные запросы. Смысл в том, что один толстый запрос может сожрать все процессоры и помешать другим пользователям. С другой стороны, запущенная на ночь обработка могла бы выполняться быстрее при использовании нескольких процессоров. Давайте поступим иначе — ограничим половиной процессоров. У меня их 8, ставлю 4.

      Эту настройку применяем только при необходимости и в зависимости от количества процессоров.

      Прирост файлов БД — реальность

      Меняем дефолтные настройки прироста размера файлов данных и лога.

      По умолчанию прирост 10%, это никуда не годится. Если база 500 гигабайт, то одномоментно отобранные 50 Гб места могут негативно сказаться на работе.

      Ставим прирост 200 Мб.

      Эту настройку применяем.

      Флаги трассировки — реальность

      4199 — включает исправления оптимизатора из фиксов.

      1118 — использовать разные страницы памяти.

      Запускаем SQL Server Configuration Manager. SQL Server Services. SQL Server — правой кнопкой свойства. Вкладка Startup Parameters. Добавляем -T1118 и -T4199.

      Для применения потребуется перезапустить SQL сервер.

      Эту настройку применяем.

      Сетевые протоколы — реальность

      Протокол «Named pipes» необходимо отключить.

      Запускаем SQL Server Configuration Manager. SQL Server Network Connfiguration. Protocols for MSSQLSERVER (наш инстанс). Делаем Named Pipes — Disabled.

      Эту настройку применяем.

      Отключение DFSS — миф

      DFSS по умолчанию устанавливается на терминальный сервер. При чём тут SQL? Отключать нечего.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector