Что сделать чтобы пользователь не подвесил бд
Перейти к содержимому

Что сделать чтобы пользователь не подвесил бд

  • автор:

Что сделать чтобы пользователь не подвесил бд

Приветствую, коллеги!
Имеется база УТ 10.3.18.3 с небольшими косметическими дописками на сервере Win2008R2(все патчи, ибо лицензия), на движке SQL 2008R2 SP2 (тоже вроде все патчи), сервер 1С 32-битный, релиз 8.2.16.368, пользователи сидят в терминале. Железо сервера: Intel i7/16 Gb/RAID 1+SSD Kingston(на SSD лежит база SQL, на обычных система). Настройки сервера 1С по умолчанию, но создано два рабочих процесса. Одновременно в базе сидит не более 8 пользователей. Размер базы около 7 Гб (mdf), лог транзакций около 3 Гб (ldf). Тестирование и исправление делается раз в неделю.
Регулярно, несколько раз в день база начинает тормозить, окно 1С у клиентов становится белёсым, клиентские процессы 1С перестают реагировать на любые действия. Это продолжается несколько минут, и может привести к аварийному завершению процесса. В журнале приложений в этом случае остаётся запись ошибки типа:

Имя сбойного приложения: 1cv8.exe, версия: 8.2.16.368, отметка времени: 0x50536397
Имя сбойного модуля: unknown, версия: 0.0.0.0, отметка времени 0x00000000
Код исключения: 0xc0000005
Смещение ошибки: 0x8a7e5bbc
Идентификатор сбойного процесса: 0x14ec
Время запуска сбойного приложения: 0x01ce0d84622fdfab
Путь сбойного приложения: C:\Program Files (x86)\1cv82\8.2.16.368\bin\1cv8.exe
Путь сбойного модуля: unknown
Код отчета: 7f0c00b5-79a7-11e2-b859-50e54950ce42

Дамп также имеется, но как из него выудить информацию непонятно.

Как бороться с данной проблемой? Куда копать и что диагностировать? Количество пользователей невелико, база тоже небольшая. Уже не знаю, что и где ковырять, систему вылизал по максимуму, после перехода на SSD база явно стала быстрее работать (как бэ так и должно быть), но вот эти периодические тормоза не исчезли. Буду благодарен за любую информацию. Не исключаю возможности привлечения гуру администрирования за отдельную плату, удалённый доступ предоставлю.

Может, какие хитрые регламентные задания?

Платформу переставьте, «Имя сбойного приложения: 1cv8.exe» — не должно быть.
регл задания — тоже вариант, тип обновление индекса полнотекстового

(1) Все регламентные задания сугубо стандартные
(2) Перекинул время регламентных заданий на ночь, посмотрю на результат. Платформу переустановлю так же ближайшей ночью. Как её грамотно удалить и какой релиз лучше поставить — не дадите рекомендаций? Программная защита слетит(не хотелось бы ключики лишний раз использовать)?

(3) дак ставь 17-ю, програмная защита не слетает при обновлении. Не удаляй платформу, а именно обнови

для начала настрой регламент на скуле.

Laravel по-русски

Русское сообщество разработки на PHP-фреймворке Laravel.

  • Форум
  • » Laravel 4
  • » Авторизация с проверкой дополнительных полей.

Страницы 1

#1 24.06.2014 08:58:29

Дмитрий Сообщений: 79

Авторизация с проверкой дополнительных полей.

Здравствуйте. Пожалуйста, подскажите мне решение такого вопроса:
— Есть авторизация на сайте, написанном на Laravel. Работает нормально, но, мне нужно сделать проверку на «заблокирован ли пользователь». Т.е. в базе с пользователями есть поле «blocked» и если в нём содержится единица, то при авторизации вывести пользователю: «Ваш аккаунт блокирован».

Я знаю, можно сделать примерно так:

$data = [ 'email' => Input::get('email'), 'password' => Input::get('password'), 'blocked' => 0 ]; # Вход успешно произведён if(Auth::attempt($data)) return Redirect::intended();

И, если email и пароль совпадут и в поле «blocked» содержится ноль, то пользователь успешно будет авторизован. Если что-либо не совпадёт, то Auth::attempt() вернёт «false». В этом-то и проблема, ведь Auth::attempt() возвращает только true или только false, и невозможно определить, запись ли блокирована или логин и пароль не совпали.

Думал повесить эту проверку на событие auth.login или auth.attempt, но не знаю, насколько это правильно.
В общем, подскажите самый правильный путь решения проблемы, как лучше это проверять?
Большое всем спасибо!

Не в сети 28.02.2014

#2 24.06.2014 09:26:08

master

Proger_XP +345 Топ 30% Мастер Сообщений: 1,312 Статей: 33

Re: Авторизация с проверкой дополнительных полей.

Смысл проверки attempt() именно в том, чтобы вернуть true или false, поэтому если вам нужно узнать точную причину (неверный пароль, блокировка и т.п. ) — можно перед Auth::attempt() сначала найти этого пользователя в БД и проверить его на блокировку. То есть ещё до проверки пароля. Если нужно сделать это после — вызовите Auth::attempt(), если вход удался — проверьте на блокировку и в этом случае сразу сделайте Auth::logout().

Не вижу смысла изобретать какой-то особый велосипед.

Не в сети 08.04.2012

#3 24.06.2014 13:28:11

Agel_Nash +31 Сообщений: 18 Статей: 1 Сайт

Re: Авторизация с проверкой дополнительных полей.

А что мешает роуты прикрыть фильтром after с проверкой на блокировку? Авторизуем, но если пользователь заблокирован, то перекидываем на страницу «Вы заблокированы». К тому же, мультиаков так фиксировать можно через какую-нибудь неубиваемую куку.

На мой взгляд это лучше чем тупо ошибку вываливать еще на этапе авторизации.

Время, качество, цена — выбирай любые 2

Не в сети 05.01.2014

#4 25.06.2014 10:47:51

Дмитрий Сообщений: 79

Re: Авторизация с проверкой дополнительных полей.

Proger_XP, Agel_Nash, большое Вам спасибо за ответы. Ответ Proger_XP понятен предельно, а Agel_Nash, не могли бы Вы показать пример? Простите, если надоедаю

Не в сети 28.02.2014

#5 26.06.2014 07:35:16

Agel_Nash +31 Сообщений: 18 Статей: 1 Сайт

Re: Авторизация с проверкой дополнительных полей.

Route::group(array('before' => 'blocked'), function()< //Тут ваши маршруты Route::get/post/any/controller >); Route::filter('blocked', function()< if(Auth::user() && Auth::user()->blocked == 1) < App::abort(403); //Перекидываем на страницу доступ запрещен где написано что мол вы заблокированы >>);

Как-то так. Можно только на один маршрут login подвесить фильтрацию after и если пользователь заблокирован — то разавторизовывать его.

Изменено Agel_Nash (26.06.2014 07:39:19)

Время, качество, цена — выбирай любые 2

Не в сети 05.01.2014

#6 26.06.2014 09:53:49

Дмитрий Сообщений: 79

Re: Авторизация с проверкой дополнительных полей.

Agel_Nash, огромное Вам спасибо за ответ! Я задал вопрос, а потом дошло вроде, что нужно сделать так:

Можно только на один маршрут login подвесить фильтрацию after и если пользователь заблокирован — то разавторизовывать его.

Оказывается правильно мыслю .

Большое спасибо Вам обоим, Agel_Nash, Proger_XP ещё раз!

Форум пользователей MySQL

У меня есть БД, работая с которой, я посылаю запросы на выборку, изменение, и тому подобное. Ну, в общем, как обычно.
Мне тут сказал один человек: Ты бы, говорит, всю логику на СУБД повесил — и клиент бы тоньше стал, и изменять в одном месте только придется, если что!

Дык вот, «всю логику на СУБД повесить» — это как, это я должен насоздавать хранимых процедур для любых операций с базой.
Тогда я могу ваще закрыть доступ к таблицам, а нараздовать прав на хранимки. Таким образом, я могу управлять доступом не к данным, а к операциям с данными. идея мне понравилась

Хотелось бы это обсудить.
Целесообразно ли все операции с данными проводить через хранимки?
Есть ли какая-то возможность, структурировать хранимки?
Так ваще кто-нибудь делает? Или так делают все?

2администрация: что за ограничение на длину заголовка, хотел понятный заголовок написать — не влез.

#2 26.05.2007 19:26:23

rgbeast Администратор Откуда: Москва Зарегистрирован: 21.01.2007 Сообщений: 3877

Re: Хранимые процедуры

Так делают, но не все, естественно.

Причины так поступить:
1. доступ к базе из разных приложений — можно избежать дублирования кода
2. структура и количесвто таблиц меняется со временем
3. обеспечение унифицированного доступа из одного приложения к базам с разной структурой (и возможно не только MySQL)
4. требуется проверка входных, которая не может быть выполнена в триггере и требует дополнительных привелегий

Причины так не поступать:
1. таблицы достаточно простые и не меняются
2. доступ только из одного приложения к одной базе
3. доступ только для одного юзера
4. невозможность позволить себе дополнительное время выполнение на запуск процедуры

Ограничение Вы имеете в виду 70 символов в поле заголовка? Если не хватает, можно увеличить.

#3 26.05.2007 19:30:58

rgbeast Администратор Откуда: Москва Зарегистрирован: 21.01.2007 Сообщений: 3877

Re: Хранимые процедуры

iCode написал:

Есть ли какая-то возможность, структурировать хранимки?

Что Вы имеете в виду по структурированием? Хранимая процедура имеет имя и принадлежит базе данных. Она может вызывать другие хранимые процедуры.

#4 27.05.2007 13:59:25

rgbeast Администратор Откуда: Москва Зарегистрирован: 21.01.2007 Сообщений: 3877

Re: Хранимые процедуры

Подобный вопрос недавно на ЛОРе обсуждался (правда в специфичном ракурсе)

#5 27.05.2007 23:04:18

iCode Участник Зарегистрирован: 26.05.2007 Сообщений: 12

Re: Хранимые процедуры

rgbeast написал:

4. невозможность позволить себе дополнительное время выполнение на запуск процедуры

Не понял.
Какое дополнительное время? К чему дополнительное?

rgbeast написал:

Ограничение Вы имеете в виду 70 символов в поле заголовка? Если не хватает, можно увеличить.

Да, конечно я имел в виду 70 символов. Это мало по-моему. Мне по крайней мере не хватило, чтобы описать в заголовке тему.

rgbeast написал:

Что Вы имеете в виду по структурированием?

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

#6 28.05.2007 00:30:27

paulus Администратор Зарегистрирован: 22.01.2007 Сообщений: 6756

Re: Хранимые процедуры

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

ООП подразумевает наследование, инкапсуляцию и прочее. И его, разумеется
ни в каком виде тут нет: процедуры не наследуются, не принадлежат объектам.
Однако, Вы можете придумать какой-нибудь хитрый метод их структуризации,
т.к. они принадлежат базам.
Например, так:
1. Создаете пустую базу obj1
2. Создаете в ней процедуру a
3. Из «реальной» базы запускаете obj1.a

Выглядит как ООП
Хотя, если честно, по-моему это некоторое усложнение.

#7 28.05.2007 01:13:27

rgbeast Администратор Откуда: Москва Зарегистрирован: 21.01.2007 Сообщений: 3877

Re: Хранимые процедуры

Дополнительное время играет роль, если сами запросы выполняются быстро. Например, приложение выполняет много запросов типа select 2+2; В таком случае, если данный запрос включить в процедуру, время вызова процедуры будет сравнимо со временем выполнения запроса. Если же в процедуре выполняются сложные запросы или много запросов, то время вызова процедуры будет пренебрежимо мало.

Ходит байка, что Керниган или Ритчи сказал всем, что нужно использовать функции, где это только возможно, так как их вызов осуществляется очень быстро а языке C. Все поверили и стали использовать, а потом оказалось, что вызовы функций могут занимать до 50% времени выполнения программы. Но было уже поздно

Размер поля расширен до 100 символов.

#8 30.05.2007 01:40:28

Golova Завсегдатай Зарегистрирован: 23.03.2007 Сообщений: 92

Re: Хранимые процедуры

Не хотел начинать новую тему, коль уж разговор зашел о скорости выполнения.
Насколько быстр оператор(команда): USE db_name;
когда при выполнении запросов нужно обращаться к разным DB, так вот думаю сделать разные соединения или делать USE?

#9 30.05.2007 09:20:00

paulus Администратор Зарегистрирован: 22.01.2007 Сообщений: 6756

Re: Хранимые процедуры

Это замена строки в памяти. очень быстро.

Когда надо обращаться к разным БД, можно обойтись одним соединением
и не делать USE. Например, вот так:

Код:
SELECT t1.a, t2.b FROM db1.table1 t1 JOIN db2.table2 t2 ON t1.c = t2.d

Сервер всегда полностью расшифровывает названия таблиц:

Код:
root@localhost : (none) > use mysql Database changed root@localhost : mysql > explain extended select User from user; +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+ | 1 | SIMPLE | user | index | NULL | PRIMARY | 228 | NULL | 6 | Using index | +----+-------------+-------+-------+---------------+---------+---------+------+------+-------------+ 1 row in set, 1 warning (0,00 sec) Note (Code 1003): select `mysql`.`user`.`User` AS `User` from `mysql`.`user`

Обратите внимание на последний запрос — это то, что реально выполняется после
прохода парсера.

Быстро грохнуть много данных

Предположим, есть здоровенная БД. В этой бд есть около 10 таблиц, которые взаимосвязаны между собой. С этой БД работают службы и идут непрерывные вствки. В общем, вопрос: Как можно незаметно для пользователей, грохнуть из БД много данных за определенных период, что бы не подвесить клиентов, которые работают с БД? Есть ли какие-нибудь интересные способы, кроме удаления небольшими порциями?

Отслеживать
задан 17 окт 2017 в 18:10
24.8k 13 13 золотых знаков 67 67 серебряных знаков 165 165 бронзовых знаков

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

17 окт 2017 в 18:13

Если остается совсем немного данных, то есть смысл перегрузить их в другую базу, переключиться на нее, а файлы первой просто физически (на уровне ОС) удалить.

17 окт 2017 в 18:23

@avp всем хорош вариант, кроме одного, если данные пополняются постоянно, то может потеряться часть данных, которые были внесены последними. Придется брать технологическое окно для переключения, а это уже будет заметно пользователям, хотя если сервер не работает в режиме 24х7 и база небольшая, то пожалуй, лучший

17 окт 2017 в 20:40

@rdorn, согласен. Тут наверное нужен совет хорошего DBA, как можно использовать журнал, чтобы изменения, начиная с некоторого момента накапливались в нем, а потом этот журнал надо накатить на новую базу.

17 окт 2017 в 21:58

«интересные способы» да пожалуй, что и нет. Minimal logging для delete пока нет. Разве что truncate . with partition (начиная с SqlServer 2016), но для этого таблица должна быть секционирована и сняты FK-ограничения, ссылающиеся на неё. Снятие FK-ограничений требует Sch-M блокировки (монопольная) на parent и referenced таблицах. Впрочем, это metadata-only операция и она должна быть достаточно быстрой. Обратное включение FK-ограничений with nocheck — также metadata-only. Включение with check может занять время (возможно приемлемое, если бОльшая часть данных будет удалена).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *