Перріодіческі з районів привозять дампи баз, які потрібно розгортати і
працювати з ними, відповідно, у себе. Хто робить ці дампи, що саме там
всередині, можна сказати - невідомо, тому кожен раз розгортати його на
живу базу, хоч і з попередньо зроблених резервних копій, страшнувато.
Закралася ідея, що було б логічно, при імпорті, засовувати весь дамп в
окремий тейблспейс, тоді, навіть якщо щось і піде не так, його можна буде
просто покласти в оффлайн і прибити без наслідків. Однак з'ясувалося, що в
9-ке такої можливості немає (на рахунок 10-ки не впевнений, але я гадаю теж).
Що народ думає з цього приводу?
І який найправильніший і безпечний алгоритм імпорту дампа?
PS Перед імпортом природно дамп Парс TOAD, однак це лише дає загальне
уявлення про об'єкти, не будеш же виникають в код величезної кількості
функцій, процедур і т.п.
Post by Mikhail Bunzya
Закралася ідея, що було б логічно, при імпорті, засовувати весь дамп в
окремий тейблспейс, тоді, навіть якщо щось і піде не так, його можна
буде просто покласти в оффлайн і прибити без наслідків. Однак
з'ясувалося, що в 9-ке такої можливості немає (на рахунок 10-ки не впевнений, але
ІМХО теж).
AL> Чи робите користувача з якимось ім'ям і даєте йому права на
AL> один-єдиний tablespace. У файлі експорту витираєте всі явні
AL> призначення tablespace. Імпорт робите fromuser = touser =.
Все було б добре, якби об'єктів було не так багато, а їх сотні.
Та хоч сотні тисяч - комп'ютер залізний :).
Post by Sergey Yudin
І майже всі посилаються на конкретні тейблспейси, яких причому з самого початку не
існує. А коли Оракл не може виявити таких імен табличних просторів, він
взагалі починає все кидати в system.
Хоча, напевно, якщо користувачеві дати права на єдиний тейблспейс, то саме
туди він і буде кидати, все що не знайде. зараз спробую :)
Саме так, і ніякого system :).
Post by Sergey Yudin
А правити руками безліч о'ектов - просто не реально.
Чи можна якось автоматизувати цей процес?
/ Usr / bin / vi - чудово все автоматизує.
Або ж, якщо проробляти під віндозой, добре справляється MultiEdit.
Дякую всім питання знято. Дякую за увагу.
From: Olexandr Siroklyn <***@inbox.ru>
Subject: Re: =? KOI8-U? Q? = E7 = D2 = C1 = CD = CF = D4 = CE = D9 = CA_ = C9 = CD = D0 = CF = D2 = D4 _? =
=? KOI8-U? Q? = C4 = C1 = CD = D0 = C1 = 2E? =
Легко. Правда для жителів іншої галактики:
sed -r 's / TABLESPACE "[a-zA-Z0-9 _ \ $] *" // g' $ 1> $ 2
Post by Mikhail Bunzya
А правити руками безліч о'ектов - просто не реально.
Чи можна якось автоматизувати цей процес?
--
With best wishes,
Olexandr Siroklyn
Dmitry Y. Bulgakov
OS> Легко. Правда для жителів іншої галактики:
OS> sed -r 's / TABLESPACE "[a-zA-Z0-9 _ \ $] *" // g' $ 1> $ 2
Так вже прям і інший. cygwin ще ніхто не відміняв.
Я з cygwin'ом ще на Oracle 8.0, який крутився під AIX'ом організовував
зв'язок через ssh c іменованих каналом на AIX'е в який відбувався export. А
на стороні WinNT інфа з цього каналу по ssh-Коннект прімімалась, різалася
split'ом на шматки по 1 Гб і дружно bzip'алась.
* Andrew *, see the sun that rises on the hill.
It's there still.
Post by Mikhail Bunzya
Закралася ідея, що було б логічно, при імпорті, засовувати весь дамп в
окремий тейблспейс, тоді, навіть якщо щось і піде не так, його можна
буде просто покласти в оффлайн і прибити без наслідків. Однак
з'ясувалося, що в 9-ке такої можливості немає (на рахунок 10-ки не впевнений, але
ІМХО теж).
AL> Чи робите користувача з якимось ім'ям і даєте йому права на
AL> один-єдиний tablespace. У файлі експорту витираєте всі явні
AL> призначення tablespace. Імпорт робите fromuser = touser =.
В принципі, якщо в експортному файлі немає команд на створення специфічних
сегментів (див. нижче), витирати назви таблеспейсов не потрібно. Hужно тільки
щоб той єдиний таблеспейс був призначений користувачеві дефолтних.
If a user's quota allows it, the user's tables are imported into the same
tablespace from which they were exported. However, if the tablespace no longer
exists or the user does not have the necessary quota, the system uses the
default tablespace for that user as long as the table is unpartitioned,
contains no LOB or VARRAY columns, is not a type table, and is not an
index-only table with an overflow segment.