Recently I created Session State in my project, code is below
<sessionState mode="SQLServer" allowCustomSqlDatabase="true"
sqlConnectionString="Data Source=ADMIN-9F8C57749\SQLEXPRESS;Initial
Catalog=kecbliss;Integrated Security=True" timeout="60"
stateNetworkTimeout="60">
</sessionState>
The problem is day by day aspstatetempsessions table is becoming big
so my question is
Can i delete previous days records from aspstatetempsessions?
How to achieve this without affecting to project ?
Project details
Front end ASP.NET
Back end MS SQL Server
To resolve this issue:
Step1:
Make sure that the SQL Agent service is running and also check to see if the SQL Agent job called SSPdatabaseName_Job_DeleteExpiredSessions exists and run successfully.
If you have the SQL Agent Services is started and the SQL Agent Job is missing, proceed to the Step2
Step2:
Run the DeleteExpiredSessions Stored Procedure manually on the SSP database.
Connect to the database server using Microsoft SSMS --> Client on
New query.
Make sure you have selected the SSP database in the new query
windows.
Type in “EXEC DeleteExpiredSessions” and execute the query.
This command would clean up the ASPStateTempSessions table and not remove any active connections.
Note: Depending on the ASPStateTempSessions table size, it is recommended to run this command during off-peak times on the SharePoint/SQL server.
To register the job to be run automatically in the future follow the below steps:
Ensure the SQL Agent is on (it should be set as an Automatic startup
Windows service as well)
Obtain the SSP database name that contains the ASPStateTempSessions
table missing an associated SQL Agent Job.
Execute the following command on a WFE or any application servers
with the server farm:
From the command prompt get to the ASP .Net folder %WINDIR%\Microsoft.NET\Framework\v2.0.50727\
aspnet_regsql.exe -sqlexportonly exportfilepath.sql -ssadd -sstype c -d SSP db name
Open the exportfilepath.sql file in a note pad, make sure to select
the text between the following lines:
/* Create the job to delete expired sessions */
and
/**********************************/
Copy the above copied test and Execute the code on the SQL box
hosting the SSP database.
Now you should find a SQL Agent Job is created.
Raj
Source: support.microsoft.com/kb/970788
Related
I am researching and trying some things out with regards to the automatic saving of session variables into SQL Server. I have found this link discussing SQL Server session state (call it 'Option 1') and this link discussing Persistent SQL Server session state (call it 'Option 2').
The main difference seems to be that with Option 1, if the machine running SQL Server is turned off, the session data is lost, contrary to Option 2 which persists it. In Option 1 it seems that the process makes use of the tempdb, whereas, Option 2 seems to persist the session data through the use of the ASPState database.
I have a few questions that I can't seem to find any answers to:
In the first option, the article discusses the configuration required in the web config with regards to the < sessionState > tag. This is not added to the persistent case (Option 2). Should the < sessionState > be the same in both cases?
I have tried the second option as that seems to be more in-line to my case scenario. I started by downloading PersistSQLState.exe which simply self-extracts the InstallPersistSqlState.sql and UninstallPersistSqlState.sql scripts. I ran the InstallPersistSQLState.sql which completed successfully and created the 'ASPState' database in the SQL Server. I set the < sessionState > tag using the format stated in Option 2 as discussed in point 1) above.
Upon running the app I got the below error:
"Unable to use SQL Server because either ASP.NET version 2.0 Session State is not installed on the SQL server, or ASP.NET does not have permission to run the dbo.TempGetVersion stored procedure. If the ASP.NET Session State schema has not been installed, please install ASP.NET Session State SQL Server version 2.0 or above. If the schema has been installed, please grant execute permission on the dbo.TempGetVersion stored procedure to either the ASP.NET application pool identity, or the Sql Server user specified in the sqlConnectionString attribute."
This outlines 2 things: the Asp.Net Version 2.0 Session state potentially being not installed yet, and the process being unable to run the dbo.TempGetVersion stored procedure (for various reasons).
The stored procedure dbo.TempGetVersion does not exist in the ASPState database created by the InstallPersistSqlState.sql script. Is this stored procedure actually related to the tempdb (non-persistent) and therefore why the schema of the ASPState does not include it?
Is this the Asp.Net Version 2.0 Session state that needs to be installed? If so what is the process to be followed?! Should it be installed in the ASPState database after running the InstallPersistSQLState.sql script? If not, what is to be done exactly? There is nothing related to this ".exe" in either Option 1 or Option 2!
Finally, I have also tried uninstalling the persistent case instead run the scripts related to the Option 1 (non-persistent). In this case, the scripts provided in the first link above do not seem to work; returning 2 errors with jobs not being found ?!. Anyone has any idea why this would happen and do the correct scripts exist in some kind of online location?!
Any help would be appreciated as documentation seems poor on this subject.
The Option 1 and Option 2 articles as listed in my question are misleading, which is why I ended up wasting a whole day trying to make it work with the wrong info: I just did not have the right article at hand!
The below is what I ended up doing to implement persistent session state. Hope it can prove helpful to anyone wanting to implement the same thing.
On the machine open CMD in Administrator mode.
Change directory to .Net framework folder:
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
Run this command:
aspnet_regsql.exe -S "SQLServerInstanceName" -U "Username" -P "Password" -ssadd -sstype p
Small explanation of command in Point 2 above.
Aspnet_regsql.exe - is the .exe that installs Asp.Net Session state on the machine.
-S defines SQL Server instance name
-U defines Username -
-P defines Password
ssadd defines creating a new database for session state
sstype defines the type of session state. p is persistent.
Finally, in the web.config of the Asp.Net application where persistent session state is to be implemented, change the tag to look like the below:
< sessionState mode="SQLServer" sqlConnectionString="data source=127.0.0.1\sqltest;User ID=*****;Password=******" cookieless="false" timeout="20" / >
For full info visit this article and refer to the SQL Server mode.
I think I have tried everything but I can't figure out how to set up an SQL Job that have a T-SQL Step that performs a SELECT on a linked server.
1) I got a Domain user mydomain\SQLJob
2) I got a SQL 2017 server 'JOBSERVER' with the SQL Agent running log on as a domain user mydomain\sv_agent (this cannot be changed). No futher rights should be given to this user either.
3) On the JOBSERVER I created a linked server
EXEC sp_addlinkedserver 'LINKEDSERVER'
4) mydomain\SQLJob is data reader on a database on LINKEDSERVER
5) I am able to do a SELECT * FROM LINKEDSERVER... from JOBSERVER in a regular Query Window.
On JOBSERVER I have tried
ALTER DATABASE MyDatabase SET TRUSTWORTHY ON
And then set the job to execute in MyDatabase
I have also tried
Job Step Properties > Advanced > Run as user > mydomain\SQLJob
I have tried adding mydomain\SQLJob to the linked server on JOBSERVER both with and without Impersonate
Could someone let me know what the correct steps are ?
Thanks
I found another post that stated it could not be done.
What I did instead was changing the T-SQL to a PowerShell script. Here the Run As works just fine.
After insert Trigger on table calls Sp1. Some code before is executed, but when it comes to EXEC xp_cmdshell it goes to suspend mode (I used sp_who on SQL server). Suspended process is bulk import of some data from csv of NT SERVER\MSQLSERVER.
Sp1 (Store procedure does some job with SSIS package.)
EXEC master.sys.xp_cmdshell 'c:\"Program Files (x86)"\"Microsoft SQL Server"\120\DTS\Binn\DTExec.exe /f "C:\xxx\yyy\import_data.dtsx"'
What I have done to solve the problem:
Security on xp_cmdshell, user A which is used to connect form app to database is in sysadmin role, xp_cmdshell in enabled. User has execute permissions on xp_cmdshell on master table.
Tried with sp_cmdshell_proxy_user no luck
NT service\MSSQLserver has full control over 'c:\"Program Files (x86)"\"Microsoft SQL Server"\120\DTS\Binn AND C:\xxx
The best part:)
When I run Sp1 from SQL studio with user A it works just fine!
When I run from app (the same user A), it goes to suspend. APP is asp.net core.
Any idea where to look? I suspect it is security issue
As per this how-to, I've successfully configured IIS on my XP-SP3 dev box for SQL Server 2008 Express to save ASP.NET session state information. I'm just using SQL Server because otherwise on every recompile, I was losing the session state which was obnoxious (having to re-login). But, I'm facing an annoying issue in that every time I restart SQL there's this error, and sometimes one or two other very similar friends:
The SELECT permission was denied on the object 'ASPStateTempSessions',
database 'tempdb', schema 'dbo'.
To fix the error, I just open Management Studio and edit the User Mapping for the login/dbo I'm using on the ASPState db, and re-add tempdb to that user with all but deny permissions. Apparently, once the right permissions are there, ASP.NET is able to automatically create the tables it uses. It just can't run that CreateTempTables sproc until the right security is there.
THE QUESTION...
Is there a way to not have to re-do this on every restart of the SQL Server?
I don't really care right now about keeping the temp data across restarts, but I would like to not have to go through this manual step just to get my web app working on localhost, which uses session state variables throughout. I suppose one could resort to some kind of stored procedure within SQL Server to accomplish the task for this machine when the service starts, to not have to do it manually. I'd accept such an answer as a quick fix. But, I'm also assuming there's a better recommended configuration or something. Not seeing an answer to this on the how-to guide or elsewhere here on StackOverflow.
Both answers seem valid; but with most things Microsoft, its all in the setup...
First uninstall the ASPState database by using the command:
aspnet_regsql –ssremove –E -S .
Note:
-E is to indicate you want to use integrated security connection.
-S informs what SQL server and SQL instance to use, and the "." (dot) specifies default local instance
Then re-install using the command:
aspnet_regsql –ssadd –sstype p –E -S .
Note:
The sstype has three options, t | p | c ... the first "t", tells the installer to host all stored procedures in the ASPState database, and all data in the tempdb. The second option "p" tells the installer to persist data to the ASPState database. The last option "c" allows you to specify a different 'custom' database to persist the session state data.
If you reinstall using the "-sstype p" you then need only to supply datareader/datawriter to the ASPState database for the user that's making the connection (in most cases, the application pool's identity in IIS).
The added benefit of persisting the data is that session state is retained even after a restart of the service. The only drawback is that you need to ensure the agent cleanup job is pruning old sessions regularly (it does this by default, every minute).
Important:
If you are running a cluster, you must persist session data. You're only option is to use sstype 'p' or 'c'.
Hope this sheds light on the issue!
For the record, I did find a way to do this.
The issue is that the tempdb is recreated from the model db each time the service restarts. The gist of the solution is to create a stored procedure that does the job, and then make that procedure run at startup.
Source code (credit to the link above) is as follows:
use master
go
-- remove an old version
drop proc AddAppTempDBOwner
go
-- the sp
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13) + 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
-- add it to the startup
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Well done for finding the strangest way possible to do this.
The correct answer is as follows:
use master
go
EXEC sp_configure 'Cross DB Ownership Chaining', '1'
go
RECONFIGURE
go
EXEC sp_dboption 'ASPState', 'db chaining', 'true'
go
We're trying to get session state working using the following web.config line:
<sessionState
mode="SQLServer"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="Data Source=dbServer;User ID=stateUser;Password='thepassword'"
cookieless="false"
timeout="20"/>
On dbServer, we've run the following command to set up the ASPState db:
aspnet_regsql.exe -S localhost-E -ssadd -sstype p
On the webServer, we've started the ASP.Net state service, however, no records show up in tables ASPStateTempApplications or ASPStateTempSessions, and it seems very much like session is still being stored in process.
What's wrong? Should the state service be running on the DB server? Does it get installed with IIS, because it's not available on that machine, despite .net 3.5.1 being installed.
The IIS logs show no hint of failure. What's wrong?
If there's really quotes around the password, try to remove them:
sqlConnectionString="Data Source=dbServer;User ID=stateUser;Password=thepassword"
And remove the following line, it has no function for SQL session storage:
stateConnectionString="tcpip=127.0.0.1:42424"
And you might as well stop the state service; it's needed for out-of-process session state, not for SQL Server session state.
Also, SQL Server session state requires you to run InstallSqlState.sql on the database, not aspnet_regsql.exe. It should create a new ASPState database.
First, you don't need to start the State Service in order to use SQL Server session state. Forget about the ASP.NET State Service.
Are you sure that your site is creating a session variable? Just because you put these changes in your web.config, if you never use session variables, it won't be used.
How about writing a small HttpModule? You could drop it into place for the period of time when you need to transition users to the new codebase. The module could do some work on each page request to check the user's session and decide whether it needs to be abandoned. Perhaps you store an application version string in the user's session when the session is first created and compare the current app version string against that.