Красиво, но не жизненно. Или мне редко встречались команды готовые встать и идти к техдиру. Скорее всего каждый будет решать проблему сам за себя. И если менеджер бросится грудью на амбразуру, то не факт что вся команда последует за ним. И всех жёны и дети. И кушать ещё никто не отменял.
1. Если вина 90-100% менеджера, то взять вину на себя и договориться с техническим, что команда будет не в курсе угрозы увольнения. Ну или скрыть это от команды.
2. Если технический хочет крови, то договориться что он её получит уже сейчас и дальше продолжать спокойно работать.
изменения в составе реализуемых требований и недооценка сроков на реализацию изменений
А как такой вариант?
Менеджер прогнулся под требования заказчика и получился фэйл. CTO устраивает этот менеджер, но решил дополнительно его промотивировать а заодно и всю команду (забыл что когда-то читал Де Марко :))
Заказчик опять меняет требования и тут уже 100% либо фэйл, либо отказать заказчику. Заказчик на прямом контакте с CEO.
Менеджеру сразу уволиться или героически работать всей командой по выходным?
Я писал немного о другом.
В моей практике бывали случаи когда нужно было кого-то уволить по сокращению. Естественно команда никогда меня не упрекала и понимала что это не моя идея. Но за двумя уволенными уходили ещё два, которые просто решили перестраховаться. В принципе их всё устраивало в нашей компании, но у них исчезала уверенность что в компании всё и дальше будет хорошо.
Так и здесь, программист может думать: «Срок провалили — это плохо. Но почему сразу не уволили? Наверное нам что-то не договаривают. Обновлю я пожалуй резюме».
Плохо в том, что технический не требовал кого-то срочно увольнять.
Т.е. в его глазах вы или сплоховали или нужно обставить этот шаг, что я мол разобрался в причинах наших неудач.
Но в глазах команды этот шаг может выглядеть как выбор жертвы и нужно предпринять шаги чтобы не ушли действительно ценные сотрудники.
допустили переход команды из стадии производства в стадию формирования
Пока она будет формироваться, неизбежен провал в производительности. А это дополнительные риски.
Недостаток в том, что не понятна причина.
А причина, например, в том, что Ген. директор компании рассчитывает на еще один проект от заказчика, но его планы не сбываются. Тех. директор рискует своим местом и вызывает на ковёр менеджера. Т.е. чтобы решилась проблема, нужно получить новый проект от заказчика.
Вариант 1: PM с командой уложились в итерацию. Заказчик стал доволен и заключил новый контракт. Как вы думаете чья заслуга в привлечении нового контракта перед Ген. директором будет выше технического или PM?
+ Т.е. в лучшем случае вы не заработаете очки в лице Ген. директора и тех. директора.
— потеряли несколько человек в команде
— допустили переход команды из стадии производства в стадию формирования, и хорошо если миновали стадию конфликтов
Вариант 2: РМ провалил итерацию. Что бы вы сделали на месте технического?
Интересный кейс. Но по моему учтены не все составляющие.
Обычный сферический менеджер слуга 3-х господ (бизнес, команда, авторитет).
Но в данном кейсе два менеджера: PM и технический директор.
Технический директор выбрал стратегию перекоса под бизнес с риском потерять команду, т.е. PM.
Шаг 0:
Выяснить с техническим, почему он выбрал этот путь?
Возможно что именно его шаги по задабриванию заказчика способствовали провалу итераций.
Если технический твердо решил пожертвовать командой, тогда какой смысл идти против течения?
Руководство готово на этот шаг. PM получается пойдет против своего начальника и не факт, что его поймут другие PM.
Да, они сделают работу в срок. Команда останется, но PM c вероятностью 90% лишится работы.
Для IOT используется UROWID (логический ROWID). Ключевое отличие в том, что вторичный индекс по IOT просто нет смысла делать asktom.oracle.com/pls/asktom/f?p=100:11:0%3A%3A%3A%3AP11_QUESTION_ID:3187583300346869958
По п.3 потому что, если Вам понадобится сделать обычный индекс, например, по полю status, то его размер будет очень не оптимальный т.к. на каждую запись в индексе придется хранить [Publication_ID]+[name]+status. А стремиться надо к меньшим размерам, только тогда будет минимум дисковых чтений и больше производительность.
IOT не абсолютно аналогичная конструкция, но во многом схожая. Почитайте Тома Кайта да и в инете много информации об этом. Смысл аналогии к ORACLE был не в том чтобы сравнивать продукты. А показать ключ к пониманию.
Тема кластерного индекса уже много раз обсуждалась в просторах инета, что смысла разводить здесь треп нет никакого.
По пункту 3 — не дай Вам Бог делать составной кластерный индекс. А вот кластерный индекс по первичному ключу в 99% дает выигрыш. Это подтверждает и мой опыт и best practice Microsoft.
Ох, что-то у вас и правда каша какая-то с середины статьи пошла :)
В ORACLE есть ROWID — единственный способ найти строку таблицы.
В SQL Server таких способа два.
1. поиск по RID (8 байт)
2. поиск по ключу кластеризованного индекса (для простоты будем считать его уникальным и типа int — 4 байта)
В итоге у нас экономия 4 байта на каждой строке + 4 байта для каждой строки каждого индекса по таблице.
Дальше, как вы заметили, мы получаем отсортированную таблицу.
Пример: select id,name from sample_table where id between 1 and 100
а) таблица имеет кластерный индекс по полю id
план — Clustered Index Seek
b) таблица имеет уникальный некластерный индекс по полю id
план- Index Seek + RID Lookup
Ну и напоследок, все что описано выше сильно упрощено.
Например, считываются не просто страницы, а блоки страниц. Кроме того SQL Server использует упреждающее чтение. Ну и еще кучу всего в чем ему могут сильно помочь кластерные индексы.
Насколько восстановленные данные получились актуальными?
Допустим у нас есть две таблицы FioTable (ID, FIO) и EMailTable(ID, ID_FIO, Email). Связь один ко многим.
Ваша утилита восстановит все данные из таблицы EMailTable, но не восстановит часть данных из FioTable.
Какой прок от данных в EMailTable в таком случае?
Извините не удержался, но выглядит это как разговор двух приятелей:
— Мерседес гуано, вчера движок стуканул. Буду покупать астон мартин.
— Так тыж наверное масло в двигателе забыл поменять?
— А что его еще и менять надо?
Была база в 1TB. Microsoft умудрились за 36 минут 2TB забекапить причем в территориально отдаленный датацентр. sqlcat.com/sqlcat/b/whitepapers/archive/2009/08/13/a-technical-case-study-fast-and-reliable-backup-and-restore-of-a-vldb-over-the-network.aspx
Но это не имеет никакого отношения к стратегии резервного копирования.
Потому что стратегия не всегда подразумевае подъем базы из полного бэкапа, но ВСЕГДА предусматривает различные ситуации выхода БД из строя и восстановления работоспособности оной в кратчайшие сроки.
Т.е. вы должны были смоделировать и предусмотреть подобные ситуации. При этом у вас должны быть четкие инструкции, что делать по шагам, а не судорожно метаться в поисках решения проблемы.
Судя по вашим объяснениям у вас произошел форс-мажор сродни ядерному взрыву в датацентре.
Согласен, что статья — это сплошное попоприкрывательство
>> Наймите, наконец, нормальных администраторов!
>> Администраторы в Сбербанке хорошие. Но они, увы, не волшебники.
У вас даже стратегии резервного копирования нет. 3 часа поднимать базу — это извините что-то :( и то с помошью техподдержи Oracle.
> — Но почему же в других банках ничего не падает!
> Во-первых, в других банках вместе взятых карт почти столько же, сколько в одном Сбербанке.
Это в каких банках Goldman Sachs, HBSC, Santander Consumer? Когда у них последний раз процессинг ложился?
ДА и вообще отмазка ниже плинтуса, мол не ходите к нам клиента наш процессинг не справляется у нас слишком много карт.
SQL Server хранит файлы как объекты BLOB.
Есть два варианта хранения BLOB: стандартно в таблицах или в объектах FILESTREAM.
Данные объектов FILESTREAM это файл в определенном каталоге файловой системы.
Размеры объектов FILESTREAM ограничены только размером тома файловой системы.
Стандартное ограничение типа varbinary(max), согласно которому размер файла не должен превышать 2 ГБ, не применяется к объектам BLOB, сохраняемым в файловой системе.
В SQL Server Express предусмотрена поддержка FILESTREAM. Ограничение размера базы данных в 10 ГБ не включает контейнер данных FILESTREAM.
Отличная идея - повысить посещаемость сайта, добавив на сайте несколько утилит на основе искусственного интеллекта.
2. Если технический хочет крови, то договориться что он её получит уже сейчас и дальше продолжать спокойно работать.
А как такой вариант?
Менеджер прогнулся под требования заказчика и получился фэйл. CTO устраивает этот менеджер, но решил дополнительно его промотивировать а заодно и всю команду (забыл что когда-то читал Де Марко :))
Заказчик опять меняет требования и тут уже 100% либо фэйл, либо отказать заказчику. Заказчик на прямом контакте с CEO.
Менеджеру сразу уволиться или героически работать всей командой по выходным?
В моей практике бывали случаи когда нужно было кого-то уволить по сокращению. Естественно команда никогда меня не упрекала и понимала что это не моя идея. Но за двумя уволенными уходили ещё два, которые просто решили перестраховаться. В принципе их всё устраивало в нашей компании, но у них исчезала уверенность что в компании всё и дальше будет хорошо.
Так и здесь, программист может думать: «Срок провалили — это плохо. Но почему сразу не уволили? Наверное нам что-то не договаривают. Обновлю я пожалуй резюме».
Плохо в том, что технический не требовал кого-то срочно увольнять.
Т.е. в его глазах вы или сплоховали или нужно обставить этот шаг, что я мол разобрался в причинах наших неудач.
Но в глазах команды этот шаг может выглядеть как выбор жертвы и нужно предпринять шаги чтобы не ушли действительно ценные сотрудники.
Пока она будет формироваться, неизбежен провал в производительности. А это дополнительные риски.
А причина, например, в том, что Ген. директор компании рассчитывает на еще один проект от заказчика, но его планы не сбываются. Тех. директор рискует своим местом и вызывает на ковёр менеджера. Т.е. чтобы решилась проблема, нужно получить новый проект от заказчика.
Вариант 1: PM с командой уложились в итерацию. Заказчик стал доволен и заключил новый контракт. Как вы думаете чья заслуга в привлечении нового контракта перед Ген. директором будет выше технического или PM?
+ Т.е. в лучшем случае вы не заработаете очки в лице Ген. директора и тех. директора.
— потеряли несколько человек в команде
— допустили переход команды из стадии производства в стадию формирования, и хорошо если миновали стадию конфликтов
Вариант 2: РМ провалил итерацию. Что бы вы сделали на месте технического?
Обычный сферический менеджер слуга 3-х господ (бизнес, команда, авторитет).
Но в данном кейсе два менеджера: PM и технический директор.
Технический директор выбрал стратегию перекоса под бизнес с риском потерять команду, т.е. PM.
Шаг 0:
Выяснить с техническим, почему он выбрал этот путь?
Возможно что именно его шаги по задабриванию заказчика способствовали провалу итераций.
Если технический твердо решил пожертвовать командой, тогда какой смысл идти против течения?
Руководство готово на этот шаг. PM получается пойдет против своего начальника и не факт, что его поймут другие PM.
Да, они сделают работу в срок. Команда останется, но PM c вероятностью 90% лишится работы.
По п.3 потому что, если Вам понадобится сделать обычный индекс, например, по полю status, то его размер будет очень не оптимальный т.к. на каждую запись в индексе придется хранить [Publication_ID]+[name]+status. А стремиться надо к меньшим размерам, только тогда будет минимум дисковых чтений и больше производительность.
Тема кластерного индекса уже много раз обсуждалась в просторах инета, что смысла разводить здесь треп нет никакого.
По пункту 3 — не дай Вам Бог делать составной кластерный индекс. А вот кластерный индекс по первичному ключу в 99% дает выигрыш. Это подтверждает и мой опыт и best practice Microsoft.
В ORACLE есть ROWID — единственный способ найти строку таблицы.
В SQL Server таких способа два.
1. поиск по RID (8 байт)
2. поиск по ключу кластеризованного индекса (для простоты будем считать его уникальным и типа int — 4 байта)
В итоге у нас экономия 4 байта на каждой строке + 4 байта для каждой строки каждого индекса по таблице.
Дальше, как вы заметили, мы получаем отсортированную таблицу.
Пример: select id,name from sample_table where id between 1 and 100
а) таблица имеет кластерный индекс по полю id
план — Clustered Index Seek
b) таблица имеет уникальный некластерный индекс по полю id
план- Index Seek + RID Lookup
Ну и напоследок, все что описано выше сильно упрощено.
Например, считываются не просто страницы, а блоки страниц. Кроме того SQL Server использует упреждающее чтение. Ну и еще кучу всего в чем ему могут сильно помочь кластерные индексы.
Допустим у нас есть две таблицы FioTable (ID, FIO) и EMailTable(ID, ID_FIO, Email). Связь один ко многим.
Ваша утилита восстановит все данные из таблицы EMailTable, но не восстановит часть данных из FioTable.
Какой прок от данных в EMailTable в таком случае?
— Мерседес гуано, вчера движок стуканул. Буду покупать астон мартин.
— Так тыж наверное масло в двигателе забыл поменять?
— А что его еще и менять надо?
Но это не имеет никакого отношения к стратегии резервного копирования.
Потому что стратегия не всегда подразумевае подъем базы из полного бэкапа, но ВСЕГДА предусматривает различные ситуации выхода БД из строя и восстановления работоспособности оной в кратчайшие сроки.
Т.е. вы должны были смоделировать и предусмотреть подобные ситуации. При этом у вас должны быть четкие инструкции, что делать по шагам, а не судорожно метаться в поисках решения проблемы.
Судя по вашим объяснениям у вас произошел форс-мажор сродни ядерному взрыву в датацентре.
>> Наймите, наконец, нормальных администраторов!
>> Администраторы в Сбербанке хорошие. Но они, увы, не волшебники.
У вас даже стратегии резервного копирования нет. 3 часа поднимать базу — это извините что-то :( и то с помошью техподдержи Oracle.
> — Но почему же в других банках ничего не падает!
> Во-первых, в других банках вместе взятых карт почти столько же, сколько в одном Сбербанке.
Это в каких банках Goldman Sachs, HBSC, Santander Consumer? Когда у них последний раз процессинг ложился?
ДА и вообще отмазка ниже плинтуса, мол не ходите к нам клиента наш процессинг не справляется у нас слишком много карт.
Миф #2: Один язык лучше другого, а лопата лучше молотка.
Есть два варианта хранения BLOB: стандартно в таблицах или в объектах FILESTREAM.
Данные объектов FILESTREAM это файл в определенном каталоге файловой системы.
Размеры объектов FILESTREAM ограничены только размером тома файловой системы.
Стандартное ограничение типа varbinary(max), согласно которому размер файла не должен превышать 2 ГБ, не применяется к объектам BLOB, сохраняемым в файловой системе.
В SQL Server Express предусмотрена поддержка FILESTREAM. Ограничение размера базы данных в 10 ГБ не включает контейнер данных FILESTREAM.