# any considerations before updating large table with pt-osc? **URL:** \ **Category:** Percona Toolkit\ **Created:** [May 19, 2020, 1:03am UTC](https://forums.percona.com/t/any-considerations-before-updating-large-table-with-pt-osc/7641 "2020-05-19T01:03:34Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![steven\_luyckx](https://avatars.discourse-cdn.com/v4/letter/s/f6c823/32.png) [@steven\_luyckx](https://forums.percona.com/u/steven_luyckx)\ **Post date:** [May 19, 2020, 1:03am UTC](https://forums.percona.com/t/any-considerations-before-updating-large-table-with-pt-osc/7641/1 "2020-05-19T01:03:34Z")
I want to update a table that holds just under 1 billion rows and 200GB of data. I’m confident that I can use the pt-osc for this. But are there any considerations to take into account? For example: staying away from backup windows, etc. ---
**Author:** ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)\ **Post date:** [May 19, 2020, 1:17am UTC](https://forums.percona.com/t/any-considerations-before-updating-large-table-with-pt-osc/7641/2 "2020-05-19T01:17:20Z")
Here are some pre-flight checks: - Make sure there are no long running transactions at the start of the operation and before the RENAME stage of pt-osc. - Make sure to check if there are any foreign keys - Check for triggers, latest MySQL version should support triggers but it would be best to test first with --dry-run option before --execute - Where are you going to use pt-osc eg. standalone, master-slave, PXC/Galera cluster, etc? - Generally we recommend testing in your staging environment with similar setup to check if everything goes well before doing it in production. ---
**Author:** ![steven\_luyckx](https://avatars.discourse-cdn.com/v4/letter/s/f6c823/32.png) [@steven\_luyckx](https://forums.percona.com/u/steven_luyckx)\ **Post date:** [May 19, 2020, 2:05am UTC](https://forums.percona.com/t/any-considerations-before-updating-large-table-with-pt-osc/7641/3 "2020-05-19T02:05:50Z")
Thanks jrivera for the quick answer!The update has already been applied to test and acceptance systems, in each case first with the --dry-run option.Databases were updated successfully, but both databases are tiny in size compared to the production database.Yes, the table has foreign keys pointing to other tables. I’m using the --alter-foreign-keys-method auto parameter for that.The table is never part of long running transactions. That is for sure.The database is part of a MASTER-SLAVE setup. I’m using the --recursion-method hosts parameter for that.Anything else that should need my attention prior to the update?So, generally speaking, there is no size/rowcount restriction to the usage of pt-osc, correct? ---
**Author:** ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)\ **Post date:** [May 19, 2020, 2:11am UTC](https://forums.percona.com/t/any-considerations-before-updating-large-table-with-pt-osc/7641/4 "2020-05-19T02:11:41Z")
There is no size or row count limitation but the bigger the table (row count) the longer the pt-osc will take. If you have reads going to the slaves and you don’t want the slaves to lag too much you may want to add --check-slave-lag and --max-lag. Do not execute pt-osc from the slave side or else you’d encounter this - [pt-online-schema-change (if misused) can't save the day - Percona Database Performance Blog](https://www.percona.com/blog/2016/05/24/pt-online-schema-change-if-misused-cant-save-the-day/) ---
**Author:** ![steven\_luyckx](https://avatars.discourse-cdn.com/v4/letter/s/f6c823/32.png) [@steven\_luyckx](https://forums.percona.com/u/steven_luyckx)\ **Post date:** [May 19, 2020, 2:23am UTC](https://forums.percona.com/t/any-considerations-before-updating-large-table-with-pt-osc/7641/5 "2020-05-19T02:23:38Z")
Thanks again. I will continue with confidence then 😉