"Ты ж компьютерщик!": 17 эпичных ситуаций из будней сисдамина (18 фото)

Млять! С клавой чего то не то

на первом офф.рабочем месте был такой Новелл.. .даже лицензия с огромной коробкой доков. Это был 97 год

97 - это наверное уже 4-й, насколько я помню.
В 93, 94 был 3.12
Хорошая была система, стабильная. Один раз поставил, настроил и все, пашет ыечно и без никаких глюков.
У меня правда была ситуация, в 95-м вроде. Иногда раз - и виснет. Но как?
Оказывается вирус был в загрузочном секторе ДОСовском

во времена ДОСа были шикарные вирусы. Один помню, на диске с бухрпрогами был... при выводе текста на матричник, анализировал вывод, и после запятых ставил слово 6LR (антимат) и еще одну запятую - итог шедеврален

Да, там главное было перехватить прерывание клавиатуры, таймера, вывода на принтер... в зависимости что тебе нужно, и... "И ДЕЛАЙ С НИМ ЧТО ХОШЬ"

всемизвестной? Газпром что ли?

ГПН-ЦР?)

Просто ты не работал в женском коллективе в госконторе. Там форсмажор каждый день. ВНЕЗАПНО ВДРУГ надо переселить отдел с 1-го на 3-й этаж, например. Ну и мебель перенести помочь, само собой. Твоя рубашка к обеду в грязную тряпочку превратится, а ты сам на лешего будешь похожь, пижон

Как раз в основном в женском и работаю. А вот если тебе не повезло работать разнорабочим и таскать мебель это далеко не показатель. И судить всех и все по единичному своему опыту как минимум не признак большого ума.

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

))))))))) Сервер подняли))

Доказательство того, что для того, чтобы поднять сервер не нужно быть админом и вообще разбираться в IT!

Поднять сервер - это легко!

- Алло! Это системный администратор? Что у нас с серверами?
- Они грузятся.
- А побыстрее нельзя?
- Можно. Сейчас подключу еще грузчиков

Лёг сервер с почтой. Директор админу: «Не к добру это, мыло уронить...»

Смотря где работаешь.
Админил одно НИИ с формой допуска только войти к ним - третья/вторая, те кто работал - первая. Там интернет даже с мобилок глушился;)

Так что да, там все проблемы нужно было уметь решать без гугла;)

Сисадмин, он как уборщица (никого не собирался обидеть), никто не видит, как он работает, но сразу становится заметно, если он работать перестал.

обычно так и есть.... на нынешней работе мы носимся как в опу раненые, ибо кроме текучки москвичи еще задач нарезают, поэтому никто не говорит, что не работаем, но ипут, что не успеваем)))) и был у меня еще один тип, который мне сразу сказал (это подработка была) - а давай ты все сделаешь у меня так, что я буду видеть тебя раз в месяц, когда радостно бабки тебе плачу, а остальное время все работало...... остальным не докажешь, что первое - когда что-то надо сделать, то звонят мне, а не начальству и истинный объем работы не видит никто, и второе - если админ сидит, то вы должны радоваться этому)))

таких приводов живых аж 2 точно есть... настервятничали перед списанием )))

Односкоростные еще поди?

А Вы точно понимаете, о чем пишите? А то у меня складывается впечатление, что не очень...

поколение пепси, что с них взять?
(сам такое не застал, сестра рассказывала)

ну материализованная вьюха - вещь действительно специфичная)
Но иногда работает, как серебрянная пуля - особенно на больших таблицах-фактах, которые пишутся редко но читаются часто (DWH), куда клиенты приходят, чтобы делать агрегаты показателей и группировки по атрибутам измерений

А кто спрашивал то про них и не понимал? Сиквельные разрабы или клиенты софта и потребители?

согласен что полезнаю штука, но надо знать когда и как её использовать

разные люди спрашивали... как клиенты, так и разработчики. в основном это уже было введено давно и никто не помнит кто это сделал и зачем

пример
archivelogs росли по не понятным причинам. выяснилось что это была MV,которая актуализировалась сотни раз в день просто так. её команда была select * from table, то есть тупо копировала всю таблицу.
сама команда работала быстро. долго длилось пока разрешили её переделать на обычную view.

а сделали её, потому что ктото когдато прочитал что это хорошая штука

ну да, горе-разрабы, блин - она же еще и обновляется там, под капотом, всякий раз, когда базовая таблица получает вставку/обновление - поэтому да, для "просто так" такие штуки не делаются

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

:)

Надо включить профилировщик, фильтр по событиям и пусть трассировка в реальном времени пишется в выходной файл. Потом вместе ее проанализировать и сказать - вот оно - узкое место - такой-то аккаунт, такое-то время, такой-то запрос, такой-то duration.
Потом посмотреть план выполнения этого запроса, который оптимизатор генерит
Profit

может, там куча некластерных индексов на таблице, когда-то их пачкой насоздавали, чтобы чтение пооптимизировать, а теперь таблица разрослась и движок вынужден при вставке строк их так же каскадно обновлять?

нене, там pl/sql. таблицы и индексы проходят без проблем

та уже по немногу решается проблема )

Тот самый момент, когда для СУБД общей концепции - подходы и методология Microsoft и Oracle разнятся :)

да там много различий

кстати напомнил случай когда я разработчиком был в T-SQL один главный по базам данным запрещал использовать View. я спросил почему... потому что опасно. грит один коллега напрограммровал бесконечный цикл (ссори за мой русский, если определение не правильное). и сразу повод запретить view

)))) ну это не от большого ума и ограниченности мышления)
View - отличный способ организовать внешний, витринный слой БД.
А если боится циклов (в детстве покусали) - то есть параметр MAXRECURSION

та просто код писать нормально. View это ж тоже просто команда, в ней то и проблема,а не сам факт использования View. конечно view на view может повлеч проблему за собой, но это разработчик должен видеть. execution plan никто не отменял

вместо этого он использовал процедуры. тоже не плохой подход. проги имели право обращаться только к процедурам. благо в T-SQL можно в конце процедуры напсиать select * ... и вуаля, DataSet готов

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

но это все уже не "тру"-подход, сейчас прибегут ребята со стильно-модно-молодежно - что хранимки, вьюхи, индексы - все это дикий легаси из 90х, и настоящие парни используют codefirst-подход, .net Core и MVC с ОРМ'ом - EntityFramework/NHibernate - чтобы для сущностей самогенерился датабазный уровень.
Да и вообще - все это в inMemory и колончатый базы или вообще граф всякий noSql

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

вот-вот :)
Главное, чтоб СУБД ACID выдерживал и грязные страницы фиксировал в персистент, а MVC само все могёт якобы :)

Правда, проектирование эффективного поиска и сканирования по многомиллиардным таблицам никто по-прежнему не отменял

если денег не жалко, то Partitioning в Oracle. или можно данные списать в архивную таблицу. более 90 % таких данных хранятся как правило на всякий случай или потому что предписано так, а работать с ними никто не собирается

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

Часто даже само по себе ТЗ это уже фантастика, обычно бизнес пожелания и не более, а вот сроки должны быть четкими и как можно меньше ...))

Это хорошо, когда только бизнес-пожелания, но зачастую по ГОСТ 34 - это все фиксируется только в документе БТ, а вот в ТЗ уже по полной функциональные и нефункиональные вещи. Про документ ТП вообще полчу, когда все забюрокрпатизированно)))) Чуть ли не цвет патч-кордов описывать надо, коими сервера в новом ИТ разворачиваемом решении будут