Подозреваю, что хочу немного странного, но всё же...
Известно, что одни СУБД позволяют сразу при создании БД задать ограничения размера, другие сами сломаются при достижении некоторых лимитов или когда места не останется.
"Большие" СУБД имеют свои средства мониторинга, а нет ли какой-нибудь более-менее универсальной библиотеки, грубо говоря уровня QtSQL, позволяющей приближенно оценить состояние БД? Не любой БД, конечно, но чтоб понимала распространенные MySQL, Postgress, MS SQL Server, ODBC вообще, если это возможно. Запредельная точность не нужна, хватит на уровне "5-10-20% такого же, что было раньше, еще сохранить можно/возможно/ну уж никак не выйдет"
Здравствуйте, BigBoss, Вы писали:
BB> Подозреваю, что хочу немного странного, но всё же...
Очень странного. Я так понимаю, задача из головы, не реальная.
BB> "5-10-20% такого же, что было раньше, еще сохранить можно/возможно/ну уж никак не выйдет"
Здравствуйте, wildwind, Вы писали:
W>Очень странного. Я так понимаю, задача из головы, не реальная.
Совсем наоборот. Есть БД, в неё пишут и пишут. Рано или поздно допишутся до какого-нибудь лимита и всё сломается. Хочется узнать об этом заранее, законное желание
BB>> "5-10-20% такого же, что было раньше, еще сохранить можно/возможно/ну уж никак не выйдет"
W>Что это за бред? От чего проценты?
Если что-то непонятно -- это не обязательно бред, может просто не дошло
Простой пример: есть MS SQL база с лимитом 10Gb. sp_spaseused говорит, что 8Gb уже занято. Я уже должен беспокоиться, если объем хранимых данных предположительно вырастет на 5%? А если он удвоится?
On 20.10.2015 17:13, BigBoss wrote: > Потому и спрашиваю > Понятно, что соответствующие запросы > нагугливаются легко. Но вдруг кто-нибудь собрал их все уже, выложил на > github да еще и обновляет, когда новые версии выходят... А я тут > велосипед выдумываю
Эта задача решается мониторинговыми системами вроде munin/zabbix/etc. А
написание плагинов для конкретных БД к ним и установка алертов (типа 80%
заполнения — warning, 90 — error и т.п.) — это уже делается/гуглится под
конкретную БД.
Задача поддержать "все БД из коробки" не стоит, ибо это никому не нужно
— там, где стоит беспокоиться о содержимом БД, как правило их
ограниченное количество и типов и версий.
Здравствуйте, BigBoss, Вы писали:
BB> W>Что это за бред? От чего проценты?
BB> Если что-то непонятно -- это не обязательно бред, может просто не дошло
Пока не дошло, выглядит бредом.
BB> Простой пример: есть MS SQL база с лимитом 10Gb. sp_spaseused говорит, что 8Gb уже занято. Я уже должен беспокоиться, если объем хранимых данных предположительно вырастет на 5%? А если он удвоится?
Значит процент от текущего объема данных. OK, хотя это тоже туманно, sp_spaseused не одну цифру возвращает. Но sp_spaseused не сообщает ничего о лимитах и о том, насколько текущий объем к нему близок. Как считать дальше?
[оффтопик]
Кроме того, бредомнепонятной выглядит задача в целом. Свести все нюансы управления физическим пространством БД к одной цифре — для чего? Куда эта цифра будет выведена и для кого? Очевидно, потребитель этой цифры человек нетехнический, явно не DBA. Кто он?
Здравствуйте, BigBoss, Вы писали:
BB> Но вдруг кто-нибудь собрал их все уже, выложил на github да еще и обновляет, когда новые версии выходят... А я тут велосипед выдумываю
Нет, никто этим не занимается. Будь первым. Но я уверен, и ты не будешь. Там столько нюансов и различий, что ты или бросишь, или все выродится в поддержку единственной СУБД.
Здравствуйте, BigBoss, Вы писали:
BB>Простой пример: есть MS SQL база с лимитом 10Gb. sp_spaseused говорит, что 8Gb уже занято. Я уже должен беспокоиться, если объем хранимых данных предположительно вырастет на 5%? А если он удвоится?
На оба вопроса нет. Потому что такими штуками положено заниматься дбадмину. У которого вопросов "а как это сделать?" не должно быть по определению.
Другими словами: если ваш админ не сподобился прикрутить нужные perfcounters в zabbix/system center, то "внезапно закончился ms sql" — меньшая из ваших возможных проблем.
Здравствуйте, BigBoss, Вы писали:
BB>Подозреваю, что хочу немного странного, но всё же...
Надеюсь, задача перед тобой стоит не техническая.
Берешь каждую табличку, смотришь сколько там записей, сколько записей может быть максимально. все эти данные усредняешь по всем табличкам всех БД в целом.
Например если под индекс выделено SMALLINT(unsigned) а записей уже 42934 и каждый месяц прибавляется по 8000, то определенно пора уже подумать о покупке нового сервера.
Здравствуйте, Stanislaw K, Вы писали:
SK>Например если под индекс выделено SMALLINT(unsigned) а записей уже 42934 и каждый месяц прибавляется по 8000, то определенно пора уже подумать о покупке нового сервера.
А может ALTER TABLE и новый ключ с bigint? а то напоминает смену мерседеса из-за забившейся пепельницы.
SK>>Например если под индекс выделено SMALLINT(unsigned) а записей уже 42934 и каждый месяц прибавляется по 8000, то определенно пора уже подумать о покупке нового сервера.
BE>А может ALTER TABLE и новый ключ с bigint? а то напоминает смену мерседеса из-за забившейся пепельницы.
Я же говорю — это метод решения не технической задачи.
Например нужно купить новый сервер. у старого дремучего жесткие диски большие а оперативы всего 4GB. провести по бухгалтерии расширение памяти сложно. самой памяти уже давно нет в продаже, та что есть стоит дороже нового сервера. покупку нового сервера обосновать сложно.
дать отчет перед акционерами, которые умеют только графики смотреть и тп.
Здравствуйте, BigBoss, Вы писали:
W>>Очень странного. Я так понимаю, задача из головы, не реальная.
BB>Совсем наоборот. Есть БД, в неё пишут и пишут. Рано или поздно допишутся до какого-нибудь лимита и всё сломается. Хочется узнать об этом заранее, законное желание
Нет, именно очень странного.
Нормальные СУБД в таких случаях позволяют находу добавить диск и продолжить текущую транзакцию.
