Is there a "generic" script I may run to delete the tables and stored procedures to a SqlServer 2000 database.I would really like to delete every table and stored procedure I have created as quickly and efficiently as possible.
I need to rebuild a corrupted/deleted master database in SQL Server 2005 SP2.
When I run setup.exe from the install media as directed by SQL Books Online, I get to the point where it says the instance is a later version and setup cannot continue. Rerunning the SP2 installer, the instances cannot be selected for upgrade (and it ignores the command line options for the original installer).
How to proceed?
Also, it would seem simpler to have a detach, copy and attach the system databases process, rather than run the installer. (I realize you can stop the instance, copy files, restart the instance; but that's not "high availability".)
If one is regularly taking backups of system databases, when does it become necessary to rebuild the master database. I am looking for a situation where rebuilding the master is preferred to restoring it from backup.
Hi, I'm testing my recovery on a sql server 2005 database. The server has been restored, which includes the OS and sql server 2005 installation (binaries, full tape restore). The tape restore didn't put back the master.mdf and other .mdf files (can't be backed up when open), so I need to rebuild the master and do a database recovery on it and the other supporting databases (yes, I have database backups). I have installed the sql 2005 setup CDs in a folder and run the following command to rebuild the master, but nothing happens, it pauses for a couple of minutes before it returns to the prompt, but it does not put and new master.mdf files in the folder and I can't start the service in single user mode. "start /wait setup.exe /qn INSTANCENAME=MSSQLSERVER REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=mypassword" Anybody have any procedures for a full sql server 2005 recovery or suggestions on this, please post.
I'm trying to rebuild my master database for sql server 2000. The process of rebuilding stared fine. But it is almost 4 hours since it got started. Performing it on a test system. Got doubtful and started the same on another test system. Issue is same and it is almost 2 hours. The Db size is less than 100 MB in both cases. IS IT NORMAL? I've tried the same for SQL SERVER 2005 and it got finished in couple of minutes. Please advise.
On our particular database server, we run the Rebuild Index Task (Using classic Maintenance Plan Designer) every night. Running the script below, I saw that about 77 tables had an avg_fragmentation_in_percentage between 80% and 99% !!
SELECT OBJECT_NAME(ind.OBJECT_ID) AS TableName, ind.name AS IndexName, indexstats.index_type_desc AS IndexType, indexstats.avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats INNER JOIN sys.indexes ind ON ind.object_id = indexstats.object_id AND ind.index_id = indexstats.index_id WHERE indexstats.avg_fragmentation_in_percent > 30--You can specify the percent as you want ORDER BY indexstats.avg_fragmentation_in_percent DESC
I dont understand why these tables are highly fragmented after a daily index rebuild! Unless the users are doing heavy inserts/updates/deletes during the day.
Complete: SetPackageInstallStateAction at: 2007/9/23 7:33:43, returned true Running: DeterminePackageTransformsAction at: 2007/9/23 7:33:43 Complete: DeterminePackageTransformsAction at: 2007/9/23 7:33:43, returned true Running: ValidateSetupPropertiesAction at: 2007/9/23 7:33:43 Complete: ValidateSetupPropertiesAction at: 2007/9/23 7:33:43, returned true Running: OpenPipeAction at: 2007/9/23 7:33:43 Complete: OpenPipeAction at: 2007/9/23 7:33:43, returned false Error: Action "OpenPipeAction" failed during execution. Running: CreatePipeAction at: 2007/9/23 7:33:43 Complete: CreatePipeAction at: 2007/9/23 7:33:43, returned true Running: RunRemoteSetupAction at: 2007/9/23 7:33:43 <Func Name='CProcessCtrl::GetInstallPath'> <EndFunc Name='CProcessCtrl::GetInstallPath' Return='0' GetLastError='0'> Error: 0x80070050 TaskScheduler::NewWorkItem for SQL Server Remote Setup Error: 0x80070005 TaskSchedulerWorkItem failed to save the task [SQL Server Remote Setup ] Complete: RunRemoteSetupAction at: 2007/9/23 7:33:43, returned false Error: Action "RunRemoteSetupAction" failed during execution. Error information reported during run: Attempting to determine log files for remote install. Connection to remote computer's scheduler service. Creating new workitem. Deleting existing work item and trying again... Starting remote setup onSQL1N2 Error: 80070005 Access is denied. Running: PopulateMutatorDbAction at: 2007/9/23 7:33:43 Complete: PopulateMutatorDbAction at: 2007/9/23 7:33:43, returned true Running: GenerateRequestsAction at: 2007/9/23 7:33:43 SQL_Engine = 3 SQL_Data_Files = -1 SQL_Replication = -1 SQL_FullText = -1 SQL_SharedTools = -1 SQL_BC_DEP = -1 Analysis_Server = -1 AnalysisDataFiles = -1 AnalysisSharedTools = -1 RS_Server = -1 RS_Web_Interface = -1 RS_SharedTools = -1 Notification_Services = -1 NS_Engine = -1 NS_Client = -1 SQL_DTS = -1 Client_Components = -1 Connectivity = -1 SQL_Tools90 = -1 SQL_WarehouseDevWorkbench = -1 SDK = -1 SQLXML = -1 Tools_Legacy = -1 TOOLS_BC_DEP = -1 SQL_SSMSEE = -1 SQL_Documentation = -1 SQL_BooksOnline = -1 SQL_DatabaseSamples = -1 SQL_AdventureWorksSamples = -1 SQL_AdventureWorksDWSamples = -1 SQL_AdventureWorksASSamples = -1 SQL_Samples = -1 Complete: GenerateRequestsAction at: 2007/9/23 7:33:44, returned true Running: CreateProgressWindowAction at: 2007/9/23 7:33:44 Complete: CreateProgressWindowAction at: 2007/9/23 7:33:44, returned false Error: Action "CreateProgressWindowAction" failed during execution. Running: ScheduleActionAction at: 2007/9/23 7:33:44 Complete: ScheduleActionAction at: 2007/9/23 7:33:45, returned true Skipped: InstallASAction.11 Waiting for actions from remote setup(s) Breaking wait state and aborting package due to cancel code received: 1602 Remote setup(s) are ready Notify package action is determined: 1602 Error Code: 0x800700e9 (233) Windows Error Text: No process is on the other end of the pipe.
Source File Name: remotemessageliboverlappedpipelistener.cpp Compiler Timestamp: Sat Oct 7 09:43:54 2006 Function Name: sqls:verlappedPipeListener::writePipe Source Line Number: 294
Notification failed to send. ---- Context ----------------------------------------------- sqls::HostSetupPackageInstallerSynch::installAction
Removing machine from list of targets to sync. Skipped: Action "InstallASAction.11" was not run. Information reported during analysis: All installs have been cancelled, so package: "sqlsupport", referred by package: "as", will not be installed. Skipped: InstallASAction.18 Skipped: Action "InstallASAction.18" was not run. Information reported during analysis: All installs have been cancelled, so package: "owc11", referred by package: "as", will not be installed. Skipped: InstallASAction.22 Skipped: Action "InstallASAction.22" was not run. Information reported during analysis: All installs have been cancelled, so package: "bcRedist", referred by package: "as", will not be installed. Skipped: InstallASAction.9 Skipped: Action "InstallASAction.9" was not run. Information reported during analysis: All installs have been cancelled, so package: "msxml6", referred by package: "as", will not be installed. Skipped: InstallDTSAction Skipped: Action "InstallDTSAction" was not run. Information reported during analysis: All installs have been cancelled, so package: "dts", will not be installed. Skipped: InstallDTSAction.11 Skipped: Action "InstallDTSAction.11" was not run. Information reported during analysis: All installs have been cancelled, so package: "sqlsupport", referred by package: "dts", will not be installed. Skipped: InstallDTSAction.12 Skipped: Action "InstallDTSAction.12" was not run. Information reported during analysis: All installs have been cancelled, so package: "sqlncli", referred by package: "dts", will not be installed. Skipped: InstallDTSAction.18 Skipped: Action "InstallDTSAction.18" was not run. Information reported during analysis: All installs have been cancelled, so package: "owc11", referred by package: "dts", will not be installed. Skipped: InstallDTSAction.22 Skipped: Action "InstallDTSAction.22" was not run. Information reported during analysis: All installs have been cancelled, so package: "bcRedist", referred by package: "dts", will not be installed. Skipped: InstallDTSAction.9 Skipped: Action "InstallDTSAction.9" was not run. Information reported during analysis: All installs have been cancelled, so package: "msxml6", referred by package: "dts", will not be installed. Skipped: InstallNSAction Skipped: Action "InstallNSAction" was not run. Information reported during analysis: All installs have been cancelled, so package: "ns", will not be installed. Skipped: InstallNSAction.11 Skipped: Action "InstallNSAction.11" was not run. Information reported during analysis: All installs have been cancelled, so package: "sqlsupport", referred by package: "ns", will not be installed. Skipped: InstallNSAction.12 Skipped: Action "InstallNSAction.12" was not run. Information reported during analysis: All installs have been cancelled, so package: "sqlncli", referred by package: "ns", will not be installed. Skipped: InstallNSAction.18 Skipped: Action "InstallNSAction.18" was not run. Information reported during analysis: All installs have been cancelled, so package: "owc11", referred by package: "ns", will not be installed. Skipped: InstallNSAction.22 Skipped: Action "InstallNSAction.22" was not run. Information reported during analysis: All installs have been cancelled, so package: "bcRedist", referred by package: "ns", will not be installed. Skipped: InstallNSAction.9 Skipped: Action "InstallNSAction.9" was not run. Information reported during analysis: All installs have been cancelled, so package: "msxml6", referred by package: "ns", will not be installed. Skipped: InstallRSAction.11 Skipped: Action "InstallRSAction.11" was not run. Information reported during analysis: All installs have been cancelled, so package: "sqlsupport", referred by package: "rs", will not be installed. Skipped: InstallRSAction.18 Skipped: Action "InstallRSAction.18" was not run. Information reported during analysis: All installs have been cancelled, so package: "owc11", referred by package: "rs", will not be installed. Skipped: InstallRSAction.22 Skipped: Action "InstallRSAction.22" was not run. Information reported during analysis: All installs have been cancelled, so package: "bcRedist", referred by package: "rs", will not be installed. Skipped: InstallSqlAction Clustered feature detected: SQL_Engine Clustered feature detected: SQL_FullText Loaded DLL:C:Program FilesMicrosoft SQL Server90Setup Bootstrapsqlsval.dll Version:2005.90.3042.0 Windows Error Text: User cancelled installation.
Source File Name: sqlchainingsqlchainingactions.cpp Compiler Timestamp: Thu Nov 16 20:32:00 2006 Function Name: sqls::ReportChainingResults:erform Source Line Number: 3667
---- Context ----------------------------------------------- sqls::RunRemoteSetupAction::waitForRemoteSetupComplete king package: "patchRS2000" as failed due to cancel code received from cancel source: 1602 sqls Delay load of action "UploadDrWatsonLogAction" returned nothing. No action will occur as a result. Message pump returning: 1602
I'm upgrading to SQL 2012 from 2008R2, while doing so i will be rebuilding all the indexes on all the database. In my previous environment while doing so, i got space related error in primary filegroup for insufficient space in the primary filegroup. Is there any rule of thumb about how much space is required by index rebuild command for each database, or is there a safe threshold for free space in the database?
We have 3 maintenance jobs configured in this particular DB instance:
Daily backup of system database - SubPlan1 (Check Database Integrity Task --> Rebuild Index Task-->Backup Database Task)Daily backup of user databases - Five subplans for each task : (Check DB integrity --> Rebuild Index -->Backup User Database, Backup Log -->Cleanup History)Weekly maintenance - SubPlan1 (Check Database integrity job (system+user DB) + rebuild index job (system+user DB) )
PROBLEM: I just noticed that the User DB Rebuild Index task has been running since the 03/04 and the Weekly maintenance plan - subplan1 since the 12/04.
Which job is "safe" to stop without impacting the database?
I have a requirement to only rebuild the Clustered Indexes in the table ignoring the non clustered indexes as those are taken care of by the Clustered indexes.
In order to do that, I have taken the records based on the fragmentation %.
But unable to come up with a logic to only consider rebuilding the clustered indexes in the table.
Can anyone advise on issues arising from a complete format & rebuild of a SQL server. The machine exists in a small domain and contains 1 small 30 MB production database which I would want to back up and restore to the newly built server. What are the issues with maintaining permissions? etc.
I had to reinstall sql 6.5 on my server. However I am not sure of the correct sequence to resetup my databases. I have all of my original database devices and backups. However when reinstalling I no longer see the database devices or databases( excepected). How do I recreate my database devices using the devices that I have on an existing device. I need sql to recognize these devices then I can recreate my databases and do my restores. Please help!
I have a SQL Server 7 box that is shortly to be rebuilt completely (still on NT4, but with new RAID system), does anyone have any advice on how I can make the transition as painless as possible? Particularly, I want to maintain the backup, security and DTS structures as much as possible.
Hi All, SQL 7 REQUIRES THE DBA TO MANAGE THE INDEXES AND IN PARTICULAR THE FILL FACTOR AVAILABILITY. DOES SQL SERVER 2000 AUTOMATICALLY ADDRESS THIS OR DO WE STILL HAVE TO PERIODICALLY RUN,
I understand the difference between REBUILD and REORGANIZE. Just wondering if you can do both in the same script or do you have to rebuild the index first and later reorganize?
In the maintance plans there is a Rebuild Index choice. If u choose tables and views the plan executes ALTER INDEX <index> ON <table> ;REBUILD for all indexes in the datebase. I am currently using this plan on our production DB, scheduled for every Saturday night. I wonder if there is a downside of using maintance plans. Because it seems to be doing the job. Any comments?
I am upgrading from SQL2000 to SQL2005. I have restored my 2000 db to 2005. I have changed the Compatiblilty level to 90. Now I need to reindex. How do I reindex all the tables at once? Thanks for ALL your help r/p
Rebuild Index job for user db's is failing, one user db is a huge size 120 GB. The job scheduled to run every sunday 1 AM
I found the below error in log report
Rebuild Index Task (server name) Rebuild index on Local server connection Databases: All user databases Object: Tables and views Original amount of free space Task start: 01/13/2008 1:26 AM. Task end: 01/13/2008 2:38 AM. Failed-1073548784) Executing the query "ALTER INDEX [Idx_CISCO_WLC_EVENTID] ON [dbo].[CISCO_WLC_200711262137] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, ONLINE = OFF ) " failed with the following error: "Cannot find the object "dbo.CISCO_WLC_200711262137" because it does not exist or you do not have permissions.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
will maintenance tasks like rebuilding and reorganizing indexes be replicated in transactional replication, or do i have to setup these management tasks on the subscribers as well?
I have a table with over 60 million rows (approx 20GB) which has an indexed column. I have tried using DBC DBReindex to rebuild the index, but after kicking it off on a friday, it is still running the following wednesday. Since managers and other finicky types access this database, that's not acceptable (it slows down their reporting).
Is there a way to speed up the reindexing process? Perhaps by adding space to the tempdb (it's 500MB) or putting it in RAM temporarily? I haven't seen any articles that specifically state that TEMPDB is used during an index rebuild, but it seems logical that it would be.
Any suggestions to speed up the process would be most appreciated!
I am performing a Rebiuld of the Master database using the REBUILDM utility on a SQL 2000 SP3 database which is clustered. The utility starts off correclty, copying the correct MDF and LDF files to the hard drive, and the configuration bar goes across the screen 4 times, before giving the following error "Rebuild master failed with error -1".
I can't find anything on microsoft. I followed KB-298568 to perform this process, but the SQL Service will now not start as it cannot find the master, as it did not get rebuilt properly.
I have included screen shots of the error, in the zipped up word doc.
I did Index defragmentation a week ago . for 1 database only , In the middle of rebuild I kill the process twice cause It takes more than 1 hour so I killed it and wonder how many high level fragmented indexes left ...
We have a script running everyday for rebuild and re-organisation of indexes. But, somehow its getting failed. Attached script for your consideration. There is no database name with amoperations. There is table called DatabaseObjectAudit but it exist on master db.
Message:
-->Start Index Maint -> Gathering fragmentation information (can take a while!) -> Gathering COMPLETE : Total of 43 databases were found. -> Gathering COMPLETE : Total of 1622 indexes were found.