Да можно даже и не переносить в другие базы. В той же базе создать один или более tablespaces, датафайлы которых будут находится на более дешевых накопителях. И потом двигать партиции в эти tablespaces, это Оракл умеет с версии 11, а в 12 даже с опцией ONLINE (хотя для вас оно, наверное, не очень важно).
Мы так храним некоторые базы : небольшой объем read-write данных на быстрых и "родных" Exadata storage cells, а исторические данные - на более дешевых ZFS appliances. Легким движением руки данные еженедельно или ежемесячно переносятся с одного накопителя на другой : alter table ... move partition ... tablespace <ZFS>, всё автоматизировано.
Причем, иногда данные в этих партициях на ZFS приходится обновлять, ну, типа, клиент решил воспользоватся законом "right to be forgotten" и его имя / адрес / размер противогаза приходится вымарывать отовсюду, включая исторические данные. Тоже работает, пусть и не быстро - но в таких делах никто быстроты не ожидает, важна скорость работы с оперативными данными, а не с историческими.
А не проще будет двигать партиции на накопители, состоящие из дешевых не-SSD дисков, вместо того, чтобы платить за Advanced Compression лицензию и хранить сжатые партиции на тех же дорогих накопителях?
Ну ок, а тем у кого есть местное гражданство по рождению или натурализации - им чего бояться? Или гражданство другой страны ЕС (применимо, кстати, к ситуации NL <-> RO). У них ВНЖ не отберут. Однако ж их тоже особо не пущають. Из-за этого бывают конфликты. Вот у меня коллега проработал из дома в Порто 5 месяцев, а потом прислал емайл "извините, но с завтрашнего дня я у вас не работаю, лаптоп пришлю по почте, еще раз извините за столь короткий срок уведомления". И что? Какие кары ему могут грозить за неотработку 1 месяца, указанного в стандартном контракте? Не заплатят ему за этот неотработанный месяц - думаю, что он был готов к этому, увольняясь завтрашним днём.
Или как пример - у нас индусов отнесли в отдельную категорию пацаков : тем гражданам Индии, кто был нанят на работу в NL (т.е. является здесь резидентом), им можно работать из Индии максимум 15 дней. Почему не 5 месяцев как из ЕС, Китая, Арабских Эмиратов и еще ряда стран? Почему не 0 дней как из России? Документ на тему ограничений работы за рубежом длинный и местами довольно е#а... странный... Есть ощущение, что базовые тезисы этого документа (если не весь документ целиком) были спущены в большие организации из местного политбюро. Если завтра кого-то еще объявят врагом - то послезавтра эта страна начнет фигурировать в списке стран, откуда нельзя работать.
Мне кажется, что если Вася исправно платил все налоги в NL и ничего не платил в RO, то неважно сколько времени Вася провел в RO. Народ уезжает "на деревню к дедушке", не выписываясь с основной прописки в NL и исправно платя все налоги по месту этой самой основной прописки. Мне кажется, что никому не хочется разбираться в этой серой зоне и гораздо проще всё тупо запретить. На месте правителей ЕС я бы напрягся и родил какой-то нормативный документ на эту тему. Это пойдёт на пользу всей объединенной Европе и так тщательно декларируемому размытию границ внутри неё.
Про работу из Р - в прошлом году я работал оттуда три месяца, никаких проблем не было. Усиление паранойи до уровня кипения произошло буквально в последние два месяца.
Но я согласен, что это оффтоп (просто наболело, простите).
Советская травма у голландской компании? Ок, значит пора вводить санкции и за это.
Причем, моя компания, судя по отзывам многих знакомых, не единственная такая травмированная, это не её частная и единичная инциатива. Например, всем известный здесь booking.com тоже не разрешает работникам даже временно работать в стране, отличной от той, где ты официально трудоустроен. Народ, конечно, шкерится и работает. Но каждый понимает, что могут быть и последствия. А могут и не быть - на это все и надеются.
Вообще-то, моя компания кагбе разрешает до 5ти месяцев в году работать из других стран. Но:
1) Страна, из которой хочется временно поработать, должна входить в специальный одобренный список "кошерных" стран.
2) Надо сильно заранее подать заявку на такую работу и надеяться на одобрение, которое, кстати, не гарантировано.
3) России в этом "кошерном" списке разрешенных стран нет. Более того, есть документ, открытым текстом запрещающий любую работу из России - запрещено работать оттуда и даже просто, поехав туда в отпуск, запрещается брать с собой любые рабочие устройства. Если же ты по ошибке всё же приехал в Россию, например, с рабочим телефоном, то инструкцией предписано срочно выключить устройство и принести его в отдел IT, где оно будет немедлено уничтожено без включения. Хочу сказать, что не одной России так "повезло" - такие же правила IT-security распространяются еще на 2 страны: Северную Корею и Иран.
У нас компании вынуждены подчиняться анти-пандемийным распоряжениям правительства "работайте из дома как мождно больше", но всё еще требуют, чтобы работник был не то, что в стране головного офиса, но еще и в часе езды от головного офиса. Зачем? Объяснения один глупее другого, но требования остаются требованиями. С амальфитанского побережья не поработаешь, не говоря ж про Тайланд, Вьетнам и прочую экзотику.
Всё очень подробно расписано в одном из тикетов, созданном в VEEAM Support, не вижу смысла тащить сюда многостраничные выкладки.
Наверное, когда есть один хост с одной базой - то локальный коннект будет работать на ура. Но когда количество баз данных исчисляется тысячами, то backup стратегия отходит от локальных коннектов, дрейфуя в сторону централизованных скрипт-серверов, которые используют удаленные соединения к базам данных.
Да и просто бэкапить RAC базы с помощью локального коннекта - это очень так себе затея. Представьте, что у вас есть RAC бд с 8ю инстансами, запущенными на разных хостах одного Exadata кластера. Подключаясь к каждому инстансу локально, вы в итоге сбэкапите одну и ту же базу 8 раз. А если у вас сотни таких баз? Напрасная трата ресурсов и дискового пространства. А так - на одном из инстансов запущен сервис со специальным кодовым именем, к которому RMAN присоединяется, используя TNSNAMES. База бэкапится всего один раз, плюс есть необходимая гибкость в оперировании ресурсами бд, хоста и кластера - можно держать бэкап-сервис запущенным на наименее нагруженном инстансе/хосте и легко отключать/переносить его при возникающей необходимости.
Если эта часть дизайна не работает или работает лишь при определенных условиях, зачастую несовместимых с клиентской архитектурой или безопасностью - то это всё же баг, а не фича. Ну или недоделка, если это звучит лучше для вас.
Вернемся к разговору когда научитесь поддерживать соединения через TNS, что является стандартом для Оракловских соединений (локальные соединения "/" как раз являются частностью). Но очень слабо верится, что это получится, учитывая нынешнюю архитектуру Оракловского плагина.
Бэкап Оракловских баз с помощью RMAN + Veeam Plugin так и будет продолжать работать лишь при условии соединения к базе вида "target /" и будет падать при "target sys@<db_service>"? Мы так и не смогли победить этот баг с этой дополнительной, непонятной (и ненужной) callback сессией, которую Veeam Plugin пытается установить с Оракловской базой в процессе бэкапа. И Veeam Support не помог, разве что пытался убедить нас перестать использовать TNS-соединение и перейти на локальный коннект к базе. В итоге пришлось отказаться от Veeam.
Социализм — это когда ты можешь рвать на работе жопу и получить аж 120 рублей, а можешь ничего не делать и получить всего 120 рублей. Зависит от того какие 120 рублей тебе ближе по духу.
> Если все было, как вы говороите, то все только и делали бы, что покупали и продавали дома.
Этим в Нидерландах занимается довольно много народа. Особенно в последние годы, когда рынок летит вверх. Все надеются, что успеют продать дороже. Поэтому и принимали законы, повышающие налог при перепродаже меньше, чем через три (?) года.
В большой четверке городов (Амстердам, Роттердам, Гаага, Утрехт) и пригородах почти все дома правильные, кроме совсем уж плохих районов. Прирост был порядка 100% за 10 лет, что есть неплохо.
Эти затраты можно списать с налогов. Почти 50% (у КМов меньше) вернется на следующий год. Но правильно купленный и правильно проданный дом покроет все эти копейки без оглядки.
Я там служил в рядах СА, как раз еще в прошлом веке, еще при Горбачеве. Очень так себе была движуха, из серии «курица — не птица, Монголия — не заграница»
Эх, когда уже в Монголии начнут развивать программы для IT-мигрантов? А то она выбыла после первого круга, аж обидно… А так отличная страна — никто на нее не нападет (потому что нафиг это не нужно), места свободного навалом.
Неправда, отнюдь не логичное. Неумение правильно и грамотно выражать свои мысли заставляет сбиваться на такой вот суржик. Или использовать «бля» как соединитель для частей фразы. И от языка это несильно зависит. Думаю, что и в английском языке автор выражает мысли просто и кратко, используя по максимуму Present Simple и сложившиеся в коллективе языковые штампы.
У дочери в школе английский преподавал англичанин, еще и изучавший английскую литературу в Оксфорде. Я на школьные собрания ходил лишь для того, чтобы его послушать :) У него фразы были прям как у Маркеса — длиной в страницу-две. Заслушаться.
Не буду спорить, но я бы сделал так:
1. sqlloader с опцией direct в оракловскую таблицу без всяких индексов, всё в одну транзакцию — это будет очень быстро, мы максимально быстро загнали данные из файла в БД с огромными кэшами и улучшенной возможностью применения бизнес логики.
2. insert /*+ APPEND */ select * из временной оракловской таблицы в другую оракловскую таблицу (пустую или не очень), в которой уже есть индексы и всё прочее. Можно даже в таблицу с партициями, тогда можно будет доступ к данным еще подтюнить.
3. Если фильтрация не очень сложная — то на правильно индексированной таблице вы довольно быстро почистите данные от шелухи.
Везде должно быть быстро. У меня в одном проекте еще был шаг 0 — perl'овый скрипт делал первоначальную очистку файлов от шелухи. Вот уж кого нельзя обвинить в медленности дисковых операций.
Я сильно не слежу за судьбой букинга, но гугленье вывело на эту статью про его спасение.
Я даже не знаю кого считать индикатором в Нидерландах. Банки? Они очень сильно повязаны с государством, им не дадут упасть. Филипс? Тоже священная корова. Онлайн магазины? У них, наоборот, сейчас расцвет торговли, хотя post.nl их частенько подводит с доставкой, ссылаясь на коронавирус. Хороший индикатор тревоги — рынок недвижимости, но здесь он так перегрет, что народ еще по инерции будет хватать всё, что попало на рынок, не торгуясь.
Да можно даже и не переносить в другие базы. В той же базе создать один или более tablespaces, датафайлы которых будут находится на более дешевых накопителях. И потом двигать партиции в эти tablespaces, это Оракл умеет с версии 11, а в 12 даже с опцией ONLINE (хотя для вас оно, наверное, не очень важно).
Мы так храним некоторые базы : небольшой объем read-write данных на быстрых и "родных" Exadata storage cells, а исторические данные - на более дешевых ZFS appliances. Легким движением руки данные еженедельно или ежемесячно переносятся с одного накопителя на другой : alter table ... move partition ... tablespace <ZFS>, всё автоматизировано.
Причем, иногда данные в этих партициях на ZFS приходится обновлять, ну, типа, клиент решил воспользоватся законом "right to be forgotten" и его имя / адрес / размер противогаза приходится вымарывать отовсюду, включая исторические данные. Тоже работает, пусть и не быстро - но в таких делах никто быстроты не ожидает, важна скорость работы с оперативными данными, а не с историческими.
А не проще будет двигать партиции на накопители, состоящие из дешевых не-SSD дисков, вместо того, чтобы платить за Advanced Compression лицензию и хранить сжатые партиции на тех же дорогих накопителях?
Ну ок, а тем у кого есть местное гражданство по рождению или натурализации - им чего бояться? Или гражданство другой страны ЕС (применимо, кстати, к ситуации NL <-> RO). У них ВНЖ не отберут. Однако ж их тоже особо не пущають. Из-за этого бывают конфликты. Вот у меня коллега проработал из дома в Порто 5 месяцев, а потом прислал емайл "извините, но с завтрашнего дня я у вас не работаю, лаптоп пришлю по почте, еще раз извините за столь короткий срок уведомления". И что? Какие кары ему могут грозить за неотработку 1 месяца, указанного в стандартном контракте? Не заплатят ему за этот неотработанный месяц - думаю, что он был готов к этому, увольняясь завтрашним днём.
Или как пример - у нас индусов отнесли в отдельную категорию пацаков : тем гражданам Индии, кто был нанят на работу в NL (т.е. является здесь резидентом), им можно работать из Индии максимум 15 дней. Почему не 5 месяцев как из ЕС, Китая, Арабских Эмиратов и еще ряда стран? Почему не 0 дней как из России? Документ на тему ограничений работы за рубежом длинный и местами довольно
е#а...странный... Есть ощущение, что базовые тезисы этого документа (если не весь документ целиком) были спущены в большие организации из местного политбюро. Если завтра кого-то еще объявят врагом - то послезавтра эта страна начнет фигурировать в списке стран, откуда нельзя работать.Мне кажется, что если Вася исправно платил все налоги в NL и ничего не платил в RO, то неважно сколько времени Вася провел в RO. Народ уезжает "на деревню к дедушке", не выписываясь с основной прописки в NL и исправно платя все налоги по месту этой самой основной прописки. Мне кажется, что никому не хочется разбираться в этой серой зоне и гораздо проще всё тупо запретить. На месте правителей ЕС я бы напрягся и родил какой-то нормативный документ на эту тему. Это пойдёт на пользу всей объединенной Европе и так тщательно декларируемому размытию границ внутри неё.
Про работу из Р - в прошлом году я работал оттуда три месяца, никаких проблем не было. Усиление паранойи до уровня кипения произошло буквально в последние два месяца.
Но я согласен, что это оффтоп (просто наболело, простите).
Советская травма у голландской компании? Ок, значит пора вводить санкции и за это.
Причем, моя компания, судя по отзывам многих знакомых, не единственная такая травмированная, это не её частная и единичная инциатива. Например, всем известный здесь booking.com тоже не разрешает работникам даже временно работать в стране, отличной от той, где ты официально трудоустроен. Народ, конечно, шкерится и работает. Но каждый понимает, что могут быть и последствия. А могут и не быть - на это все и надеются.
Вообще-то, моя компания кагбе разрешает до 5ти месяцев в году работать из других стран. Но:
1) Страна, из которой хочется временно поработать, должна входить в специальный одобренный список "кошерных" стран.
2) Надо сильно заранее подать заявку на такую работу и надеяться на одобрение, которое, кстати, не гарантировано.
3) России в этом "кошерном" списке разрешенных стран нет. Более того, есть документ, открытым текстом запрещающий любую работу из России - запрещено работать оттуда и даже просто, поехав туда в отпуск, запрещается брать с собой любые рабочие устройства. Если же ты по ошибке всё же приехал в Россию, например, с рабочим телефоном, то инструкцией предписано срочно выключить устройство и принести его в отдел IT, где оно будет немедлено уничтожено без включения. Хочу сказать, что не одной России так "повезло" - такие же правила IT-security распространяются еще на 2 страны: Северную Корею и Иран.
Такие вот у нас реалии удаленной работы.
У нас компании вынуждены подчиняться анти-пандемийным распоряжениям правительства "работайте из дома как мождно больше", но всё еще требуют, чтобы работник был не то, что в стране головного офиса, но еще и в часе езды от головного офиса. Зачем? Объяснения один глупее другого, но требования остаются требованиями. С амальфитанского побережья не поработаешь, не говоря ж про Тайланд, Вьетнам и прочую экзотику.
Всё очень подробно расписано в одном из тикетов, созданном в VEEAM Support, не вижу смысла тащить сюда многостраничные выкладки.
Наверное, когда есть один хост с одной базой - то локальный коннект будет работать на ура. Но когда количество баз данных исчисляется тысячами, то backup стратегия отходит от локальных коннектов, дрейфуя в сторону централизованных скрипт-серверов, которые используют удаленные соединения к базам данных.
Да и просто бэкапить RAC базы с помощью локального коннекта - это очень так себе затея. Представьте, что у вас есть RAC бд с 8ю инстансами, запущенными на разных хостах одного Exadata кластера. Подключаясь к каждому инстансу локально, вы в итоге сбэкапите одну и ту же базу 8 раз. А если у вас сотни таких баз? Напрасная трата ресурсов и дискового пространства. А так - на одном из инстансов запущен сервис со специальным кодовым именем, к которому RMAN присоединяется, используя TNSNAMES. База бэкапится всего один раз, плюс есть необходимая гибкость в оперировании ресурсами бд, хоста и кластера - можно держать бэкап-сервис запущенным на наименее нагруженном инстансе/хосте и легко отключать/переносить его при возникающей необходимости.
Если эта часть дизайна не работает или работает лишь при определенных условиях, зачастую несовместимых с клиентской архитектурой или безопасностью - то это всё же баг, а не фича. Ну или недоделка, если это звучит лучше для вас.
Вернемся к разговору когда научитесь поддерживать соединения через TNS, что является стандартом для Оракловских соединений (локальные соединения "/" как раз являются частностью). Но очень слабо верится, что это получится, учитывая нынешнюю архитектуру Оракловского плагина.
Бэкап Оракловских баз с помощью RMAN + Veeam Plugin так и будет продолжать работать лишь при условии соединения к базе вида "target /" и будет падать при "target sys@<db_service>"? Мы так и не смогли победить этот баг с этой дополнительной, непонятной (и ненужной) callback сессией, которую Veeam Plugin пытается установить с Оракловской базой в процессе бэкапа. И Veeam Support не помог, разве что пытался убедить нас перестать использовать TNS-соединение и перейти на локальный коннект к базе. В итоге пришлось отказаться от Veeam.
Эх, а я бы с удовольствием уехал жить куда-нибудь в Лечче или еще глубже в Саленто, на какое-нибудь из побережий. Только где я там работать буду?
Этим в Нидерландах занимается довольно много народа. Особенно в последние годы, когда рынок летит вверх. Все надеются, что успеют продать дороже. Поэтому и принимали законы, повышающие налог при перепродаже меньше, чем через три (?) года.
В большой четверке городов (Амстердам, Роттердам, Гаага, Утрехт) и пригородах почти все дома правильные, кроме совсем уж плохих районов. Прирост был порядка 100% за 10 лет, что есть неплохо.
Эх, когда уже в Монголии начнут развивать программы для IT-мигрантов? А то она выбыла после первого круга, аж обидно… А так отличная страна — никто на нее не нападет (потому что нафиг это не нужно), места свободного навалом.
У дочери в школе английский преподавал англичанин, еще и изучавший английскую литературу в Оксфорде. Я на школьные собрания ходил лишь для того, чтобы его послушать :) У него фразы были прям как у Маркеса — длиной в страницу-две. Заслушаться.
бысделал так:1. sqlloader с опцией direct в оракловскую таблицу без всяких индексов, всё в одну транзакцию — это будет очень быстро, мы максимально быстро загнали данные из файла в БД с огромными кэшами и улучшенной возможностью применения бизнес логики.
2. insert /*+ APPEND */ select * из временной оракловской таблицы в другую оракловскую таблицу (пустую или не очень), в которой уже есть индексы и всё прочее. Можно даже в таблицу с партициями, тогда можно будет доступ к данным еще подтюнить.
3. Если фильтрация не очень сложная — то на правильно индексированной таблице вы довольно быстро почистите данные от шелухи.
Везде должно быть быстро. У меня в одном проекте еще был шаг 0 — perl'овый скрипт делал первоначальную очистку файлов от шелухи. Вот уж кого нельзя обвинить в медленности дисковых операций.
Я даже не знаю кого считать индикатором в Нидерландах. Банки? Они очень сильно повязаны с государством, им не дадут упасть. Филипс? Тоже священная корова. Онлайн магазины? У них, наоборот, сейчас расцвет торговли, хотя post.nl их частенько подводит с доставкой, ссылаясь на коронавирус. Хороший индикатор тревоги — рынок недвижимости, но здесь он так перегрет, что народ еще по инерции будет хватать всё, что попало на рынок, не торгуясь.