Now mssql: GETDATE (Transact-SQL) — SQL Server

Help, my database is corrupt. Now what? / Хабр

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

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

Как обнаружить, что база данных повреждена

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

Вот пара примеров системных сообщений при обнаружении повреждения БД:

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file ‘D:\Develop\Databases\Broken1. mdf’.

Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.

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

Я не буду описывать ситуацию когда база данных перешла в состояние «suspect» («подозрительная» в русской редакции SQL Server — прим. переводчика). Описание всевозможных причин почему база данных может перейти в «suspect» и множества вариантов исправления этого — тема отдельной статьи, если не книги.

Что делать если база данных все-таки повреждена

1. Не паниковать
2. Не отсоединять (detach) ее
3. Не перезапускать SQL Server
4. Не начинать восстановление сразу
5. Запустить проверку целостности
6. Найти причину

Не паниковать

Самое важное, при обнаружении повреждения БД — это не паниковать. Любые принимаемые решения должны быть тщательно взвешаны, во внимание должны быть приняты все возможные факторы. Чертовски просто ухудшить ситуацию приняв не до конца обдуманное решение.

Не отсоединять базу данных

В большинстве случаев, когда SQL Server обнарживает повреждение базы данных, это означает, что в БД на самом деле есть поврежденные страницы. Попытка убедить SQL Server что это не так, путем отсоединения (detach) и повторного присоединения (attach) БД, бэкапа и последующего восстановления, перезапуска службы SQL Server, либо перезагрузки сервера, не приведет к тому, что ошибка исчезнет.

Если база данных повреждена и SQL Server обнаружит это при присоединении, он не сможет присоединить ее. Есть несколько способов заставить его увидеть эту БД, но намного лучше просто не отсоединять ее.

Не перезапускать SQL Server

Точно так же, как при отсоединении-присоединении, перезапуск службы SQL Server не сможет исправить обнаруженные ошибки (если они есть).

Перезапуск службы может сделать ситуацию хуже. Если SQL Server обнаружит ошибки во время выполнения фазы восстановления (recovery) БД после перезапуска, он пометит ее как «suspect», что сильно усложнит процесс восстановления БД.

Не начинать восстановление сразу

У вас может возникнуть соблазн просто запустить DBCC CHECKDB с одним из «восстановительных» параметров (обычно допускающими потерю данных) и надеяться, что все станет лучше (по моему опыту — первое что рекомендуют на «непрофильных» форумах по SQL Server — запустить DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS — прим. переводчика). Во многих случаях запуск такого восстановления не рекомендуется. Он не гарантирует исправления всех ошибок и может привести к недопустимой потере данных.

Такое восстановление — это последний шаг при исправлении ошибок. Оно должно быть запущено только если у вас уже нет другого выбора, но никак не в первую очередь.

Запустить проверку целостности

Для того чтобы решить как исправить базу данных, мы точно должны знать что именно повреждено. Единственный способ, которым мы можем это выяснить — запустить DBCC CHECKDB с параметром All_ErrorMsgs (в SQL Server 2005 SP3, SQL Server 2008 SP1 и в более старших версиях, этот параметр включен по умолчанию, указывать его не обязательно). Помните, что если вы запустите DBCC CHECKDB без параметра No_InfoMsgs, в выводе этой процедуры будет информация о количестве строк и страниц в каждой таблице, что вряд ли будет вас интересовать при анализе ошибок.

DBCC CHECKDB может долго выполняться на больших БД, но необходимо дождаться пока эта процедура не закончит работу. Грамотная стратегия восстановления может быть построена только при наличии информации обо всех проблемах в БД.

Найти причину

После того как ошибки исправлены, работу нельзя считать законченной. Если причина этих ошибок не установлена, они могут возникнуть снова. Обычно, основной причиной ошибок являются проблемы с подсистемой ввода-вывода, но они также могут быть вызваны неправильной работой «низкоуровнего ПО» (вроде антивируса), действиями человека, либо багами самого SQL Server.

Что дальше

Дальнейшие действия по исправлению ошибок целиком и полностью зависят от результатов выполнения CheckDB. Чуть дальше я покажу несколько наиболее часто возникающих ошибок (учтите, что эта статья не претендует на звание полного описания всевозможных ошибок).

Описанные ошибки располагаются по возрастанию уровня серьезности — от наименее серьезных к наиболее серьезным. В общем-то, для наиболее серьезных ошибок, находимых CheckDB, есть описание доступных методов их резрешения.

Если у вас вдруг обнаружится ошибка не описанная в статье, обратите внимание на последний раздел — «Поиск помощи».

Неверная информация о свободном месте на странице

Msg 2508, Level 16, State 3, Line 1

The In-row data RSVD page count for object «Broken1», index ID 0, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.

В SQL Server 2000, количество строк и страниц в таблице или индексе, хранящееся в метаданных, могло не соответствовать действительности (и даже быть отрицательным) и DBCC CHECKDB не видел в этом ничего плохого. В SQL Server 2005, это количество должно быть правильным и CheckDB выдаст предупреждение, если вдруг найдет несоответствие.

Это несерьезная прблема и очень легко разрешается. Как говорится в сообщении, нужно всего лишь запустить DBCC UPDATEUSAGE в контексте нужной БД и предупреждение исчезнет. Эта ошибка часто встречается в базах данных обновленных с SQL Server 2000 и не должна появляться в базах данных, созданных в SQL Server 2005/2008.

Msg 8914, Level 16, State 1, Line 1

Incorrect PFS free space information for page (1:26839) in object ID 181575685, index ID 1, partition ID 293374720802816, alloc unit ID 76911687695381 (type LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.

Эта ошибка появляется, когда PFS-страница (Page Free Space), которая учитывает насколько заполнены страницы в БД, содержит некорректные значения. Эта ошибка, как и упомянутая ранее, не является серьезной. Алгоритм, по которому определялось насколько заполнены страницы, в SQL Server 2000 не всегда отрабатывал правильно. Для решения этой проблемы нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS и, если это единственная ошибка в БД, никакие данные, на самом деле, не пострадают.

Повреждение только некластерных индексов

Если все ошибки, найденные CheckDB, относятся к индексам с ID = 2 и больше, это означет, что были повреждены только некластерные индексы. Поскольку информация, содержащаяся в некластерных индексах, является «избыточной» (те же самые данные хранятся в куче, либо в кластерном индексе — прим. переводчика), эти повреждения могут быть исправлены без потери каких-либо данных.

Если все ошибки, найденные CheckDB, относятся к некластерным индексам, рекомендуемый «уровень восстановления» для DBCC CHECKDB — REPAIR_REBUILD. Примеры таких ошибок (на самом деле ошибок такого типа намного больше):

Msg 8941, Level 16, State 1, Line 1

Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted [i].offset >= PAGEHEADSIZE) failed. Slot 159, offset 0x1 is invalid.

Msg 8942, Level 16, State 1, Line 1

Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted[i].offset >= max) failed. Slot 0, offset 0x9f overlaps with the prior row.

В этом случае, повреждение может быть полностью исправлено удалением поврежденных некластерных индексов и повторным их созданием. Перестроение индекса (ALTER INDEX REBUILD) в режиме on-line (и иногда в off-line) читает страницы старого индекса для создания нового и, следовательно, завершится с ошибкой. Поэтому, необходимо удалить старые индексы и создать их заново.

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

Если у вас недостаточно времени на то, чтобы пересоздать нужные индексы и в наличии есть «чистый» (не содержащий в себе ошибок) полный бэкап и бэкапы журнала транзакций с неразорванной цепочкой журналов, вы можете восстановить поврежденные страницы из них.

Повреждение LOB-страниц

Msg 8964, Level 16, State 1, Line 1

Table error: Object ID 181575685, index ID 1, partition ID 72057594145669120, alloc unit ID 72057594087800832 (type LOB data). The off-row data node at page (1:2444050), slot 0, text ID 901891555328 is not referenced.

Ошибка говорит о том, что существуют LOB-страницы (Large OBject), на которые не ссылается ни одна страница с данными. Такое может произойти, если ранее был поврежден кластерный индекс (или куча) и его поврежденные страницы были удалены.

Если CheckDB говорит только о таких ошибках, то можно запускать DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS — эти страницы будут уничтожены. Поскольку у вас все равно нет страниц с данными, которые ссылаются на эти страницы, бОльшей потери данных уже не будет.

Ошибки, связанные с выходом за пределы допустимого диапазона

Msg 2570, Sev 16, State 3, Line 17

Page (1:1103587), slot 24 in object ID 34, index ID 1, partition ID 281474978938880, alloc unit ID 281474978938880 (type «In-row data»). Column «modified» value is out of range for data type «datetime». Update column to a legal value.

Эти ошибки показывают, что в столбце есть значения выходящие за пределы допустимого диапазона. Это может быть значение типа datetime, предполагающее, что с полуночи прошло больше 1440 минут, строка-Unicode, в которой количество байт не делится на 2, или float/real с неверным значением точности.

Проверка на эти ошибки не выполняется по умолчанию, для баз данных обновленных с версии SQL Server 2000 или более ранних, если перед этим ни разу не выполнялась команда DBCC CHECKDB со включенным параметром DATA_PURITY.

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

Повреждение кластерного индекса или кучи

Если обнаруживается, что повреждены страницы кучи или листового уровня (leaf pages) кластерного индекса — это означает, что данные на них потеряны. Страницы листового уровня кластерного индекса содержат непосредственно страницы данных и для них избыточность никак не обеспечивается.

Если CheckDB сообщает о повреждении страниц листового уровня кластерного индекса, необходимый «уровень восстановления» для DBCC CHECKDB — REPAIR_ALLOW_DATA_LOSS.

Примеры таких ошибок:

Server: Msg 8976, Level 16, State 1, Line 2

Table error: Object ID 181575685, index ID 1, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data). Page (1:22417) was not seen in the scan although its parent (1:479) and previous (1:715544) refer to it.

Server: Msg 8939, Level 16, State 1, Line 2

Table error: Object ID 181575685, index ID 0, page (1:168576). Test (m_freeData >= PAGEHEADSIZE && m_freeData <= (UINT)PAGESIZE — m_slotCnt * sizeof (Slot)) failed. Values are 44 and 8028.

Следует помнить, что если ошибки, возвращаемые CheckDB, относятся к index id = 0 или 1, это значит, что повреждены непосредственно данные.

Такой тип ошибок исправляется, но исправление заключается в уничтожении строк или целых страниц. Когда CheckDB удаляет данные для исправления ошибки, ограничения, налагаемые внешними ключами, не проверяются и никакие триггеры не срабатывают. Строки или страницы просто удаляются. В результате данные могут оказаться не согласованными, либо может быть нарушена логическая целостность (на LOB-страницы может больше не ссылаться ни одна строка, либо строки некластерного индекса могут указывать «в никуда»). Из-за таких последствий, подобное восстановление, не рекомендуется использовать.

Если у вас есть «чистый» бэкап, восстановление из него обычно является более предпочительным, для исправления таких ошибок. Если база данных находится в полной модели восстановления и у вас есть бэкапы журнала транзакций с неразорванной цепочкой журналов (начиная с последнего «чистого» полного бэкапа), вы можете сделать бэкап активной части лога и восстановить базу данных целиком (или только поврежденные страницы), в результате чего данные вообще не будут потеряны.

Если бэкапа с неповрежденными данными нет, у вас остается только один вариант — запуск DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Это потребует перевода базы данных в однопользовательский режим на все время выполнения этой процедуры.

И хотя у вас нет возможности избежать потери данных, вы можете посмотреть какие данные будут удалены из кластерного индекса. Для этого, посмотрите этот пост Пола Рэнадала.

Повреждение метаданных

Msg 3853, Level 16, State 1, Line 1

Attribute (object_id=181575685) of row (object_id=181575685,column_id=1) in sys.columns does not have a matching row (object_id=181575685) in sys.objects.

Подобные ошибки, обычно, возникают в базах данных, обновленных с SQL Server 2000, когда кто-то ковырялся напрямую в системных таблицах.

В системных таблицах любой версии SQL Server внешние ключи не используются, поэтому в SQL Server 2000 была возможность удалить строку из sysobjects (например, таблицу) и оставить в таблицах syscolumns и sysindexes строки, ссылающиеся на удаленную строку.

В SQL Server 2000 CheckDB не проверял целостность системного каталога и такие проблемы зачастую висели незамеченными. В SQL Server 2005, CheckDB проверяет целостность системного каталога и такие ошибки могут проявиться.

Исправление этих ошибок дело не самое легкое. CheckDB не может их исправить, поскольку единственное что можно сделать — это удалить записи из системных таблиц, что, в свою очередь, может вызвать потерю большого количества данных. Если у вас есть бэкап этой БД, сделанный до обновления на SQL Server 2005 и обновление было совсем недавно, вы можете развернуть его на SQL Server 2000, на нем вручную подправить системные таблицы и снова перенести БД на SQL Server 2005.

Если у вас нет бэкапа БД на SQL Server 2000 или обновление прошло слишком давно и потеря данных неприемлима, есть два пути. Первый — отредактировать системные таблицы в SQL Server 2005, но следует учитывать, что это довольно сложный и рискованный процесс, поскольку системные таблицы не документированы и гораздо более сложны, чем в ранних версиях. В этом посте можно найти дополнительную информацию.

Второй путь — это заскриптовать все объекты БД и экспортировать все данные, после чего создать новую базу данных, восстановить объекты и залить данные. Этот вариант более предпочтителен.

Неисправимые повреждения

CheckDB не может исправить все. Любые ошибки вроде приведенных ниже неисправимы и единственный вариант — это восстановление базы данных из бэкапа, в котором нет этих повреждений. Если у вас есть полный бэкап и цепочка журналов не нарушена до текущего времени, вы можете забэкапить заключительный фрагмент журнала транзакций и база данных может быть восстановлена без потери каких-либо данных.

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

Повреждение системных таблиц

Msg 7985, Level 16, State 2, Line 1

System table pre-checks: Object ID 4. Could not read and latch page (1:358) with latch type SH.

Check statement terminated due to unrepairable error.

Msg 8921, Level 16, State 1, Line 1

Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent.

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

Повреждение «карт распределения»

Msg 8946, Level 16, State 12, Line 1

Table error: Allocation page (1:2264640) has invalid PFS_PAGE page header values. Type is 0. Check type, alloc unit ID and page ID on the page.

Msg 8998, Level 16, State 2, Line 1

Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 13 pages from (1:2264640) to (1:2272727)

В этом случае, одна или несколько страниц определяющих размещение данных в БД (карты распределения — прим. переводчика) повреждены. Эти страницы используются для того чтобы определять какие страницы и экстенты в БД используются, а какие свободны. CheckDB не может исправить такие ошибки, поскольку практически невозможно определить (без этих страниц) какие экстенты используются для размещения данных, а какие нет. Простое удаление такой «карты распределения» невозможно, поскольку удаление любой из них повлечет за собой удаление 4 GB данных.

Поиск помощи

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

Если у вас есть Senior DBA, обратитесь к нему. Если у вас есть «наставник» — спросите у него. Спросите совета на форумах, но помните, что не все советы полученные на форумах полезны. На самом деле, именно там время от времени публикуются абсолютно неправильные и даже опасные решения.

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

Заключение

В этой статье я дал несколько примеров того, что можно сделать при обнаружении поврежденной БД и, что даже важнее, того, что делать не надо. Надеюсь, что теперь вы лучше понимаете какие методы можно применять для решения описанных проблем и насколько важно иметь хорошие бэкапы (и правильно выбрать модель восстановления — прим. переводчика).

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

С уважением, unfilled.

P.S. Когда я уже собрался было нажать на кнопочку «Опубликовать», мне на почту свалилась рассылка от SQL Server Central с вот таким вот комиксом.

SQL Server эквивалентно MySQL NOW ()?

спросил
14 лет, 5 месяцев назад

Изменено
5 месяцев назад

Просмотрено
215 тысяч раз

Я парень MySQL, работающий над проектом SQL Server, пытаюсь получить поле даты и времени, чтобы показать текущее время. В MySQL я бы использовал NOW(), но он этого не принимает.

 ВСТАВИТЬ В журнал времени (datetime_filed) ЗНАЧЕНИЯ (СЕЙЧАС())
 

• sql
• sql-сервер

0

getdate() или getutcdate() .

0

 получить дату()
 

является прямым эквивалентом , но вы всегда должны использовать UTC datetimes

 getutcdate()
 

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

1

SYSDATETIME() и SYSUTCDATETIME()

являются эквивалентами DateTime2

GetDate() и GetUTCDate() 9000 5

, которые возвращают DateTime.

DateTime2 теперь является предпочтительным методом хранения даты и времени в SQL Server 2008+. См. следующий пост StackOverflow.

0

Вы также можете использовать CURRENT_TIMESTAMP , если хотите быть более совместимым с ANSI (хотя, если вы переносите код между поставщиками баз данных, это будет наименьшей из ваших забот). Это точно так же, как GetDate() под обложками (подробности см. в этом вопросе).

Нет эквивалента ANSI для GetUTCDate() , который, вероятно, следует использовать, если ваше приложение работает более чем в одном часовом поясе…

1

Ниже приведены функции, которые вы можете использовать в SQL Server вместо NOW()

1. SYSDATETIME()
2. ПОЛУЧИТЬ ДАТУ ()
3. ПОЛУЧИТЬ ДАТУ ()
4. CURRENT_TIMESTAMP

Эти функции дают почти точную дату и время, тогда как SYSDATETIME дает более точное время в миллисекундах.

Запрос:
ВЫБЕРИТЕ SYSDATETIME()

Вывод:
2022-12-21 19:38:49. 4181976

Запрос:
ВЫБЕРИТЕ ПОЛУЧИТЬ ДАТУ () | ПОЛУЧИТЬДАТУ() | CURRENT_TIMESTAMP

Вывод:
2022-12-21 19:38:49.413

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания и подтверждаете, что прочитали и поняли нашу политику конфиденциальности и кодекс поведения.

Функция SQL Server GETDATE() и варианты ее использования

В этой статье мы обсудим обзор и варианты использования функции SQL Server GETDATE(), которая используется для возврата текущей даты и времени системы, в которой работает экземпляр SQL Server. Есть несколько связанных с датой и временем
функции в SQL Server для различных требований, таких как SYSDATETIME, CURRENT_TIMESTAMP и т. д. Все эти функции будут
вернуть текущую дату и время системы, в которой работает SQL Server. Единственная разница в наличии этих многих функций — это точность длины временной метки, например, до какой точности вы хотите вернуть дату и время.
выход. Я покажу вам вывод некоторых из этих функций даты и времени и сравним их с функцией SQL Server GETDATE().

Ниже приведен синтаксис функции GETDATE. Выходные данные этой функции будут возвращены в формате «ГГГГ-ММ-ДД чч:мм:сс.ммм».

Функция SQL Server GETDATE очень гибкая и может использоваться с различными другими функциями даты и времени для возврата вывода в желаемом формате. Давайте сначала сравним эту функцию с другими функциями даты и времени, доступными в SQL Server, в разделе ниже.

Сравните функцию SQL Server GETDATE() с другими функциями даты и времени

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

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

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

Мы видим, что текущая метка времени, возвращаемая вышеуказанными функциями, имеет определенный формат. Если мы хотим получить только текущую дату системы или только время системы, то нам нужно использовать другую функцию SQL Server CONVERT
чтобы вернуть только дату или время из приведенного выше вывода. Я покажу это в приведенных ниже примерах использования, чтобы вы могли использовать их в соответствии с вашими требованиями.

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

Вывод показывает текущую системную дату только для всех системных функций.

Точно так же мы можем получить текущее системное время, только выполнив следующие запросы. Нам просто нужно заменить «Дата» на «Время» в скобках, как показано в приведенных ниже утверждениях.

Вот вывод, в котором мы видим одно и то же время, возвращаемое всеми тремя функциями, за исключением долей секунды.

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

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

Примеры использования функции SQL Server GETDATE()

Вывод вышеуказанных запросов возвращается в определенном формате. Предположим, вы хотите вернуть единственный год,
месяц, дату или день, то вы не можете получить это с помощью вышеуказанных запросов. SQL Server предлагает несколько функций, которые мы можем
используйте для получения гораздо более глубоких и детализированных результатов с помощью функции SQL Server GETDATE. Эти функции
DATENAME, DATEPART, DAY, MONTH, YEAR и т. д.

Теперь давайте обсудим, как использовать функцию SQL Server GETDATE с различными другими функциями в следующем разделе.

Используйте функцию GETDATE с функциями DATENAME, DATEPART и DATEADD

DATENAME и DATEPART — это функции SQL Server,
в другом формате. Функция DATENAME вернет дату и время на основе строки символов указанного
date, тогда как функция DATEPART вернет дату и время в виде целого числа для указанной даты.

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

Ниже приведены части даты и времени, которые могут быть возвращены с помощью этих функций:

• Год
• Четверть
• Месяц
• День года
• День
• Неделя
• будний день
• Час
• Минута
• Второй
• Миллисекунда
• микросекунда
• Наносекунда
• TZсмещение
• ISO_WEEK

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

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

Мы также можем использовать его аббревиатуру, чтобы получить результат, например, мы можем использовать mm или m для МЕСЯЦЕВ, dd или d для ДНЯ и т. д.

Теперь мы запустим вышеуказанный запрос с функцией DATEPART и посмотрим разницу между их выводом. Ты можешь видеть,
Я только что заменил функцию DATENAME функцией DATEPART в приведенном ниже запросе.

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

Использование функции DATEADD совсем другое. Это помогает нам получить прошлые или будущие даты на основе
в числовом выражении, переданном указанному значению или частям даты и времени, как указано в приведенном ниже запросе.

Я использовал номер 2 для каждой части выражений даты и времени, поэтому приведенный выше запрос будет отображаться:

• 2 ^-й -й квартал с сегодняшнего дня
• 2 ^й месяц с сегодняшнего дня
• 2 ^-й -й день с сегодняшнего дня
• 2 ^nd неделя с сегодняшнего дня
• 2 ^й рабочий день с сегодняшнего дня

Обратите внимание: я получил текущий вывод даты и времени, используя функцию SQL Server GETDATE, чтобы отметить, что сегодня
Дата и время. Все расчеты будут происходить от этого значения. Вы можете передать любое число этому запросу, и результат будет
вернуть n-е значение этой части даты и времени. Если вы хотите получить аналогичный результат из прошлого, вам нужно
передайте это число с отрицательными знаками, такими как -2, -5 и т. д.

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

Использовать функцию SQL Server GETDATE с функциями ДЕНЬ, МЕСЯЦ, КОНМЕСЯЦ и ГОД

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

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

Мы использовали:

• Функция YEAR для отображения текущего года из функции SQL Server GETDATE
• МЕСЯЦ функция для отображения номера текущего месяца из функции SQL Server GETDATE
• Функция DAY для отображения даты из функции SQL Server GETDATE
• EOMONTH функция для отображения последнего дня текущего месяца с помощью функции SQL Server GETDATE

Мы также можем использовать функцию КОНМЕСЯЦ для отображения последней даты текущего, прошлого, будущего или любого другого события.
указанные месяцы. Нам нужно передать число в эту функцию. Это число определит n-й месяц.

Вы можете проанализировать приведенный ниже пример, где:

• Я не передал ни одного числа, чтобы получить последнюю дату текущего месяца
• Я использовал -1 число, чтобы получить последнюю дату предыдущего месяца
• Я использовал номер 1 , чтобы получить последнюю дату следующего месяца.

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

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

Преобразование формата даты и времени с помощью CAST и CONVERT

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

SQL Server предлагает две функции ПРИВЕСТИ и ПРЕОБРАЗОВАТЬ в адресный формат даты и времени
проблемы. Вы можете преобразовать текущую дату в соответствии с вашими местными стандартами, используя функцию ПРЕОБРАЗОВАТЬ. Здесь я покажу
вы, как преобразовать текущие форматы даты и времени, используя функции CAST и CONVERT.

Приведенный ниже запрос отобразит вывод:

• Функция SQL Server ПОЛУЧИТЬ.ДАТУ
• В следующей строке кода используется функция CAST для преобразования существующего текущего формата даты и времени, отображаемого в первом столбце, в другой формат МММ ДД ГГГ ЧЧ:ММ.
• Функция CONVERT также вернет тот же результат, что и функция CAST.

Я бы порекомендовал вам посетить прикрепленную ссылку MSDN, чтобы получить все применимые форматы даты и времени, в которых мы можем получить
текущую дату и время с помощью функции SQL Server GETDATE() с помощью функции CONVERT.

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

В приведенном ниже примере я продемонстрировал отображение текущей даты и времени в различных форматах, начиная с номера формата 0.
для формата № 7.

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

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

Заключение

Я объяснил обзор и различные варианты использования функции SQL Server GETDATE. Эта функция очень полезна
чтобы вернуть текущую метку времени в нескольких форматах в зависимости от нашего требования. Вы можете понять это больше,
рассматривая несколько примеров, приведенных в этой статье. Вы также можете попробовать другие функции даты и времени SQL Server, если
функция SQL Server GETDATE не подходит для ваших требований.