DeepEdit!

Итак, какого вида планы вам нужны? О чем необходимо подумать и какие решения должны быть приняты? Скорее всего, при планировании сетевой конфигурации Oracle вам не придется начинать с нуля. Большинство организаций уже имеют готовую        которую вы должны будете принять за основу, поэтому вам не потребуется выбирать базовые сетевые протоколы. Принимаемые решения будут зависеть как от базовой сети, так и от приложений, которые предполагается поддерживать.

Чтобы определить, какой должна быть сетевая конфигурация Oracle в вашем конкретном случае, нужно ответить на много вопросов. На некоторые из них в вашей среде уже могут быть даны ответы. Кроме того, не все из рассматриваемых ниже вопросов имеют отношение к любой компании или системе. Вопросы можно разбить на следующие общие

категории:

Несмотря на то что все эти категории в равной степени важны, входящие в них вопросы образуют определенную логическую последовательность. Рассмотрим каждую область и те вопросы, на которые вам потребуется отвечать.

Вопросы, относящиеся к области управления, могут потребовать согласования с вышестоящим начальством. Ответы на них формируют основу для принятия всех остальных решений, определяющих конфигурацию сети Oracle. Вопросы приведены здесь в произвольно выбранной последовательности.

При наличии нескольких разных серверов, на каждом из которых запускается один или несколько прослушивающих процессов, имеет смысл выработать соглашения об именовании прослушивающих процессов, служб и экземпляров. „Это облегчит идентификацию баз данных, с которыми предстоит взаимодействовать. Иногда трудно проверить, что вы вносите изменения именно в базу данных А на узле А, если на узлах В, С и D также присутствуют базы данных А.

Поскольку имена служб и экземпляров перечислены в файле init.ora каждой базы данных, а следовательно, считываются базами данных во время запуска, вы можете идентифицировать базу данных, с которой взаимодействуете, непосредственно из приложения. Для этого необходимо иметь привилегии, позволяющие обращаться к представлению V$PARAMETER. Просмотреть значения имен можно при помощи следующего запроса (выходные данные соответствуют базе данных версии 8.1.6)

В этом запросе нужно отметить два момента. Во-первых, аргументы конструкции where записаны в нижнем регистре. Это сделано намеренно, поскольку значения хранятся в базе данных именно в таком виде. Во-вторых, имя параметра service_names записано во множественном числе, тогда как имена остальных параметров — в единственном.

Подобная несогласованность внутренних имен Oracle встречается и во многих других местах. Это должно послужить вам дополнительным аргументом в пользу выработки единого подхода к именованию баз данных, экземпляров и прослушивающих процессов, позволяющего избежать путаницы в определении их местонахождения.

Соглашения об именовании имеют и свою отрицательную сторону. Они дают посторонним лицам потенциальную возможность изучить вашу структуру имен, а затем проникнуть в систему, используя это знание. Например, если известно, что вы всегда называете прослушивающий процесс по имени узла с добавлением слова "LIST" и последовательного номера, то по этой информации можно составить имя вашего прослушивающего процесса. Если известно, что для имен экземпляров используется имя узла, слово и последовательный номер, то можно с тем же
успехом составлять имена ваших экземпляров.

Предположим, я точно знаю, что ваш узел называется PROD. Тем самым мне автоматически становится известно имя вашего первого прослушивающего процесса на этом узле а также имя первого экземпляра (PRODDB1). Имя прослушивающего процесса не слишком поможет мне при попытке "взломать" вашу систему, тогда как знание имени первого экземпляра дает шанс войти в базу данных путем перебора известных имен пользователей - SCOTT, DBSNMP, SYSTEM и SYS. Возможно, что какие-то из этих стандартных имен и паролей не менялись с момента создания базы данных.

Тем не менее стандарты именования имеют смысл, особенно при наличии множества баз данных. Нет ничего плохого в том, чтобы ввести соглашения об именовании и следовать им, обеспечив тем самым согласованность и облегчив клиентам доступ к базам данных. Однако при этом вы должны учитывать, что соглашения об именовании могут облегчить доступ к базам данных и злоумышленникам. Короче говоря, пользуйтесь стандартами именования, но не делайте их слишком очевидными.

Казалось бы, этот вопрос похож на предыдущий, но это не так. Первый вопрос касался формы записи имен, присваиваемых каждому элементу сети. Сейчас речь идет о способе поддержки клиентских соединений и разрешения имен сетевых служб в адреса серверов. Чтобы помочь вам в принятии решения, ниже кратко рассматривается каждый из перечисленных методов именования.

При использовании локального именования имена сетевых служб хранятся в локальном файле конфигурации tnsnames.ora на каждой из клиентских машин. Достоинство локального именования в том, что вы можете конфигурировать каждый файл в соответствии с потребностями конкретного клиента. Доступ к информации о соединениях в этом случае относительно прост, а кроме того, можно разрешать имена сетевых служб в адреса, соответствующие различным протоколам. Недостатком, о котором упоминалось в главе 4, является необходимость реконфигурирования каждого файла при любом изменении в сети, если вы добавляете новую базу данных, то должны модифицировать файл tnsnames.ora для каждого клиента, которому требуется получать к ней доступ. При удалении базы данных из системы следует удалить ссылки на нее из всех файлов tnsnames.ora. Локальное именование рекомендуется для простых распределенных сетей с небольшим количеством редко изменяемых служб и небольшим числом клиентских машин.

Для реализации именования по каталогу используется LDAP-совместимый сервер каталога (протокол LDAP рассматривался в главе 5). Сервер каталога LDAP обеспечивает централизованное хранение сетевых имен и адресов, используемых для соединений, а это означает, что все измене-
ния нужно выполнять только в одном месте, а не в потенциально огромном количестве файлов. Каталог может хранить имена разнородных служб, что позволяет устанавливать соединения по разным протоколам.
Недостаток такого подхода к именованию заключается в том, что клиентам требуется обращаться к каталогу, а это представлять потенциальную угрозу безопасности системы. Сервер каталога LDAP рекомендуется использовать в больших сложных сетях с более чем 20 базами данных, изменяющимися на регулярной основе.

При использовании сервера имен Oracle информация обо всех службах Oracle заносится в централизованное хранилище, как было описано в главе 4. Использование сервера имен упрощает администрирование сети Oracle, поскольку в отличие от локального именования все изменения выполняются в одном месте. Даже при наличии нескольких серверов имен вам достаточно изменить информацию только на одном из них, после чего изменения будут автоматически распространены по остальным серверам. Недостатком является то, что на серверах имен Oracle можно хранить имена и адреса только служб Oracle, а установка и начальное конфигурирование серверов имен требуют определенных усилий с вашей стороны. Подобно серверу каталога LDAP, сервер имен Oracle лучше всего подходит для больших сложных сетей с более чем 20 базами данных, изменяющимися на регулярной основе.

В случае именования по хосту разрешение имен служб в IP-адреса может выполняться при помощи уже существующего механизма, например, службы имен доменов (DNS), сетевой информационной службы (NIS) или централизованно ведущегося файла со списком хостов TCP/IP. Такой подход требует минимального конфигурирования на стороне клиента (пользователю нужно указывать только имя хоста), но вместе с тем накладывает ряд ограничений, о которых необходимо знать. И клиент, и сервер должны использовать TCP/IP, и при этом они не могут пользоваться услугами менеджера соединений Oracle. Это означает, что вы не сможете соединяться с базами данных, отличными от Oracle. Именование по хосту доступно в ограниченном числе сред.

Если в вашей среде уже сконфигурирована служба имен другого производителя, то для разрешения имен служб Oracle можно использовать внешнее именование. У вас есть возможность загрузить информацию об именах во внешнюю службу, используя уже освоенные утилиты. Такой подход позволит избежать дополнительного конфигурирования.

Не существует "правильного" или "неправильного" метода именования; вам и вашему руководству нужно решить, что лучше всего подходит для вашей организации. Имейте в виду, что это решение не обязательно должно приниматься раз и навсегда. Через какое-то время вы можете обнаружить, что потребности в соединениях изменились, а вместе с ними должен измениться метод именования. В одной компании, где я работала, все начиналось с локального именования. Когда масштабы системы изменились, мы поняли, что необходимо изменить и метод именования. В результате мы постепенно перешли на использование сервера имен Oracle. Если для доступа пользователей к их системам планируется использовать единый вход, то возможно, что именование на основе сервера каталога LDAP окажется более перспективным.

На первый взгляд этот вопрос кажется риторическим, но смею вас заверить, что это не так! Пока вы не разобрались, от кого зависит выделение средств на реализацию тех или иных сетевых решений, составление планов может оказаться пустой тратой времени. Если вы работаете в крупной компании, то не исключено, что перед построением сети Oracle вам потребуется получить согласие нескольких людей. Точно так как сетевой трафик Oracle может оказать влияние на работу базовой сети, время выполнения запросов к базам данных может непосредственно зависеть от остального сетевого трафика вашей системы.

Заранее выяснив, с кем нужно согласовывать планы, вы сможете избежать бесполезной работы, разочарований и огорчений.

Как и в предыдущем вопросе, речь идет об идентификации лица, к которому предстоит обращаться в том случае, когда не удается получить согласие других участников процесса. Выяснив, кто принимает окончательное решение, вы поймете, кого нужно обучать в первую очередь. Зачастую такие люди не слишком разбираются в технических деталях, и возможно,

что вам потребуется провести "разъяснительную работу", чтобы получить согласие на реализацию самого эффективного решения.

Здесь уместно высказать одно предостережение. Я знаю, что это неправильно, но постарайтесь процессе принятия решения не зацикливаться на одном подходе. Вы можете оказаться в неловком положении, если будет предложен й принят другой вариант. Будьте гибче и постарайтесь
рассмотреть вопрос со всех сторон, прежде чем предпочесть одно решение всем остальным. Кроме того, не подобрать понятные и убедительные аргументы в пользу своего выбора. Фразы: "Я думаю, что мы должны выбрать вариант А, поскольку он наиболее оправдан с коммерческой точки зрения" может чтобы ваше решение было одобрено. Имейте наготове несколько веских обоснований и убедитесь, что человек, которому принадлежит последнее слово, понимает все "за" и "против" каждого предлагаемого решения.

Этот вопрос можно сформулировать и так: "Как соотносятся финансовые затраты, время администрирования и время простоя в предлагаемой сетевой конфигурации?" При подготовке предложения для руководителей высшего звена нужно учитывать, что эти люди не обязательно отдают приоритет самым дешевым вариантам; их скорее заинтересует тот вариант, который обещает наибольшую отдачу.

Имейте в виду, что некоторые методы построения сети Oracle обхо-1 дятся дороже, чем другие. Возьмем, например, сервер имен Oracle в сравнении с множеством локальных файлов tnsnames.ora. Как вы видели в главе 4, служба ONames обычно размещается на отдельной машине, тогда

как для использования локальных файлов tnsnames.ora дополнительное оборудование не нужно. Однако усилия по обновлению множества файлов, выраженные в денежном эквиваленте, вскоре превысят затраты на создание серверов имен Oracle.

Смысл сказанного сводится к следующему: не старайтесь делать конфигурацию чересчур элегантной. Создавайте такую конфигурацию, которая будет удовлетворять системным требованиям, но не выходите при этом за рамки разумного.

Недавно я получила по электронной почте письмо от одного человека, чья компания начинала процесс разработки под одной версией Oracle, a теперь пересматривает свои решения, поскольку появилась новая, улучшенная (по рекламным заявлениям) версия. Мир Oracle устроен так, что на горизонте почти всегда будет вырисовываться следующая, более совершенная версия программного обеспечения. Чтобы заранее решить, когда и как будет происходить переход на новую версию Oracle, нужно тщательно все обдумать и просчитать наперед.

Каждая новая версия приносит много новых привлекательных возможностей, основанных на старых, доступных функциях. На последней конференции я услышала чью-то фразу: "Конечно, вам всегда следует работать с самым последним выпуском продуктов Oracle!" Но так ли это? Есть ли смысл автоматически переходить на только что выпущенную версию РСУБД? Что нужно учесть перед тем, как принимать решение о миграции на новую версию продуктов Oracle?

Первый вопрос, который приходит в голову, таков: будет ли текущая версия операционной системы поддерживать новейшую версию Oracle? Когда компания, в которой я работала, решила обновить версию 7.1.5 до 7.3.2.3.2 на машинах с Alpha OpenVMS, выяснилось, что нам придется обновлять операционную систему с V6.2 до V7.1, а также производить миграцию приложения Oracle Financials с V9.4.2 на V10.6. Три обновления сразу! Одновременно с этим нам пришлось бы внести несколько довольно тонких изменений в сетевую конфигурацию. В такой ситуации весьма

вероятно возникновение непредвиденных проблем, причины которых зачастую трудно определить.

Мы не решились на три одновременных обновления и пришли к мысли о необходимости промежуточного решения. В результате начали с обновления операционной установив исправление (patch), которое решило проблему интероперабельности, а немного позже обновили РСУБД и приложения. Однако даже для использования исправления нам пришлось пересмотреть подход к организации сети Oracle.
Устранение проблем, возникших в ходе модернизации сети, привело к некоторым задержкам и повлияло на общий график наших работ. Как в картинке, разрезанной на куски, каждая часть системы зависит от других частей, и чтобы система эффективно функционировала, все они должны

быть правильно состыкованы. Модификация одного компонента может затрагивать несколько других, причем как незначительным, так и очень существенным образом.

Другой фактор, который нужно учесть, выбирая момент перехода на новую версию Oracle,— это стабильность новой версии. Я работаю с продуктами Oracle долгое время, но пока не видела основной версии, которая была бы совершенно стабильной с самого начала. Даже промежуточные версии могут создавать большие проблемы. При переходе на только что вышедшую версию вы не знаете, с какими потенциальными проблемами можете столкнуться. Я предпочитаю звонить в службу поддержки Oracle и узнавать об известных ошибках, проблемах и пакетах исправлений, прежде чем начинать обновление.

Рассматривая возможность обновления или миграции, постарайтесь совместно с разработчиками определить, без каких новых функций действительно нельзя обойтись. Оправдают ли предлагаемые усовершенствования тот риск, который связан с установкой новых программ? Работают ли вообще те новейшие функции, которые рекламируются?

Достаточно ли они совершенны, чтобы принести пользу вашей организации? Когда впервые появилась возможность делать моментальные снимки, команда разработчиков, с которой я взаимодействовала, с энтузиазмом восприняла эту идею и долго        над ее эффективной реализацией. Если бы они        подождали, то сэкономили бы немало времени и сил, поскольку в следующей версии эта функция была серьезно доработана. Такое бывает с любыми программными продуктами. Первая попытка реализовать новую функцию        Дает именно тот результат, которого ожидаете вы или ваши разработчики.

"Ещё один момент, о котором следует подумать,— это 'возможность отхода на исходную позицию в случае неудачи. Если вы переходите на новую версию операционной системы; чтобы обеспечить поддержку новой версии Oracle, которая, в свою очередь, нужна для поддержки новой версии приложения, то сможете ли вы вернуться к тому состоянию, которое было до начала первого изменения? Будет ли восстановление столь же простым, как откат к предварительно сохраненной конфигурации, или вам потребуется заново перестраивать' систему? Сколько времени система может оставаться недоступной в ходе обновления и восстановления? Как это повлияет на работу пользователей? Как именно вы собираетесь выполнять миграцию/обновление? Возможно, следует выделить весь набор дисков тестовой системы для тренировки и несколько раз прогнать всю процедуру, замеряя время ее выполнения, чтобы при настоящем обновлении не возникло никаких неожиданностей. Многие компании арендуют эквивалентную группу компьютеров для пробных прогонов перед тем, как попытаться произвести обновление в производственной среде.

Имейте также в виду, что некоторые приложения используют промежуточный слой независимого производителя, например Transaction Monitor компании Elpina. Вы должны убедиться, что все независимые программные продукты совместимы с версией Oracle, на которую пред, полагается перейти. Кроме того, код приложений часто содержит ссылки на Net8 и другие библиотеки, и для таких приложений может потребоваться полная перекомпиляция. Учитывая, что некоторые системы содержат сотни и даже тысячи программ, процесс перекомпиляции и связывания может растянуться на несколько дней.

Определение наиболее подходящей версии может стать нелегким делом. Допустим, вы решили, что предлагаемые в новой версии возможности действительно необходимы. Сколько времени вам будет отпущено на установку и тестирование версии перед ее        в производственную среду? Постарайтесь заранее определить, каким образом изменения повлияют на сеть. Чтобы обеспечить успешный запуск новых приложений, нужно решить, как будет происходить работа с новыми или исправленными версиями, пока команда разработчиков реализует и тестирует свое приложение. Сможете ли вы продолжать обслуживание существующей системы и одновременно вносить изменения в новую? Потребуется ли "заморозить" производственную среду, выполняя только неотложные изменения? Если да, то на какое время?