Комментарии 25
спасибо
1. За четкое, внятное и грамотное изложение алгоритма.
2. За то, что не страдаете убунтой головного мозга.
1. За четкое, внятное и грамотное изложение алгоритма.
2. За то, что не страдаете убунтой головного мозга.
Спасибо за подробную инфу.
А под Windows, подскажите:
1) Для разработки стоит ли ставить на свою же машину Standard/Enterprise Edition или она требует много ресурсов и все будет тормозить? (Express не подходит, так как там нет поддержки Java)
2) Под Windows 7 64bit, если сталкивались, то подойдут ли драйвера Oracle 64 bit? А то я ставил и ничего не вышло, PHP не хотел коннектиться, пока не поставил 32 битные.
А под Windows, подскажите:
1) Для разработки стоит ли ставить на свою же машину Standard/Enterprise Edition или она требует много ресурсов и все будет тормозить? (Express не подходит, так как там нет поддержки Java)
2) Под Windows 7 64bit, если сталкивались, то подойдут ли драйвера Oracle 64 bit? А то я ставил и ничего не вышло, PHP не хотел коннектиться, пока не поставил 32 битные.
1. Разнице в потреблении ресурсов между Express и Stadndard/Enterprise Edition нет. В Express просто ограничения на кол-во используемых ресурсов для базы.
2. 32 битные приложения требуют 32 битных драйверов, 64 битные — 64 битных ;-)
2. 32 битные приложения требуют 32 битных драйверов, 64 битные — 64 битных ;-)
1. То есть, S/E Edition позволит мне нормально работать на том же самом компьютере?
2. Уточните ответ, пожалуйста.
2. Уточните ответ, пожалуйста.
1. Да
2. www.viva64.com/ru/l/0002/ — тут подробнее.
А насчет PHP — в Windows обычно берут бинарные сборки, а в них библиотеки уже собраны под конкретную версию оракловой библиотеки, и с другими версиями оно работать не будет.
Для 64х битной оракловой библиотеки надо 64х битную версию PHP, а их готовых под Windows на официальном сайте я не видел. Ну и до кучи надо будет еще 64 битную версию Apache или другого веб-сервера.
2. www.viva64.com/ru/l/0002/ — тут подробнее.
А насчет PHP — в Windows обычно берут бинарные сборки, а в них библиотеки уже собраны под конкретную версию оракловой библиотеки, и с другими версиями оно работать не будет.
Для 64х битной оракловой библиотеки надо 64х битную версию PHP, а их готовых под Windows на официальном сайте я не видел. Ну и до кучи надо будет еще 64 битную версию Apache или другого веб-сервера.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
И это сделала одна из крупнейших IT-компаний в мире.
А «Почта России» — одно из крупнейших предприятий страны.
А «Почта России» — одно из крупнейших предприятий страны.
НЛО прилетело и опубликовало эту надпись здесь
Да, Сбер хорошо апгрейднулся в лучшую сторону. Но мой пост был не об этом, а о том, что размер компании — это в первую очередь признак пропиаренности среди гос. контор и крупных заказчиков, но никак не признак качественного технического исполнения. Чем крупней заказчик, тем дальше находится человек, принимающий бизнес решения от технарей, которые «как-нибудь этот бампер да прикрутят».
Чем больше узнаю про оракл, тем больше он у меня начинает ассоциироваться с коболом и мэйнфреймами. Сугубо по области своего применения/популярности.
Чем больше узнаю про оракл, тем больше он у меня начинает ассоциироваться с коболом и мэйнфреймами. Сугубо по области своего применения/популярности.
Instant Client да. INSTANT.
НЛО прилетело и опубликовало эту надпись здесь
Про наличие RPM для instant client в посте указано, а вот что у Oracle есть RPM для расширений — я не знал.
Спасибо за информацию.
Спасибо за информацию.
НЛО прилетело и опубликовало эту надпись здесь
А при более внимательном изучении вашей ссылки обнаруживаем, что:
В итоге из этих RPM можно установить только instant client, про что я написал, и oci8. Жаль.
А вот для Zend Server есть все в сборке и с поддержкой:
Наверное Oracle не хватает мощностей, что бы сделать что-то безвозмездно, т.е. даром.
The PDO_OCI driver for the PDO extension is not currently included.
В итоге из этих RPM можно установить только instant client, про что я написал, и oci8. Жаль.
А вот для Zend Server есть все в сборке и с поддержкой:
If support is needed, use Zend Server.
Наверное Oracle не хватает мощностей, что бы сделать что-то безвозмездно, т.е. даром.
Уже не помню к сожалению точные описания всех переменных для чего, но они мне в свое время очень помогли при работе из php с oracle (прописываются в .bashrc или по аналогии):
# oracle export NLS_LANG="RUSSIAN_RUSSIA.AL32UTF8" export NLS_DATE_FORMAT="YYYY-MM-DD HH24:MI:SS" export NLS_LENGTH_SEMANTICS=CHAR export NLS_NUMERIC_CHARACTERS=".,"
Немного комментариев с моей стороны (правда, я джавист), т.к. я использую оракл на локальной машине уже довольно давно (около 4 лет).
У нас (под Windows XP x32) используют локальный оракл 10g / 11g Enterprise Edition (standard не подходит из-за отсутствия ряда нужных фич), проблем не наблюдается.
Типично он потребляет памяти где то 250-300 мегабайт (что меньше чем, например, Google Chrome c тремя десятками вкладок:))), при более интенсисной обработке данных — бывает до 500 метров. Нагрузка на процессор обычно вообще не заметна (может проявится только если у вас много сложной логике в хранимых процедурах, и самих данных много).
На машинах класса Core2Duo / Quad с 3-4 гигами памяти локальный оракл совершенно не обременителен. На этих же машинах локально еще работают JBoss, Eclipse (и Google Chrome, который по моему ест памяти больше чем все выше перечисленное вместе взятое).
Типично локальная база занимает мало места сама по себе, т.к. используется локальная база в основном при разработке и локальном тестировании, т.к. данных там обычно немного (в таблицах редко бывает больше чем несколько жалких сот тысяч записей).
Укажу только несколько мелочей, который имеет смысл помнить при работе с локальной базой (когда вы сами себе DBA), они в общем-то общеизвестны, но о них часто забывают. Итак:
— Если вы часто и много (миллионы записей и больше) вставляете и удаляете данных из какой-то таблицы (например, тестируете какие-то интеграционные интерфейсы для загрузки данных из CSV / XML или что-то такое), помните о таком понятии, как Table HWM (high water mark). Переодически не забываете делать не просто delete, а truncate. Кроме того, при очень частой вставке / удалении большого количества записей, следите за размером redo-логов и датафайла с UNDO тейблспейсом.
— Для таблиц, на которые есть активные ссылающиеся внешние ключи из других таблиц, перед тем как можно будет делать truncate, придется пройтись сначала по схеме и отключить все ссылающиеся на таблицу внешние ключи (даже если нет реальных записей, ссылающихся на какие-то данные, сам факт наличия active внешнего ключа не даст сделать truncate).
— Если не следить на местом на диске, то с течением времени оракл может легко отъесть 30-40 гигабайт на диске, даже если у вас нет схем с большим объемом данных. Для борьбы с этим, из простейших методов, не забывайте стирать старые ненужные схемы (т.е. юзеров), и следить за тейблспейсами. Иногда может потребоваться сделать shrink tablespace самому. Неожиданно много места может съедать UNDO tablespace.
Если еще какие то типичные вещи вспомню, напишу.
У нас (под Windows XP x32) используют локальный оракл 10g / 11g Enterprise Edition (standard не подходит из-за отсутствия ряда нужных фич), проблем не наблюдается.
Типично он потребляет памяти где то 250-300 мегабайт (что меньше чем, например, Google Chrome c тремя десятками вкладок:))), при более интенсисной обработке данных — бывает до 500 метров. Нагрузка на процессор обычно вообще не заметна (может проявится только если у вас много сложной логике в хранимых процедурах, и самих данных много).
На машинах класса Core2Duo / Quad с 3-4 гигами памяти локальный оракл совершенно не обременителен. На этих же машинах локально еще работают JBoss, Eclipse (и Google Chrome, который по моему ест памяти больше чем все выше перечисленное вместе взятое).
Типично локальная база занимает мало места сама по себе, т.к. используется локальная база в основном при разработке и локальном тестировании, т.к. данных там обычно немного (в таблицах редко бывает больше чем несколько жалких сот тысяч записей).
Укажу только несколько мелочей, который имеет смысл помнить при работе с локальной базой (когда вы сами себе DBA), они в общем-то общеизвестны, но о них часто забывают. Итак:
— Если вы часто и много (миллионы записей и больше) вставляете и удаляете данных из какой-то таблицы (например, тестируете какие-то интеграционные интерфейсы для загрузки данных из CSV / XML или что-то такое), помните о таком понятии, как Table HWM (high water mark). Переодически не забываете делать не просто delete, а truncate. Кроме того, при очень частой вставке / удалении большого количества записей, следите за размером redo-логов и датафайла с UNDO тейблспейсом.
— Для таблиц, на которые есть активные ссылающиеся внешние ключи из других таблиц, перед тем как можно будет делать truncate, придется пройтись сначала по схеме и отключить все ссылающиеся на таблицу внешние ключи (даже если нет реальных записей, ссылающихся на какие-то данные, сам факт наличия active внешнего ключа не даст сделать truncate).
— Если не следить на местом на диске, то с течением времени оракл может легко отъесть 30-40 гигабайт на диске, даже если у вас нет схем с большим объемом данных. Для борьбы с этим, из простейших методов, не забывайте стирать старые ненужные схемы (т.е. юзеров), и следить за тейблспейсами. Иногда может потребоваться сделать shrink tablespace самому. Неожиданно много места может съедать UNDO tablespace.
Если еще какие то типичные вещи вспомню, напишу.
НЛО прилетело и опубликовало эту надпись здесь
Ответил в личку. Да, по обычным и OTN лицензиям.
www.oracle.com/technetwork/licenses/standard-license-152015.html — про OTN лицензии.
Спасибо за пост.
В закладки, потому что тоже на работе придется писать на PHP под Oracle.
А тут такая классная памятка под рукой!
В закладки, потому что тоже на работе придется писать на PHP под Oracle.
А тут такая классная памятка под рукой!
Когда будете ставить PDO_OCI на php 5.3, может не сработать make. Будет что то такое
/tmp/pear/download/PDO_OCI-1.0/pdo_oci.c:34:1: error: unknown type name 'function_entry'
Решается просто, в pdo_oci.c на 34 строке — заменяем «function_entry» на «zend_function_entry»
/tmp/pear/download/PDO_OCI-1.0/pdo_oci.c:34:1: error: unknown type name 'function_entry'
Решается просто, в pdo_oci.c на 34 строке — заменяем «function_entry» на «zend_function_entry»
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью, она чуть-чуть помогла в поисках истины. В результате все получилось, процесс установки описан тут: skalolaskovy.ru/comp-various/535-debian-and-oracle
(phpize упорно не хотел устанавливать)
(phpize упорно не хотел устанавливать)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Установка расширений OCI8 и PDO_OCI для PHP5