Что такое дамп?
#1
Отправлено 15.09.2003, 14:55:44
Они теперь говорят, что они могут распаковать нашу базу, если мы ее обработаем через дамп или sql manager, а как ее обрабатывать и что такое дамп понятия не имею!!!!!!!
#2
Отправлено 15.09.2003, 21:06:22
Но кажется мне что вам сюда http://www.mysql.ru/docs/man/
Точнее сюда http://www.mysql.ru/.../mysqldump.html
Но в любом случае уточните у вашего ?провайдера? что именно ни от вас ожидают
Одному богу известно что Вы и Они имели ввиду
Просто
если для того чтобы
дополнить базу написанную в mysql новыми таблицами
необходимо
обработаем через дамп или sql manager
и вероятно выслать им (?провайдеру?) дамп
то мне чудно
#3
Отправлено 16.09.2003, 11:31:53
ЦИТАТА
Просто
если для того чтобы
дополнить базу написанную в mysql новыми таблицами
Базу новыми таблицами я уже заполнила, проблема в том как ее сбросить на сервер, по ftp договору я не могу потому как я ее даже просто напросто не вижу
ЦИТАТА необходимо
обработаем через дамп или sql manager
и вероятно выслать им (?провайдеру?) дамп
то мне чудно
да именно выслать провайдеру дамп, и он его как то там у себя распакует и запустит, а для чего я не поняла!!!!
Так значит дамп это резервное копирование, так по ссылке поняла,
а какая разница между таким копированием и резервным?
#4
Отправлено 17.09.2003, 03:07:06
а какая разница между таким копированием и резервным
Я честно перечитал эту тему три раза и из контекста этой темы непонятно что именно вы спрашиваете. Уточните.
А дамп в данном контексте
Это текстовый файл содержащий SQL операторы и данные составляющие в совокупности запросы к СУБД . Цель запросов: создание таблиц, заполнение таблиц данными.
и он его как то там у себя распакует
примерно так и ?распакуют?
http://www.mysql.ru/...Batch_mode.html
Сообщение отредактировал uuu: 17.09.2003, 03:44:17
#6
Отправлено 18.09.2003, 08:59:29
а почему нельзя базу просто взять и кинуть на сервер без дампа?
Если я не ошибаюсь, то потому, что при дампе нужно скопировать информацию из некоторых системных таблиц. Как минимум все гранты.
Тебе было бы проще набрать в гугле mysqldump, чем так долго спрашивать в конфе.
mysqldump --opt mydb > dump.dmp
#7
Отправлено 18.09.2003, 09:47:39
Ты уверен, что формат таблиц, которые ты используешь поддерживаются у провайдера?а почему нельзя базу просто взять и кинуть на сервер без дампа?
Если это будет дамп, то достаточно будет в криейт тейбл заменить type на необходимое, а вот если бинари что делать?
#8
Отправлено 22.09.2003, 14:48:16
а почему нельзя базу просто взять и кинуть на сервер без дампа?
Если я не ошибаюсь, то потому, что при дампе нужно скопировать информацию из некоторых системных таблиц. Как минимум все гранты.
Тебе было бы проще набрать в гугле mysqldump, чем так долго спрашивать в конфе.mysqldump --opt mydb > dump.dmp
ладненько так и сделаю спасибо огромное
зато уже что-то проявилось
#9
Отправлено 22.09.2003, 14:50:50
Ты уверен, что формат таблиц, которые ты используешь поддерживаются у провайдера?
Да поддерживаются точно
#13
Отправлено 23.09.2003, 17:08:23
то мне чудно
А что ваш провайдер не даёт вам возможности работать с Perl, PHP, C/C++ ?
А ЕСЛИ вам во много мегабайтной базу необходимо заменить исправить ОДНУ запись ТО вам нужно заменит эту запись в локальной безе а потом сдампить провайдеру
Вот это то и чудно!
ИМХО а вообще дамп может быть и удобно но это ИЗВРАЩЕНИЕ переносить по сети (подчёркиваю "по сете") дамп(в том формате какой он есть) для (создание|дополнения|заполнение) (базы|таблиц) на удалённом сервере Накладно по трафику получится есть более выгодные выходы по крайней мере я бы их писал если бы довилось ИМХО(может я и не прав)
#17
Отправлено 24.09.2003, 08:31:19
Имхо нивернае заивление. Если скажем перенос базы идет (создание), то дамп очинь и очинь выгадно. Причем именно в том формате, какой он есть Он же нииб*цца как пакуеца. Ниаднакратна праверино на практике. Если обнавление, т.е. скажем синхранизация баз, то тут от дизайна таблиц зависит. Если можишь вытащить обнавленные записи (т.е. присуцтвует маркерное поле), то есть пути дешевше, а иначе тока дамп.ИМХО а вообще дамп может быть и удобно но это ИЗВРАЩЕНИЕ переносить по сети (подчёркиваю "по сете") дамп(в том формате какой он есть) для (создание|дополнения|заполнение) (базы|таблиц) на удалённом сервере Накладно по трафику получится есть более выгодные выходы по крайней мере я бы их писал если бы довилось ИМХО(может я и не прав)
#18
Отправлено 24.09.2003, 11:02:15
1) дамп это вовсе не последовательность запросов (последовательность запросов это будет SQL лог или лог транзакций если таковые поддерживаются СУБД (MySQL насколько я помню до 4 версии с транзакциями не работал))
дамп представляет из себя файл с "сырыми даннаыми" какойто базы хранящийся в формате сугубо привязанном к конкретной СУБД а еще печальней что иногда и к конкретной версии (совместимость как правило только снизу вверх)
2) МуSQL тупая и простая СУБД позволяющая просто под админом создать одноименную базу на сервере назначения, а потом тупо скопировать файлы содержащие нужную базу с сервера источника
3) правильное класическое решение : а) копируем структуру и права базы на сервере источнике (в идеале у админа должен юыть скрипт воссаздоющую стуктуру)
б) делаем дамп этой базы
в) создаем базу на новом сервере, воссоздаем ее стуктуру и назначаем права ( например с помощью скрипта. или руками)
г) заливаем имеющийся дамп в полученную базу
(не все субд могут внутри дампа содержать структуру и перечень таблиц , потому предложенное решение более универсально)
вроде все
Сообщение отредактировал Peet: 24.09.2003, 11:03:10
#19
Отправлено 24.09.2003, 11:17:31
Имхо нивернае заивление. Если скажем перенос базы идет (создание), то дамп очинь и очинь выгадно. Причем именно в том формате, какой он есть Он же нииб*цца как пакуеца. Ниаднакратна праверино на практике. Если обнавление, т.е. скажем синхранизация баз, то тут от дизайна таблиц зависит. Если можишь вытащить обнавленные записи (т.е. присуцтвует маркерное поле), то есть пути дешевше, а иначе тока дамп.
1)савсем не факт тотже дамп базы СУБД Sybase Адаптив Сервер Ентерпрайс простым юниксовым compress давиться в 2-5 раз и уж конечно при перегоне баз между серверами напримеро по FTP, при обьеме баз 10-100GB это ну просто ооочень серьезный выигрыш
2) Для синхронизации баз в приличных СУБД есть такая штука как репликация которая позволяет динамически пополнять зеркальные базы или таблицы, кроме того там бывает много других приятных мелочей наприме буферные базы которые позволяют не терять данные при проблеммах со связью, компресия при передаче данных, репликация в 2-3 базы одновременно итп ...
Количество пользователей, читающих эту тему: 1
пользователей: 0, неизвестных прохожих: 1, скрытых пользователей: 0