Scribd
Upload
27 views3 pages

Audit_Points_Unmesh

Uploaded by

akshaykhandagale9
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
27 views3 pages

Audit_Points_Unmesh

Uploaded by

akshaykhandagale9
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Here’s how you can approach these questions for a Microsoft SQL Server

environment:
1. Database Monitoring Alerts (Transaction Logs, Connection Counts)
 Transaction Logs: Set up alerts for log file utilization, warning if it
exceeds a certain percentage (e.g., 80%). This helps prevent unexpected
log file growth and transaction issues.
 Connection Counts: Use SQL Server’s Performance Monitor counters
(e.g., "User Connections") to monitor the number of connections. Set
thresholds to alert if connections exceed expected limits, indicating
potential connection leaks or application issues.
2. Backup Strategy, Frequency, and Verification
 Strategy: Use a combination of full, differential, and transaction log
backups depending on recovery objectives.
 Frequency: Common practice is full backups daily, differential backups
every few hours, and transaction log backups every 15-30 minutes.
 Verification: Regularly restore backups to a test environment to verify
backup integrity. Additionally, check backup files with RESTORE
VERIFYONLY to ensure they are valid.
3. Monitoring for Full Table Scans
 Enable the SQL Server Profiler or use Extended Events to track queries
causing full table scans, which can lead to performance degradation.
Consider adding missing indexes or optimizing query designs to prevent
full scans.
4. Monitoring for Excessive/Surge Connections
 Configure alerts on "User Connections" in SQL Server Performance Monitor.
Sudden spikes in connections can indicate application issues or attacks,
and alerts should be sent if the connection count reaches predefined
thresholds.
5. Monitoring Transaction Log Sizing/Volume Trends
 Monitor transaction log growth in SQL Server Management Studio (SSMS)
or through Dynamic Management Views (DMVs) like sys.dm_db_log_stats.
This helps identify abnormal log growth, possibly from long-running
transactions or bulk operations.
6. Authentication and Access Control Strategy (RO/RW Segregation)
 Authentication: SQL Server supports both Windows Authentication and
SQL Server Authentication. Prefer Windows Authentication where possible
for integrated security.
 Access Control: Use roles to separate permissions. For read-only (RO)
and read-write (RW) access, create specific roles and assign users based
on their access requirements. Implement row-level security if needed for
finer control.
7. Monitoring Table Record/Row Counts and Trends
 Periodically log row counts using a scheduled job that queries
sys.partitions or similar views to monitor trends in data growth for
individual tables.
8. Monitoring Table Sizes and Trends
 Use sp_spaceused or DMVs like sys.dm_db_partition_stats to monitor the
size of tables. Log this data over time to analyze growth trends and
identify large tables that may impact performance.
9. Data Replication and Sharding Strategy (Consistency/Latency
Thresholds)

 Consistency/Latency Management: Mirroring in high-safety mode


ensures data consistency but may introduce slight latency. In
high-performance mode, mirroring minimizes latency, though
there may be minor delays in data synchronization.
 Monitoring: Mirroring can be monitored via SQL Server
Management Studio (SSMS), allowing you to track the health of
both the principal and mirror servers.
 Failover: Mirroring also supports automatic failover when using a
witness server, providing seamless recovery in case of server
failure.
 Sharding: SQL Server does not natively support sharding, but partitioning
can be used within a single database. For cross-database sharding, you
might need a custom approach or use SQL Server’s distributed partitioned
views.
 Consistency/Latency: Set SLAs around acceptable replication lag, and
monitor latency using SQL Server Replication Monitor.
10. Failover Strategy and Previous Failover Details
 Mirroring and Manual Failover: Ensure that the mirror database is
regularly synchronized and ready for manual failover when
required. High-safety mode with a witness can also support
failover, though it won’t be automatic without a witness
11. Monitoring DB Host Capacity (CPU, Memory, Appropriate Sizing)
 Use SQL Server's built-in monitoring tools or external monitoring solutions
to track CPU and memory usage on the server hosting SQL Server. Set up
alerts if usage exceeds thresholds (e.g., CPU > 80%, memory > 90%).
12. Database Purging and Archival Strategy
 Implement a purging policy based on data retention requirements. Use
scheduled jobs to archive or delete old data from production tables.
Archival can be done by moving data to a separate database or storage.
Ensure indexes on archived data for fast access if needed later.

You might also like