SQL 2005 Jobs

Кто подскажет, где находится сам файл? Заебала смена интерфейса.

Где найти MaximumErrorCount?

 

select * from dba_jobs;

 

Мля, хотя бы TOP 100 написал... :-/

 

При чем тут Оракл? В MSSQL 2005 такой таблицы, view или синонима нет.

 

Он прикалывается, а мне ответ нужен. По ";" уже все понятно.

 

msdb.dbo.sysjobactivity
msdb.dbo.sysjobhistory
msdb.dbo.sysjobs
msdb.dbo.sysjobschedules
msdb.dbo.sysjobservers
msdb.dbo.sysjobsteps
msdb.dbo.sysjobstepslogs

а самого кода все никак не нахожу. Какого мудака надоумило убрать из манагера возможность редактировать код задания?!

 

Попробуй поставить SQL Maestro для MSSQL... Может в нем есть эта фича.

 

Спасибо огромное, работает, сцобака

 

Это похуй. Я к тому, что за * я бы лично увольнян нах. По крайней мере, если по строкам не режут и на продакшин 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 уже на десятки террабайт пошел, тут тоже, знаешь ли, несколько другие, отличные от твоих песочниц понятия.

 

Это зависит от Isolation level поднятой сессии. И понятия определения - наебали.

 

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