E9 to E10 Migration - Massive log file

Yahoo Archive
1
Thanks Joshua.
I will give that a try.





Joe Rojas | Director of Information Technology | Mats Inc
dir: 781-573-0291 | cell: 781-408-9278 | fax: 781-232-5191

addr: 37 Shuman Ave | Stoughton | Ma | 02072-3734
jrojas@... | www.matsinc.com
Ask us about our clean, green and beautiful matting and flooring

[cid:41c99d.png@2fac268b.45ba5a45]
This message is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.


From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com]
Sent: Wednesday, September 24, 2014 10:52 AM
To: vantage@yahoogroups.com
Subject: [Vantage] RE: E9 to E10 Migration - Massive log file


Enable simple recover on the database for the upgrade

Joshua Giese
CIO

Direct: 920.593.8299
IT Dept: 920.437.6400 Ext. 337
Site ID: 27450-E905700B2-SQL64
Wisconsin Converting, Inc.

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com]
Sent: Wednesday, September 24, 2014 9:50 AM
To: vantage@yahoogroups.com
Subject: [Vantage] E9 to E10 Migration - Massive log file



Hi All,

Everything was going great during the migration process from E9 to E10.

I got to the last step, 2000 Run all triggers, indexes, foreign keys and post scripts, and during the step that updates all configurator tables to update input names that have a “-“, the hard drive got full because of log file growth and then bombed out. The log file was over 70GBs when it filled the hard drive, which is odd because the MDF file is only 20GB. Yes, our configurator tables are that big!

Luckily I had taken a backup before getting to this step so I’ve backed up and shrunk the log file and then restore the DB. I’m rerunning all required migration steps up to step 2000.

My question is, what are people’s thoughts on how to best manage this log file issue so it doesn’t happen again.

I was wondering if temporarily setting the database recovery model to simple might work but I don’t know if this will prevent the log file from growing while this process is running. Does this bypass the log file or just auto shrink it when not in use?
Unfortunately, this test server has limited drive space but I might be able to move the log file to another drive. Not sure yet.




Joe Rojas | Director of Information Technology | Mats Inc
dir: 781-573-0291 | cell: 781-408-9278 | fax: 781-232-5191

addr: 37 Shuman Ave | Stoughton | Ma | 02072-3734
jrojas@...<mailto:jrojas@...> | www.matsinc.com<http://www.matsinc.com>
Ask us about our clean, green and beautiful matting and flooring

[cid:50fde1.png@b07f58e8.469a0324]
This message is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.



[Non-text portions of this message have been removed]



[Non-text portions of this message have been removed]
2
Hi All,

Everything was going great during the migration process from E9 to E10.

I got to the last step, 2000 Run all triggers, indexes, foreign keys and post scripts, and during the step that updates all configurator tables to update input names that have a “-“, the hard drive got full because of log file growth and then bombed out. The log file was over 70GBs when it filled the hard drive, which is odd because the MDF file is only 20GB. Yes, our configurator tables are that big!

Luckily I had taken a backup before getting to this step so I’ve backed up and shrunk the log file and then restore the DB. I’m rerunning all required migration steps up to step 2000.

My question is, what are people’s thoughts on how to best manage this log file issue so it doesn’t happen again.

I was wondering if temporarily setting the database recovery model to simple might work but I don’t know if this will prevent the log file from growing while this process is running. Does this bypass the log file or just auto shrink it when not in use?
Unfortunately, this test server has limited drive space but I might be able to move the log file to another drive. Not sure yet.




Joe Rojas | Director of Information Technology | Mats Inc
dir: 781-573-0291 | cell: 781-408-9278 | fax: 781-232-5191

addr: 37 Shuman Ave | Stoughton | Ma | 02072-3734
jrojas@... | www.matsinc.com
Ask us about our clean, green and beautiful matting and flooring

[cid:50fde1.png@b07f58e8.469a0324]
This message is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.




[Non-text portions of this message have been removed]
3

Enable simple recover on the database for the upgrade

 

Joshua Giese

CIO

 

Direct:     920.593.8299

IT Dept:   920.437.6400 Ext. 337

Site ID:    27450-E905700B2-SQL64

Wisconsin Converting, Inc.

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com]
Sent: Wednesday, September 24, 2014 9:50 AM
To: vantage@yahoogroups.com
Subject: [Vantage] E9 to E10 Migration - Massive log file

 

 

Hi All,

Everything was going great during the migration process from E9 to E10.

I got to the last step, 2000 Run all triggers, indexes, foreign keys and post scripts, and during the step that updates all configurator tables to update input names that have a “-“, the hard drive got full because of log file growth and then bombed out. The log file was over 70GBs when it filled the hard drive, which is odd because the MDF file is only 20GB. Yes, our configurator tables are that big!

Luckily I had taken a backup before getting to this step so I’ve backed up and shrunk the log file and then restore the DB. I’m rerunning all required migration steps up to step 2000.

My question is, what are people’s thoughts on how to best manage this log file issue so it doesn’t happen again.

I was wondering if temporarily setting the database recovery model to simple might work but I don’t know if this will prevent the log file from growing while this process is running. Does this bypass the log file or just auto shrink it when not in use?
Unfortunately, this test server has limited drive space but I might be able to move the log file to another drive. Not sure yet.




Joe Rojas | Director of Information Technology | Mats Inc
dir: 781-573-0291 | cell: 781-408-9278 | fax: 781-232-5191

addr: 37 Shuman Ave | Stoughton | Ma | 02072-3734
jrojas@... | www.matsinc.com
Ask us about our clean, green and beautiful matting and flooring

[cid:50fde1.png@b07f58e8.469a0324]
This message is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.



[Non-text portions of this message have been removed]