{code lang:sql showtitle:false lines:false hidden:false}USE MASTER
SELECT * FROM sysprocesses WHERE dbid = DB_ID(‘APPV’){/code}
Using the SPID from the output above kill any identified session by using the simple SQL below:
{code lang:sql showtitle:false lines:false hidden:false}kill <session ID>{/code}
]]>I recently ran into some issues with a remote sites EPO server. There were seveal issues:
Move The Database
— Identify logical file names and file locations for the database you wish to move
select a.name, b.name as ‘Logical filename’, b.filename from sys.sysdatabases a
inner join sys.sysaltfiles b
on a.dbid = b.dbid
— Set DB Offline, forcefully
ALTER DATABASE ePO4_SERVER
SET offline WITH ROLLBACK IMMEDIATE
GO
— Copy files to the new location, yes COPY!
— New location D:\Program Files\McAfee\ePO SQL Database
— Old Location C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data
— Set Destination NTFS Permissions to Match Source location
— Move database files(As there was not enough disk space on the C:\ on SERVER)
ALTER DATABASE ePO4_SERVER
MODIFY FILE ( NAME = ePO4_SERVER,
FILENAME = “D:\Program Files\McAfee\ePO SQL Database\ePO4_SERVER.mdf”)
GO
ALTER DATABASE ePO4_SERVER
MODIFY FILE ( NAME = ePO4_SERVER_log,
FILENAME = “D:\Program Files\McAfee\ePO SQL Database\ePO4_SERVER_log.LDF”)
GO
ALTER DATABASE ePO4_SERVER
SET online
GO
Cleanup The Database
— Find Out EPO DB Size
EXEC sp_spaceused
— Find Table Sizes
select object_name(id) [Table Name],
[Table Size] = convert (varchar, dpages * 8 / 1024) + ‘MB’
from sysindexes where indid in (0,1)
order by dpages desc
— Identify Events that can be purged between a specific date/time range
Select ThreatEventid, Count(Threateventid)
FROM EPOEvents
WHERE ReceivedUTC BETWEEN ‘2000-01-01 00:00:00.000’ AND ‘2011-03-31 23:59:59.999’
GROUP BY ThreatEventid
— Purge Events
— 1 Stop all EPO Sevices
— 2 Backup DB
— 3 Purge table
DELETE FROM EPOEvents
WHERE ReceivedUTC BETWEEN ‘2000-01-01 00:00:00.000’ AND ‘2011-05-31 23:59:59.999’
— 4 shrink the database
dbcc shrinkdatabase (ePO4_SERVER,1)
]]>In order to configure a DTC per SQL instance perform the following steps:
Create a new DTC resource
i. Look for a green arrow in the middle pane next to “Configure a Service or Application” and click on it to open the “High Availability Wizard”
ii. Choose “Next” to go to the “Select Service or Application” screen
iii. Choose “Distributed Transaction Coordinator (DTC)” then click “Next”
iv. You can either use the default name or create your own unique name for the “Client Access Point” then click “Next”. You may want to name it something like DTC_YourSQLServerResourceName. For example: if your SQL instance’s virtual name is SQL01, call your DTC resource something like DTC_SQL01 or MSDTC-SQL Server (SQL01).
v. Choose a disk that is not already used and will not be the disk you choose during SQL Server setup.
vi. Click “Next” twice.
Install SQL Server on at least one node.
Move DTC to the SQL Server group
i. Right click on the DTC resource and choose “More Actions” then “Move this resource to another service or application”.
ii. Choose your SQL Server group in “Select A Service or Application”.
iii. Right click on the DTC resource and choose “Properties”. Go to the “Policies” tab and uncheck “if restart is unsuccessful, fail over all resources in this service or application” for the DTC resource unless you are sure you want a DTC failure to cause SQL Server to fail over. This is the same thing as “affect the group” in older versions of Windows.
iv. Optionally you can take DTC offline and make it dependent on the SQL Server name and disk. Then remove its dependencies on the original name and disk. Then you can optionally delete the original IP, name, and disk or move them out of the SQL Server group.
(Optional for SQL Server 2008) Map SQL Server to this DTC resource.
If you skip this step SQL Server 2005 will use the default DTC. SQL Server 2005 will only use the DTC in the SQL Server group if that one is the default for the entire cluster or if you do the mapping step. SQL Server 2008 will use the DTC in its group unless that DTC is not online/started when SQL Server starts or if you create a mapping to a different DTC.
i. Open a dos prompt using “Run as Administrator”.
ii. Modify the below statement with a mapping name (make up a name to id the mapping), service (the SQL Server service name – not the display name), and ClusterResourceName (DTC resource name) then run it
Example: Msdtc -tmMappingSet -name DTC_SQL01_Mapping -service “MSSQL$SQL01” -ClusterResourceName “MSDTC-SQL Server (SQL01)” <<-- Note the correction I made here on 3/21/09 to the service name for SQL, and the additional verification steps below
Do you want to continue with this operation? [y/n] y [enter]
iii. Run “msdtc -tmmappingview *” to verify the mapping was created successfully. The mapping is also stored in HKEY_LOCAL_MACHINE\Cluster\MSDTC\TMMapping\Service\ as a new key named the same as the mapping parameter used in the msdtc command.
iv. To verify SQL Server is mapped to the expected instance of DTC you can either
§ Shut down all the other DTC services and make sure the mapped DTC is online. Verify you can do a BEGIN DISTRIBUTED TRANSACTION from this SQL Server.
§ Do a BEGIN DISTRIBUTED TRANSACTION from this SQL Server, verify it succeeds and roll it back. Then shut down the mapped DTC and verify a new BEGIN DISTRIBUTED TRANSACTION will work.
e) Enable network access
i. Run DcomCnfg
ii. Navigate to Computers.Component Services.My Computer.Distributed Transaction Coordinator.Clustered DTCs
iii. Right click on the DTC service for this SQL Server group and select “Properties”.
iv. Go to the security tab and check “Network DTC Access”, “Allow Inbound”, and “Allow Outbound”.
v. When you hit “Apply” or “OK” it will restart the DTC resource.
]]>To create a shared mailbox:
New-Mailbox -database “MAILSERVER\MDB1\Mailbox Database” -Name Cancel -OrganizationalUnit “domain.local/Exchange Objects/Resource Mailboxes” -DisplayName “user1” -UserPrincipalName “user1@domain.local” -Shared
To set the country code on the user (may be used for address list policies):
Set-User Cancel -CountryOrRegion “GB”
Grant full access/sendas permissions:
Add-MailboxPermission Cancel -User “user2” -AccessRights FullAccess
Add-ADPermission Cancel -User “user2” -Extendedrights “Send As”
Pre-requisites:
The following TSQL will enable you to perform point-in-time recovery on an SQL database:
/* SQL Point-in-time recovery script */
/* Uses the last full back, then TRN files from the last backup. */
/* Restore the last Full backup */
RESTORE DATABASE [POTRecovery]
FROM DISK = N’D:\MSSQL$POTRecovery\Data\Backup\POTRecovery.bak’
WITH FILE = 1, NOUNLOAD , STATS = 10, NORECOVERY
/* Restore the TRN backups, using the same point-in-time for each */
/* Date format is YYYY-MM-DD HH:MM:SS – 24Hr clock */
RESTORE LOG [POTRecovery] FROM DISK = N’D:\MSSQL$POTRecovery\Data\Backup\POTRecovery_tlog_201003051015.TRN’
WITH FILE = 1, NOUNLOAD , STATS = 10, RECOVERY , STOPAT = N’2010-03-05 10:20:00‘
RESTORE LOG [POTRecovery] FROM DISK = N’D:\MSSQL$POTRecovery\Data\Backup\POTRecovery_tlog_201003051016.TRN’
WITH FILE = 1, NOUNLOAD , STATS = 10, RECOVERY , STOPAT = N’2010-03-05 10:20:00‘
RESTORE LOG [POTRecovery] FROM DISK = N’D:\MSSQL$POTRecovery\Data\Backup\POTRecovery_tlog_201003051024.TRN’
WITH FILE = 1, NOUNLOAD , STATS = 10, RECOVERY , STOPAT = N’2010-03-05 10:20:00‘
/* Now set the database into a useable mode – without this the database will be stuck in a ‘Loading’ state */
RESTORE DATABASE [POTRecovery] WITH RECOVERY
Using a third party backup tool and SQL-based TRN backups you can still recover as above, just ensure you perform the database restore using Data Protector then use SQL Management Tools to perform the point-in-time recovery.
]]>SQL Server Migration Process
Environment information:
You will need to update these domain names in the relevant processes and scripts detailed below.
Stage one of this process is to establish any domain dependencies within an application. This includes email and active directory (authentication).
Logon to the system you are intending to migrate and identify all service accounts that are on the old domain;
Each of these accounts must be recreated on the new domnew.local domain. Each account should be prefixed with ‘svc_’ in order to easily identify service accounts in the future.
The accounts should also be configured so that the password does not expire, passwords should be documented. Once recreated you must now modify services so that they use the new service account:
It may also be necessary to mail-enable service accounts, ensuring they have the correct email address.
File System Permissions
Verify file system permissions and create additional entries for the new service account. Generally speaking these will be application specific directories and must be set manually.
Quest Tools Processing
EU Operations are now able to process the machine using the Quest tools. This tool will ensure all file system level user permissions are migrated on the server (excluding service accounts).
After completion of this step we can now move the server into the domnew.local domain, once complete the server will reboot.
Local Server Security Polices
Local security policies must be modified to allow logon as a service / batch job rights for individual accounts. On the old domain this was done via GPO, however we have now moved back to local security policies to achieve this.
Identify where the existing service account has been granted permissions and manually recreate them.
To identify current permissions Start > Run > gpedit.msc to load the local security policy editor.
Expand Computer Configuration > Windows Settings > Security Settings > Local policies > User Rights Assignment
Check for any entries for the local domain such as DOMOLD accounts and replace these with DOMNEW accounts.
Application Level Changes
We are now ready to change application level domain dependencies on the migrated server as identified in stage one.
Scheduled Tasks
You will need to ensure all scheduled tasks are using DOMNEW accounts.
For non-SQL servers the migration process ends here.
SQL Server Specific Elements for Migration
Create a new service account; this account must be a local administrator on the machine:
The account must be granted logon as a service rights:
The account must be granted a SQL Login at the server instance level, this can be achieved form within Enterprise Manager:
Please note if the account is shown as the ‘dbo’ user do not set the permissions, instead you must run the sp_changedbown stored procedure against the database:
The Query should look as follows:
USE
Expediciones
EXEC sp_changedbowner ‘DOMNEW\SVC_USD1SQL’
USE
mdb
EXEC sp_changedbowner ‘DOMNEW\SVC_USD1SQL’
Change the Database name (in bold) and the username as is appropriate.
Next we must change the SQL Agent Job owners for the database. You can view all jobs from enterprise manager:
Double-click each job and change the owner to the new DOMNEW object:
To automate job changes you can use the following T-SQL script, this will change the owner of all jobs that have domold.local ownership to domnew.local\svc_sqladmin
–********* Before proceeding please backup the MSDB database in order to provide roll-back. ***********
USE MSDB
GO
SELECT GETDATE() AS ‘ExecutionTime’
GO
SELECT @@SERVERNAME AS ‘SQLServerInstance’
GO
SELECT j.[name] AS ‘JobName’,
Enabled = CASE WHEN j.Enabled = 0 THEN ‘No’
ELSE ‘Yes’
END,
l.[name] AS ‘OwnerName’
FROM MSDB.dbo.sysjobs j
INNER JOIN Master.dbo.syslogins l
ON j.owner_sid = l.sid
WHERE l.[name] like ‘%DOMOLD\%’ or l.[name] like ‘%DOMOLD\%’
ORDER BY j.[name]
GO
SET NOCOUNT ON
SELECT ‘EXEC MSDB.dbo.sp_update_job ‘ + char(13) +
‘@job_name = ‘ + char(39) + j.[Name] + char(39) + ‘,’ + char(13) +
‘@owner_login_name = ‘ + char(39) + ‘DOMNEW\svc_sqladmin’ + char(39) + char(13) + char(13)
FROM MSDB.dbo.sysjobs j
INNER JOIN Master.dbo.syslogins l
ON j.owner_sid = l.sid
WHERE l.[name] like ‘%DOMOLD\%’ or l.[name] like ‘%DOMOLD\%’
ORDER BY j.[name]
Next we must identify and change all DTS Packages that are owned by old domain accounts. The following T-SQL will identify all unique accounts, which own DTS packages:
SELECT distinct owner FROM sysdtspackages
You will need to manually list the unique users and then run the following T-SQL for each user. Change the @old_owner and @new_owner definition at the start of the script:
–********* Before proceeding please backup the MSDB database in order to provide roll-back. ***********
DECLARE @old_owner varchar(100), @new_owner varchar(100), @name sysname, @id uniqueidentifier
set @old_owner = ‘DOMOLD\sqladmin’
set @new_owner = ‘DOMNEW\svc_sqladmin’
IF (NOT EXISTS (SELECT * FROM sysdtspackages WHERE [owner] = @old_owner))
BEGIN
RAISERROR(‘User ”%s” does not own any packages’, 16, 1, @old_owner)
RETURN
END
SELECT DISTINCT [name], [id]
FROM sysdtspackages
WHERE [owner] = @old_owner
DECLARE cur_sysdtspackages CURSOR FOR
SELECT DISTINCT [name], [id]
FROM sysdtspackages
WHERE [owner] = @old_owner
OPEN cur_sysdtspackages
FETCH NEXT FROM cur_sysdtspackages
INTO @name, @id
WHILE @@FETCH_STATUS = 0
BEGIN
Print +N’Re-assigning owner on DTS Package: ‘ + @name
EXEC sp_reassign_dtspackageowner @name=@name, @id=@id, @newloginname=@new_owner
FETCH NEXT FROM cur_sysdtspackages
INTO @name, @id
END
CLOSE cur_sysdtspackages
DEALLOCATE cur_sysdtspackages
Finally, change the credentials for the SQL services:
Enter the new DOMNEW username and password:
Verify that Database Level Users are added for the new DOMNEW domain:
]]>
TempDB should be configured to have approx 4 data files, execute the code below, modify for each additional data file:
ALTER DATABASE [tempdb]
ADD FILE (
NAME = N’tempdev_1′,
FILENAME = N’E:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data\tempdb_1.ndf’ ,
SIZE = 8MB ,
FILEGROWTH = 10% )
GO
Additional Notes/Setup Instructions
SQL Server Memory Configuration
Suggested maximum memory allocations (http://www.sqlservercentral.com/blogs/glennberry/archive/2009/10/29/suggested-max-memory-settings-for-sql-server-2005_2F00_2008.aspx):
Physical RAM MaxServerMem Setting
2GB 1500
4GB 3200
6GB 4800
8GB 6400
12GB 10000
16GB 13500
24GB 21500
32GB 29000
48GB 44000
64GB 60000
72GB 68000
96GB 92000
128GB 124000
Configuring a maximum meory size for an SQL instance
EXEC sp_configure‘max server memory (MB)’,2048;
GO
RECONFIGURE;
GO
Disk Alignment
To verify disk alignment execute the command: diskpar –I 2 – where 2 is the number of the disk you wish to check the alignment.
The important setting here is the StartingOffset – this value should divide cleanly by the NTFS cluster size implemented on the disk.
Ensure that Partition Offset ÷ Stripe Unit Size is a whole number (you will need to consult the storage configuration to identify stripe size).
Ensure that Stripe_Unit_Size ÷ File_Allocation_Unit_Size is also a whole number.
http://msdn.microsoft.com/en-us/library/dd758814%28v=sql.100%29.aspx
Configure MAXDOP
sp_configure ‘show advanced options’, 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure ‘max degree of parallelism’, 8;
GO
RECONFIGURE WITH OVERRIDE;
GO
The following commands can be used to move the log/data files for a SQL database Note this is an OFFLUINE process!
/* Find file locations for your database */
SELECT name, dbid FROM sysdatabases WHERE name = ‘lansweeperdb’
SELECT * FROM sys.master_files WHERE database_id = 16
/* Offline the Database */
ALTER DATABASE lansweeperdb SET OFFLINE;
/* Now move files, use the file names gather in step 1*/
ALTER DATABASE lansweeperdb
MODIFY FILE ( NAME = lansweeperdb, FILENAME = ‘E:\SQLDB\lansweeperdb.mdf’ );
ALTER DATABASE lansweeperdb
MODIFY FILE ( NAME = lansweeperdb_log, FILENAME = ‘E:\SQLDB\lansweeperdb_log.ldf’ );
/* Now online the database */
ALTER DATABASE lansweeperdb SET ONLINE;
]]>
When re-attaching a database I received an error “Database ‘Database_Name’ already exists.” There were no duplicate name databases with the instance, so this was incorrect.
After running the following SQL I found that the database was still ‘known:’
select name from sys.databases
To resolve the issue, execute the command below, changingt he database name:
DROP database ‘Database_Name’
Whilst working in a split domain, lets say Domain A and Domain B, environment we had a request for a user from Domain A to login using SQL Server Management Studio (SSMS) using Windows Credentials (Domain Account) to connect to a SQL instance using credentials from Domain B. The domains in this environment did not trust each other, they were isolated environments with only DNS stub-zones/secondary zones in place to ensure connetcivity to resources.
SSMS will not allow you to enter alternate Windows Credentials when connecting using Windows Authentication. It is however possible to achieve this using RunAs in the following way:
RUNAS /netonly /user:DOMAINB\user “C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”
You can even set this as a shortcut which will then prompt for the supplied username’s password and then exeute SSMS.
]]>