Problem:
Unable to start execution of step 3 (reason: The PowerShell subsystem failed to load [see the SQLAGENT.OUT file for details];The job has been suspended). The step failed.

Cause of the failure: This is due to invalid location of SQLPS.exe file

Solution:

1. We can use the below script check the location of SQLPS.exe file.

SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'

2. Go to the server and check whether the file ‘SQLPS.exe’ is located in the path as per step1.

3. There may be chance that the path is different on Node1 and Node2.

4. Find out the correct path of the SQLPS.exe and re-configure it using below command

Use msdb
go
sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE

/* Update to correct path
For example correct path is “D:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe” Than change it accordingly*/

UPDATE msdb.dbo.syssubsystems SET agent_exe='E:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe' WHERE start_entry_point ='PowerShellStart'

sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE

5. Confirm that SQLPS.exe file path has changed by running the below script once again

SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'

6. Restart the respective SQL agent service. For the cluster server you have to use cluster administrator to restart the service.

7. Re – run the job.

An upgrade is any kind of transition from SQL Server 2000 or SQL Server 2005 to SQL Server 2008.

Upgradation Startegies

In-place upgrade: Using the SQL Server 2008 Setup program to directly upgrade an instance of SQL Server 2000 or SQL Server 2005 to SQL Server 2008. The older instance of SQL Server is replaced.

• Side-by-side upgrade: Using steps to move all or some data from an instance of SQL Server 2000 or SQL Server 2005 to a separate instance of SQL Server 2008. There are two types of side-by-side upgrade strategy:
  • One server: The new instance exists on the same server as the target instance.
  • Two servers: The new instance exists on a different server than the target instance.

The system objects are physically stored in the resource database, they are logically presented as the sys schema in each database.

The following code returns the build number of the resource database:
SELECT SERVERPROPERTY(‘ResourceVersion’)

To return the date and time the resource database was last updated, the following code can be executed:
SELECT SERVERPROPERTY(‘ResourceLastUpdateDateTime’)

SQLCMD is particularly useful for creating batch scripting jobs for administrative purposes. SQLCMD has replace OSQL. It is using OLEDB to connect the SQL Server. However, as an emergency utility to diagnose and hopefully correct server problems, it has no peer. By Using the –A argument, the SQLCMD utilizes an exclusive connection to SQL Server. If no other connection is possible, the SQLCMD –A command is the last and best hope for diagnosing server problems and preventing data loss. By default, only local DACs are allowed because the DAC components only listen on the loopback connection. However, remote DACs can be enabled using the sp_configure stored procedure by changing the remote admin connections option to true, as the following code illustrates:

sp_configure ‘remote admin connections’, 1
RECONFIGURE