Size: a a a

2020 November 05

o

om in sql_ninja
Олег 奧列格 (Ào liè gé)
Ну а ПГ то ещё как тот паровоз из анекдота допилить до нужного состояния ракеты
Но он работает, своими жалкими мегабайтами обеспечивает производительность уступающую ненамного сиквел серверу. Скажем так - не драматично.
источник

IZ

Ilia Zviagin in sql_ninja
om
Студия уже под гиг весит.
Гранулированность пакетов ПО вообще в мире GNU традиционно сильно больше.
То есть сами пакеты - меньше
источник

AK

Andy Korg in sql_ninja
Олег 奧列格 (Ào liè gé)
Ну а ПГ то ещё как тот паровоз из анекдота допилить до нужного состояния ракеты
+ К тому же на больших проектах не получается обойтись PostgreSQL, приходится покупать Postgres Pro
Standard или Postgres Pro Enterprise, ну и временем разработки платить :(
источник

K

Kostya in sql_ninja
Народ, подскажите пожалйста, сейчас самая стабильная связка сиквел + винда какая ?
2016/2016 или уже лучше 2019/2019 ставить ?
Сервер и БД будут жестоким OLTP заниматься
источник

M

Marat in sql_ninja
sql лучше 2017 пока что, по винде все равно
источник

ML

Mihail Li in sql_ninja
sql 2016, винда 2019 server, вроде без проблем
источник

K

Kostya in sql_ninja
Понял, спасибо
источник

О奧

Олег 奧列格 (Ào liè gé)... in sql_ninja
Kostya
Народ, подскажите пожалйста, сейчас самая стабильная связка сиквел + винда какая ?
2016/2016 или уже лучше 2019/2019 ставить ?
Сервер и БД будут жестоким OLTP заниматься
2017 мои програмисты любят.
источник

K

Kostya in sql_ninja
в 2019-м меня завлекают какие-то индексы. оптимайзд под сиквенс .. и все. больше особо не вижу преимуществ
Понял, ну, сейчас 2017 и стоит, норм вроде тож
источник

О奧

Олег 奧列格 (Ào liè gé)... in sql_ninja
Kostya
в 2019-м меня завлекают какие-то индексы. оптимайзд под сиквенс .. и все. больше особо не вижу преимуществ
Понял, ну, сейчас 2017 и стоит, норм вроде тож
Можно и нужно идти к этой версии, но может стоит подождать ещё немного, парочку CU
источник

o

om in sql_ninja
Раньше ждали первый СП. Видимо, в связи с этим, майрософт отказался выпускать сервиспаки )
источник

M

Max in sql_ninja
немного холивара в чатик )
Стоит ли заморачиваться с размером кластера на диске для сиквела, если все это на виртуалке с vSAN под ней? @User322 , ты не на vSAN случайно живешь?
btw, в доках вмвары только про тип дисков для OLTP указано
источник

K

Kostya in sql_ninja
Max
немного холивара в чатик )
Стоит ли заморачиваться с размером кластера на диске для сиквела, если все это на виртуалке с vSAN под ней? @User322 , ты не на vSAN случайно живешь?
btw, в доках вмвары только про тип дисков для OLTP указано
Стоит конечно, ну, как минимум, количество обращений операционки будет сбалансированным.
источник

К

Какой-то Хмырь... in sql_ninja
Max
немного холивара в чатик )
Стоит ли заморачиваться с размером кластера на диске для сиквела, если все это на виртуалке с vSAN под ней? @User322 , ты не на vSAN случайно живешь?
btw, в доках вмвары только про тип дисков для OLTP указано
у нас просто san, без v
источник

K

Kostya in sql_ninja
А так-то да, там если заморачиваться, то начинать надо со страйпсета и настроек кеша схд
источник

К

Какой-то Хмырь... in sql_ninja
Max
немного холивара в чатик )
Стоит ли заморачиваться с размером кластера на диске для сиквела, если все это на виртуалке с vSAN под ней? @User322 , ты не на vSAN случайно живешь?
btw, в доках вмвары только про тип дисков для OLTP указано
не подскажу, сам бы послушал умных дядь. но я бы заморочился от греха подальше)
источник

M

Max in sql_ninja
"Format the disks using 64k allocation unit size."
Вот отсюда https://kb.vmware.com/s/article/54461
источник

M

Max in sql_ninja
помню, что вара пробрасывает запросы виртуалки прямо к диску без всяких посредников, но сбивает с толку наличие vSAN
источник

K

Kostya in sql_ninja
Они 64к на основании чего интересно выбрали, на основании того, что у последних винсерверов 64к по умолчанию ?
источник

K

Kostya in sql_ninja
очень блять гениально
источник