I have a large query running that loops over multiple stored procedures. Based on business rules, I'm calling the appropriate stored procedures for each record that is in my loop.
The problem is that those stored procedures sometimes generate multiple result sets. What happens then is that in SQL Server Management Studio, the 'results pane' gets filled up with data, it slows down SQL Server Management Stidion and in the end Management Studio even crashes with an out of memory exception. Is there any way in which I can suppress the results from showing up?
You can also execute it from a command line using OSQL, and specify a logfile:
osql -E -S ServerName -d DBNAme -q "EXIT(<QUERY STUFF HERE>)" -o PathtoLogFile.txt
run the query as a job in Sql Server Agent.
Related
After the scheduled maintenance when the DBA tried to start the SQL Server;
it failed due to some corruption issue with storage subsystem.
Later on, we identified that the drive on which we had our TempDB's data and log files was corrupt and it was preventing SQL Server from starting successfully.
(Drive was corrupt, so I am unable to read anything from that drive)
So basically we did not have Tempdb database on the server.
And we had to start SQL Server without TempDB
So how do we start the SQL Server without TempDB and how do we fix this?
Before you try anything make sure you backup your data. If one drive failed, another one might fail and leave you without your data. Drives that are purchases at around the same time tend to fail around the same time too.
You need to do that even if some of the data is stored in a RAID array - RAID isn't the same as a backup. If something happens to the array, your best case scenario is that you'll wait for a few hours to recover the data. Worst case, you could lose it all.
The process is described in The SQL Server Instance That Will not Start in the TempDB location does not exist section, and other sites like Start SQL Server without tempdb.
You'll have to start SQL Server with Minimal Configuration. In that state, tempdb isn't used. You can do this with the -f command-line parameter. You can specify this parameter in the service's property page, or by calling sqlservr.exe -f from the command line, eg:
sqlservr -f
Another option is to use the -t3608 trace flag which starts only the master database.
sqlservr -t3608
After that, you need to connect to the server with the sqlcmd utility, eg :
sqlcmd -S myservername -E
to connect using Windows authentication.
Once you do this, you can go to the master database and change the file location of the tempdb files:
USE master;
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'E:\SQLData\tempdb.mdf');
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'F:\SQLLog\templog.ldf');
GO
After that, remove the parameters from the service (if you set them there) and restart the service.
Finally, you may have to reconsider the placement of TempDB. TempDB is used heavily for sorting, calculating window functions or in situations where the available RAM isn't enough. Some operations require creating intermediate results, which get stored in TempDB. In general, you should have
multiple tempdb files, although the exact number depends on the server's workload.
How to Start SQL Server without TempDB database?
Step 1: Start the SQL Server in minimal configuration mode.
Click here
to see, "How to start the SQL Server in minimal mode using command prompt".
Step 2: Once SQL Server has started with minimum configuration mode;
connect to SQL Server instance and move TempDB data and log file to a new location.
See, move TempDB data and log files to new location
Step 3: Once you have performed the troubleshooting steps; exit SQLCMD window by typing Quit and Press Enter.
Step 4: . In the initial window click CTRL C and enter Y to Stop SQL Server Service.
Step 5 : Eventually, start the SQL Server Database Engine by Using SQL Server Configuration Manager.
What version of SQL Server it is? One simple solution is to move the tempdb.* files from that location and restart the SQL Server it will create new tempdb files. If you keep those files in that same location it will fail to start.
In SQL Server 2016 If you remove the tempdb physical files, on startup it will see they are missing and rebuild them on the fly in the location they are supposed to be in sysdatabases.
Let's say I have a number of "autoexec" stored procedures, i.e., marked with:
exec sp_procoption 'myproc', 'startup', 'ON';
Is there a way to start SQL Server so that the autoexec procedures are not executed at startup this time? I need to do this sometimes for certain maintenance operations.
Thanks.
From the fine manual.
Although stored procedures are set for automatic execution
individually, the SQL Server scan for startup procs configuration
option can be set using sp_configure to prevent all stored procedures
from executing automatically when SQL Server starts. To skip launching
these stored procedures, specify trace flag 4022 as a startup
parameter. If you start SQL Server with minimal configuration (using
the -f flag), the startup stored procedures are not executed. For more
information, see Trace Flags.
I'm having an issue with a stored procedure which SQL Server being executed as a scheduled task through Task Manager. I have a batch file containing the EXECUTE statement which is called by Task Scheduler. Platforms is SQL Server 2008 R2 on Windows Server 2008 R2.
The batch file code
#echo off
SQLCmd -S lccc-cpc-sql -E -d NTSR -Q "Execute update_vw_NTSR_Base_AllRecords_Labels_new_proc"
This SP does the following:
Drops a table
Recreates it with updated data using a SELECT INTO statement
Problem: It's running the DROP statement, but failing on the SELECT INTO. Here's what's weird though:
If I execute the sp through SSMS (right click the sp, choose Execute) OR, view a query editor, run the code to drop the table and the SELECT INTO statement, it finishes correctly. It's a very large SELECT INTO statement - hundreds of columns and about 100 joins. The purpose is to join a lot of lookup tables to values so I have one place for my users to go for labeled data and some variables computed for user friendliness. It's messy, but it's what I have to work with.
Query timeout is set to 0 (no limit). This only happened recently as I added more columns and variables but it seems it'd fail called through any method, not just through the batch file. Any thoughts on how to make this work as-is (ie without breaking this up into multiple SELECT INTO statements)?
Thanks.
i dont want to use SQLCMD mode or addlinkedserver...i m creating a sp which will fire from central server and collect the data from multiple server...i just want query..
query to connect to another instance of Another SQL sever not using linked server or SQLCMD mode so that I can just paste that in the top of the create script and F5 to run it and it would switch to the new server and run the create script.
I dont want to use SP_addLinkedserver i.e. i dont want to link the server....I just want to Connect to that server....
You can use a Server Group which allows you to run a script against multiple servers. See Create a Central Management Server and Server Group. The good thing is that the queries are run concurrently, not serially, and the result sets are concatenated by SSMS into a single result set. For interactive queries it works OK. The bad thing is when you have failures the retry and rerun can be tricky.
For automation though using SQLCMD mode or PowerShell cmdlets is a far better alternative.
How to execute same SP in 2 different connection.
Ex: ALTER PROCEDURE test
...
....
I want to execute this SP in db called "database1" in 192.168.1.100 and same in 192.168.1.102.
I want this to be done using script not using the change connection window
You can use SQLCMD to run a .sql file against multiple server connections.
sqlcmd -S <ComputerName>\<InstanceName> -i <MyScript.sql> -d <database_name> -T
You can do that in SSMS Tools Pack using one of its features called "Run one script on multiple databases".
Editing this to add that this is a tiny and free add-in to SQL Server, that you would find extremely useful.