Comments (0)

Symptoms
When you install SQL Server 2000 Service Pack 3 (SP3), a Microsoft Windows user account named SQLDebugger is created. This article discusses the SQLDebugger account, including when the account is created, the default permissions that are assigned to the account, and when the account is used.
Resolution
The SQLDebugger Windows user account is created when the SQL Debugger Registry2 DCOM server process (Sqldbreg2.exe) is registered. By default,SQL Server 2000 SP3 registers this process, and the SQLDebugger Windows user account is created.
SQL Query Analyzer includes T-SQL Debugger. By using T-SQL Debugger, you can control and monitor how stored procedures run. T-SQL Debugger uses the SQLDebugger Windows user account to connect to the database server.
Microsoft Visual Studio .NET applications use SQL Server Debugging to debug SQL Server stored procedures. The SQLDebugger Windows user accountis also created when you install Visual Studio .NET.
Note The SQLDebugger account is created by usinga strict random password policy for security purposes. If the password does not comply with the effective local password complexity policy, the SQLDebugger account is not created and the DCOM server is registered to run under the interactive user account. This prevents SQL Server Debugging from working correctly when you run Visual Studio .NET in the Terminal Services client session.
The SQLDebugger Windows user account has the following characteristics : It belongs to the built-in Windows Users group. It does not have local logon rights.
Note The Deny logon locally security setting is set for the SQLDebugger account.You can log on to the SQLDebugger account by using a batch-queue facility.
Note The Log on as a batch job security setting is set for the SQLDebugger account.By default, the User cannot change password and Password never expires options are set. System users do not have default permissions to use this Windows user account to explicitly connect to the computer running SQL Server.
Warning Microsoft recommends that the administrator of the computer where the database server is installed and the database administrator should not give any explicit permissions to this account. Explicit permissions to this account may lead to security vulnerabilities.
If you do not want to use SQL Server Debugging against the computer running SQL Server, you can delete the SQLDebugger Windows user account. For additional information about how to enable SQL Server Debugging, click the following article number to view the article in the Microsoft Knowledge Base:
318632?(http://support.microsoft.com/kb/318632/EN-US/) FIX: SQL Debugging May Fail Because of Strict Local Password Complexity Policy

Comments (0)

Symptoms
This article describes the following about this hotfix release: The issues that are fixed by this hotfix packageThe prerequisites for applying this hotfix packageWhether you must restart the computer after you apply this hotfix packageWhether this hotfix package is replaced by any other hotfix packageWhether you must make any registry changes after you apply this hotfix packageThe files that are contained in this hotfix package
Resolution
In Microsoft SQL Server 2000, the synchronization process may take a long time when you synchronize merge replication publications. You may experience this problem if you have created many generations of the publication since the last time that you synchronized the merge replications.
For a list of all publicly released SQL Server 2000 post-service pack hotfixes, see the following article in the Microsoft Knowledge Base:
894905?(http://support.microsoft.com/kb/894905/) Cumulative list of the hotfixes that are available for SQL Server 2000 SP4

Comments (0)

Symptoms
SQL Server may experience the following assertion, and a 3314 error message occurs if SQL Server tries to roll back a text operation when a connection is running with the READ UNCOMMITTED transaction isolation level set on the connection:

2002-03-14 10:31:48.95 kernelSQL Server Assertion: File: <page.cpp>, line=2825 Failed Assertion = ‘sid >= m_slotCnt || m_slots[-sid].offset ==0′. Additionally, on SQL Server 2000, the following assertion may also be present in the SQL Server error log:

2002-08-23 10:21:14.39 spid54SQL Server Assertion: File: <logscan.cpp>, line=3049 Failed Assertion = ‘(m_lastLSN == NullLSN) || (m_lastLSN > m_curLSN)’.2002-03-14 10:32:03.02 spid9Error: 3314, Severity: 21, State: 42002-03-14 10:32:03.02 spid9Error while undoing logged operation in database ‘myDB’. Error at log record ID (8976:897:74).. On SQL Server 2000, the following message may accompany the 3314 error message:

2002-08-23 10:21:14.68 spid54Error: 9004, Severity: 23, State: 72002-08-23 10:21:14.68 spid54An error occurred while processing the log for database ‘myDB’..
Resolution
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem.
If the hotfix is available for download, there is a “Hotfix download available” section at the top of this Knowledge Base article. If this section does not appear, submit a request to Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or tocreate a separate service request, visit the following Microsoft Web site:
http://support.microsoft.com/contactus/?ws=support(http://support.microsoft.com/contactus/?ws=support)Note The “Hotfix download available” form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.The English version of the SQL Server 2000 fix should have the following file attributes or later:

DateVersionSizeFile name———————————————————————–05-SEP-20028.00.6827,467,089 bytesSqlservr.exeSP2-Based Fix NOTE: The SQL Server 2000 based fix will be included in Microsoft SQL Server 2000 Service Pack 3 (SP3).
The English version of the SQL Server 7.0 fix should have the following file attributes or later:

DateVersionSizeFile name———————————————————————–15-MAR-20027.00.10265,054,736 bytesSqlservr.exeSP3-Based Fix14-FEB-20027.00.1021586,000 bytesSqlsort.dllSP3-Based Fix14-MAY-20027.00.10715,058,832 bytesSqlservr.exeSP4-Based Fix NOTE: Because of file dependencies, the most recent hotfix or feature that contains the files may also contain additional files.
NOTE: The fix for this bug will be included in SQL Server 2000 Service Pack 3.

Comments (0)

Symptoms
This article describes the steps that you must follow when the transaction logs expand to an unacceptable limit. The expansion of the transaction logs can make your Microsoft SQL Server database unusable. Thisarticle also provides the options that you can use to stop the transaction logs from growing unexpectedly.

Resolution
In SQL Server 2000 and in SQL Server 2005, each database contains at least one data file and one transaction log file. SQL Server stores the data physically in the data file. The transaction log file stores the details of all the modifications that you perform on your SQL Server database and the details of the transactions that performed each modification. Because thetransactional integrity is considered a fundamental and intrinsic characteristic of SQL Server, logging the details of the transactions cannot be turned off in SQL Server.
The transaction log file is logically divided into smaller segments that are referred to as virtual log files.In SQL Server 2000, you can configure the transaction log file to expand as needed. The transaction log expansion can be governed by the user or can be configured to use all the available disk space. Any modifications that SQL Server makes to the size of the transaction log file, such as truncating the transaction log files or growing the transaction log files, are performed in units of virtual log files.
If the transaction log file that corresponds to a SQL Server database is filled and if you have set the option for the transaction log files to grow automatically, the transaction log file grows in units of virtual log files. Sometimes, the transaction log filemay become very large and you may run out of disk space. When a transaction log file grows until the log file uses all the available disk space and cannot expand any more, you can no longer perform any data modification operations on your database. Additionally, SQL Server may mark your database assuspect because of the lack of space for the transaction log expansion.
For additional information about the scenarios that may cause the transaction log file to grow unexpectedly, click the following article number to view the article in the Microsoft Knowledge Base:
317375?(http://support.microsoft.com/kb/317375/) Transaction log grows unexpectedly or becomes full on SQL Server
Reduce the size of the transaction logsTo recover from a situation where the transaction logs grow to an unacceptable limit, you must reduce the size of the transaction logs. To do this, you must truncate the inactive transactions in your transaction log and shrink the transaction log file.
Note The transaction logs are very important to maintain the transactional integrity of the database. Therefore, you must not delete the transaction log files even after you make a backup of your database and the transaction logs.
Truncate the inactive transactions in your transaction log When the transaction logs grow to an unacceptable limit, you must immediately back up your transaction log file. While thebackup of your transaction log files is created, SQL Server automatically truncates the inactive part of the transaction log. The inactive part of the transaction log file contains the completed transactions, and therefore, the transaction log file is no longer used by SQL Server during the recovery process. SQL Server reuses this truncated, inactive space in the transaction log instead of permitting the transaction log to continue to grow and to use more space.
For additional information about the issues that you must consider when you make a backup of the transaction logs and the issues that you must consider when you restore the transaction log backups, visit the following topics in SQL Server Books Online:Transaction log backupsTransaction log backup and restoreYou can also delete the inactive transactions from a transaction log file by using the Truncate method. For additional information about truncating the transaction logs, see the “Truncating the transaction log” topic in SQL Server Books Online.
Important After you manually truncate the transaction log files, you must create a full database backup before you create a transaction log backup.
For additional information about the issues that may occur when you truncate the transaction log files, click the following article number to view the article in the Microsoft Knowledge Base:
62866?(http://support.microsoft.com/kb/62866/) Reasons why SQL transaction log is not being truncatedShrink the transaction log file The backup operation or the Truncate method does not reduce the log file size. To reduce the size of the transaction log file, you must shrink the transaction log file. To shrink a transaction log file to the requested size and to remove the unused pages, you must use the DBCC SHRINKFILE operation. The DBCC SHRINKFILE Transact-SQL statement can only shrink the inactive partinside the log file.
Note The DBCC SHRINKFILE Transact-SQL statement cannot truncate the log and shrink the used space inside the log file on its own.
For more information about shrinking the transaction log files, see the following topics in SQL Server Books Online:Shrinking the transaction logDBCC SHRINKFILEFor additional information about how to shrink the transaction log files in SQL Server 2000, click the following article number to view the article in the Microsoft Knowledge Base:
272318?(http://support.microsoft.com/kb/272318/) Shrinking the transaction log in SQL Server 2000 with DBCC SHRINKFILEFor additional information about the problems that may occur when you shrink the transaction log files, click the following article numbers to view the articles in the Microsoft Knowledge Base:
814574?(http://support.microsoft.com/kb/814574/) PRB: Error message: “Cannot shrink log file …” occurs when you shrink the transaction log file
324432?(http://support.microsoft.com/kb/324432/) PRB: DBCC SHRINKFILE and SHRINKDATABASE commands may not work because of sparsely populated text, ntext, or image columns
Prevent thetransaction log files from growing unexpectedlyTo prevent thetransaction log files from growing unexpectedly, consider using one of the following methods:Set the size of the transaction log files to a large value to avoid the automatic expansion of the transaction log files. Configure the automatic expansion of transaction log files by using memory units instead of a percentage after you thoroughly evaluate the optimum memory size.
For additional information about the issues to consider when you configure the autogrow option, click the following article number to view the article in the Microsoft Knowledge Base:
315512?(http://support.microsoft.com/kb/315512/) Considerations for autogrow and autoshrink configurationChange the recovery model. If a disaster or data corruption occurs, you must recover your database so that the data consistency and the transactional integrity of the database are maintained. Based on how critical the data in your database is, you can use one of the following recovery models to determine how your data is backed up and what your exposure to the data loss is:Simple recovery modelFull recovery modelBulk-logged recovery modelBy using the simple recovery model, you can recover your database to themost recent backup of your database. By using the full recovery model or the bulk-logged recovery model, you can recover your database to the point when the failure occurred by restoring your database with the transaction log file backups.
By default, in SQL Server 2000 and in SQL Server 2005, the recovery model for a SQL Server database is set to the Full recovery model. With the full recovery model, regular backups of the transaction log are used to prevent the transaction log file size from growing out of proportion to the database size. However, if the regular backups of the transaction log are not performed, the transaction log file grows to fill the disk, and you may not be able to perform any data modification operations on the SQL Server database.
You canchange the recovery model from full to simple if you do not want to use the transaction log files during a disaster recovery operation.Back up the transaction log files regularly to delete the inactive transactions in your transaction log.Design the transactions to be small.Make sure that no uncommitted transactions continue to run for an indefinite time.Schedule the Update Statistics option to occur daily.To defragment the indexes to benefit the workload performance in your production environment, use the DBCC INDEXDEFRAG Transact-SQL statement instead of the DBCC DBREINDEX Transact-SQL statement. If you run the DBCC DBREINDEX statement, the transaction log may expand significantly when your SQL Server database is in Full recovery mode. Additionally, the DBCC INDEXDEGRAG statement does not hold the locks for a long time, unlike the DBCC DBREINDEX statement.
For additional information about defragmenting the indexes in SQL Server 2000, see the following Microsoft Web site:
http://technet.microsoft.com/en-us/library/cc966523.aspx(http://technet.microsoft.com/en-us/library/cc966523.aspx) If you must run the DBCC DBREINDEX statement as a job that is a part of the database maintenance plan, you must break up the job into multiple jobs. Additionally, you must take the frequent backups for the transaction logs between the execution of thejobs.