Re: store transaction rollback information
On 26 Jul 2012, at 21:43, James Devine wrote: > I have a large series of mysql changes(inserts/deletes/updates) taking > place in a transaction. After committing there may be some times where I > need to roll those changes back later on. Is there an easy way of > determining what was changed in a transaction in a way I can store it and > rollback later? James, The way you describe it sounds like you have a modeling issue with your system. Committed transactions are not supposed to be rolled back. Your System Architect has to arrange things in such a way that all the information required to decide if a change to the database can be made permanent is available to the application *before* COMMIT-time. Until then, you're supposed to hold your transaction (and all locks resulting from it) open and uncommitted. In other words: once a transaction is committed, the changes are permanent. Rolling it back may still be possible, but it will be complicated and extremely expensive, computationally speaking. I strongly recommend you to review your design choices. I hope this helps. Kind regards, -- Luis Motta Campos is a DBA, Foodie, and Photographer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Commit commands with SELECT
Hello COMMIT statements may or may not force the database to call fflush() to flush your double-write to disk. This may or may not affect your performance, depending on your scale, traffic, and how much you're trying to squeeze your hardware. If you're working on the borderline like I am, benchmark, benchmark, benchmark. My 0.02€. Kind regards, -- Luis Motta Campos is a DBA, Foodie, and Photographer On 9 Apr 2012, at 20:47, Karen Abgarian wrote: > I vote 1) yes 2) no > > It could be result of the app developer's convenience to just wrap anything > they submit to the database in a transaction. Selects are not transaction > but autocommit/commit do no harm. That might be the thinking. > > > On 09.04.2012, at 11:38, Rozeboom, Kay [DAS] wrote: > >> We have an application with blocks of code that begin with setting >> autocommit off, and end with a commit. The code in between does only >> selects, no updating. >> >> 1) Am I correct in thinking that the autocommit and commit statements >> don't really accomplish anything useful? >> >> 2) If the autocommit and commit statements are unneeded, do they add >> enough additional overhead that I should be concerned about them? >> >> Kay Rozeboom >> Information Technology Enterprise >> Iowa Department of Administrative Services >> Telephone: 515.281.6139 Fax: 515.281.6137 >> Email: kay.rozeb...@iowa.gov >> >> >> > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe:http://lists.mysql.com/mysql > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Tuning mysql
On 7 Feb 2012, at 00:55, Grant wrote: > I'm running mysql on Gentoo with 4GB RAM and I'm wondering if I should > change any settings. I'm using mysql with a website on the same > server so I have skip-networking, and I increased key_buffer and > innodb_buffer_pool_size from 16M to 256M. Everything else is default. > Should I consider changing these or any other settings? Grant, What I usually recommend about database tuning: 1. Visibility. There's no way you can see if your changes are good or bad for performance if you don't have a waterline and visibility. I recommend you to pick your favourite performance graphing tool and ensure we have good graphs available for all the most important key performance indicators that you can think of. The more graphs, the easier it gets to spot bottlenecks and understand root-causes of performance issues. 2. Monogamy Tuning MySQL databases that mix MyISAM and InnoDB storage engines is hard and tricky. If you have the chance, I strongly recommend you choosing one storage engine and sticking to it above everything else. This might sound like a hard choice to make in the beginning but it will pay you back with good dividends later on, both in improved performance and lower resource consumption than the equivalent databases with hybrid storage engine options. 3. Control Before you start making changes to your configuration, I strongly recommend you to version-control it. I used to use and recommend RCS for this, but Git is a more modern, yet flexible and powerful version control to which I've feel in love. Version controlling your changes gives you control over your configuration and helps determining what changes happened in which order and when. This helps you pin-pointing results of your changes on your graphs and correlating what you do with how the server reacts. 4. Logs Make sure you enable all the information you can about your slow-query log, this is an essential part of detecting query and schema related bottlenecks. Here at the office we use Percona Patched MySQL databases, and I usually enable all the Percona-provided extensions to the slow query log. 5. Work Holistically Database Tuning isn't an isolated process. You should start from a "best guess" configuration and work in cycles towards a configuration that satisfies your needs without compromising more resources than you have available. Remember, there's no point in adjusting a couple of database variables without understanding what it means for the application and for the queries / schema. Make sure you include your developers (if you're not one of them) and take into consideration all the information you have at hand. I hope this helps with getting started. Good luck, and kind regards. -- Luis Motta Campos is a DBA, Foodie, and Photographer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: add index to slave but not master
On 31 Oct 2011, at 08:46, Jeff Pang wrote: > Hello, > > I have a question that, if I add the index to the table in slave, but > don't do it in master, will it make problems? Jeff, I manage some big data here and this is my preferred strategy - shard the workload in different mysql pools (behind a load balancer) and give each different pool a different, custom-tailored index set optimized for the workload expected. Be warned that if you promote a new master without ensuring index-compatibility with the master workload you will (obviously) observe performance variations. Good luck. Cheers! -- Luis Motta Campos is a DBA, Foodie, and Photographer -- Luis Motta Campos is a DBA, Foodie, and Photographer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: importing mysql structures only or restore ignoring non-existing tables and columns?
On 29 Oct 2011, at 22:59, luci spam wrote: > I have 2 servers (1 for development, 1 for service) > > I keep ADD/DELETE columns and CREATE/DELETE Indexes on my development > server, so these 2 server have similar but different mysql data structures. > > I know there's an option to expert structures only. (like –no-data) > > Is there a way (except 3rd party software like mysqldiff.org) to import > structure only to an existing data? > Alternativley, is there a way to import only data ignoring non-existing > tables and colums? (I thought this may do the trick if I back-up data -> > import structure -> restore the data.) You can use SELECT...INTO DUMPFILE and LOAD DATA INFILE... to achieve what I believe you're asking here, save the eventual misunderstanding. ;-) Cheers -- Luis Motta Campos is a DBA, Foodie, and Photographer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: how to understand seconds_behind_master
On 28 Oct 2011, at 10:03, 王科选 wrote: > According to , > > seconds_behinds_master is inaccurate, so I just skipped how it works... > If you want to measure slave lag, follow that book's suggestion: > One good solution is a heartbeat record,which is a timestamp that you update > once persecond on the master.To calculate the lag,you can simply subtract the > heartbeat from the current timestamp on the slave. This assumes updates and inserts happen at the same speed on the master and slave. If your assumption is not true (e.g., slaves with SSD disks; or with different indexes than the master; or with locked tables because of long-running-queries), this will be as precise as seconds-behind-master, no more than a lousy estimate. Cheers. -- Luis Motta Campos is a DBA, Foodie, and Photographer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: 5.1.51 Database Replica Slows Down Suddenly, Lags For Days, and Recovers Without Intervention
Thank you for sharing your experience, Howard. As those are replica servers, I don't care much about losing a second worth of data in case of power failure. I believe the data centre has double independent power sources, and my hardware man assured me if the power goes down at the data centre we'll have bigger issues to worry about. As a result, I can run with innodb_flush_log_at_trx_commit = 2 without worrying too much about it. The most interesting thing that came out of all this conversation is that everybody seems to agree this is some sort of lock contention on a lock that only get hot under certain conditions, and that doesn't seems part of the usual set of locks monitored by Cacti. I shall start paying beers to the MySQL developers I know again... Thank you very much once more for sharing your experiences. This is invaluable and I hope I can do the same for you in the future. Kind regards, -- Luis Motta Campos
Re: 5.1.51 Database Replica Slows Down Suddenly, Lags For Days, and Recovers Without Intervention
Claudio, Thank you for your interest. I will wait for the issue to happen again and will see what kind of information I can get back with strace. This is indeed something I didn't think of trying yet. I'll keep you people posted on this. Much appreciated on the new approaches and fresh ideas. Kind regards, -- Luis Motta Campos On 23 Oct 2011, at 23:27, Claudio Nanni wrote: > Luis, > > Very hard to tackle. > In my experience, excluding external(to mysql) bottlenecks, like hardware, > o.s. etc, 'suspects' are the shared resources 'guarded' by unique mutexes, > like on the query cache or key cache. > Since you do not use MySQL it cannot be the key cache. Since you use percona > the query cache is disabled by default. > You should go a bit lower level and catch the system calls with one of the > tools you surely know to see if there are waits on the semaphores. > > I also would like to tell that the 'seconds behind master' reported by the > slave is not reliable. > > Good luck! > > Claudio > > 2011/10/23 Tyler Poland > >> Luis, >> >> How large is your database? Have you checked for an increase in write >> activity on the master leading up to this? Are you running a backup against >> the replica? >> >> Thank you, >> Tyler >> >> Sent from my Droid Bionic >> On Oct 23, 2011 5:40 AM, "Luis Motta Campos" >> wrote: >> >>> Fellow DBAs and MySQL Users >>> >>> [apologies for eventual duplicates - I've posted this to >>> percona-discuss...@googlegroups.com also] >>> >>> I've been hunting an issue with my database cluster for several months >> now >>> without much success. Maybe I'm overlooking something here. >>> >>> I've been observing the database slowing down and lagging behind for >>> thousands of seconds (sometimes over the course of several days) even >>> without any query load besides replication itself. >>> >>> I am running Percona MySQL 5.1.51 (InnoDB plug-in version 1.12) on Dell >>> R710 (6 x 3.5 inch 15K RPM disks in RAID10; 24GB RAM; 2x Quad-core Intel >>> processors) running Debian Lenny. MySQL data, binary logs, relay logs, >>> innodb log files are on separated partitions from each other, on a RAID >>> system separated from the operating system disks. >>> >>> Default Storage Engine is InnoDB, and the usual InnoDB memory structures >>> are stable and look healthy. >>> >>> I have about 500 (read) queries per second on average, and about 10% of >>> this as writes on the master. >>> >>> I've been observing something that looks like between 6 and 10 pending >>> reads per second uniformly on my cacti graphs. >>> >>> The issue is characterized by the server suddenly slowing down writes >>> without any previous warning or change, and lagging behind for several >>> thousand seconds (triggering all sorts of alerts on my monitoring >> system). I >>> don't observe extra CPU activity, just a reduced disk access ratio (from >>> about 5-6MB/s to 500KB/s) and replication lagging. I could correlate it >>> neither InnoDB hashing activity, nor with long-running-queries, nor with >>> background read/write thread activities. >>> >>> I don't have any clues of what is causing this behavior, and I'm unable >> to >>> reproduce it under controlled conditions. I've observed the issue both on >>> severs with and without workload (apart from the usual replication load). >> I >>> am sure no changes were applied to the server or to the cluster. >>> >>> I'm looking forward for suggestions and theories on the issue - all ideas >>> are welcome. >>> Thank you for your time and attention, >>> Kind regards, >>> -- >>> Luis Motta Campos >>> is a DBA, Foodie, and Photographer >>> >>> >>> -- >>> MySQL General Mailing List >>> For list archives: http://lists.mysql.com/mysql >>> To unsubscribe: >>> http://lists.mysql.com/mysql?unsub=tpol...@engineyard.com >>> >>> >> > > > > -- > Claudio
Re: 5.1.51 Database Replica Slows Down Suddenly, Lags For Days, and Recovers Without Intervention
The data size is about 200 GB. I would have noticed increase on writes. No backup activity is running (actually I don't do conventional backups). Any theories? Thank you for your interest. Kind regards, -- Luis Motta Campos On 23 Oct 2011, at 14:06, Tyler Poland wrote: > Luis, > > How large is your database? Have you checked for an increase in write > activity on the master leading up to this? Are you running a backup against > the replica? > > Thank you, > Tyler > > Sent from my Droid Bionic > On Oct 23, 2011 5:40 AM, "Luis Motta Campos" > wrote: > >> Fellow DBAs and MySQL Users >> >> [apologies for eventual duplicates - I've posted this to >> percona-discuss...@googlegroups.com also] >> >> I've been hunting an issue with my database cluster for several months now >> without much success. Maybe I'm overlooking something here. >> >> I've been observing the database slowing down and lagging behind for >> thousands of seconds (sometimes over the course of several days) even >> without any query load besides replication itself. >> >> I am running Percona MySQL 5.1.51 (InnoDB plug-in version 1.12) on Dell >> R710 (6 x 3.5 inch 15K RPM disks in RAID10; 24GB RAM; 2x Quad-core Intel >> processors) running Debian Lenny. MySQL data, binary logs, relay logs, >> innodb log files are on separated partitions from each other, on a RAID >> system separated from the operating system disks. >> >> Default Storage Engine is InnoDB, and the usual InnoDB memory structures >> are stable and look healthy. >> >> I have about 500 (read) queries per second on average, and about 10% of >> this as writes on the master. >> >> I've been observing something that looks like between 6 and 10 pending >> reads per second uniformly on my cacti graphs. >> >> The issue is characterized by the server suddenly slowing down writes >> without any previous warning or change, and lagging behind for several >> thousand seconds (triggering all sorts of alerts on my monitoring system). I >> don't observe extra CPU activity, just a reduced disk access ratio (from >> about 5-6MB/s to 500KB/s) and replication lagging. I could correlate it >> neither InnoDB hashing activity, nor with long-running-queries, nor with >> background read/write thread activities. >> >> I don't have any clues of what is causing this behavior, and I'm unable to >> reproduce it under controlled conditions. I've observed the issue both on >> severs with and without workload (apart from the usual replication load). I >> am sure no changes were applied to the server or to the cluster. >> >> I'm looking forward for suggestions and theories on the issue - all ideas >> are welcome. >> Thank you for your time and attention, >> Kind regards, >> -- >> Luis Motta Campos >> is a DBA, Foodie, and Photographer >> >> >> -- >> MySQL General Mailing List >> For list archives: http://lists.mysql.com/mysql >> To unsubscribe: >> http://lists.mysql.com/mysql?unsub=tpol...@engineyard.com >> >>
5.1.51 Database Replica Slows Down Suddenly, Lags For Days, and Recovers Without Intervention
Fellow DBAs and MySQL Users [apologies for eventual duplicates - I've posted this to percona-discuss...@googlegroups.com also] I've been hunting an issue with my database cluster for several months now without much success. Maybe I'm overlooking something here. I've been observing the database slowing down and lagging behind for thousands of seconds (sometimes over the course of several days) even without any query load besides replication itself. I am running Percona MySQL 5.1.51 (InnoDB plug-in version 1.12) on Dell R710 (6 x 3.5 inch 15K RPM disks in RAID10; 24GB RAM; 2x Quad-core Intel processors) running Debian Lenny. MySQL data, binary logs, relay logs, innodb log files are on separated partitions from each other, on a RAID system separated from the operating system disks. Default Storage Engine is InnoDB, and the usual InnoDB memory structures are stable and look healthy. I have about 500 (read) queries per second on average, and about 10% of this as writes on the master. I've been observing something that looks like between 6 and 10 pending reads per second uniformly on my cacti graphs. The issue is characterized by the server suddenly slowing down writes without any previous warning or change, and lagging behind for several thousand seconds (triggering all sorts of alerts on my monitoring system). I don't observe extra CPU activity, just a reduced disk access ratio (from about 5-6MB/s to 500KB/s) and replication lagging. I could correlate it neither InnoDB hashing activity, nor with long-running-queries, nor with background read/write thread activities. I don't have any clues of what is causing this behavior, and I'm unable to reproduce it under controlled conditions. I've observed the issue both on severs with and without workload (apart from the usual replication load). I am sure no changes were applied to the server or to the cluster. I'm looking forward for suggestions and theories on the issue - all ideas are welcome. Thank you for your time and attention, Kind regards, -- Luis Motta Campos is a DBA, Foodie, and Photographer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Triggers - Accessing all NEW data
On 8 Sep 2011, at 16:23, Chris Tate-Davies wrote: > Hello. I want to know if there is a special way I can access all the data in > the NEW/OLD data? > > I realise I can access it by referencing NEW.fieldname but I want to > serialise the NEW object so I can save as a string. Is this possible or do I > need to write a function? Hi, You'll have to write your own function for that. Cheers -- Luis Motta Campos is a DBA, Foodie, and Photographer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: How much memory can mysql 5.1 take advantage of?
Jake Maul wrote: > Didn't want this to go unanswered, although I don't have any great > info for you. > > As long as you're running a 64-bit OS and a 64-bit version of MySQL, > there's no technical reason it would be limited to less than the > addressable space (that I know of). The main gain would be the > ability to set larger buffers and handle more connections > simultaneously. Of course, this is assuming your queries and schema > are good and you don't suffer from excessive locking problems. > > That is to say... yes, it'll work, and yes, as far as I know MySQL > will be able to allocate as much RAM as you can stuff in the box. > Whether it can use it *effectively* is something I don't have any > experience with beyond ~8GB. I suspect it would work just fine, > though. I have a personal experience in this. At the office we run a High Availability Replicated Cluster with MySQL, and I can effectively use up (but surely not limited) to 15GB (out of 16GB available) RAM, mainly for buffers and connections. My current implementation bottleneck is processor cycles and the outrageous amount of bugs and half-implemented standards that plague 5.0.45 (the latest pre-compiled stable version available for CentOS 64 bits). Please feel free to address me if you need more information about that, either here or at the FreeNode's #mysql IRC channel (my nick there is LuisMottaCampos). Cheers -- Luis Motta Campos is a software engineer, Perl Programmer, foodie and photographer. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Database Migration Path / Activity List?
Baron Schwartz wrote:
> On Jan 2, 2008 10:04 AM, Luis Motta Campos wrote:
>> Baron Schwartz wrote:
>>> What are the biggest changes you anticipate? I'd say they will be
>>> the version upgrade, converting to InnoDB, and using
>>> replication. It looks like you have planned well for all but
>>> using replication.
>> That's interesting. What kind of activities (besides configuration,
>> maybe?) are interesting to add?
>
> Lots of experimentation!
>
> Let me ask it another way: how are you planning to use replication?
> -- for load balancing/scaling reads, backups, a hot standby machine?
OK, I guess a bit more of information can help. I have a very sensitive
database at the company, almost unprotected at the moment. It's big
hardware, lots of hot-replaceable parts, and a quite big energy
generator attached, but nothing guarantees our data between the last
backup and the present moment case the building burns down to the ground.
The database I/O activity obey the 80-20 rule: 80% reads and 20% writes.
I have an average of 80,000 read-queries per second (that's average - I
got 'nice' peaks sometimes, with 4 times more activity). We have 20,000
write-queries per second in the same database.
As we're addressing the risk of major disasters (like the building
burning down to ashes), the plan is spreading this database through the
two data centers we hire: one data center would hold the master
database, and a spare reading slave, and the other data center would
hold "the" reading slave and a spare master database.
Don't worry about connectivity issues: I have plenty of bandwidth
between those two sites, and I can ask for more. I just need to know in
advance how much to ask for, and I will surely get it.
The master/spare and slave/spare machines would be connected through
heartbeat and will keep the database in a DRDB filesystem. This will
guarantee that, in case of failure, the other machine can raise the same
IP address in it's own interface and continue operations after a short
delay.
Now, about the existing database: it runs Debian Stable, and a
pre-compiled mysql server. As I said before, it's a big machine, but
it's getting old (more than 2 years already), and must be replaced.
The system running on it is quite old, more than 10 years old. This
means that the design and implementation aren't nice. And the
maintenance added new improvements where needed (as InnoDB tables).
The basic idea is to completely re-design and re-implement the database
as soon as the new server is in place (being stability and failure
resistance the priorities fixed by management for the first stage).
>> Isn't predicting that the replication is one of the three biggest
>> changes I have in my database a bit of an exaggeration?
>
> Definitely not. It is a huge change. From one server to a
> two-server replication setup is a quantum leap. You'll have all
> kinds of new things to think about, such as data consistency, dealing
> with replication lag, performance changes on the master due to
> binary logging, etc.
>
> It depends a lot on WHY you're using replication (see my earlier
> question).
Well, I guess I don't need to worry about multi-master replication for
now, the application must be re-designed and re-implemented before we
can start thinking about this. It's currently quite hard to maintain,
and we don't know a lot of important things about it. There is a team
working on this already.
About data consistency, I would like to have some pointers: is this an
issue, provided that I stick to single-master architectures?
About binary logging, I must first read more about this. Thanks for the
warning, though.
Replication lag is another thing that worries me a lot - is there a
mathematical model I can use in order to forecast the expected average
replication lag?
The application can handle quite big replication lags at the moment.
It's not web-based, and there is no users directly interacting with it
at the present moment, what makes everything much simpler - you can have
a program waiting for 5 minutes to "see" a change without a lot of fuss
about it.
Sorry, I guess this email is a bit bigger than I was expecting... :(
I hope this gives you a general idea about my current problem.
Please feel free to ask more about it if you feel that this details
aren't enough.
Kind regards.
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Database Migration Path / Activity List?
Baron Schwartz wrote:
> What are the biggest changes you anticipate? I'd say they will be the
> version upgrade, converting to InnoDB, and using replication. It
> looks like you have planned well for all but using replication.
That's interesting. What kind of activities (besides configuration,
maybe?) are interesting to add?
> Unless you are familiar with it, that is likely to be a bigger change
> than the version upgrade and switch to InnoDB.
That's alarming. I was expecting replication to be a lesser change, not
something this big. Isn't predicting that the replication is one of the
three biggest changes I have in my database a bit of an exaggeration?
> There's a lot to learn about replication if you haven't used it
> before. I'd suggest that you read the manual chapters about
> replication and binary logging, and definitely experiment with
> replication.
Thanks for the advice. I will start reading right away.
I would like to read more comments from the members of this list.
Thank you all for your patience and help.
Cheers!
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Database Migration Path / Activity List?
Hey there
I have a not-so-big (50GB, including indexes) database (MySQL 4.0.24,
mixed MyISAM and InnoDB tables) that I need to migrate to a MySQL 5.1
Master + Slave Replication server, with InnoDB tables only, over a new
hardware.
Unfortunately, this is the first time I play a role as MySQL DBA, and
don't have a complete migration plan (yet).
Can someone here please review my migration plan and help me
adding/prunning missing/exceeding bits?
My current plan is more or less like below. I removed task descriptions
removed, guess the task name is descriptive enough. Indenting marks
sub-tasks, as expected.
Many thanks in advance.
Cheers!
- BEGIN TASK LIST -
Database Migration Project
Current Database Procedures Mapping
Plan Database Test Procedure
Determine Current Database Backup Procedures
Determine Current Database Restore Procedures
Obtain Copies of the Current Database Backup Scripts
Obtain Copies of the Current Database Restore Scripts
Determine Current Database Stored Procedures / Triggers
Database Statistics Collection
Determine Current Database Size
Determine Current Database Grow Ratio
Determine Current Database Schema
Operating System Installation and Configuration Plan
Determine Hardware Requirements
Determine Operating System Requirements
Determine Required Operating System Configuration
Plan Operating System Installation
Plan Operating System Configuration
Document Changes on Operating System
Database Software Installation and Configuration Plan
Study Need for Database Build
Plan Database Build
Plan Database Installation
Plan Database Configuration
Database Performance Tunning
Determine Current Database Queries
Determine Current Database Performance Indicators
Plan Measurement Procedure for the Performance Indicators
Measure Current Database Performance
Database Schema Refactoring
Obtain Current Database Schema Definition
Review Database Schema
Review Database Stored Procedures and Triggers
Suggest Changes for Database Schema
Study Desired Database Backward Compatibility Level
Design Views to Allow Database Backward Compatibility
Redesign Database
Write SQL for Changes
Staging System Deployment and Testing
Install Operating System in the Staging Environment
Configure Operating System in the Staging Envinronment
Build Database Software in Staging Environment
Install Database Software in Staging Environment
Configure Database Software in Staging Environment
Obtain Current Copy of the Database Backup from Production
Restore Database Using the Restore Procedure
Fix or Improve Restore Procedure
Test Database in Staging Environment
Measure Staging Database Performance Indicators
Compare Performance Figures for the Staging Database
Production Database Deployment
Plan Database Maintenance Stop
Advertise Database Maintenance Stop
Install Operating System in the Production Environment
Configure Operating System in the Production Envinronment
Build Database Software in Production Environment
Install Database Software in Production Environment
Configure Database Software in Production Environment
Stop Production Database
Obtain Current Copy of the Database Backup from Production
Restore Database Using the Restore Procedure
Test Database in Production Environment
Start Database in Production Environment
Database Monitoring
Follow Up Database Behavior and Performance
- END TASK LIST -
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
