Где искать глюки?
Нужны эксперты с деструктивным мышлением
Необходимо после перевода некой работающей системы на MS SQL проверить ее (систему) на живучесть. Если кто может сказать- где прежде всего надо искать глюки после перевода на SQL, буду очень благодарен. Предвосхищаю возможные вопросы - Я - тестер. Меня интересуют потенциальные ошибки, а не особенности и фичи... Заранее огромное всем спасибо.
Необходимо после перевода некой работающей системы на MS SQL проверить ее (систему) на живучесть. Если кто может сказать- где прежде всего надо искать глюки после перевода на SQL, буду очень благодарен. Предвосхищаю возможные вопросы - Я - тестер. Меня интересуют потенциальные ошибки, а не особенности и фичи... Заранее огромное всем спасибо.
Ваш вопрос неконкретен. Если система раньше была на другой "большой" СУБД - это один разговор. Если на "настольной" Windows-СУБД -совершенно другой. Может это был вообще FoxPro работающий под MS-DOS.
Кроме того, важно на чем написана клиентская часть, и как она связана с базой (ODBC, BDE, ADO и т.д.)
Вы же понимаете, что есть специалисты пишущие на Delphi+MSSQL, на Access+MSSQL, на FoxPro+MSSQL, на ASP+MSSQL наконец и каждый из них Вам наговорит про глюки несколько страниц. Но кому же из них откликнуться?
Опять же, живучесть какого плана Вас интересует? Устойчивость против взлома? Тогда сразу отправляю вас читать бюллетени Майкрософт о найденных "дырках". Устойчивость самой СУБД? Так она вообще наверно непотопляема (правда спорить не возмусь) и если что не так, то виноват или администратор или разработчики клиента или железо маломощное.
Также укажите версию MSSQL
Кроме того, важно на чем написана клиентская часть, и как она связана с базой (ODBC, BDE, ADO и т.д.)
Вы же понимаете, что есть специалисты пишущие на Delphi+MSSQL, на Access+MSSQL, на FoxPro+MSSQL, на ASP+MSSQL наконец и каждый из них Вам наговорит про глюки несколько страниц. Но кому же из них откликнуться?
Опять же, живучесть какого плана Вас интересует? Устойчивость против взлома? Тогда сразу отправляю вас читать бюллетени Майкрософт о найденных "дырках". Устойчивость самой СУБД? Так она вообще наверно непотопляема (правда спорить не возмусь) и если что не так, то виноват или администратор или разработчики клиента или железо маломощное.
Также укажите версию MSSQL
Объясню поподробнее - а то действительно, что это я...
Приложение, работает процентов на 70-80 на Java.Основной смысл системы - некий документооборот, отчеты по документам, поиск документов, создание заданий по документам и т.д. и т.п. Базы данных - большие, серверные монстры (заточенные давно под систему, созданную нашей конторой)- количество объектов исчисляются тысячами... Меня интересуют в первую очередь узкие места - где база может споткнуться. Попробую привести немного бредовый,но пример(ничего особо толкового в голову не идет) если попытаться сохранить в базу какой-то объекто типа string, но содержащий некие зарезервированные системные символы (например кусок запроса или что-нибудь вроде (*) или (???)). Надеюсь я понятно излагаю... Возможно это какие-то глюки при изменении(добавлении) каких-то составляющих в уже хранимые объекты... Что-то подобное...
Приложение, работает процентов на 70-80 на Java.Основной смысл системы - некий документооборот, отчеты по документам, поиск документов, создание заданий по документам и т.д. и т.п. Базы данных - большие, серверные монстры (заточенные давно под систему, созданную нашей конторой)- количество объектов исчисляются тысячами... Меня интересуют в первую очередь узкие места - где база может споткнуться. Попробую привести немного бредовый,но пример(ничего особо толкового в голову не идет) если попытаться сохранить в базу какой-то объекто типа string, но содержащий некие зарезервированные системные символы (например кусок запроса или что-нибудь вроде (*) или (???)). Надеюсь я понятно излагаю... Возможно это какие-то глюки при изменении(добавлении) каких-то составляющих в уже хранимые объекты... Что-то подобное...
Проверьте ошибки в проектировании базы:
1) Проверка потребности в свойстве identity ключевого поля таблиц. Введите еще раз запись которая уже есть. Если даст ввести, попробуйте ее затем найти. Попробуйте её удалить.
2) Проверка правильности выбора collation сервера.
Задайте регистрозависимый поиск - например сравните поиск документа с именем "ПРИВЕТ" и "Привет". Задайте поиск документа по дате и сравните результаты при поиске с различных рабочих станций (подберите станции с разными версиями ОС, и особенно с разными локализациями - например Win2000 EN и Win98 RUS). Если клиентская часть системы работает через web-браузеры, попробуйте это обязательно.
3) Проверка правильности выбора типов блокировок. Посадите одного пользователя смотреть документ (режим просмотра). В этот момент попробуйте его удалить. Кроме того, посадите одного пользователя редактировать документ. Попробуйте его посмотреть, а затем удалить. Реакция системы должна соотвествовать требованиям поставленной задачи.
4) Проверка правильности выбора сетевых протоколов и настроек клиентских частей. Если у вас есть филиалы, имеющие свои ЛВС, но связанные с вами модемами, мостами, маршрутизаторами и т.д.
попробуйте установить клиентскую часть системы в этих филиалах и попробуйте достучаться до sql-сервера.
5) Оцените производительность сервера и системы. Нагрузите сервер одновременно 20-30 запросами на выборку данных (желательно с разных станций), причем результат выборки должен быть несколько сотен записей. Попробуйте, чтобы запросы работали с одной областью таблицы (т.е. со всех станций запустите одинаковые запросы) и попробуйте с разными областями таблиц (разные запросы). С помощью Profiler (утилита из комплекта MS SQL Server) оцените загрузку процессора и жесткого диска сервера. Если загрузка составит 3-5%, то это игрушки для вашего сервера, если процентов 60-70, то Вам стоит задуматься, особенно если пользователей будет больше чем 20-30 человек.
6) Оцените секьюрити системы. Сравните доступ к базе из вашей системы документооборота и из утилит Query Analyzer. Например, зайдя под логином пользователя имеющего права не на все таблицы, убедитесь, что ему видно из системы то же что и из QA. А пробовали заходить из системы под логином SA ? Не из утилит, а именно из системы документооборота? Разработчики часто чудят с раздачей привелегий и придумывают свои средства контроля, не всегда удачные.
1) Проверка потребности в свойстве identity ключевого поля таблиц. Введите еще раз запись которая уже есть. Если даст ввести, попробуйте ее затем найти. Попробуйте её удалить.
2) Проверка правильности выбора collation сервера.
Задайте регистрозависимый поиск - например сравните поиск документа с именем "ПРИВЕТ" и "Привет". Задайте поиск документа по дате и сравните результаты при поиске с различных рабочих станций (подберите станции с разными версиями ОС, и особенно с разными локализациями - например Win2000 EN и Win98 RUS). Если клиентская часть системы работает через web-браузеры, попробуйте это обязательно.
3) Проверка правильности выбора типов блокировок. Посадите одного пользователя смотреть документ (режим просмотра). В этот момент попробуйте его удалить. Кроме того, посадите одного пользователя редактировать документ. Попробуйте его посмотреть, а затем удалить. Реакция системы должна соотвествовать требованиям поставленной задачи.
4) Проверка правильности выбора сетевых протоколов и настроек клиентских частей. Если у вас есть филиалы, имеющие свои ЛВС, но связанные с вами модемами, мостами, маршрутизаторами и т.д.
попробуйте установить клиентскую часть системы в этих филиалах и попробуйте достучаться до sql-сервера.
5) Оцените производительность сервера и системы. Нагрузите сервер одновременно 20-30 запросами на выборку данных (желательно с разных станций), причем результат выборки должен быть несколько сотен записей. Попробуйте, чтобы запросы работали с одной областью таблицы (т.е. со всех станций запустите одинаковые запросы) и попробуйте с разными областями таблиц (разные запросы). С помощью Profiler (утилита из комплекта MS SQL Server) оцените загрузку процессора и жесткого диска сервера. Если загрузка составит 3-5%, то это игрушки для вашего сервера, если процентов 60-70, то Вам стоит задуматься, особенно если пользователей будет больше чем 20-30 человек.
6) Оцените секьюрити системы. Сравните доступ к базе из вашей системы документооборота и из утилит Query Analyzer. Например, зайдя под логином пользователя имеющего права не на все таблицы, убедитесь, что ему видно из системы то же что и из QA. А пробовали заходить из системы под логином SA ? Не из утилит, а именно из системы документооборота? Разработчики часто чудят с раздачей привелегий и придумывают свои средства контроля, не всегда удачные.
Проверьте ошибки в обслуживании базы:
1) Отработайте ситуацию, когда пользователь обнаружит, что две недели назад ошибочно удалил 400 документов. При этом после удаления введено еще 600 документов, которые потерять нельзя.
2) То же самое, но точная дата удаления неизвестна.
1) Отработайте ситуацию, когда пользователь обнаружит, что две недели назад ошибочно удалил 400 документов. При этом после удаления введено еще 600 документов, которые потерять нельзя.
2) То же самое, но точная дата удаления неизвестна.
Проверьте ошибки в обслуживании базы:
1) Отработайте ситуацию, когда пользователь обнаружит, что две недели назад ошибочно удалил 400 документов. При этом после удаления введено еще 600 документов, которые потерять нельзя.
2) То же самое, но точная дата удаления неизвестна.
1) Отработайте ситуацию, когда пользователь обнаружит, что две недели назад ошибочно удалил 400 документов. При этом после удаления введено еще 600 документов, которые потерять нельзя.
2) То же самое, но точная дата удаления неизвестна.