Создание резервной копии журнала транзакций при повреждении базы данных (sql server)

Сломанная цепочка журнала транзакций

Цепочка журнала (транзакции) никогда не нарушается, если не выполняется одно из следующих условий:

файл резервной копии журнала транзакций был удален
файл резервной копии журнала транзакций недоступен (где-то на устройстве резервного копирования; стороннее решение для резервного копирования)
база данных находится в простой модели восстановления
резервное копирование журнала транзакций было выполнено с параметром
пОЛНАЯ резервная копия базы данных была сделана без опции , а затем удалена с диска, поскольку разработчикам требовалось только быстрое резервное копирование для анализа ситуации в базе данных и ваш резервное копирование до того, как оно было удалено (a) процедурой резервного копирования.

Общие сведения о сценариях восстановления

Сценарий восстановления в SQL Server — процесс восстановления данных из одной или более резервных копий и возврат в исходное состояние базы данных. Поддерживаемые сценарии восстановления зависят от модели восстановления базы данных и выпуска SQL Server.

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

Сценарий восстановления	Простая модель восстановления	Модель полного восстановления или модель восстановления с неполным протоколированием
полное восстановление базы данных	Это базовая стратегия восстановления. Полное восстановление базы данных может содержать простые операции возврата и восстановления из полной резервной копии. Также полное восстановление базы данных может проводиться на основе полной резервной копии базы данных с ее последующим обновлением по журналу. Дополнительные сведения см. в разделе Полное восстановление базы данных (простая модель восстановления).	Это базовая стратегия восстановления. Восстановление всей базы данных включает в себя восстановление полной резервной копии, возможно, разностных резервных копий (если они есть) и восстановления всех последующих резервных копий журналов (последовательно). Восстановление всей базы данных завершается восстановлением из последней резервной копии журнала и возвратом в исходное состояние (RESTORE WITH RECOVERY). Дополнительные сведения см. в статье Выполнение полного восстановления базы данных (модель полного восстановления).
File restore *	Восстановление одного или более поврежденных файлов с атрибутом «только для чтения» без восстановления всей базы данных. Восстановление файла возможно только при наличии в базе данных хотя бы одной файловой группы с атрибутом «только для чтения».	Восстановление одного или нескольких файлов без восстановления всей базы данных. Восстановление файлов может выполняться, когда база данных находится в режиме «вне сети» или в некоторых выпусках SQL Server«в сети». Во время восстановления файла файловые группы, содержащие обрабатываемый файл, всегда находятся в режиме вне сети.
Восстановление страницы	Неприменимо	Восстановление одной или нескольких поврежденных страниц. Восстановление страницы может выполняться, когда база данных находится в режиме «вне сети» или в некоторых выпусках SQL Server«в сети». Во время восстановления страницы всегда находятся в режиме вне сети. Должна быть доступна непрерывная цепочка резервных копий журналов вплоть до текущего файла журнала, и они должны быть применены для приведения страницы в соответствие текущему журналу. Дополнительные сведения см. в разделе Восстановление страниц (SQL Server).
Поэтапное восстановление *	Поэтапное восстановление базы данных на уровне файловой группы, начиная с групп файлов, доступных для чтения и записи, вторичных файловых групп.	Восстановление и перевод базы данных в режим в сети по этапам на уровне файловой группы, начиная с первичной файловой группы. Дополнительные сведения см. в разделе Поэтапное восстановление (SQL Server)

* Восстановление в сети поддерживается только в выпуске Enterprise Edition.

Шаги по восстановлению базы данных

Для восстановления файла Компонент Database Engine выполняет два шага:

создает любой недостающий файл базы данных;
копирует данные с устройств резервного копирования в файл(ы) базы данных.

Для восстановления базы данных Компонент Database Engine выполняет три шага:

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

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

Преимущества восстановления файлов или страниц

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

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

Шаг 2. Настройка сервера Microsoft SQL 2005

2.1. Настройка протоколов подключения

Для настройки протоколов взаимодействия сервера и клиента Microsoft SQL необходимо запустить «SQL Server Configuration Manager»:

…и оставить для работы только протоколы TCP/IP и Shared Memory:

Если устанавливается версия MS SQL Express по-умолчанию выключен протокол TCP/IP, нужный для работы с 1С:Предприятие 8 — его необходимо включить. Протокол именнованных каналов (Named Pipe) выключите совсем (и для «клиента» тоже на сервере приложений).

2.2. Перенос tempdb на быстрый независимый массив/диски

Для переноса tempdb необходимо запустить sql-скрипт примерно следующего содержания:

USE master
GO
ALTER DATABASE tempdb
modify file (NAME=tempdev, FILENAME='E:\Temp\tempdb_data.mdf')
GO
ALTER DATABASE tempdb
modify file (NAME=templog, FILENAME='E:\Temp\tempdb_log.ldf')
GO

где, E:\Temp\ — каталог, в котором будут лежать tempdb, а tempdb_data.mdf и tempdb_log.ldf имя файла базы данных и лога соответственно.

2.3. Настройка параметров сервера SQL

Для настройки сервера запускаем «SQL Server Management Studio», подключаемся к установленному серверу Database Engine’ом и открываем свойства (Server Properties). Тут нам нужно настроить 3 пункта:

Память (Memory)

Параметр «Maximum server memory (in MB)» задает максимально отведенное серверу количество памяти из расчета: – – . Например, если у нас на сервере всего 24 ГБ оперативной памяти, стоит Windows 2003 и запущен сервер 1С Предприятия с 2мя процессами rphost (которым нужна память хотябы по 1,5Гб) то рассчет будет следующим: 24 — 1,5 — 1,5*2 = 19,5 ГБ ставит параметр «Maximum server memory (in MB)». Это необходимо для того, чтобы sql-сервер рассчитывал на заданный объем и освобождал память заблаговременно, т.к. если поставить неограниченный объем, и сервер попробует получить память, которой нет, он начинает лезть в файл подкачки, что сильно замедлит работу.

Процессоры (Processors)

Максимальное количество потоков (Maximum worker threads) стОит регулировать только при большом количестве клиентов (более 255) и для 1С это не актуально, поэтому оставим по-умолчанию. (хотя обратное ). Также выставляем галку повышенного приоритета сервера (Boost SQL Server priority).

Database Settings

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

Сжатие баз данных 1С:Предприятие в MS SQL Server Промо

Тема сжатия баз данных 1С в настоящий момент довольно часто обсуждается. Достоинства сжатия известны – уменьшение размера базы данных, уменьшение нагрузки на дисковую подсистему и некоторое ускорение выполнения тяжелых операций чтения/записи. Из недостатков – небольшое увеличение нагрузки на процессоры сервера СУБД за счет расхода ресурсов на компрессию/декомпрессию данных. Но при использовании в качестве MSSQL и DB2 (за Oracle и PostgreSQL не скажу, т.к. не знаю) есть один «подводный камень» — при выполнении реструктуризации происходит декомпрессия новых таблиц и индексов. Происходить это может как при выполнении обновления конфигурации с изменением структуры метаданных, так и при выполнении тестирования и исправления ИБ (реиндексация пересоздает только индексы, а реструктуризация – и таблицы, и индексы). «Проблема» кроется в том, что признак сжатия устанавливается индивидуально для каждой таблицы и индекса.

Обработка больших файлов

Операция резервного копирования SQL Server выполняется в несколько потоков, чтобы оптимизировать передачу данных к службам хранилищ BLOB-объектов Azure. Однако производительность зависит от различных факторов, в том числе от пропускной способности ISV и размера базы данных. Если планируется создавать резервные копии больших баз данных или файловых групп в локальной базе данных SQL Server, вначале рекомендуется проверить пропускную способность

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

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

Ректальное администрирование: Основы для практикующих системных АДминистраторов

Одной из самых популярных и зарекомендовавших себя методологий системного администрирования является так называемое ректальное. Редкий случай сопровождения и обслуживания информационных систем, инфраструктуры организации обходится без его использования. Зачастую без знания данной методологии сисадминам даже бывает сложно найти работу в сфере ИТ, потому что работодатели, особенно всякие аутсорсинговые ИТ фирмы, в основном отдают предпочтение классическим, зарекомендовавшим себя методикам, а не новомодным заграничным веяниям: практикам ITIL, нормальным ITSM и прочей ерунде.

Разрешения

Чтобы использовать RESTORE для несуществующей базы данных, пользователь должен обладать разрешениями CREATE DATABASE. Разрешения на выполнение инструкции RESTORE для существующих баз данных базы данных по умолчанию предоставлены членам предопределенных ролей сервера sysadmin и dbcreator, а также владельцу базы данных (dbo).

Сведения о членстве для ролей, имеющих разрешения на выполнение инструкции RESTORE, всегда доступны в экземпляре.

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

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

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

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

FAQ MS SQL для 1С Предприятие

В связи с частыми одинаковыми вопросами в комментах решил добавить FAQ.

Q: Сегодня настроил SQL и создал план обслуживания. Все в точности по данной статье, но бэкапы не создаются. Почему? (ведь настроено создание бэкапов каждые 30 минут)
A: Потому что бэкапы каждые 30 минут создают копии журналов транзакций. Данный вид копий может создаваться только от полной копии. Соответственно, (бэкап лога транзакций) будет выполнен только после выполнения и только после удачного выполнения шага полного бэкапа в первом подплане!!! Соответственно, выход из ситуации — дождаться выполнения первого подплана.

Q: Почему файл жарнала транзакций растет? Как от этого избавиться? Что делать? A: Самый правильный выход из ситуации — увеличить раздел жесткого диска, на котором размещен файл журнала. Уменьшать размер файла с помощью операции shrink только вызовет лишние обращения сервера к жесткому диску. Сервер увеличивает размер этого файла до того размера, который ему необходим для выполнения транзакций. Соответственно, обрезав файл журнала мы заставляем SQL сервер лишний раз насиловать жесткий диск — снова увеличивая размер журнала при очередной ресурсоемкой транзакции. Данный нюанс я обсуждал в — советую перечитать ее. Есть еще выход — «если не очень сыкотно — можно перед ребилдом делать «финальный» бакап (можно только логов), ставить симпл модель, после ребилда — возвращать фулл рекавери и опять делать фулл бакап» отпять же .

Q: Почему не делается shrink для лога? многие советуют…
A: см предыдущий вопрос\ответ

Дополнительно почитать:

— обслуживание базы данных MS SQL (регламентные задания и резервное копирование) от мекрософт и
— установка MS SQL 2005-
— Настройка почтовых уведомлений об ошибках выполнения плана MS SQL серера

Удачных Вам бэкапов

upd 2012.12.09: добавлен

Резервные копии заключительного фрагмента журнала с неполными метаданными

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

Если резервная копия заключительного фрагмента журнала содержит неполные метаданные, то параметр has_incomplete_metadata в таблице backupset принимает значение 1. Кроме того, выходной аргумент HasIncompleteMetadataинструкции RESTORE HEADERONLY принимает значение 1.

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

backup_set_id
filegroup_id
type
type_desc
is_readonly

Методы устранения неполадок

Вопросы

На каком этапе синхронизации происходит сбой репликации?
В каком агенте возникает ошибка?
Когда в последний раз репликация завершилась успешно? Изменилось ли что-нибудь с того момента?

Действия для выполнения

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

Копирование числовых ячеек из 1С в Excel Промо

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

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

Поддержка совместимости

В SQL Server 2019 (15.x)можно восстановить пользовательскую базу данных из резервной копии базы данных, созданной с помощью SQL Server 2005 (9.x) или более поздней версии. Восстановление резервных копий баз данных master, model и msdb, созданных путем использования SQL Server 2005 (9.x) через SQL Server 2012 (11.x), невозможно в SQL Server 2019 (15.x). Кроме того, резервные копии, созданные в SQL Server 2019 (15.x) , невозможно восстановить в более ранних версиях SQL Server.

SQL Server 2019 (15.x) используется путь по умолчанию, отличный от пути, использованного в предыдущих версиях. Чтобы восстановить из резервной копии базу данных, созданную в расположении по умолчанию для SQL Serverпредыдущих версий, необходимо использовать параметр MOVE.

Если восстановить базу данных предыдущей версии до SQL Server 2019 (15.x), то эта база данных автоматически обновится. Как правило, база данных сразу становится доступной. Однако если база данных SQL Server 2005 (9.x) содержит полнотекстовые индексы, то в процессе обновления будет произведен их импорт, сброс или перестроение, в зависимости от установленного значения свойства сервера Режим обновления полнотекстового каталога . Если при обновлении выбран режим Импортировать или Перестроить, то полнотекстовые индексы во время обновления будут недоступны. В зависимости от объема индексируемых данных процесс импорта может занять несколько часов, а перестроения — в несколько (до 10) раз больше

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

Использование Transact-SQL

Создайте полную резервную копию базы данных, выполнив инструкцию для создания полной резервной копии базы данных и указав следующее:

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

Базовая структура синтаксиса Transact-SQL для полного резервного копирования базы данных:

BACKUP DATABASE database TO backup_device ] ;

Параметр	Описание
database	База данных для резервного копирования.
backup_device	Указывает список от 1 до 64 устройств резервного копирования, используемых для создания резервной копии. Можно указать как физическое устройство резервного копирования, так и соответствующее логическое устройство, если оно уже определено. Для указания физического устройства резервного копирования используйте параметр DISK или TAPE. { DISK \| TAPE } = physical_backup_device_name Дополнительные сведения см. в разделе Устройства резервного копирования (SQL Server).
WITH with_options	Используется для указания одного или нескольких параметров, o. Сведения о некоторых основных параметрах см. в пункте 2.

При необходимости укажите один параметр WITH или несколько. Здесь описываются некоторые основные параметры WITH. Сведения о всех параметрах WITH см. в разделе BACKUP (Transact-SQL).

Основные параметры WITH резервного набора данных:

{ COMPRESSION | NO_COMPRESSION } : Только в версии SQL Server 2008 Enterprise и выше указано, выполняется ли команда backup compression для этой резервной копии, переопределяя значение по умолчанию на уровне сервера.
ENCRYPTION (ALGORITHM, SERVER CERTIFICATE | ASYMMETRIC KEY) : Только для SQL Server 2014 и выше укажите используемый алгоритм шифрования, а также сертификат или асимметричный ключ для шифрования.
DESCRIPTION = { ‘ text ‘ | @ text_variable }: Задает произвольное текстовое описание резервного набора данных. В этой строке может содержаться до 255 символов.
NAME = { имя_резервного_набора_данных | @ переменная_резервного_набора_данных } : Указывает имя резервного набора данных. Длина имени не может превышать 128 символов. Если имя не указано, оно остается пустым.

По умолчанию команда добавляет резервную копию в существующий набор носителей, сохраняя существующие резервные наборы данных. Чтобы явно задать значение, используйте параметр . Сведения о присоединении к существующим резервным наборам данных см. в разделе Наборы носителей, семейства носителей и резервные наборы данных (SQL Server).

Чтобы отформатировать носитель резервной копии, используйте параметр FORMAT:

FORMAT

Используйте предложение FORMAT при первом обращении к носителю или при необходимости перезаписать все существующие данные. При необходимости назначьте новому носителю имя и описание.

Важно!

Будьте предельно осторожны, используя предложение FORMAT инструкции , так как оно удаляет все резервные копии, сохраненные ранее на носителе резервных копий.

A. Резервное копирование на дисковое устройство

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

Б. Резервное копирование на ленточное устройство

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

В. Резервное копирование на логическое ленточное устройство

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

10 ответов

Лучший ответ

> > > > >

После изменения этого параметра вам может потребоваться закрыть и снова открыть SSMS.

На панели инструментов редактора SQL вы можете выбрать сохранение в файл без перезапуска SSMS

287

RBT
18 Мар 2019 в 09:44

Я тоже сталкиваюсь с той же проблемой. Когда я использовал правый щелчок в окне запроса и выбрал Параметры запроса. Но строки заголовка не отображаются в выходном CSV-файле.

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

RBT
18 Мар 2019 в 09:06

В SQL Server 2014 Management Studio этот параметр находится по адресу:

Инструменты> Параметры> Результаты запроса> SQL Server> Результаты в текст> Включить заголовки столбцов в набор результатов.

RBT
18 Мар 2019 в 09:05

Попал сюда, когда искал способ заставить SSMS правильно экранировать разделители CSV при экспорте результатов.

Угадай, что? — это действительно опция, и она не отмечена по умолчанию . Таким образом, по умолчанию вы получаете битые CSV-файлы (и можете даже не осознавать этого, особенно если ваш экспорт большой и ваши данные обычно не содержат запятых) — и вам нужно войти и установить флажок, чтобы ваши CSV-файлы экспортировались правильно!

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

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

Daibhi O Domhnaill
27 Авг 2018 в 11:21

Параметры, которые было рекомендовано изменить в принятом ответе @Diego, могут быть хорошими, если вы хотите установить этот параметр постоянно для всех будущих сеансов запросов, которые вы открываете в SQL Server Management Studio (SSMS). Обычно это не . Кроме того, изменение этого параметра требует перезапуска приложения SQL Server Management Studio (SSMS). Это снова «не очень приятный» опыт, если у вас много несохраненных открытых окон сеанса запросов и вы находитесь в процессе некоторой отладки.

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

Щелкните правой кнопкой мыши в окне редактора запросов> щелкните в нижней части контекстного меню, как показано ниже:

Выберите > на левой панели навигации. Установите флажок на правой панели, как показано ниже:

Вот и все. В текущем сеансе ваши настройки сразу же вступят в силу без перезапуска SSMS. Кроме того, этот параметр не будет распространен на любой будущий сеанс. Эффективное изменение этого параметра для каждого сеанса гораздо менее шумно.

RBT
7 Янв 2020 в 13:32

Выберите результаты, щелкнув в верхнем левом углу, щелкните правой кнопкой мыши и выберите «Копировать с заголовками». Вставить в Excel. Готово!

RBT
4 Май 2019 в 09:54

Та же проблема существует в Visual Studio, вот как ее исправить:

Перейти к:

Теперь установите флажок в значение true: «Включить заголовки столбцов при копировании или сохранении результатов».

Nicholas Petersen
16 Ноя 2015 в 18:24

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

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

Michael McCormick
2 Июн 2014 в 22:47

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

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

o.v
15 Ноя 2019 в 01:40

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