MS SQL data export/import

[Sabina]

isql -q "EXEC dbo.up_expAllTables" -U login -P password -S server -d database
Что за path - не понятно.

Это path к папке C:\ExportDataFiles, который hard coded в том примере, что я привела выше.

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

Мне просто казалось что запускать процедуру внутри которой запускается bcp через xp_cmdshell это как "масло масляное". Или я не права?

Спасибо вам большое за все ваши подсказки, мне они очень помогли.

Сабина

[Niky]

Этот path надо передавать в процедуру как параметр, вызов isql будет выглядеть так:

isql -q "EXEC dbo.up_expAllTables 'C:\ExportDataFiles'" ...

[Sabina]

Этот path надо передавать в процедуру как параметр, вызов isql будет выглядеть так:

isql -q "EXEC dbo.up_expAllTables 'C:\ExportDataFiles'" ...

А как при этом EXEC поймет какой параметр я передаю как 'C:\ExportDataFiles' ?

И как isql посадит юзернейм, пароль и проч. в нужные переменные?

Наверное нужно что-то мнеять в синатаксисе самой user procedure? Пока же там только

--Declare variables

Code: Select all

DECLARE @strDBName SYSNAME --holds database names
DECLARE @lngCounter INTEGER --loop counter
DECLARE @strTableName SYSNAME --holds table names
DECLARE @lngTabCount INTEGER --holds table count
DECLARE @strSQL NVARCHAR(4000) --dynamic sql string
DECLARE @myQuery NVARCHAR(1000) --bcp query for format files and export
DECLARE @myServer NVARCHAR(100) --server name
DECLARE @myOutPathFolder NVARCHAR(200) --path for exported data folder
DECLARE @myOutPath NVARCHAR(200) --full path for exported data files
DECLARE @myFormatPath NVARCHAR(200) --full path for format files
DECLARE @myLogin NVARCHAR(50) --login name
DECLARE @myPassword NVARCHAR(50) --password

SET @myServer = (SELECT @@SERVERNAME)
SET @myLogin = '.....'
SET @myPassword = '......'
SET @strDBName = '....._DEV'
SET @myOutPathFolder = 'C:\ExportDataFiles'

Сабина

[Niky]

Процедуру конечно надо менять, примерно так:

Code: Select all

CREATE PROCEDURE dbo.up_expAllTables 
@myOutPath NVARCHAR(200) ,
@myServer NVARCHAR(100) ,
@myLogin NVARCHAR(50) ,
@myPassword NVARCHAR(50) ,
@strDBName SYSNAME 
AS
...

Параметры можно передать :
1. по порядку - тогда вызов процедуры будет выглядеть так:

Code: Select all

EXEC dbo.up_expAllTables 'C:\tmp' , 'mysql2000dev' , 'user1' , 'pass1' , 'pubs'

2. по именам - тогда вызов процедуры будет выглядеть так:

Code: Select all

EXEC dbo.up_expAllTables @myOutPath='C:\tmp' , 
@myServer='mysql2000dev' , 
@strDBName='pubs', 
@myLogin='user1' , @myPassword='pass1' 

[Sabina]

Процедуру конечно надо менять, примерно так:
[code]
CREATE PROCEDURE dbo.up_expAllTables

Ну теперь вы мне все до конца по полочкам разложили. Спасибо огромное. Да-а-а, DBA бы из меня точно не получился

Сабина

[Sabina]

Возвращаясь к этому вопросу...

Если нужно воссоздать точную копию существующей базы из текст файлов, можно ли сделать так:

1) прогнать скрипт, создающий все таблицы;
2) импортировать данные ( в том числе lookup data)
3) посадить на это constraints (FK, etc.) ?

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

Сабина

[Sabina]

Еще раз извиняюсь за возврат к этой теме, но мне ОЧЕНЬ нужна помощь с этим вопросом.
В Интернете я ничего толкового найти не могу, ибо большинство народу пользуется import/export тулами и там рассматривается в основном какую кнопку нажать, какую опцию включить, нежели концептуальная сторона вопроса.

У меня есть скрипты, которые создают всю базу from scratch. То есть как создать чистую базу с нуля - понятно.
А как создать копию уже существующей базы с данными?

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

Мой вопрос так ли оно обычно делается, или нет?

Спасибо,
Сабина

[tengiz]

А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

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

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

[Sabina]

А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

dbschema меняется (таблицы добавлены), а данные надо оставить.

[irksome]

А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

dbschema меняется (таблицы добавлены), а данные надо оставить.

А нельзя новые таблицы создать в новой копии?

[Sabina]

А как создать копию уже существующей базы с данными?

А backup/restore почему не походит? Зачем нужно пересоздавать объекты?

dbschema меняется (таблицы добавлены), а данные надо оставить.

А нельзя новые таблицы создать в новой копии?

Пока так и делаем, но для этого надо кому-то собирать все changes в отдельный update script и ранать. Они хотят чтобы я им написала нечто, чтобы нажал на кнопку и готово.
Я в приниципе написала по тому принципу что выше описала, сейчас буду тестировать. НО мне это все жутко не нравится. Хочется узнать как жругие это делают.

Неужели все делают backup/restore и потом изменеия добавляют? Или никто не делает DBSchema changes после того как в базе уже есть данные ?

Сабина

[tengiz]

Неужели все делают backup/restore и потом изменеия добавляют? Или никто не делает DBSchema changes после того как в базе уже есть данные

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

Другой вариант - reverse engineering, который умеют делать страндартные database design инструменты. Однако в мои времена они всего лишь были удобным подспорьем, и ни в коем случае не могли служить полноценной заменой того, что изложено выше.

Так что на мой скромный взгляд, самая большая проблема здесь - это организация эффективного процесса разработки, а не экспорт/импорт. Я бы именно в этом направлении двигался.

[Dmitry67]

Sabina, я наконец понял что у Вас хотят

У нас при разработке делают так
Все изменения sp при релизе отливают просто скопом
А вот изменения структуры делаются скриптами
Я потом эти скрипты собираю, тестирую и формирую скрипт для PREPROD -> PROD

Вы хотите реинжениринг, по старой и новой схеме сгенерить alter tables. Такой тул у меня есть но это очень нетривиально

Задайте своему шефу вопросы
Что делать если колонке в таблице убрали NULL
Что делать если уменшьшили длину verchar - is it ok to truncate data ?
Что делать если таблитцу или колонку переименовали - догадаться ? Или это новые объекты ?

[Sabina]

Sabina, я наконец понял что у Вас хотят?

Да, я наверное не очень понятно изъясняюсь, поскольку имею с этим делом в первый раз. Сорри.

У нас при разработке делают так
Все изменения sp при релизе отливают просто скопом
А вот изменения структуры делаются скриптами
Я потом эти скрипты собираю, тестирую и формирую скрипт для PREPROD -> PROD

У нас тоже до прошлой недели изменения структуры делались upgrade скриптами и составляла их одна strong backend programmer, которая на этой неделе ушла.
То есть она собирала все изменения из master scripts и потом вставляла это все в batch и передавала QA, чтобы они это прогнали на своих серверах.
Теперь эта дама ушла, а я работаю из дома. Доступа к QA серверам у меня нет, поскольку если что пойдет не так... Короче я это на себя взять не могу.
QA считает, что если я сделаю им скрипт, который импортирует данные во вновь созданную базу (по обновленным master скриптам), то это будет решением вопроса. Но я чем больше работаю над этим делом, тем меньше верю в надежность такого выхода.

Вы хотите реинжениринг, по старой и новой схеме сгенерить alter tables. Такой тул у меня есть но это очень нетривиально

Можно название тула, просто так чтобы знать? У нас не так много изменений, чтобы пользоваться тулом, все можно и в ручную. В крайнем случае я могу писать скрипты, QA их прогонять. Ну и если что не так - поеду в офис за 30 миль

Задайте своему шефу вопросы
Что делать если колонке в таблице убрали NULL
Что делать если уменшьшили длину verchar - is it ok to truncate data ?
Что делать если таблитцу или колонку переименовали - догадаться ? Или это новые объекты ?

Мой шеф врядли ответит на этот вопрос
От себя же скажу, что на моем веку (полгода) ни одного из перечисленных вами изменений не было. Было по мелочи, добавить/убрать таблицу/колонку.

Опять же для меня самой чтобы знать, а как вы выходите из ситуации, когда колонка вдруг стала not null, или длину колонки урезали, колонку переименовали? Можно просто ткнуть в URL не объясняя здесь подробно.

Спасибо,
Сабина

[SkyWalker]

Есть несколько вариантов решения.

1. Организационное.
Девелоперы при изменении чего либо готовят script. Если ето изменение структуры таблицы то соответственно script с ALTER и т.д.
Данные скрипты отправляются DBA. DBA готовит upgrade script затем тестирует на тестовой базе и затем делает upgrade боевой базы.
Tаким образом вы будете иметь upgrade script для каждой версии базы. К тому же еше неплохо писать где-нибудь в саму базу номер текушей версии. Ето опять же можно добавлять в upgrade script.

2. Автоматическое.
http://www.adeptsql.com/
http://www.lockwoodtech.com/index_sqldiff.htm
http://www.red-gate.com/sql_comparison_ ... oolkit.htm

и т.д. Таких tool'oв очень много. Но в етом случае Вы не будете контролировать ситуацию, да и работу каждого из них надо сначала хорошенько проверить

3. Интересное
Написать синхронизацию самому, использовать скриптование и т.д.
Процесс давольно трудоемкий и не во всех случаях простой. Синхронизацию SP, view, UDF можно реализовать достаточно не сложно, а вот изменение структуры таблиц, триггеров, добавление FK, PK, index и т.д. может вызвать сложности.