When developers and general IT staff double as accidental DBAs, you inevitably inherit:

-- Typical signs of neglect in uncontrolled environments
SELECT *
FROM sys.databases
WHERE compatibility_level < 140
  AND (user_access_desc != 'RESTRICTED_USER' 
       OR is_auto_close_on = 1)

1. Backup Strategy Red Flags
The sysadmin who suggests:

-- The "it'll never fail" backup plan
BACKUP DATABASE [CriticalDB] 
TO DISK = 'C:\Temp\backup.bak' 
WITH INIT, SKIP

Instead, watch for proper syntax like:

-- Proper backup with verification
BACKUP DATABASE [CriticalDB]
TO DISK = '\\SAN\SQLBackups\CriticalDB_FULL_$(date).bak'
WITH CHECKSUM, COMPRESSION, STATS = 10;
GO
VERIFYONLY FROM DISK = '\\SAN\SQLBackups\CriticalDB_FULL_$(date).bak'

Immediate concern if you see:

-- The "nuclear option" for permissions
GRANT CONTROL SERVER TO [Domain\Developers]
GO
EXEC sp_addsrvrolemember 'Domain\AppService', 'sysadmin'

Proper approach would be:

-- Principle of least privilege implementation
CREATE ROLE [DB_ReadOnly_Users];
GRANT SELECT TO [DB_ReadOnly_Users];
CREATE USER [Domain\ReportUser] FOR LOGIN [Domain\ReportUser];
ALTER ROLE [DB_ReadOnly_Users] ADD MEMBER [Domain\ReportUser];

Avoid admins who can't explain why this is problematic:

-- The "I read it on a forum" index approach
CREATE NONCLUSTERED INDEX [IX_Bad_Idea] 
ON [dbo].[LargeTable] ([CreatedDate])
INCLUDE ([ID], [Name], [Description], [...50 more columns...])

Warning sign if they dismiss the need for:

-- Basic health check queries every admin should run
SELECT TOP 10
    qs.execution_count,
    qs.total_logical_reads/qs.execution_count AS avg_logical_reads,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1) AS query_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
ORDER BY qs.total_logical_reads DESC;

Ask them to explain the implications of:

-- Transaction log handling scenarios
ALTER DATABASE [ProdDB] 
SET RECOVERY SIMPLE;
GO
-- Versus proper log management
ALTER DATABASE [ProdDB]
SET RECOVERY FULL;
GO
BACKUP LOG [ProdDB]
TO DISK = '\\SAN\SQLBackups\ProdDB_LOG_$(date).trn'

Demand these artifacts within the first 30 days:

• Recovery procedures for each SLA tier
• Customized DBCC CHECKDB schedules
• Index maintenance strategies per workload pattern
• Security audit procedures

---

Hiring a budget SQL Server sysadmin often leads to more expensive problems down the road. When you notice these warning signs in the first weeks, it's time to investigate deeper:

1. No Backup Verification:

-- Competent admins validate backups with RESTORE VERIFYONLY
RESTORE VERIFYONLY FROM DISK = 'C:\Backups\YourDB.bak' WITH FILE = 1

If they never test restore procedures, your disaster recovery is theoretical.

2. Inappropriate Authentication Practices:
Watch for SA account abuse or shared logins. Proper practice:

-- Should create individual logins with least privilege
CREATE LOGIN [Domain\JSmith] FROM WINDOWS
CREATE USER [JSmith] FOR LOGIN [Domain\JSmith]
EXEC sp_addrolemember 'db_datareader', 'JSmith'

1. Missing Maintenance Plans:

-- A competent admin would schedule at minimum:
EXEC sp_updatestats
DBCC CHECKDB('YourDB') WITH ALL_ERRORMSGS
-- Plus regular index maintenance

No evidence of scheduled integrity checks is alarming.

2. Performance Ignorance:
They should immediately run:

-- Key diagnostic queries
SELECT TOP 20 qs.execution_count, qt.text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_worker_time DESC

Not knowing these basics suggests deeper issues.

1. No Documentation:
Proper admins maintain runbooks with:

• Service accounts and their permissions
• Backup schedules and locations
• DR procedures with RTO/RPO metrics

2. Change Control Absence:
All production changes should follow:

-- Example change ticket template
/*
Change Request: CR-2023-08-001
Impact: High Availability Group configuration
Rollback Plan: Restore from snapshot
Tested In: DEV/UAT
Approval: DBA Team Lead
*/

Ad-hoc changes spell trouble.

Within the probation period, verify they can:

-- Demonstrate AlwaysOn configuration
SELECT ag.name AS [AG Name], ar.replica_server_name, ars.connected_state_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id

And understand security implications:

-- Should recognize dangerous permissions
SELECT pr.principal_id, pr.name, pr.type_desc, pe.permission_name, pe.state_desc
FROM sys.database_principals pr
JOIN sys.database_permissions pe ON pe.grantee_principal_id = pr.principal_id
WHERE pe.permission_name = 'CONTROL' OR pe.permission_name = 'ALTER'