Отчет oracle 13 сентября

Обновлено: 07.07.2024

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

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

Первая часть статьи, посвященная особенностям оператора order by, функционированию not in и примеру неявного преобразования типов, находится здесь.

Функция to_date и форматы даты

Мало кто из программистов любит тематику форматирования. Например, на некоторых курсах темы форматирования дат и региональных стандартов специально ставят на последние часы последнего дня тренинга, т.к. слушателям нудно. Причина в большом количестве существующих форматов при относительно редком их использовании в стандартных задачах. Чаще всего маски используются в трех функциях: to_number, to_char и to_date. Во всех трех случаях маска идет вторым необязательным параметром. И если масок для форматирования чисел еще более-менее вменяемое количество, то масок для форматирования дат до неприличия много, плюс еще суффиксы и модификаторы.

Безусловно, доступность большого количества масок является позитивным моментом, поскольку расширяет возможности, например, проверить является ли 13 сентября 2011 днем программиста, можно с помощью маски 'DDD', которая возвращает номер дня в году:

Несмотря на явную пользу форматирования, я не планировал включать во вторую часть статьи обзор форматов дат и примеры использования экзотических масок. Во-первых, вряд ли это будет кому-то интересно, во-вторых, автор также не является большим почитателем сложного форматирования, поскольку редко его применяет в жизни. Единственная причина появления данного раздела – некоторые вопросы, возникшие у читателей по поводу использования формата RR.

Перед тем как перейти непосредственно к основной теме раздела, давайте рассмотрим несколько нестандартных примеров работы с датами.

Пример №1. Использование урезанных шаблонов
Начнем со стандартного форматирования. Пускай сегодняшняя дата 16.09.2011, выполнятся ли следующие запросы, и что они вернут?

Запрос №2 является типичным примером конвертации даты в строку с приведением ее к нужному формату. Единственное отличие – вместо более привычных масок вида 'DD.MM.YY' или 'DD-MON-YYYY' мы использовали маску, задающую только год. Запрос №2 выполнится успешно и вернет текущий год в четырехзначном формате, т.е. '2011'.

Запрос №3 немного интереснее, он представляет собой типичный пример явного преобразования строки в дату с урезанной маской формата, поэтому, с точки зрения синтаксиса, запрос верный и выполнится успешно. Более важным вопросом является результат его выполнения, т.е. какую дату он вернет, если задан только день? Перед ответом на данный вопрос давайте вспомним, как Oracle устанавливает время, если оно явно не задано:

В запросе №4 время не указано, в запросе №5 указано только количество минут, часы и секунды опущены. В Oracle существует правило, согласно которому, если в дате отсутствует временной компонент, то время автоматически устанавливается в значение 00:00:00 (т.е. полночь), если задана только часть элементов времени (как в запросе №5), то пропущенные элементы устанавливаются в 00. Поэтому, запрос №4 вернет строку '03.02.2011 00:00:00', а запрос №5 — '03.02.2011 00:30:00'.

Вернемся к запросу №3, верно ли данное правило для дат, т.е. заменяются ли пропущенные при конвертации элементы даты на 00 или 01? Да заменяются, но не все, точнее, для пропущенных элементов даты используются значения из sysdate (первый день текущего месяца текущего года). Поэтому запрос №3 будет использовать 09 в качестве месяца и 2011 в качестве года, таким образом, результатом выполнения запроса будет дата 03.09.2011.

Пример №2. Порядок параметров форматирования
Выполнится ли следующий запрос, и если да, то какую дату он вернет?

На первый взгляд, отсутствие разделителей в строке с датой может показаться критическим фактором несовместимым с выполнением запроса, однако маска даты также задана без разделителей и строка для преобразования соответствует указанному шаблону. Поэтому запрос №6 выполнится успешно и вернет 20.11.2009 (формат результата может несколько отличаться в зависимости от настроек сессии). Детальнее вопросы, связанные с разделителями, мы рассмотрим в следующем примере.

Пример №3. Неявная конвертация
Пусть формат даты по умолчанию DD.MON.RR, а язык даты – русский, отработает ли следующий запрос:

В данном запросе указано два строковых параметра, которые должны быть преобразованы в даты с помощью неявной конвертации. Согласно документации, при использовании форматов по умолчанию, строка для неявного преобразования в дату должна удовлетворять шаблону: [D|DD] separator1 [MM|MON|MONTH] separator2 [R|RR|YY|YYYY]. В качестве separator1 и separator2 можно использовать большинство разделительных знаков и специальных символов, в том числе пробелы, табуляцию, а также " и удвоенную одинарную кавычку ''. Более того, если в строке указано не менее двух цифр для задания дней, месяцев и лет, то separator вообще может быть опущен. Например:

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

Пример №4. Параметры функции to_date
Пусть формат даты по умолчанию DD.MON.RR, а язык даты – русский, отработает ли следующий запрос:

Схожий запрос фигурировал в одном из обсуждений на странице ask Tom. Ловушка запроса в том, что мы пытаемся преобразовать дату (sysdate) в дату. Если бы запрос выглядел так:

То выполнение прошло бы успешно, и он вернул строку '09/15/2011 23:00:11'. Однако функция to_date в качестве первого параметра ожидает строку поэтому, вначале происходит неявная конвертация даты в строку (что эквивалентно вызову to_char(sysdate) с маской по умолчанию). Результатом данной конвертации является строка '15.09.11', далее происходит вызов to_date. Таким образом, запрос №11 эквивалентен следующему запросу:

Как не сложно убедиться, запрос №13 не может быть выполнен, поскольку строка '15.09.11' не соответствует установленной маске, соответственно, запрос №11 так же не может быть выполнен.

Установка формата даты по умолчанию
Формат дат по умолчанию задается двумя параметрами: NLS_DATE_FORMAT (отвечает за сам формат как таковой) и NLS_DATE_LANGUAGE (отвечает за язык, который будет использован при написании названий дней, месяцев и т.д.). Если эти параметры не заданы явно, то их значения устанавливаются на основе параметра NLS_LANG.

Уровень БД: Параметры этого уровня устанавливаются при создании БД и прописываются в файле init.ora.
Уровень экземпляра: Параметры этого уровня устанавливаются при старте экземпляра и могут быть изменены с помощью команды ALTER SYSTEM.
Уровень сессии: Параметры этого уровня могут быть изменены командой ALTER SESSION. Также значение данных параметров можно проверить с помощью запроса:

Логично предположить, что преобразование строки '11.09.11' в дату пройдет успешно, а строки '11.SEP.11' – нет. Однако это не так, успешно выполнятся оба преобразования. Вначале я предполагал, что в случае невозможности преобразовать строку по маске сессии Oracle пытается задействовать маски других уровней (маска уровня БД у меня установлена в 'DD-MON-RR'). Чтение документации показало, что это не так, и Oracle руководствуется принципами, описанными в предыдущем пункте.

Попробуем другой пример:

Если вы думаете, что результат будет идентичен предыдущему запросу, то вы ошибаетесь. Одно из преобразований не выполнится. В данном случае строка '11.09.11' не удовлетворяет шаблону. Возможно, это мистика?

Увы, нет. Чтение документации показало, что существуют правила автозамены элементов форматирования даты. Ниже привожу таблицу замен.

Original Format Element	Additional Format Elements to Try in Place of the Original
'MM'	'MON' and 'MONTH'
'MON	'MONTH'
'MONTH'	'MON'
'YY'	'YYYY'
'RR'	'RRRR'

Глядя на содержимое этой таблицы, становится понятно, что в формате 'DD.MM.RR' неявным образом присутствует формат 'DD.MON.RR' (а также 'DD.MONTH.RR' и другие), а вот в формате 'DD.MON.RR' формат 'DD.MM.RR' не присутствует, что и объясняет поведение запросов №14 и №15.

Пример №6. Формат RR vs YY
Большинству пользователей отличия масок RR и YY хорошо известны, однако есть и те, кому данная информация окажется полезной. Перейдем сразу к рассмотрению примера. Какие данные вернут следующие запросы:

Оба приведенных выше запроса выполнятся успешно и вернут даты в соответствии с правилами, описанными в примере №1 для запроса №3. Таким образом, значение дня во всех полученных датах будет равно 01, а значение месяца 09 (если вы выполняете запрос в сентябре). Главный вопрос, каким будет значение года?

Как несложно предположить, в запросе №16 под '11' я подразумевал 2011 год и обе маски мне его вернули, т.е. результат выполнения запроса №16 это 01.09.2011 и 01.09.2011.

В запросе №17 под '99' я подразумевал 1999 год и тут мнения масок разделились: маска RR вернула ожидаемый 1999 год, а маска YY – 2099, т.е. результат выполнения запроса №17 это 01.09.1999 и 01.09.2099.

Рассмотрим, как работают эти элементы форматирования более детально:

If the last two digits of the current year are 00 to 49, then the returned year has the same first two digits as the current year.
If the last two digits of the current year are 50 to 99, then the first 2 digits of the returned year are 1 greater than the first 2 digits of the current year.

If the last two digits of the current year are 00 to 49, then the first 2 digits of the returned year are 1 less than the first 2 digits of the current year.
If the last two digits of the current year are 50 to 99, then the returned year has the same first two digits as the current year.

Поэтому запрос №19 вернет 1950 год в обоих случаях.

Пример №7. Некоторые другие примеры
В завершение обзора рассмотрим немного экзотики. Будет ли ошибка в результате выполнения следующего запроса:

Если вы решили, что это бессмысленная запись, то вы ошибаетесь – это вполне корректное задание даты в соответствии со стандартом ANSI, запрос №20 выполнится успешно и вернет 25.12.1928.

Какой из запросов не выполнится?

Данный пример призван продемонстрировать наличие третьего параметра в функции to_date. Данный параметр позволяет установить значение одного из NLS (National Language Support) параметров только для этого вызова функции to_date. Установку NLS параметров для сессии мы рассматривали в примере №5. Ключевая разница запросов №20 и №21 состоит не в названии месяца (маска MON автоматически замещается маской MONTH, как это описано в примере №5), а в указании разных языков даты. Запрос №21 ожидает название месяца на английском и, соответственно, не выполнится, запрос №22 ожидает название месяца на русском и выполнится успешно.

В каком случае следующее объявление таблицы может приводить к возникновению ошибок при вставке данных?

Каждый раз, когда сессия с форматом даты по умолчанию 'DD.MON.RR' будет производить вставку с указанием только значения первого столбца будет возникать ошибка.

Особенности отображения дат в различных приложениях

Что влияет на отображение даты
Этот раздел добавлен после публикации статьи благодаря рекомендациям, указанным в комментариях. Описанное далее верно как для отображения дат, так и для отображения чисел. Возможно, при выполнении некоторых приведенных выше в статье примеров, вы получили даты в отличном от указанного в результатах формате. Если настройки вашей сессии соответствовали указанным в примерах, то это представляется, по меньшей мере, странным.

Правда заключается в том, что при выполнении запроса
вы получаете дату, но для отображения результата на экран конкретная утилита, с помощью которой вы обращаетесь к БД, должна провести конвертацию даты в строку. Таким образом, для отображения дат (и чисел) неявным образом вызывается to_char, т.е. имеем классический случай неявной конвертации (это конвертация только для вывода на экран, ее результаты не участвуют ни в каких вычислениях и ни на что кроме отображения данных не влияют). Если есть неявная конвертация, значит, существует и маска, по которой она выполняется. В классическом случае это должна быть маска, установленная для сессии, т.е. маска, указанная в параметре NLS_DATE_FORMAT таблицы nls_session_parameters, с которой мы активно работали на протяжении всей статьи.

Давайте проверим работу некоторых приложений. Проверять будем с помощью следующего скрипта:

Проверим, какие параметры для отображения дат использует sqlplus.

Рис. 1. Результат выполнения запроса №25 в sqlplus.

Как видно из рис.1, формат отображения даты меняется в зависимости от настроек сессии, т.е. sqlplus использует настройки сессии. Это упрощает понимание процесса преобразования дат в строки и обратно, поскольку и для преобразования и для отображения используются одинаковые маски.

Некоторые продвинутые средства разработки используют свои собственные NLS настройки, не имеющие отношения к настройкам Оракл. В качестве примера проверим, какие параметры для отображения дат использует PL/SQL Developer. Для этого выполним в нем запрос №25.

Рис. 2. Результат выполнения запроса №25 в PL/SQL Developer.

Как видно из рис.2, формат отображения даты не меняется при изменении настроек сессии. Более того, если посмотреть внимательно, то видно, что и первый и второй результаты вывода даты на экран не соответствовали параметрам сессии (в первом случае выведенная дата имела год в четырехзначном формате, а маска указывала год в двухзначном формате). Это означает, что утилита использует собственные NLS настройки, в случае PL/SQL Developer’а их расположение указано на рис. 3.

Рис. 3. Установка NLS параметров отображения дат в PL/SQL Developer.

Чем могут быть вредны NLS настройки утилит
Отображение даты в формате отличном от формата сессии вредно по одной причине – оно вводит пользователя в заблуждение и может привести к возникновению ошибок. Выполним в sqlplus и PL/SQL Developer следующий запрос:
В последнюю строку запроса вместо ХХХХХХХХ мы будем вставлять полученные из предыдущей строки данные.

Результаты выполнения запроса представлены на рисунках ниже.

Рис. 4. Результат выполнения запроса №26 в sqlplus.

Рис. 5. Результат выполнения запроса №26 в PL/SQL Developer.

Почему в sqlplus выведенные на экран данные были успешно конвертированы в дату, а данные выведенные на экран PL/SQL Developer’ом не смогли сконвертироваться? Потому что для конвертации Оракл использует формат данных указанный в сессии, а данные выведенные PL/SQL Developer’ом были приведены для отображения в свой формат, отличный от формата сессии.

Заключение

В качестве заключения хочу напомнить, что почти в каждом своем посте посвященном работе с датами, Том Кайт говорит о необходимости использования явных преобразований и обязательном указании маски. «При конвертации строки в дату никогда не полагайтесь на формат даты по умолчанию, всегда явно задавайте маску» — примерно так звучат его слова. Дополнительные примеры и возможные ошибки при работе с преобразованием дат вы можете найти, воспользовавшись страничкой ask Tom.

Поскольку работа с датами заняла всю статью, то «за бортом» осталось множество интересных вопросов, которые я хотел бы рассмотреть. Скорее всего, появится и третья часть статьи, как только у меня найдется свободное время.

Oracle Corporation (NYSE:ORCL) — крупнейший в мире разработчик программного обеспечения для организаций, крупный поставщик серверного оборудования — вчера после закрытия американской торговой сессии представил отчет за IV квартал 2014 финансового года. Финансовые результаты разочаровали инвесторов, и акции на постмаркете обвалились на 5% (итоговая котировка — $40,38).

Скорректированная прибыль на одну акцию выросла на 6% по сравнению с аналогичным периодом прошлого года и составила $0,92 (аналитики в среднем ожидали $0,95). Выручка выросла лишь на 3%, достигнув $11,3 млрд, тогда как эксперты прогнозировали $11,48 млрд. Несколько слабый отчет за IV квартал, причем второй год подряд, может вызвать удивление. Традиционно IV квартал является сильным для Oracle, так как перед закрытием фискального года менеджеры по продажам стремятся подписать контракты, чтобы получить годовые бонусы.

Но давайте разберемся, действительно ли все так плохо.

Во-первых, финансовые показатели все-таки выросли. Выручка за год достигла рекордных $38,3 млрд. Вопрос в том, что котировки, которые успели приблизиться к историческим максимумам 2000 года, закладывали более оптимистичные прогнозы экспертов.

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

Прогноз Oracle на текущий квартал вполне соответствует прогнозам экспертов. Скорректированная прибыль на одну акцию может составить $0,62-0,66 (эксперты ожидают $0,64). Выручка, по мнению топ-менеджмента, может вырасти на 4-6% (аналитики прогнозируют 5%).

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

Техническая картина: когда американские биржи сегодня откроются, акции, вероятно, выйдут вниз из медвежьего клина, а также пробьют линию среднесрочного восходящего тренда. Падение, скорее всего, продолжится. В качестве ближайшей поддержки можно указать статический уровень $39, примерно здесь находится и проекция клина. При ее пробитии бумаги могут уйти на 200-дневную скользящую среднюю в район $37.

Уровни сопротивления: 41,6 / 42,4 / 43,2
Уровни поддержки: 39 / 37 / 34

Оксана Холоденко, БКС Экспресс

Зарегистрируйтесь, чтобы иметь возможность оставлять комментарии. Уже есть аккаунт? Войти Покупайте ценные бумаги любимых брендов в один клик Зарегистрируйтесь, чтобы управлять панелью котировок. Уже есть аккаунт? Войти Покупайте ценные бумаги любимых брендов в один клик 5 идей в американских акциях: инфляция и праздничный сезон Спреда как не бывало — российский рынок утратил преимущество

Рубль стремительно дешевеет: доллар уже выше 74

Распродажи на рынке. Угольщики хуже всех

Ход торгов. Падение продолжается, индекс МосБиржи ушел ниже 4000

Скованные одной цепью

Крупнейшие автопроизводители на СПБ Бирже. Инфографика

РОСНАНО может реструктурировать долг. Облигации теряют более 10%

Спреда как не бывало — российский рынок утратил преимущество

Голубые фишки сорвались вниз. Индекс МосБиржи теряет более 3%

* Материалы, представленные в данном разделе, не являются индивидуальными инвестиционными рекомендациями. Финансовые инструменты либо операции, упомянутые в данном разделе, могут не подходить Вам, не соответствовать Вашему инвестиционному профилю, финансовому положению, опыту инвестиций, знаниям, инвестиционным целям, отношению к риску и доходности. Определение соответствия финансового инструмента либо операции инвестиционным целям, инвестиционному горизонту и толерантности к риску является задачей инвестора. ООО «Компания БКС» не несет ответственности за возможные убытки инвестора в случае совершения операций, либо инвестирования в финансовые инструменты, упомянутые в данном разделе.

Информация не может рассматриваться как публичная оферта, предложение или приглашение приобрести, или продать какие-либо ценные бумаги, иные финансовые инструменты, совершить с ними сделки. Информация не может рассматриваться в качестве гарантий или обещаний в будущем доходности вложений, уровня риска, размера издержек, безубыточности инвестиций. Результат инвестирования в прошлом не определяет дохода в будущем. Не является рекламой ценных бумаг. Перед принятием инвестиционного решения Инвестору необходимо самостоятельно оценить экономические риски и выгоды, налоговые, юридические, бухгалтерские последствия заключения сделки, свою готовность и возможность принять такие риски. Клиент также несет расходы на оплату брокерских и депозитарных услуг, подачи поручений по телефону, иные расходы, подлежащие оплате клиентом. Полный список тарифов ООО «Компания БКС» приведен в приложении № 11 к Регламенту оказания услуг на рынке ценных бумаг ООО «Компания БКС». Перед совершением сделок вам также необходимо ознакомиться с: уведомлением о рисках, связанных с осуществлением операций на рынке ценных бумаг; информацией о рисках клиента, связанных с совершением сделок с неполным покрытием, возникновением непокрытых позиций, временно непокрытых позиций; заявлением, раскрывающим риски, связанные с проведением операций на рынке фьючерсных контрактов, форвардных контрактов и опционов; декларацией о рисках, связанных с приобретением иностранных ценных бумаг.

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

👉 С 2020 год Nasdaq 100 вырос почти на 100%. Текущее падение котировок технологических компаний нормально, они не могут вечно дорожать. Сектор был драйвером роста в течение десятилетия и выглядит слишком «надутым»

Авто-репост. Читать в блоге >>>

Целевая цена по Oracle - $83,4 за акцию - Фридом Финанс
В контексте ускорения роста во втором квартале результаты Oracle в третьем квартале выглядят невыразительно. При этом менеджмент дал сильный прогноз на весь фискальный год.

Выручка Oracle выросла на 4% г/г, что оказалось на уровне первоначальных оценок менеджмента, но на 0,3% ниже консенсус-прогноза аналитиков. При исключении эффекта валютных курсов продажи выросли лишь на 2%. Разводненный non-GAAP EPS вырос на 10,7% – на 6% выше ожиданий рынка.

Авто-репост. Читать в блоге >>>

📉 Акции Oracle теряют 3.5% после выхода квартальной отчётности

👉 Компания отчиталась о квартальном EPS в $1.03 лучше ожиданий аналитиков, но выручка оказалась хуже оценок экспертов — $9.73 млрд

👉 Отчётность компании заставила инвесторов задуматься о перспективах компании в конкуренции за рынок облачных услуг

👉 Так, выручка от облачных лицензий и локального лицензирования упала на 8% год к году

👉 В Oppenheimer отмечают, что инвестиции компании в облачные сервисы окажут некоторое давление на рентабельность в обозримом будущем, что также не порадовало инвесторов

Авто-репост. Читать в блоге >>>

сегодня ожидаем: ORCL отчет. Прогн.EPS $0,85, Выручка $9,8B

Oracle - Прибыль 2021 ф/г, зав 31 мая: $13,746 млрд (+36% г/г). Дивы 4 кв $0,32. Отсечка 29 июля

Общий долг FY – 31.05.2019г: $86,346 млрд
Общий долг FY – 31.05.2020г: $102,721 млрд
Общий долг FY – 31.05.2021г: $125,155 млрд

Выручка FY – 31.05.2019г: $39,506 млрд
Выручка 9 мес – 29.02.2020г: $28,629 млрд
Выручка FY – 31.05.2020г: $39,068 млрд
Выручка 1 кв – 31.08.2020г: $9,367 млрд
Выручка 6 мес – 30.11.2020г: $19,167 млрд
Выручка 9 мес – 28.02.2021г: $29,252 млрд
Выручка FY – 31.05.2021г: $40,479 млрд

Прибыль 9 мес – 28.02.2019г: $7,343 млрд
Прибыль FY – 31.05.2019г: $11,083 млрд
Прибыль 9 мес – 29.02.2020г: $7,019 млрд
Прибыль FY – 31.05.2020г: $10,135 млрд
Прибыль 1 кв – 31.08.2020г: $2,251 млрд
Прибыль 6 мес – 30.11.2020г: $4,693 млрд
Прибыль 9 мес – 28.02.2021г: $9,714 млрд
Прибыль FY – 31.05.2021г: $13,746 млрд

Авто-репост. Читать в блоге >>>

Прибыль 2021 ф/г, завершился 31 мая: $13,746 млрд (+36% г/г).
Дивы 4 кв $0,32. Отсечка 29 июля

сегодня ожидаем: ORCL отчет. Прогн.EPS $1,31, Выручка $11B

сегодня ожидаем: ORCL: дивиденды $0.32; Выплата 22.04.2021

CEO Catz Safra на 333 мульта зелени за раз. Оптовый, так сказать, слив .
Таковых еще не видывал. Живут же люди. И спит, небось, крепким сном )

сегодня ожидаем: ORCL отчет. Прогн.EPS $1,11, Выручка $10,1B

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

Всем привет, Друзья. Сегодня у нас на очереди еще несколько перспективных компаний США. Разберем Oracle и Illumina, которые работают в разных секторах экономики. Посмотрим на их бизнесы, финансовые показатели и решим, стоит ли покупать компании в свой портфель.

Oracle (ORCL)
Американская компания разработчик программного обеспечения. Основной продукт Oracle Database широко используется в более чем 140 странах. Компания занимает второе место в мире по объемам продаж программного обеспечения, уступая лишь Microsoft. С 2010 года активно работает в направлении облачных вычислений и CRM решений. Примечательно, что до 2010 года компания критиковала это направление. Также Oracle после поглощения Sun Microsystems расширила свое присутствие на рынке серверного ПО, а в последствии и занялась производством оборудования для дата-центров. В сентябре 2020 года стало известно, что Oracle планирует приобрести Tik-Tok.

Самая оперативная информация в моем Telegram

Авто-репост. Читать в блоге >>>

Oracle и Zoom объединятся, чтобы улучшить взаимодействие с клиентами. Для этого компании внедряют серию интеграций между платформой Zoom и приложениями Oracle Cloud CX. В частности, Oracle и Zoom будут развивать приложения Oracle CX Marketing, Oracle CX Service и Oracle CX Sales. Интеграция позволит отделам продаж, маркетинга и обслуживания клиентов беспрепятственно встраивать видео в существующие процессы и лучше работать с каждым клиентом.

Положение дел усугубляет тот факт, что точных сведений о пунктах сделки нет. Американские покупатели в лице Oracle и Walmart заявили, что получат совокупно контрольный пакет акций TikTok Global при участии еще трех ключевых акционеров-юрлиц из США. Эта передача контроля, как они полагают, будет сопровождаться вхождением в совет директоров представителей новых и старых инвесторов, причем 4 из 5 мест достанется гражданам США. Последняя версия итогов переговоров от ByteDance существенно противоречит этой схеме. Компания говорит, что намерена сохранить 80% в структуре TikTok Global, но не напрямую, а посредством своих дочерних структур в США. То есть принцип передачи контроля американцам будет соблюден лишь формально. При этом американский состав руководства фирмы не оспаривался: у ByteDance, несмотря на регистрацию в Пекине, и сейчас трое из пяти членов совета директоров – иностранцы, аффилированные с бизнесом в США.

Авто-репост. Читать в блоге >>>

Проклятый Oracle опять обманул
14 сентября какой-то инсайдер или просто разводила на СПБ загнал Oracle с открытия на 40%, потом также быстро сдул. Сначала акция мне дала, а потом все взад забрала и мое прихватила.

А сегодня Трамп опять с тик током мутит, и в понедельник Oracle снова полетит в небеса.
Вот гопники проклятые, опять обманули.

Разработчик программного обеспечения Oracle (NYSE: ORCL) отчитался за четвертый квартал и 2021 финансовый год. Основные финансовые результаты за четвертый квартал:

выручка выросла на 8%, до 11,2 млрд долларов;
продажи в сегменте облачных услуг прибавили 8%, а в сегменте облачных и локальных лицензий — 9%;
операционная прибыль выросла на 5%, до 4,5 млрд;
чистая прибыль выросла на 29%, до 4 млрд.

А вот как закончился для компании 2021 финансовый год:

выручка выросла на 4%, до 40,5 млрд долларов;
облачный и лицензионный сегменты прибавили по 5%;
операционная прибыль выросла на 9%, до 15,2 млрд;
чистая прибыль выросла на 36%, до 13,7 млрд.

Глава Oracle Сафра Катц назвала квартальные результаты, которые оказались выше ожидаемых, выдающимися: «‎Темпы роста наших облачных решений Fusion и NetSuite стали еще выше. В третьем и четвертом кварталах Fusion ERP выросла на 30 и 46%, Fusion HCM — на 23 и 35%, NetSuite — на 24 и 26%. Fusion и NetSuite — крупнейшие в мире облачные ERP-системы. Выручка от нашей IaaS-платформы второго поколения, включая автономную базу данных, выросла более чем на 100%. Ускорение темпов роста наших приложений и облачной инфраструктуры позволило увеличить прибыль на акцию на 21% в 2021 финансовом году. Размер прибыли на акцию растет двузначными темпами четвертый год подряд».

Как победить выгорание

Курс для тех, кто много работает и устает. Цена открыта — назначаете ее сами

По данным агентства Apps Run The World, в 2020 году Oracle была лидирующим разработчиком облачных ERP-приложений и занимала 12,2% всего рынка. ERP (enterprise resource planning) — приложения, которые помогают компаниям управлять бухгалтерским учетом, закупками, проектами, рисками и цепочками поставок.

Несмотря на позитивный отчет, акции Oracle упали на 5%, до 77,8 $, после закрытия основной торговой сессии. Инвесторам не понравилось, что прогнозы скорректированной прибыли компании оказались ниже ожиданий аналитиков. В 2022 финансовом году Oracle планирует увеличить капитальные вложения в облачные технологии примерно в два раза, до 4 млрд долларов. Это уменьшит размер будущей прибыли.

С начала года акции Oracle в два раза доходнее индекса широкого рынка S&P 500 — 28 против 15%. Консенсус аналитиков по ценным бумагам Oracle в следующие 12 месяцев — 73 $.

Читайте также: