ASP. NET сохранение состояния сеанса в базе данных приложения

Question

Существует опция для настройки ASP. NET приложения для хранения информации о сеансе на SQL Сервер: https://docs.microsoft.com/en-us/previous-versions/ms178586 (v = vs.140)

Однако это требует создания новой базы данных (ASPState) с некоторым сценарием

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

Answer 1

Сначала я упомяну, что не рекомендуется смешивать объекты aspstate и user в одной базе данных. Аспатские данные используются довольно интенсивно и могут потребовать значительного SQL пространства журнала транзакций сервера для временных данных, которые никогда не требуется восстанавливать. Было бы лучше иметь выделенную базу данных в модели восстановления SIMPLE для состояния сеанса, а не смешивать данные с различными требованиями к восстановлению.

Имя базы данных aspstate настраивается. Укажите аргумент Aspnet_reg sql -sstype c для пользовательской базы данных и имя базы данных с помощью -d. Например:

 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Aspnet_regsql.exe" -ssadd -sstype c -d YourUserDatabase -S YourSqlInstance -E

Ниже приведен пример строки подключения aspstate с приведенным выше примером для Windows аутентификации. Это может быть идентично вашей обычной строке подключения к базе данных пользователей, но здесь я добавил явное имя приложения для уникальной строки подключения, чтобы в состоянии сеанса использовался отдельный пул подключений.

Data Source=YourSqlInstance;Initial Catalog=YourUserDatabase;Integrated Security=SSPI;Application Name=aspstate

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

USE YourUserDatabase;
GO
CREATE Role APSStateRole;
ALTER  ROLE APSStateRole
    ADD MEMBER [YourUserAccount]; --assuming user already exists
GRANT EXECUTE ON dbo.TempReleaseStateItemExclusive TO ASPStateRole;
GRANT EXECUTE ON dbo.TempInsertUninitializedItem TO ASPStateRole;
GRANT EXECUTE ON dbo.TempInsertStateItemShort TO ASPStateRole;
GRANT EXECUTE ON dbo.TempInsertStateItemLong TO ASPStateRole;
GRANT EXECUTE ON dbo.TempUpdateStateItemShort TO ASPStateRole;
GRANT EXECUTE ON dbo.TempUpdateStateItemShortNullLong TO ASPStateRole;
GRANT EXECUTE ON dbo.TempUpdateStateItemLong TO ASPStateRole;
GRANT EXECUTE ON dbo.TempUpdateStateItemLongNullShort TO ASPStateRole;
GRANT EXECUTE ON dbo.TempRemoveStateItem TO ASPStateRole;
GRANT EXECUTE ON dbo.TempResetTimeout TO ASPStateRole;
GRANT EXECUTE ON dbo.GetMajorVersion TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetVersion TO ASPStateRole;
GRANT EXECUTE ON dbo.GetHashCode TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetAppID TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetStateItem TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetStateItem2 TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetStateItem3 TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetStateItemExclusive TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetStateItemExclusive2 TO ASPStateRole;
GRANT EXECUTE ON dbo.TempGetStateItemExclusive3 TO ASPStateRole;
GO