|
|
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
SYBASE 12.5 / SUSE 9 Есть желание настроить бэкапироание методом снятия, копирования и накатывания транзакшн логов. Подскажите - есть ли где подробная инструкция по этому вопросу или тут дайте подсказку. До сего момента делали бэкап - снятием и накатыванием дампа. С увеличением объемов - стало очень уж накладно этим заниматься. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2010, 11:30 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
YVG19, вы все время накатываете снятый дамп на другую машину? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2010, 13:43 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
Да. Пока объем был небольшой - было нормально. "Доросли" до необходимости смены технологии создания бэкапного сервера. :) Но знаний не хватает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2010, 16:38 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
YVG19, если так и собираетесь использовать для поддержания "горячей" копии сервера технологию дампов то Вы должны понимать что потери в данных неизбежны. Если раньше Вы теряли все изменения между дампами то теперь будут потери между дампами транзакций. Для полного исключения потерь такая схема не подходит. Смотрите в сторону кластера. Для того что Вы задумали: 1) Переведите вашу базу в режим сохранения транзакций sp_dboption 'trunc log on chkpt', false 2) Что бы не писать самому посмотрите в сторону sybadmin 3) Регулярно делайте дамп логов на основном сервере 4) С помощью at REMOTE_BS в команде load tran поднимайте транзакции на второй сервер. Вариаций может быть много, вплоть до копирования по scp файлов на вторую машину, но идея примерно такова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2010, 14:40 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
SQLMantisYVG19, если так и собираетесь использовать для поддержания "горячей" копии сервера технологию дампов то Вы должны понимать что потери в данных неизбежны. Если раньше Вы теряли все изменения между дампами то теперь будут потери между дампами транзакций. Для полного исключения потерь такая схема не подходит. Смотрите в сторону кластера. не согласен с "потери в данных неизбежны" тынц цитата If your data device fails and the database is inaccessible, use the with no_truncate option of dump transaction to get a current copy of the log. This option does not truncate the log. You can use it only if the transaction log is on a separate segment and the master database is accessible. про последовательность работы с логами читайте здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2010, 17:01 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
Спасибо! Буду изучать вопрос! Потом уж - если что - задам уточняющие... :) PS Глупый может вопрос: можно тут сделать чтоб уведомления на почту об ответах приходили?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2010, 10:05 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
YVG19 PS Глупый может вопрос: можно тут сделать чтоб уведомления на почту об ответах приходили?... верхний правый угол страницы -> "Подписаться" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2010, 11:42 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
komradSQLMantisYVG19, если так и собираетесь использовать для поддержания "горячей" копии сервера технологию дампов то Вы должны понимать что потери в данных неизбежны. Если раньше Вы теряли все изменения между дампами то теперь будут потери между дампами транзакций. Для полного исключения потерь такая схема не подходит. Смотрите в сторону кластера. не согласен с "потери в данных неизбежны" тынц И чем это поможет? Если это горячая копия, то: 1) Накравается (Сервер | ASE ) 2) В зависимости от критичности, на резервный должны переключиться приложения в течении как минимум минут 30-40 (это потолок и безобразие). 3) Как только они переключаться, начнутся изменения в базе и остатки лога транзакций уже будут не нужны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2010, 14:44 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
SQLMantis И чем это поможет? Если это горячая копия, то: 1) Накравается (Сервер | ASE ) 2) В зависимости от критичности, на резервный должны переключиться приложения в течении как минимум минут 30-40 (это потолок и безобразие). 3) Как только они переключаться, начнутся изменения в базе и остатки лога транзакций уже будут не нужны п.2 - в каждом случае индивидуально регулируется внутренней процедурой/соглашениями в компании ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2010, 12:37 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
YVG19komrad, Спасибо! :) + Backing Up and Restoring User Databases, стр. 877 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2010, 12:52 |
|
||
|
Бэкап
|
|||
|---|---|---|---|
|
#18+
Много прочитал, много советов еще получил. И вроде настроил. Но при поднятии дампов логов встречаю такую ошибку: "Unrecoverable I/O or volume error" Это что? Не попорядку поднимаемый дамп?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2010, 09:17 |
|
||
|
|
start [/forum/search_topic.php?author=soleil_mmc&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
get settings: |
8ms |
get forum list: |
12ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
58ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 1303ms |
| total: | 1497ms |
| 0 / 0 |
