zhaar

Не выкладывать его в Интернет.

SELECT DATEDIFF( DAY, '20181116', '20190906') % 14
SELECT DATEDIFF( DAY, '20181116', '20190906') % 15

SELECT period.name, period.startdate
FROM period 
  LEFT OUTER JOIN period AS period_end ON period.name = period_end.name 
    AND DATEADD(dd, 1, period.enddate) = period_end.startdate
  WHERE (period_end.startdate IS NULL)

Но сюда будет попадать последний период.
Будем считать, последний период "закрыт" максимальной для name датой, то есть:

ddd	2019-01-01	2019-05-01
ddd	2019-05-02	2019-06-07
ddd	2019-06-10	2019-09-04
ddd	2019-09-05	2999-12-31
aaa	2019-09-01	2019-09-10
aaa	2019-09-12	2019-12-31
aaa	2020-01-01	2020-12-31

SELECT period.name, period.startdate, period.enddate
  FROM period 
    LEFT OUTER JOIN period AS period_end ON period.name = period_end.name 
                              AND DATEADD(dd, 1, period.enddate) = period_end.startdate
  WHERE (period_end.startdate IS NULL) 
     AND (period.enddate <> (SELECT MAX(enddate) FROM period AS period_last 
                                                 WHERE (name = period.name)))

Оповещения рассылаются не самим сервисом, а через сторонних провайдеров PUSH-нотификаций, которые могут быть не заблокированы. Гуглите по "push notifications provider".

Найдено в сети:

Когда вы используете константу, значение известно оптимизатору, поэтому может определять селективность (и возможное использование индекса) на основе этого. Когда вы используете переменную, значение неизвестно оптимизатору.

Performance Impact: Constant value -vs- Variable.

похоже вариантов решения немного...
запрос начнет отрабатывать без старых кэшированных данных

Личный опыт: при освоении MS SQL, обратил внимание, что промежуточный слой ADO, иногда меняет в реальном запросе константы на переменные и наоборот. При использовании хранимых процедур план запроса строится и кэшируется при её создании. Это одна из причин оборачивать в процедуру запрос даже без дополнительных обработок.

NOWAIT.