msdb.dbo.sysjobactivity msdb.dbo.sysjobhistory msdb.dbo.sysjobs msdb.dbo.sysjobschedules msdb.dbo.sysjobservers msdb.dbo.sysjobsteps msdb.dbo.sysjobstepslogs а самого кода все никак не нахожу. Какого мудака надоумило убрать из манагера возможность редактировать код задания?!
Это похуй. Я к тому, что за * я бы лично увольнян нах. По крайней мере, если по строкам не режут и на продакшин oltp пасутся. Тут уже пох какая rdbms используется.
Наздоровье. Хотя, эта тулза полезна только для DB дизайна и администрирования. Девелопмент удобней из Студии вести.
Что-то не могу придумать конфигурации, в которой у Oracle такой запрос мог бы привести к проблемам. В продакшен. В oltp.
Речь не о конкретной таблице, как я понимаю, а вообще. Легким мановением руки создается временная копия чего-то неизвестного размера
В Oracle, если речь идет о таблицах, никаких копий нигде не создается. Сори. Наболело. Недавно столкнулся с MSSQL и был неприятно поражен как людям приходится извращаться с транзакциями и грязным чтением, чтобы избежать непонятных блокировок.
250 млн строк, в таблице. Клиент фетчит до EOT в память. А если, блядь, упоминать о тех уродах, которые с завидным постоянством на удаленном серваке начинают в отчеты кортезиан джойны всасывать, то вообще охуеть можно. А то, что ты придумать не можешь. Нууу... не удивлен. Да и ничему уже не удивляюсь...
1. такой - select * from dba_jobs; о каких млн строк речь? 2. 250 млн строк в память - либо у вас очень короткие строки, либы вы своим обезьянкам на рабочий стол 64x-разрядные платформы ставите? %) Но даже если клиент только фетчит, он просто немного загружает дисковую систему своим чтением. oltp, даже в продакшен, должна пережить. (надеюсь всем понятно, что речь идет не о разработке приложений, а о выполнении запроса администратором системы %)
Какая интересная теория То есть результатом SELECT является набор указателей на записи и поля в исходных таблицах? А теперь представим, что с теми же данными работают другие, мало того, они меняют их. И при очередном FETCH по этой теории первый пользователь должен получить изменившиеся значения, которые в общем случае уже не удовлетворяют начальному условию. Что-то мне подсказывает, что это далеко не так Значит, кого-то крупно наепали, и копии, таки, создаются Если же записи, попавшие в SELECT блокируются, и все изменения идут в лог, по которому лазят все последующие запросы, то стоит кому-то запустить UPDATE, таблицы начнут пухнуть в зависимости от объема UPDATE. Причем чередующиеся SELECT/UPDATE начнут умножать сущности до заполнения дискового пространства, если результаты SELECT'ов не будут вовремя освобождаться. Мало того, для организации базы таким макаром каждая запись должна иметь временной маркер с точностью до микросекунд, и каждая запись -- стек блокировок... Именно так и работает ORACLE?
1. Речь о том, что приучать себя надо сызмальства. Распиздяйство в промышленых масштабах ведет к гимору для всех. OLTP, это только как пример. Да и не пускают ебланов на нее, как правило. А тех кого пускают, те * не пишут, выгребают то, что конкретно нужно. 2. Закоруслость мышления не добавляет и грамма положительного. Если вяжут 5-10 таблиц, да еще и 3 подселектами, а одну по внешней ссылке, две из них - десятки миллионов, одна - две больше сотни лямов, при этом еще кейсят и все это в паралеле с 3-5 десятками других пользователей. Клиент возвращает 150000 тысяч строк, но на сервере квери может по глюку висеть до финиша и пузырить миллиарды строк кортезиана, а юзвери пищат, потом как хранилище в анусе... вот тогда и приходит понимания хлопка одной ладною. Конечно, если туда сюда пару гигов песочишь - да бля, хоть индксы не делай. И про фул-текстовые можно забыть. А вот когда локальная OLTP АБСки террабайты, центральной АБСки полтора десатка террабайт, а OLAP уже на десятки террабайт пошел, тут тоже, знаешь ли, несколько другие, отличные от твоих песочниц понятия.
Копии создаются не при селекте а при апдейте, и хранятся конечно не достаточно долго, чтобы те, кто начал селект, могли его окончить когда им вздумается. Select, длящийся более суток, мне кажется не очень правильным решением.