Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Переход с ASA6.04 на ASA9.02 и репликация.
|
|||
|---|---|---|---|
|
#18+
Есть консолидированная база три удалённых филиала, репликация на SQL Remote. Всё работает на ASA 6.04. Для перевода на ASA 9 требуется ребилд базы. Как сохранить работающую систему реплакаций, ведь при ребилде обнуляется лог? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2005, 18:09 |
|
||
|
Переход с ASA6.04 на ASA9.02 и репликация.
|
|||
|---|---|---|---|
|
#18+
поиск слова rebuild в документации легко приводит к следующему: автор To rebuild a database involved in replication Shut down the database. Perform a full off-line backup by copying the database and transaction log files to a secure location. At a command prompt, run dbunload to rebuild the database: dbunload -c connection_string -ar directorywhere connection_string is a connection with DBA authority, directory is the directory used in your replication environment for old transaction logs, and there are no other connections to the database. The -ar option only applies to connections to a personal server, or connections to a network server over shared memory. For more information, see Unload utility options. Shut down the new database. Perform validity checks that you would usually perform after restoring a database. Start the database using any production options you need. You can now allow user access to the reloaded database. Notes There are additional options available for the dbunload utility that allow you to tune the unload, as well as connection parameter options that allow you to specify a running or non-running database and database parameters. If the above procedure does not meet your needs, you can manually adjust the transaction log offsets. The following procedure describes how to carry out that operation. To rebuild a database involved in replication, with manual intervention Shut down the database. Perform a full off-line backup by copying the database and transaction log files to a secure location. Run the dbtran utility to display the starting offset and ending offset of the database's current transaction log file. Note the ending offset for later use. Rename the current transaction log file so that it is not modified during the unload process, and place this file in the dbremote off-line logs directory. Rebuild the database. For information on this step, see Rebuilding databases. Shut down the new database. Erase the current transaction log file for the new database. Use dblog on the new database with the ending offset noted in step 3 as the -z parameter, and also set the relative offset to zero. dblog -x 0 -z 137829 database-name.dbWhen you run the Message Agent, provide it with the location of the original off-line directory on its command line. Start the database. You can now allow user access to the reloaded database. все-таки лучше проверить предварительно на двух машинах (одна cobsolidated), как это все поедет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2005, 20:12 |
|
||
|
Переход с ASA6.04 на ASA9.02 и репликация.
|
|||
|---|---|---|---|
|
#18+
Спасибо, будем пробовать. Похоже пройдёт только второй способ. В старой базе Custom collation win_1251 и dbunload9 -ar выдаёт ошибку - неизвестный collation ( не может он подставить свой cp1251 на автомате ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2005, 09:53 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=33102002&tid=2013613]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 227ms |
| total: | 369ms |

| 0 / 0 |
