“Always Learning, Always Improving”
Cross
“Always Learning, Always Improving” | “கற்றது கைமண் அளவு, கல்லாதது உலகளவு” | “What you have learned is a mere handful of sand, but what you haven’t learned is the size of the world.”
MADURAIKARAN
“Love the Lord your God with all your heart and with all your soul and with all your strength.”
DB
VEERAKUMAR
Technology • Trading • Spirituality • History
Welcome to my journey

My Journey of Learning & Discovery

Technology | NSE Options Trading | Spirituality | World & Evolution | History

Sharing my personal journey, research, experiences and continuous learning across technology, NSE options trading, spirituality, world evolution and history.

Explore Blog → About Me
Veerakumar profile photo
DATA ENGINEERING
Microsoft SQL Server logo SQL SERVER
Oracle logo ORACLE
MySQL logo MySQL
Databases • ETL • Data Warehousing • Performance
DB

Technology

SQL Server, databases, AI, programming and the evolution of technology.

EXPLORE →

NSE Index Options Trading

NIFTY, BANK NIFTY, option strategies, trading psychology and my journal.

EXPLORE →

Spirituality

Personal reflections, philosophy, spirituality and questions about life.

EXPLORE →

World & Evolution

Human history, civilization, science and how the world and technology evolve.

EXPLORE →

Latest Articles

SQL SERVER – 15 Best Practices for Better Database Performance:

SQL SERVER – 15 Best Practices for Better Database Performance:

1. Store relevant and necessary information in the database instead of application structure or array.
2. Use normalized tables in the database. Small multiple tables are usually better than one large table.
3. If you use any enumerated field to create look up for it in the database itself to maintain database integrity.
4. Keep primary key of lesser chars or integer. It is easier to process small width keys.
5. Store image paths or URLs in database instead of images. It has less overhead.
6. Use proper database types for the fields. If StartDate is database filed use date time as datatypes instead of VARCHAR (20).
7. Specify column names instead of using * in SELECT statement.
8. Use LIKE clause properly. If you are looking for exact match use “=” instead.
9. Write SQL keyword in capital letters for readability purpose.
10. Using JOIN is better for performance than using sub queries or nested queries.
11. Use stored procedures. They are faster and help in maintainability as well security of the database.
12. User comments for readability as well as guidelines for the next developer who comes to modify the same code. Proper documentation of application will also aid help too.
13. Proper indexing will improve the speed of operations in the database.
14. Make sure to test it any of the database programming as well administrative changes.
15. ______________________________________________________________
Let me know what should be the 15th best practice.







Frequently Raised Errors in Log-Shipping



Frequently Raised Errors in Log-Shipping

1. Question : IS it possible to log ship database between SQL 2000 & SQL 2008?
 Answer: No, thats impossible, In SQL 2008 transaction log architecture is changed compared to SQL 2000 and hence you won’t be able to restore tlog backups from SQL 2000 to SQL 2008 or vice versa.
2. Question:I’m getting the below error message in restoration job on secondary server, WHY?
[Microsoft SQL-DMO (ODBC SQLState: 42000)]
Error 4305: [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set begins at LSN 7000000026200001, which is too late to apply to the database. An earlier log backup that includes LSN 6000000015100001 can be restored.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
Answer: Was your sql server or agent restarted Y’day in either source or destination ? because the error states there is a mismatch in LSN. A particular tran log was not applied in the destination server hence the subsequent tran logs cannot be applied as a result !
You can check log shipping monitor \ log shipping tables to check the which transaction log is last applied to secondary db, if the next consecutive transaction logs are available in the secondary server share folder you manually RESTORE the logs with NORECOVERY option, Once you restored all the logs automatically from the next cycle the job will work fine.
Incase if you are not able to find the next transaction log in secondary server shared folder, you need to reconfigure log shipping. Try the below tasks to re-establish log shipping again.

Disable all the log shipping jobs in source and destination servers
Take a full backup in source and restore it in secondary server using the With Standby option
Enable all the jobs you disabled previously in step1
3. Question: Is it possible load balance in log shipping?
Answer: Yes of course it’s possible in log shipping, while configuring log shipping you have the option to choose standby or no recovery mode, and there you select STANDBY option to make the secondary database read-only.
4. Question: Can I take full backup of the log shipped database in primary server??
Answer: In SQL Server 2000 you won’t be able to take full backup of log shipped database, because this will break the LSN chain and it directly affects the log shipping.
In SQL Server 2008, yes its possible. You can take full backup of log shipped database and this won’t affect the log shipping.
In SQL Server 2008, yes its possible. You can take full backup of log shipped database and this won’t affect the log shipping.
5. Question : Can I shrink log shipped database log file??
Answer: Yes of course you can shrink the log file, but you shouldn’t use WITH TRUNCATE option. If you use this option obviously log shipping will be disturbed.
6. Can I take full backup of the log shipped database in secondary server?
Answer: No chance, you won’t be able to execute BACKUP command against a log shipped database in secondary server.
7. I’ve configured Log shipping successfully on standby mode, but in the restoration job I’m getting the below error. What I do to avoid this in future??
Message
2006-07-31 09:40:54.33 *** Error: Could not apply log backup file ‘C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\LogShip\TEST_20060731131501.trn’ to secondary database ‘TEST’.(Microsoft.SqlServer.Management.LogShipping) ***
2006-07-31 09:40:54.33 *** Error: Exclusive access could not be obtained because the database is in use.
RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) ***
Answer: To restore transaction logs to the secondary db, SQL Server needs exclussive access on the database. When you configure it in standby mode, users will be able to access the database and runs query against the secondary db. Hence If the scheduled restore jobs runs at that time, the db will have a lock and it won’t allow SQL Server to restore the tlogs. To avoid this you need to check “Disconnect users in the database when restoring backups” options in log shipping configuration wizard.
8. Question : Suddenly I’m getting the error below, How can I rectify this?
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally
Answer : We had the same issue some time ago, this was related to a new file being created in a filegroup on the source. Don’t know if this applies to your case, but restoring a backup of this new file on the secondary server solved the problem.
9. Question : Is it possible to log ship database from SQL server 2005 to SQL server 2008 and vice versa?
Answer : Yes you can log ship database from SQL server 2005 to SQL Server 2008 this will work. However log shipping from SQL Server 2008 to SQL Server 2005 is not possible because you won’t be able to restore SQL server 2008 backup to SQL Server 2005 (downgrading version)
1. Error message 14420 and error message 14421 that occur when you use log shipping:
Error message 14420 Error: 14420, Severity: 16, State: 1
The log shipping destination %s.%s is out of sync by %s minutes.
The log shipping destination %s.%s is out of sync by %s minutes.
Error message 14421 Error: 14421, Severity: 16, State: 1
The log shipping destination %s.%s is out of sync by %s minutes.
The log shipping destination %s.%s is out of sync by %s minutes.
If you are using SQL Server 2008, the description for these error messages are different:
Error message 14420 Error: 14420, Severity: 16, State: 1
The log shipping primary database %s.%s has backup threshold of %d minutes and has not performed a backup log operation for %d minutes. Check agent log and logshipping monitor information.
The log shipping primary database %s.%s has backup threshold of %d minutes and has not performed a backup log operation for %d minutes. Check agent log and logshipping monitor information.

Error message 14421 Error: 14421, Severity: 16, State: 1
The log shipping secondary database %s.%s has restore threshold of %d minutes and is out of sync. No restore was performed for %d minutes. Restored latency is %d minutes. Check agent log and logshipping monitor information.
The log shipping secondary database %s.%s has restore threshold of %d minutes and is out of sync. No restore was performed for %d minutes. Restored latency is %d minutes. Check agent log and logshipping monitor information.

Welcome to my blog!


Hello, readers!🙏வணக்கம்  வாசகர்களே!

Welcome to my blog!🙏. I'm Veerakumar, and I have to share my inspiring journey of professional growth and career transitions. In 2010, I graduated with a Bachelor's degree in Mechanical Engineering, laying the foundation for my future endeavors.
From 2010 to 2012, I embarked on a role as a Quality Control Engineer, where I applied my expertise to ensure product excellence and maintain high standards. This experience allowed me to develop a keen eye for detail and a commitment to delivering top-notch results.
In 2014, driven by my passion for technology, I took a leap of faith and ventured into the exciting world of IT. I embraced the role of an IT Support Engineer, providing technical assistance, troubleshooting hardware and software issues, and ensuring smooth operations for my organization. This marked the beginning of my journey in the vast and ever-evolving field of information technology. one of my most well wisher (Selventhiran Maplaji) guide me and changed me into Sqlserver DBA environment.
In 2017, I expanded my skills further and transitioned into the role of a Microsoft SQL Server Database Administrator (DBA). This shift allowed me to delve into the intricacies of database administration, including tasks such as creating logins and users, granting permissions, and monitoring server performance. I thrived in this role, providing 24x7 support, collaborating with the DBA team, and resolving database-related issues with efficiency.
Throughout my journey, I've had the privilege of gaining diverse experiences and acquiring valuable skills. In this blog, I aim to share my knowledge, experiences, and insights, providing practical tips, best practices, and innovative solutions related to  database server administration.
Thank you for joining me on this exciting adventure, and I look forward to engaging with each and every one of you!

Best regards,
Veerakumar| veerakumarakkini.a27@outlook.com






I would like to share with you what I have learned and I hope it will be useful for you. _V€€RAKUMAR

Mastering SQL Server

Search This Blog

Powered by Blogger.

Mastering SQL Server

Labels


Translate

Restarting my career from where I left off. With hands-on experience as a Microsoft SQL Server DBA, I have developed skills in database mana...