|
|
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
-2-казинакпропущено... между прочим это именно айбиэм и оракл двигают жавуА БМВ двигают велосипеды. На замену своим же автомобилям, где узкое место водитель и пассажиры не масштабируются более положенных сидячих мест. Хотя... если ремни безопасности реализовать на уровне - держаться рукой за переднее кресло, можно на заднем сидении вместо трех и пятерых пассажиров посадить, а если вместо isofix применить коленки родителей, то еще двоих-троих детей ту да же. какое-то словесное недержание -2-казинакпропущено... а про сервер в никуда - ваще бред, не знаешь, так хоть не позорьсяПоздно, уже опозорился. Для осознания "тупо добавить" у меня недостаточно квалификации. Пришлось воспользоваться документацией на сайте Томката. Смотрю раздел Apache Tomcat Clustering ... ты походу кластер бд не отличаешь от кластера серверов приложений кластеру сервера приложений не надо consistency данных обеспечивать это просто дополнительный процесс, который перестартует упавшие/зависшие жава машины неохото мне ликбезом заниматься, читай доки елика, тоже с собой возьми ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 09:38 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакв фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают все на серверах приложений ..чушь тихонько повизгивала... Они всего лишь prestodb разработали, где практически ansi https://prestodb.io/docs/current/sql/select.html При том у них совсем другая задача - Big Data, логика относительно простая, но даже в ней они без sql и джойнов не обошлись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:20 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
kinky catказинакв фейсбуке ни форин кей констрейнтов, ни джойнов в базе не делают все на серверах приложений ..чушь тихонько повизгивала... Они всего лишь prestodb разработали, где практически ansi https://prestodb.io/docs/current/sql/select.html При том у них совсем другая задача - Big Data, логика относительно простая, но даже в ней они без sql и джойнов не обошлись. я там не работал, доказать не смогу, но первый же нагугленный линк говорит авторMySQL - используется как хранилище пар ключ-значение, никаких join'ов https://www.insight-it.ru/highload/2010/arkhitektura-facebook/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:30 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинак, учитесь для начала гуглить https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920/?s=keen-io ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакMaximaXXLпропущено... ага, а потом приложения втянув в себя 16+ Гб данных из таблиц валятся с переполнением памяти ... а всего то надо было селектик написать и получить постранично (по 100 например) записей. Так нет жеж, мы все вытянем и в памяти быстро соберем/обработаем. Мы же однотабличные селекты делать умеем ... А еще можно пожаловаться что надо памяти докупить, это всегда проще чем код оптимизировать ... сдуру конечно можно и хер сломать только никто не будет 16Гб тянуть из базы просто последовательно сделают сначала по параметрам с формы вытащат айди регионов, например, потом, айди наименований товаров а потом из таблицы транзакций вытащат нужные транзакции ну это к примеру Ну если к примеру: Есть 2 таблицы: таб1 (Отдел, Сотрудник) - все сотрудники предприятия таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили ну и надо увидеть те отделы где на работу приходили все сотружники. Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте? И это ОЧЕНЬ простой пример ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 10:51 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
kinky catказинак, учитесь для начала гуглить https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920/?s=keen-io ну меряться линками глупо но даже в вашем линке написано "The Presto system is implemented in Java" такшто, оракл бд там, какбэ нету, и ваш агрумент только подтверждает уменьшение потребности оракл админов и прогеров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:06 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
MaximaXXLказинакпропущено... сдуру конечно можно и хер сломать только никто не будет 16Гб тянуть из базы просто последовательно сделают сначала по параметрам с формы вытащат айди регионов, например, потом, айди наименований товаров а потом из таблицы транзакций вытащат нужные транзакции ну это к примеру Ну если к примеру: Есть 2 таблицы: таб1 (Отдел, Сотрудник) - все сотрудники предприятия таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили ну и надо увидеть те отделы где на работу приходили все сотружники. Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте? И это ОЧЕНЬ простой пример элментарно в одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:08 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакMaximaXXLпропущено... Ну если к примеру: Есть 2 таблицы: таб1 (Отдел, Сотрудник) - все сотрудники предприятия таб2 (Сотрудник, Время прихода/ухода) - только те сотрудники которые приходили ну и надо увидеть те отделы где на работу приходили все сотружники. Расскажите мне несведущему, как Вы его реализуете не делая объединение таблиц в одном селекте? И это ОЧЕНЬ простой пример элментарно в одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надо Вот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. А если сервера БД нахожятся в Маями а сервера приложений в Лондоне ... то лучше написать один правильный запрос чем укатывать сервера приложений ... с криками, добавте памяти То же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:24 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакты походу кластер бд не отличаешь от кластера серверов приложений кластеру сервера приложений не надо consistency данных обеспечивать Ты путаешь социальную помойку с информационной системой. Если слетела подписка или странности с количеством лайков, всегда можно списать на руку Кремля или происки Госдепа. казинакэто просто дополнительный процесс, который перестартует упавшие/зависшие жава машины неохото мне ликбезом заниматься, читай докиДокументация томката clustering how-to пишет про репликацию сессий и предостерегает от "тупо добавил" для больших систем. казинакв одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надоМногие здесь проходили это "объединяем" в эпоху beforesql на прогрессивном dbase. Но потом объемы подросли, требования усложнились и вложенный цикл (нестед-луп) перестал покрывать все потребности. Потом захотелось не тупить, когда данные меняют более одного пользователя, потом прочий acid ... и dbase сдулся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:36 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
MaximaXXLВот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. это с какого перепугу? применяем фильтры тащим из одной таблицы, отфильтрованное, а потом, по результатам первой, тащим из второй MaximaXXLТо же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо кэши обновлять можно по требованию, то бишь после изменений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 11:37 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
казинакMaximaXXLВот и получаеться Вы тянете 16+ ГБ данных, вместо 2 строчек. это с какого перепугу? применяем фильтры тащим из одной таблицы, отфильтрованное, а потом, по результатам первой, тащим из второй Да с такого, что Вы уже вытащили данные из 2-й таблицы чтоб их проанализировать (это уже более 2 строчек) А далее Вам надо вытащить все данные из первой, потому как Вы не можете из вытащенных данных сформировать полный фильтр, в класcике банальный Left Join без полных данных первой таблицы сложно организовать. Но и так, взяв данные из второй таблицы вы получаете НАМНОГО больше данных чем пришлет результирующий селект. казинакMaximaXXLТо же относиться и к справочникам, иногда полезно иметь ин-мемори, но они должны быть не простыми (например, не нашел ин-мемори - полез в базу). Иначе кто-то добавит(а не дай бог исправит роутинг) в справочнике, а Вы об этом не знаете и по своей ин-мемори отправите транзакцию в другое приложение и разрушите бизнес логику. А это уже совсем плохо кэши обновлять можно по требованию, то бишь после изменений Можно кеши обновлять "по требованию" но опять таки - Вы будете тянуть все данные, а их может быть не мало и тянете Вы их для того чтоб получить колекцию для работы с чем? Если с данными из базы (вытянутые другим селектом) то может разумнее написать 1 правильный селект, а не городить огород? Данные кеша обновляються не моментально... Ставить всех на холд для обновления кешей зачастую так себе практика. Я много лет работаю с джавистами и они осознали силу sql. Даже если им надо что-то на 1 фильтр (например отчет МОЖЕТ вытягянуть 10+ ГБ, потому что в форме чел может указать очень поверхносно фильтр) и джависты этого не делали раньше, они приходят и мы обсуждаем как лучше. Уже давно они отошли от практики вытянем все и в памяти все быстро сделаем. Хотя еще приходят "молодые дарования" которые мыслят аналогично Вашему, но лабы в институте и реальная работа это разные вещи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 12:22 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Как-то дискуссия не в то русло немного утекла. Начиналось все с вопроса про DBA и уход в cloud. А, еще почему-то автора интересует Россия хотя сам он там не обитает и контактов не имеет. Несколько моментов 1. Облака Действительно в западном мире ведется активный выход в облако (включая банковскую сферу и прочие sensitive data) и действительно это уже привело (и тренд продолжается) к уменьшению вакансий DBA. Еще Oracle продвигает свои мега-технологии под названием "the self-driving database" и "Oracle autonomous database", что призвано уменьшить число DBA... правда оно может и наоборот потребовать больше человеческих ресурсов, но в этом случае можно отключить (как некоторые типа меня делают с другими особо интеллектуальными технологиями типа cardinality feedback или adaptive plans). Возвращаясь к России, достаточно разумно что компании намного менньше ведуться на вывод своих данных в облако, владеемое юр лицом другой страны. 2. Удешевление железа и в частности оперативки + увеличение объемов данных. Предпринимается много попыток перенести базы в кластера, в частности хадуп. И это действительно приводит к уменьшению потребности в ораклистах, но есть несаолько моментов. Как бало замечено, надо полностью осознавать, что ACID не поддерживается (хотя дяди, выделяющие бюджеты ведутся на маркетинговый буллщит типа limited ACID support от чего в итоге страдают все). И, второе, даже когда пришло осознание что всякие хадупы не вариант для OLTP, то даже для DWH/OLAP возникают серьезные проблемы с масштабируемостью по нагрузке (число одновременно запущенных запросов по простому), а во вторых недопустимая latency. Внезапно обраруживается, что типичное время отзыва не конкурирует с аналогичной логикой в Оракле. И тут приходит новый тренд - кластер но уже в памяти. Что-то в духе гибрида GridGain + Hadoop . Как бы там ни было это таки сжимает долю Оракла. 3. Отупение среднестатистического специалиста. Этот тренд скомбинирован с пунктом 2. В общем ситуация такая: снижаются издержки на человеческий ресурс и на дорогое ПО типа Оракла и вместо этого вбухивается в железо. Никто особо не пытается понимать как работает оптимизатор запросов (про такое понятие как query transformations знает вообще наверное менее 5%), мало кто умеет нормально анализировать куда уходит время и ресурсы при обработке данных. Вместо этого давайте пытаться перейти на кластер, использовать разнообразные кеши и прочее... мало у кого взлетает. Люди которые были не в состоянии delivery on mature software вдруг терпят крах на сырых технологиях - внезапно! Но тенденция есть и долю Оракла это тоже уменьшает. 4. Жадность Ларри и замедленная приспособляемость к реалиям. Важный архитектурный недостаток Оракла - остуствие columnar storage. Это достаточно критично для больших хранилищ. Всякие hybrid columnar compressionна на то и гибрид, что это не полноценный колоночный формат. Вроде бы многообещающе выглядит in-memory column store, но влетает в копеечку. И на волне общего хайпа касательно хадупа, клстеров и прочих in-memory caches мало кто рассматривает инвестицию в Oracle in-memory option. Доля рынка на крупных хранилищах уходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 14:50 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
WolverinesВ этом есть ценность человека - желание улучшать процессы в компании. В Cloud кто этим будет заниматься? Просто купим больше дисков, больше памяти, больше CPU.Может в каком-то "Рога и копыта" у админа болит душа как сэкономить на железе, особено если он друг владельца или директора или имеет на этом фоне хорошие премии, но во всяких крупных бизнесах, которые являются основными потребителями Оракла есть DBA team и есть application team. application team смотрит насколько эффективно приложение потребялет ресурсы и насколько отзывчиво к пользователю. При переходе в облако ничего особо не меняется, если есть доступ к oracle performance views. А вот DBA team в принципе исчезает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 15:30 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopWolverinesВ этом есть ценность человека - желание улучшать процессы в компании. В Cloud кто этим будет заниматься? Просто купим больше дисков, больше памяти, больше CPU.Может в каком-то "Рога и копыта" у админа болит душа как сэкономить на железе, особено если он друг владельца или директора или имеет на этом фоне хорошие премии, но во всяких крупных бизнесах, которые являются основными потребителями Оракла есть DBA team и есть application team. application team смотрит насколько эффективно приложение потребялет ресурсы и насколько отзывчиво к пользователю. При переходе в облако ничего особо не меняется, если есть доступ к oracle performance views. А вот DBA team в принципе исчезает. А application team почему выживает?)) Приложеньки еще проще вынести, сам разработчик сразу после тестов деплоит контейнеры в облако. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 17:25 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Wolverines, application team это те, кто пишет приложение. Появление искусственного интеллекта, транслирующего невнятные хотелки пользователей в конкретный код я в ближайшем будущем не предвижу. Если же речь про вынесение логики из базы, то это даже неохота обсуждать. Но как я отметил основных тренда два 1. уменьшается доля ДБА из-за облака и разнообразных атоматизаций. Это влияет только на ДБА. 2. уменьшается доля Оракла в целом как из-за нездорового хайпа касательно новых подходов так и по некоторым объективным причинам. Это влияет и на разрабов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 18:15 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopWolverines, application team это те, кто пишет приложение. Ок, думал, что application team это люди, которые поддерживают апликейшен сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 19:20 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Меня приводит в легкое изумление доверчивость бизнеса к облакам. Отдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Полагаю, в данном случае скорее это вопрос веры и маркетинга. Веры в cloud-провайдеров с просветленными лицами, привнесенной в бизнес мессиями от маркетинга. Как полагаете, какой процент топ-менеджмента сможет провести параллель между переданными в облака базами и историей с гуглодоками, осознать наличие параллелей и задуматься о вечном? ...впрочем, за любым увлечением очередной новомодностью следует неизбежный откат. Не думаю, что DBA как профессия неизбежно отомрет в ближайшие годы. В конце концов, тем же клаудам нужны высокопрофессиональные администраторы, а это достигается планомерной селекцией, для которой необходима широкая "кормовая база" (или "поголовье" - кому как удобнее) администраторов обыкновенных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2018, 20:29 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, жизненный цикл менеджмента обычно короче жизненного цикла компаний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 00:12 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Железный конь идет на смену крестьянской лошадке. (С) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 04:25 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
-2-казинакты походу кластер бд не отличаешь от кластера серверов приложений кластеру сервера приложений не надо consistency данных обеспечивать Ты путаешь социальную помойку с информационной системой. Если слетела подписка или странности с количеством лайков, всегда можно списать на руку Кремля или происки Госдепа. опять понос -2-Документация томката clustering how-to пишет про репликацию сессий и предостерегает от "тупо добавил" для больших систем. двоюшник, то б хоть раз по делу чо написал а то только понос один ну какой смысл чота с тобой обсуждать? репликация сессий, блин, прочитал словечко и думаешь уел? даж не буду объяснять просто, я сам конфигурил веблоджики в кластер и без кластера а ты только отдельные фразы из доки выдергиваешь -2-казинакв одну коллекцию тащим первую таблицу, в другую - вторую и объединяем коллекции ессно там наверняка фильтры будут, например, приходы/уходы за месяц да даже если не будут, объединяем и кэшируем, если надоМногие здесь проходили это "объединяем" в эпоху beforesql на прогрессивном dbase. Но потом объемы подросли, требования усложнились и вложенный цикл (нестед-луп) перестал покрывать все потребности. Потом захотелось не тупить, когда данные меняют более одного пользователя, потом прочий acid ... и dbase сдулся. это ты типа в историю нас посвятил)) проблема твоя и тебе подобных в том, что вы даже не понимаете что есть альтернативные решения, сотворили себе кумира из оракла и обсираете тех, кому в принципе насрать на оракл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 08:33 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousМеня приводит в легкое изумление доверчивость бизнеса к облакам. Отдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Полагаю, в данном случае скорее это вопрос веры и маркетинга. Веры в cloud-провайдеров с просветленными лицами, привнесенной в бизнес мессиями от маркетинга. Как полагаете, какой процент топ-менеджмента сможет провести параллель между переданными в облака базами и историей с гуглодоками, осознать наличие параллелей и задуматься о вечном? ...впрочем, за любым увлечением очередной новомодностью следует неизбежный откат. Не думаю, что DBA как профессия неизбежно отомрет в ближайшие годы. В конце концов, тем же клаудам нужны высокопрофессиональные администраторы, а это достигается планомерной селекцией, для которой необходима широкая "кормовая база" (или "поголовье" - кому как удобнее) администраторов обыкновенных.Точно, такие же мысли. Вот навернется Амазон из-за кассового разрыва, как Bear Sterns какой-нибудь или братья Леманы... И что будет с данными в AWS? Выключат нахрен и всё, а ещё лучше - продадут конкурентам чтобы, стало быть, покрыть убытки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 08:46 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
Почитал я 3 страницы. Захотелось вступить в дискуссию. Вроде бы лет 10 назад пытались убить SQL? Привело к тому, что в каждой компании "ушедшей" от SQL родился собственный уродец а-ля SQL. Для выборки, агрегирования и сортировки данных. Компании подумали и вернулись обратно к SQL. Возможно облака ждет та же участь. Большая часть бизнеса уйдет в облака. Условно какой-нибудь Вася Пупкин будет сотрудником Амазона, но закреплен будет за компанией "Рога и копыта", базы которой будет администрировать. Собственно тот же ДБА, работающий на компанию "Рога и копыта", только вид сбоку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 18:46 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousОтдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Это не сильно отличается от передачи всего и вся в аутсорсинг. Арендуется у кого-то датацентр или место в нём. Берётся в лизинг железо. Нанимается подрядчик следить за системами. Разработка отдаётся вендору или его партнёру. Если бизнес согласен на это, то почему бы уже в клауд всё не сгрузить, чтобы минимизировать количество подрядчиков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 19:07 |
|
||
|
Будущее Oracle DBA v 1.1
|
|||
|---|---|---|---|
|
#18+
master_yodaandrey_anonymousОтдать свои чувствительные данные под фактический чужой контроль - модель поведения, в чем-то созвучная девизу "слабоумие и отвага". Это не сильно отличается от передачи всего и вся в аутсорсинг. Арендуется у кого-то датацентр или место в нём. Берётся в лизинг железо. Нанимается подрядчик следить за системами. Разработка отдаётся вендору или его партнёру. Если бизнес согласен на это, то почему бы уже в клауд всё не сгрузить, чтобы минимизировать количество подрядчиков. Тогда уж приложение тоже в лизинг отдать, одно но Если сломается сетевой ms office - останется часть документов ( большинство в отправленных письмах) Если сломается безвозвратно база - компанию можно закрывать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2018, 20:30 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39670259&tid=1883723]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
85ms |
get tp. blocked users: |
2ms |
| others: | 221ms |
| total: | 397ms |

| 0 / 0 |
