Как развернуть базу данных Oracle?
У меня есть приложение ASP .NET, которое подключается к базе данных Oracle или SQL Server. Программа установки была разработана для установки новой базы данных на существующий SQL Server с помощью команд sql, таких как " restore database..."который просто восстанавливает ".BAK " файл, который мы держим под контролем источника.
Я очень новичок в Oracle, и наше приложение только недавно было портировано, чтобы быть совместимым с 10g.
в настоящее время мы используем "exp.exe " инструмент для создания ".ДМП" файл, а затем с помощью "ИМП.exe", чтобы импортировать его в поле разработчиков.
Как вы собираетесь создать "установщик баз данных Oracle"?
вы бы создали базу данных с помощью файлов сценариев, а затем заполнить базу данных с требуются данные по умолчанию?
не могли бы вы запустить " imp.exe " инструмент за кулисами?
нам нужно предоставить чистый интерфейс для системных администраторов, чтобы они могли просто выбрать место назначения сервер и сделали, или мы должны просто предоставить им".файл "dmp"? Каковы наилучшие методы?
спасибо.
4 ответов
вопрос в том, что ваши клиенты знают о Oracle?
ничего? Тебе, наверное, стоит пересмотреть свою позицию. Oracle очень большой и сложный. Если вы предполагаете, что ваши клиенты ничего не знают, вы начнете предоставлять учебники и помощь, которая неуместна.
Минимально Компетентным? Если они компетентны, то знают достаточно, чтобы управлять ИМП самостоятельно. Кроме того, они знают достаточно, чтобы запустить сценарий, который выполняется язык SQL.
фактические DBA? Большинство организаций, которые могут позволить себе Oracle, могут позволить себе реальные DBA. Настоящие DBA могут справиться со многими вещами - им не нужно много рук. Некоторые из них любят назначать параметры хранения в соответствии со своими стандартами магазина.
вы должны предоставить сценарий с разумными значениями по умолчанию. Вы должны определить свой скрипт таким образом, чтобы кто-то мог легко найти все ваши параметры хранения и настроить их, если необходимый.
ваши исходные данные могут быть через экспорт / импорт или через скрипт. Я предпочитаю сценарий.
Я делал это неоднократно с обеих сторон (потребитель и поставщик) как DBA, разработчик и архитектор.
как поставщик, одним из моих больших достижений (в 1996 году) было создание установочного компакт-диска для программного обеспечения для управления коммерческими страховыми претензиями, предназначенного для крупнейших страховых компаний (многомиллионный продукт). На этом установочном компакт-диске установлен движок Oracle 7.2 RDBMS, оптическая система хранения FileNet (сканирует бумажные документы и создает каталогизированные двоичные версии) и наше пользовательское приложение для обработки утверждений (встроенное в VB 4.0), интегрированное и готовое к запуску. В процессе установки пользователь может пропустить установку программного обеспечения Oracle или настроить ее, а также настроить/переопределить конфигурацию базы данных во всех ее основных деталях (база данных, схемы, табличные пространства, размеры, диски и т. д.).
Я также обеспечил обслуживание поля для этого продукта, который включил путешествовать к месту клиента как необходимый. Я тестировал установочный компакт-диск буквально сотни раз по всем мыслимым сценариям, которые я мог воспроизвести, и у нас никогда не было полевого сбоя, который потребовал бы даже телефонного звонка, не говоря уже о поездке (я путешествовал четыре раза, но вместо этого для предпродажных вещей).
недавно (2007) я написал сценарий создания базы данных Oracle 10g для внутренней системы в megacorp. В производстве размер базы данных составлял 8 ТБ, в основном для одной таблицы транзакций с высоким объем данных. В тесте база данных была размером около 1 ТБ для скромного сервера. В развитии, база данных размером около 100 МБ для работы на моем ноутбуке. Точно такие же сценарии создали все три среды, и я мог бы расширить их для обработки новой среды/машины примерно за пять минут. Эта база данных включала экстремальную настройку производительности, поэтому настройка всех соответствующих характеристик была абсолютно необходима.
назад к продукту обработки страховых претензий--позвольте мне пожалуйста добавьте, что я был первоначально нанят, чтобы привести его преобразование из базы данных SQL Server в базу данных Oracle. Это преобразование было определено как бизнес-необходимость, поскольку большинство потенциальных клиентов не рассматривали продукт на основе SQL-сервера как профессиональное, серьезное решение. Это не так распространено сегодня, но все же применяется в целом: программный продукт имеет больше шансов на проникновение на рынок, если он может вместить несколько вариантов базы данных, как предпочитают целевые клиенты (особенно клиенты корпоративного класса).
аналогичным образом, установочный компакт-диск также рассматривался как важный элемент. Однако эта ситуация и многие другие показали мне, что большинство "реальных" СУБД не будут принимать установку базы данных на основе импорта. Как DBA и архитектор, Я знаю, что я точно не буду по тем же причинам.
проще говоря, установка базы данных на основе импорта не дает клиенту почти никакого контроля над результирующей базой данных. Он непрозрачен для клиента, оставив их в недоумении. Это заставляет клиента тратить огромные усилия, чтобы попытаться осуществить тот небольшой контроль, который они могут. Он, как известно, хрупкий и подвержен ошибкам (импорт Oracle хорошо известен проблемами владения и разрешения, проблемами ограничений и т. д.). Взвешивая все эти последствия, установка базы данных на основе импорта непрофессиональна-она не ставит потребности клиентов на первое место.
скриптинг установка базы данных обеспечивает правильный вид прозрачность, конфигурируемость, выборочная повторимость, и общий контроль клиента который профессионализм требует. Это также побуждает вас правильно понимать влияние ваших решений по проектированию базы данных таким образом, что импорт не делает.
наилучшие пожелания.
лично я предпочитаю SQL-скрипты для создания базы данных и загрузки данных, где это возможно. Я склонен использовать PL / SQL Developer. У него есть несколько хороших опций для создания скриптов из существующей базы данных. После этого вы можете запускать скрипты с помощью sqlplus или любого кода приложения, который может выполнять произвольный SQL (например, JDBC с Java). жаба является более распространенным (и более дорогим) инструментом для разработки Oracle.
единственное ограничение экспорта SQL он не может экспортировать поля CLOB/BLOB. Если у вас есть такие, вам нужно либо сделать их отдельно (как экспорт PL/SQL), либо сделать все это как экспорт PL/SQL. Theres никаких драм с этим, за исключением того, что файл эффективно двоичный экспорт (расширение .pde) и более ограничен в том, как вы можете его выполнить.
другим большим преимуществом исходных файлов SQL является то, что они могут легко управляться версией. Это очень удобно, чтобы иметь возможность создавать среду базы данных, запустив один или два файлы сценариев.
инструменты импорта и экспорта для Oracle, я думаю, более применимы для операций резервного копирования и восстановления.
теперь, что касается доставки этого клиенту, из ваших комментариев кажется, что вы дадите это DBAs. В значительной степени любая установка Oracle будет иметь DBAs. Они будут в порядке со сценариями SQL для создания схемы и загрузки данных. Они будут делать много конфигурации для конкретного сайта (например, настройка SGA, временных табличных пространств, # параллельные соединения и т. д. На основе ожидаемой нагрузки).
вы, как поставщик, можете дать рекомендации по любой соответствующей конфигурации, и вы можете принять участие в поддержке и, возможно, установке, но в конечном итоге это до них, чтобы выяснить, что работает для них. Oracle работает на большом количестве операционных систем и аппаратных вариантов с бесконечными вариациями топологии сети и конфигурации брандмауэра. Вы не можете учитывать все это для установщика или даже набора инструкций (помимо упомянутых выше руководящих принципов).
в последний раз, когда я участвовал в создании (oracle) db (для достаточно большой компании с собственными DBAs), DBAs хотел знать такие вещи, как:
- то, что мы хотели назвать db,
- какие табличные пространства нам понадобятся, и оценка того, сколько данных будет в каждом из них
- сколько пользователей будет подключено.
(из памяти) они настроили БД и табличные пространства, затем мы предоставили комбинацию простых скрипты, которые они могли запускать (или четкие инструкции, если задача была нелегкой для автоматизации)
Как я уже сказал, Это было для внутреннего приложения, поэтому ваш пробег может отличаться, но в моем случае они хотели, чтобы все инструкции были четко прописаны, Чтобы (а) не было никакого возможного недоразумения, ведущего к неправильной вещи, и (Б) никакой вины с их стороны, если что-то не сработало ("мы просто следовали инструкциям")