Re: [rt-users] Query Regarding Upgrade to 3.8.4
On Wed, Jul 29, 2009 at 9:20 AM, Duncan McEwandun...@ecs.vuw.ac.nz wrote: Hi, I recently upgraded our RT installation from 3.8.1 to 3.8.4. The upgrade seemed to go fine, and as far as I can see everything is working well. But I have a query relating to the upgrade script etc/upgrade/3.8.4/content. We do use Ruslan's RT-Action-NotifyGroup extension (version 0.2) and so I'd like to know what effect this upgrade script has on our database. Do you know that this extension is part of RT 3.8? If you have extension installed from the CPAN as well then most probably CPAN version will mask RT's version which has been updated. RT's version has new features, for example it allow you to use non-user email address, user name, user email, group name or numeric id in the argument. With these changes it's really easier to use this action with rt-crontool. As far as I could see from examining the ScripActions table before and after running the upgrade script (using rt-setup-database), it made no change. Both before and after the script was run, the Argument value for each NotifyGroup or NotifyGroupAsComment action was the numeric id of the appropriate group from the Groups table. Is this what they are supposed to be? Yes. This script converts very old format of argument string to the current. Probably nobody has arguments in this format anymore. Also, in old version any separator of ids was allowed, but now it's only comma. I tried to understand what the upgrade script is doing, but I got lost on the call to Storable::thaw($arg). I'm not sure why it is trying to thaw the value of $arg, when I can't see how that variable would contain something previously returned by Storable::freeze(). In fact I can't see anywhere that $arg is set, so I was wondering whether that was a typo and it should actually be $argument, which *is* set three lines earlier. On the off-chance, I tried changing $arg to $argument and rerunning the script (on a test database!) but it still had no (apparent) effect. Oh, you're right about argument vs arg. Going to change that, but you shouldn't worry. Hope nobody has that old format used. It's quite likely that I'm missing something obvious here. Any assistance with what this upgrade script is trying to achieve, and whether or not the current values for the Arguments for those actions in our database seem correct would be much appreciated. Comma separated list of ids is perfectly good argument. Thanks, Duncan ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Best regards, Ruslan. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] SimpleSearch excludes resolved results
Hello, I am aware of the patches offered here: http://wiki.bestpractical.com/view/SimpleSearchIncludeResolved Now, I am referring to the the following thread: http://lists.bestpractical.com/pipermail/rt-users/2008-September/053928.html I was curious to know if the feature/patch discussed by Jesse and the community was somewhere in the development tree ? Thanks, ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Migrating from Postgres to MySQL
On Tue, Jul 28, 2009 at 3:56 PM, Kenneth Marshall k...@rice.edu wrote: Kage, The main advantage is gained by avoiding I/O through the virtual disk. The layout of the virtual disk tends to turn most I/O into random I/O, even I/O that starts as sequential. The factor of 10 performance difference between random/sequential I/O causes the majority of the performance problem. I have not had personal experience with using an NFS mount point to run a database so I cannot really comment on that. Good luck with your evaluation. You're trading head-seeking latencies for network latencies, and those are almost certainly higher. Hosting your database server binaries and such forth in NFS is possible, though again, not optimal both from a performance and risk standpoint (NFS server drops, your DB binaries vanish, your DB server drops even though the machine hosting it was fine). I think hosting databases in NFS can cause serious problems - I seem to remember older versions of mysql wouldn't support that. I don't know if newer ones do...but I do know in the *very large* IT environment I worked in, all database servers hosted the DBs on their local disks or in filesystems hosted on disks (SANS?) attached via fibre-channel. Could solid-state drives side-step the random-access issue with virtualization, or at least make it suck less? Based on how many people I know who have said Wow, my SSD died. I thought those were supposed to be more reliable? ... I wouldn't bet my service uptime on it. ;) -Rob ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] SimpleSearch excludes resolved results
On Wed, Jul 29, 2009 at 07:58:46AM -0400, David wrote: I am aware of the patches offered here: http://wiki.bestpractical.com/view/SimpleSearchIncludeResolved Now, I am referring to the the following thread: http://lists.bestpractical.com/pipermail/rt-users/2008-September/053928.html I was curious to know if the feature/patch discussed by Jesse and the community was somewhere in the development tree ? Nothing has hit the repo at this time, you can look at the history here: http://github.com/bestpractical/rt/commits/3.8-trunk/lib/RT/Search/Googleish.pm -kevin ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Table 'rt3.ObjectCustomFields' doesn't exist
Hi, Thank you for the suggestion. I'll give that a shot. This is a migration from an old box running 3.2.2 to a new server which is rt 3.8.4 fresh install. Will I need to do make upgrade as indicated in the 3.8.4 README file? I am exporting rt 3.2.2 db on old server and importing to the new server running rt 3.8.4 mysql -u root -p rt3 oldrt3.2.2.db.sql raymond On Wed, 29 Jul 2009, Ruslan Zakirov wrote: Then you missed one step. You have to upgrade DB first from 3.2.2 to 3.7.89 first. It's `rt-setup-database --action update ...` command described in more details in UPGRADING.mysql and README files. On Tue, Jul 28, 2009 at 11:39 PM, raym...@pilotsupplies.com wrote: Hi Ruslan, My apologies. I was upgrading from 3.2.2 raymond On Tue, 28 Jul 2009, Ruslan Zakirov wrote: Why do you even need mysqlupgrade.sql if it's fresh install? On Tue, Jul 28, 2009 at 10:13 PM, raym...@pilotsupplies.com wrote: ubuntu vmware esx4i with ubuntu 9.04 4GB of memory dual xeon processor fresh 3.8.4 install, apache2, perl_Mode 2, mysql 5 go error Table 'rt3.ObjectCustomFields' doesn't exist so I went and commented out the following, see below and proceed with the install with no other issues. Am wondering if there are any implications, issues or problems with this or is there a better way to fix this ? thanx! /usr/local/src/rt-3.8.4/etc/upgrade# mysql -u root -p rt3 mysqlupgrade.sql Enter password: ERROR 1146 (42S02) at line 77: Table 'rt3.ObjectCustomFields' doesn't exist r...@joeblow:/usr/local/src/rt-3.8.4/etc/upgrade# vi mysqlupgrade.sql #ALTER TABLE ObjectCustomFields # DEFAULT CHARACTER SET utf8; #ALTER TABLE ObjectCustomFieldValues # DEFAULT CHARACTER SET utf8; -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Migrating from Postgres to MySQL
On Jul 29, 2009, at 7:10 AM, Robert Nesius wrote: On Tue, Jul 28, 2009 at 3:56 PM, Kenneth Marshall k...@rice.edu wrote: Kage, The main advantage is gained by avoiding I/O through the virtual disk. The layout of the virtual disk tends to turn most I/O into random I/O, even I/O that starts as sequential. The factor of 10 performance difference between random/sequential I/O causes the majority of the performance problem. I have not had personal experience with using an NFS mount point to run a database so I cannot really comment on that. Good luck with your evaluation. You're trading head-seeking latencies for network latencies, No. If this were a standard host environment, that would be true. But in a virtual environment, there is the overhead of the disk create/ maintenance/update processes of the virtualization engine which multiply the overhead of the disk. Just run a disk benchmarking utility inside a VE running under any platform that uses disk images (vmware, xen, parallels, etc...) and then run those same tests on the host node. The difference in performance is often an order of magnitude slower for the virtual disks. Contrast that with NFS performance, which has a small fixed overhead imposed by the network (even smaller if you use jumbo frames). If you were using a platform with a robust NFS implementation (Solaris, FreeBSD), I'd put money on the database performing better on NFS than inside most virtual machines. If you're using NFS with Linux, you will certainly have performance issues that you won't be able to get past. If the virtualization environment provides raw disk access to the VE, my bet is off. Examples of virtualization platforms that [can] do this are FreeBSD jails and Linux OpenVZ. On several occasions, I have built VEs for MySQL and mounted a dedicated partition in the VE. Assuming you've given adequate resources to the DB VE, that works as well as a dedicated machine. When I arrived at my current position, the SA team had put the databases into the VEs that needed them, along with the apps that accessed them. Despite having 6 servers to spread the load across, they had recurring database performance issues (a few times a week), particularly with RT. I resolved all the DB issues by building a dedicated machine with 4 disks (two battery backed RAID-1 mirrors) all the databases to it. The databases have dedicated spindles as does the OS logging. Despite the resistance to the all our DB eggs in one basket approach, the wisdom of that choice is now plainly evident. All the performance problems went away and haven't returned. and those are almost certainly higher. Hosting your database server binaries and such forth in NFS is possible, though again, not optimal both from a performance and risk standpoint (NFS server drops, your DB binaries vanish, your DB server drops even though the machine hosting it was fine). That's not how NFS works. If the NFS server vanishes, the NFS client hangs and waits for it to return. That is a design feature of NFS. The consistency of the databases is entirely dependency on the disk subsystem of the file server. I think hosting databases in NFS can cause serious problems - I seem to remember older versions of mysql wouldn't support that. I don't know if newer ones do...but I do know in the very large IT environment I worked in, all database servers hosted the DBs on their local disks or in filesystems hosted on disks (SANS?) attached via fibre-channel. I would never host a database server on anything but RAID protected disks with block level access (ie, local disks, iSCSI, etc). Database engines have been explicitly designed and optimized for this type of disk backend. That is starting to change, as a few new DB engines that are designed for network storage (like SimpleDB). But none I know of are production-ready. Could solid-state drives side-step the random-access issue with virtualization, or at least make it suck less? Haven't tried it yet, but my guess is no. However, I have put databases on SSD disks with excellent results. Based on how many people I know who have said Wow, my SSD died. I thought those were supposed to be more reliable? ... I wouldn't bet my service uptime on it. ;) There's this thing called RAID, that protects against disk failures It works quite well with SSD disks and delivers performance numbers for a couple thousand bucks that would otherwise take a $150,000+ SAN. Matt ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Table 'rt3.ObjectCustomFields' doesn't exist
On Wed, Jul 29, 2009 at 9:21 PM, raym...@pilotsupplies.com wrote: Hi, Thank you for the suggestion. I'll give that a shot. This is a migration from an old box running 3.2.2 to a new server which is rt 3.8.4 fresh install. Will I need to do make upgrade as indicated in the 3.8.4 README file? Nope, you run `make install` instead of `make upgrade` as you have no RT files on new server. I am exporting rt 3.2.2 db on old server and importing to the new server running rt 3.8.4 Don't forget to using --default-charset=binary, both on export and import. Check exact syntax in mysql's docs. It's important or you can break every binary attachment. mysql -u root -p rt3 oldrt3.2.2.db.sql mysql --default-charset=binary -u root -p rt3 oldrt3.2.2.db.sql raymond On Wed, 29 Jul 2009, Ruslan Zakirov wrote: Then you missed one step. You have to upgrade DB first from 3.2.2 to 3.7.89 first. It's `rt-setup-database --action update ...` command described in more details in UPGRADING.mysql and README files. On Tue, Jul 28, 2009 at 11:39 PM, raym...@pilotsupplies.com wrote: Hi Ruslan, My apologies. I was upgrading from 3.2.2 raymond On Tue, 28 Jul 2009, Ruslan Zakirov wrote: Why do you even need mysqlupgrade.sql if it's fresh install? On Tue, Jul 28, 2009 at 10:13 PM, raym...@pilotsupplies.com wrote: ubuntu vmware esx4i with ubuntu 9.04 4GB of memory dual xeon processor fresh 3.8.4 install, apache2, perl_Mode 2, mysql 5 go error Table 'rt3.ObjectCustomFields' doesn't exist so I went and commented out the following, see below and proceed with the install with no other issues. Am wondering if there are any implications, issues or problems with this or is there a better way to fix this ? thanx! /usr/local/src/rt-3.8.4/etc/upgrade# mysql -u root -p rt3 mysqlupgrade.sql Enter password: ERROR 1146 (42S02) at line 77: Table 'rt3.ObjectCustomFields' doesn't exist r...@joeblow:/usr/local/src/rt-3.8.4/etc/upgrade# vi mysqlupgrade.sql #ALTER TABLE ObjectCustomFields # DEFAULT CHARACTER SET utf8; #ALTER TABLE ObjectCustomFieldValues # DEFAULT CHARACTER SET utf8; -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others -- Best regards, Ruslan. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Migrating from Postgres to MySQL
Hi Matt, Raid is not the end-all be-all for disk safety, especially when you step into terabyte class computing, sorry I am taking this a bit off topic. While RAID has it's bonuses, there are drawbacks as well, take your standard RAID 5 setup, 4 Disks, 3 active, 1 Hot Spare. Now lets say that Disk number 2 decided it was going to release it's smoke to the world (never a good thing), now your array is still alive and it is starting to rebuild onto disk 4 to make up for the death of disk 2. During the rebuild process Disk 1 comes across a bad sector, poof, your data is gone. Just a word of warning, don't put all your data safety eggs into the RAID basket. Otherwise I agree that running via NFS from a virtualized server would probably have perfromance gains over running in the virtual invironment. Thanks, Bill On Wed, Jul 29, 2009 at 10:26 AM, Matt Simerson m...@corp.spry.com wrote: On Jul 29, 2009, at 7:10 AM, Robert Nesius wrote: On Tue, Jul 28, 2009 at 3:56 PM, Kenneth Marshall k...@rice.edu wrote: Kage, The main advantage is gained by avoiding I/O through the virtual disk. The layout of the virtual disk tends to turn most I/O into random I/O, even I/O that starts as sequential. The factor of 10 performance difference between random/sequential I/O causes the majority of the performance problem. I have not had personal experience with using an NFS mount point to run a database so I cannot really comment on that. Good luck with your evaluation. You're trading head-seeking latencies for network latencies, No. If this were a standard host environment, that would be true. But in a virtual environment, there is the overhead of the disk create/maintenance/update processes of the virtualization engine which multiply the overhead of the disk. Just run a disk benchmarking utility inside a VE running under any platform that uses disk images (vmware, xen, parallels, etc...) and then run those same tests on the host node. The difference in performance is often an order of magnitude slower for the virtual disks. Contrast that with NFS performance, which has a small fixed overhead imposed by the network (even smaller if you use jumbo frames). If you were using a platform with a robust NFS implementation (Solaris, FreeBSD), I'd put money on the database performing better on NFS than inside most virtual machines. If you're using NFS with Linux, you will certainly have performance issues that you won't be able to get past. If the virtualization environment provides raw disk access to the VE, my bet is off. Examples of virtualization platforms that [can] do this are FreeBSD jails and Linux OpenVZ. On several occasions, I have built VEs for MySQL and mounted a dedicated partition in the VE. Assuming you've given adequate resources to the DB VE, that works as well as a dedicated machine. When I arrived at my current position, the SA team had put the databases into the VEs that needed them, along with the apps that accessed them. Despite having 6 servers to spread the load across, they had recurring database performance issues (a few times a week), particularly with RT. I resolved all the DB issues by building a dedicated machine with 4 disks (two battery backed RAID-1 mirrors) all the databases to it. The databases have dedicated spindles as does the OS logging. Despite the resistance to the all our DB eggs in one basket approach, the wisdom of that choice is now plainly evident. All the performance problems went away and haven't returned. and those are almost certainly higher. Hosting your database server binaries and such forth in NFS is possible, though again, not optimal both from a performance and risk standpoint (NFS server drops, your DB binaries vanish, your DB server drops even though the machine hosting it was fine). That's not how NFS works. If the NFS server vanishes, the NFS client hangs and waits for it to return. That is a design feature of NFS. The consistency of the databases is entirely dependency on the disk subsystem of the file server. I think hosting databases in NFS can cause serious problems - I seem to remember older versions of mysql wouldn't support that. I don't know if newer ones do...but I do know in the *very large* IT environment I worked in, all database servers hosted the DBs on their local disks or in filesystems hosted on disks (SANS?) attached via fibre-channel. I would never host a database server on anything but RAID protected disks with block level access (ie, local disks, iSCSI, etc). Database engines have been explicitly designed and optimized for this type of disk backend. That is starting to change, as a few new DB engines that are designed for network storage (like SimpleDB). But none I know of are production-ready. Could solid-state drives side-step the random-access issue with virtualization, or at least make it suck less? Haven't tried it yet, but my guess is no. However, I have put
Re: [rt-users] Migrating from Postgres to MySQL
On Jul 29, 2009, at 10:44 AM, William Graboyes wrote: Hi Matt, Raid is not the end-all be-all for disk safety, especially when you step into terabyte class computing, sorry I am taking this a bit off topic. While RAID has it's bonuses, there are drawbacks as well, take your standard RAID 5 setup, 4 Disks, 3 active, 1 Hot Spare. Now lets say that Disk number 2 decided it was going to release it's smoke to the world (never a good thing), now your array is still alive and it is starting to rebuild onto disk 4 to make up for the death of disk 2. During the rebuild process Disk 1 comes across a bad sector, poof, your data is gone. Just a word of warning, don't put all your data safety eggs into the RAID basket. RAID poorly implemented is a placebo, and is often less reliable than a single disk. RAID properly implemented IS the end-all be-all of disk safety. Your chosen argument is only valid against RAID level 5, which would be a very poor choice for a database application. RAID-5 is a poor choice in any environment where the data set is volatile and valuable. Especially when you consider the number of hours (or days) it takes to rebuild a hot spare into the RAID-5 set. (HINT: test that before deployment!) During that rebuild window, your system performance is heavily degraded and extremely vulnerable. If the performance of your RAID system is halved, is that sufficient for your application, or is your system effectively down during the rebuild period? (HINT: test before deployment!). But a RAID-1 or RAID 10 can be extremely robust, remaining online and performing optimally during multiple catastrophic disk failures. You can mirror the data to as many spindles as you need to insure data integrity. When disks fail, rebuilding a mirror disk usually takes less than an hour. The systems engineer has to choose between data integrity, performance, and storage efficiency. One of my systems is about 2/3 full with 24.64 TB of data. Does that count as terabyte class computing? :) I'm using ZFS to manage it. :) :) Matt ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Table 'rt3.ObjectCustomFields' doesn't exist
HI, I'll give it another shot with the required options. Thank you! raymond On Wed, 29 Jul 2009, Ruslan Zakirov wrote: On Wed, Jul 29, 2009 at 9:21 PM, raym...@pilotsupplies.com wrote: Hi, Thank you for the suggestion. I'll give that a shot. This is a migration from an old box running 3.2.2 to a new server which is rt 3.8.4 fresh install. Will I need to do make upgrade as indicated in the 3.8.4 README file? Nope, you run `make install` instead of `make upgrade` as you have no RT files on new server. I am exporting rt 3.2.2 db on old server and importing to the new server running rt 3.8.4 Don't forget to using --default-charset=binary, both on export and import. Check exact syntax in mysql's docs. It's important or you can break every binary attachment. mysql -u root -p rt3 oldrt3.2.2.db.sql mysql --default-charset=binary -u root -p rt3 oldrt3.2.2.db.sql raymond On Wed, 29 Jul 2009, Ruslan Zakirov wrote: Then you missed one step. You have to upgrade DB first from 3.2.2 to 3.7.89 first. It's `rt-setup-database --action update ...` command described in more details in UPGRADING.mysql and README files. On Tue, Jul 28, 2009 at 11:39 PM, raym...@pilotsupplies.com wrote: Hi Ruslan, My apologies. I was upgrading from 3.2.2 raymond On Tue, 28 Jul 2009, Ruslan Zakirov wrote: Why do you even need mysqlupgrade.sql if it's fresh install? On Tue, Jul 28, 2009 at 10:13 PM, raym...@pilotsupplies.com wrote: ubuntu vmware esx4i with ubuntu 9.04 4GB of memory dual xeon processor fresh 3.8.4 install, apache2, perl_Mode 2, mysql 5 go error Table 'rt3.ObjectCustomFields' doesn't exist so I went and commented out the following, see below and proceed with the install with no other issues. Am wondering if there are any implications, issues or problems with this or is there a better way to fix this ? thanx! /usr/local/src/rt-3.8.4/etc/upgrade# mysql -u root -p rt3 mysqlupgrade.sql Enter password: ERROR 1146 (42S02) at line 77: Table 'rt3.ObjectCustomFields' doesn't exist r...@joeblow:/usr/local/src/rt-3.8.4/etc/upgrade# vi mysqlupgrade.sql #ALTER TABLE ObjectCustomFields # DEFAULT CHARACTER SET utf8; #ALTER TABLE ObjectCustomFieldValues # DEFAULT CHARACTER SET utf8; -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others -- Regards, Raymond Wong Personal motto: P.E.A.C.E Enjoy the present Assert your goals Champion peace Entrust others___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] Attachment storage
I am considering attaching .wav files of the voicemail left on our helpdesk to rt tickets, but I'm worried about performance/stability if I start putting this amount of binary data in the system. I ran this thought by our local DB guy and he suggested that this might not be a problem if the database just contained pointers to files stored elsewhere. I looked at the rt3.Attachments and it looks like the content is actually stored in the DB itself, but I'm a DB newbie. So I suppose I have three questions: 1) Do I have it right that the attachments are stored in the DB itself? 2) If they are, could the DB handle, say, a thousand 200KB-2MB attachments per year (and if so for how long?)? 3) If they aren't, is there something else that might be a problem? Thanks for your help, Mike___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Attachment storage
1) Do I have it right that the attachments are stored in the DB itself? Alas, they are. 2) If they are, could the DB handle, say, a thousand 200KB-2MB attachments per year (and if so for how long?)? Depends on your rdbms. Oracle could it, not so sure about MySQL. Alternatively, you could stash them on a network share or similar, and give the path in a clickable custom field... ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Attachment storage
On Wed 29.Jul'09 at 18:16:51 -0500, Michael Ellis wrote: So I suppose I have three questions: 1) Do I have it right that the attachments are stored in the DB itself? Yes. 2) If they are, could the DB handle, say, a thousand 200KB-2MB attachments per year (and if so for how long?)? 2 gigabytes of storage per year isn't a whole heck of a lot to see a database grow by in the 21st century. All our corporate voicemail goes into a MySQL backed RT and we're very happy with it. pgpCxaj0ukCjO.pgp Description: PGP signature ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com