Re: Tokutek Acquires Oracle
Hi guys, Is the information is true. No, it was blocked by the EU. http://tokutek.com/2010/04/tokuteks-acquisitions-blocked-by-eu/ http://planet.mysql.com/ http://tokutek.com/2010/04/tokutek-acquires-oracle/ With regards, Martijn Tonies Upscene Productions http://www.upscene.com Download Database Workbench for Oracle, MS SQL Server, Sybase SQL Anywhere, MySQL, InterBase, NexusDB and Firebird! Database questions? Check the forum: http://www.databasedevelopmentforum.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Can't drop index
Hello: When I try to drop an index from an InnoDB table: drop index company_n56 on company; I get this error: ERROR 1025 (HY000): Error on rename of './thymeleweb/#sql-788_1218' to './thymeleweb/company' (errno: 150) Look at the index using: show keys from company\G gives me this info for that key: Table: company Non_unique: 1 Key_name: company_n56 Seq_in_index: 1 Column_name: client_manager_person_id_oid Collation: A Cardinality: 2 Sub_part: NULL Packed: NULL Null: YES Index_type: BTREE Comment: The field is a varchar field that holds the id of a record in the person table: Field: client_manager_person_id_oid Type: varchar(256) Null: YES Key: MUL Default: NULL Extra: When I look at the person table, I do not see an index that would refer back to this table. Any ideas why I can't drop this index? Thanks, Neil -- Neil Aggarwal, (281)846-8957 MySQL pre-installed on a virtual private server for $25/mo Unmetered bandwidth = no overage charges, 7 day free trial -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Can't drop index
Hi Neil, Just check it up that any active transaction is still there in innodb internal data dictionary. Execute show engine innodb status\G Check for active transaction related to the current table. If it's there kill that transaction id and try again. _Krishna On Fri, Apr 2, 2010 at 10:35 PM, Neil Aggarwal n...@jammconsulting.comwrote: Hello: When I try to drop an index from an InnoDB table: drop index company_n56 on company; I get this error: ERROR 1025 (HY000): Error on rename of './thymeleweb/#sql-788_1218' to './thymeleweb/company' (errno: 150) Look at the index using: show keys from company\G gives me this info for that key: Table: company Non_unique: 1 Key_name: company_n56 Seq_in_index: 1 Column_name: client_manager_person_id_oid Collation: A Cardinality: 2 Sub_part: NULL Packed: NULL Null: YES Index_type: BTREE Comment: The field is a varchar field that holds the id of a record in the person table: Field: client_manager_person_id_oid Type: varchar(256) Null: YES Key: MUL Default: NULL Extra: When I look at the person table, I do not see an index that would refer back to this table. Any ideas why I can't drop this index? Thanks, Neil -- Neil Aggarwal, (281)846-8957 MySQL pre-installed on a virtual private server for $25/mo Unmetered bandwidth = no overage charges, 7 day free trial -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=prajapat...@gmail.com
RE: Can't drop index
Krishna: Just check it up that any active transaction is still there in innodb internal data dictionary. Acutally I figured it out. There was a constraint on that column as well. Once I dropped the constraint, I was able to drop the index. Thanks for the help, Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net/mysql MySQL pre-installed on a virtual private server for $25/mo Unmetered bandwidth = no overage charges, 7 day free trial -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
MyISAM better than innodb for large files?
I'm going to be setting up a MySQL database for a project. My reading indicates that MyISAM (default) is going to be better than InnoDB for the project but I want to be sure I have the trade-offs right. This is going to be a very large data file -- many gigabytes -- only used internally, and once installed perhaps updated once a year, queried much more often. MyISAM apparently has the advantage in memory and time overheads. InnoDB's advantage seems to be better recovery from disk crashes. Should I stick with MyISAM (MySQL default), or does the recovery issue mean I'm better off using InnoDB for an insurance policy? Inexperienced minds want to know -- ideally, from experienced minds. Thanks! -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MyISAM better than innodb for large files?
InnoDB won't give you much in terms of disk crash recovery. That's what backups are for. Where InnoDB does excel is if your database server dies while updating rows. If that happens, your database will come back up with sane data. For both table types, once the data has been flushed to disk, the data will still be there if your db server crashes. It does indeed sound like you will be better off using MyISAM. This will also reduce your disk space usage considerably. / Carsten Mitchell Maltenfort skrev: I'm going to be setting up a MySQL database for a project. My reading indicates that MyISAM (default) is going to be better than InnoDB for the project but I want to be sure I have the trade-offs right. This is going to be a very large data file -- many gigabytes -- only used internally, and once installed perhaps updated once a year, queried much more often. MyISAM apparently has the advantage in memory and time overheads. InnoDB's advantage seems to be better recovery from disk crashes. Should I stick with MyISAM (MySQL default), or does the recovery issue mean I'm better off using InnoDB for an insurance policy? Inexperienced minds want to know -- ideally, from experienced minds. Thanks! -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
RE: MyISAM better than innodb for large files?
I disagree. There's nothing about his requirements that sounds like MyIsam is a better solution. InnoDB should be your default for all tables, unless you have specific requirements that need myisam. One specific example of an appropriate task for myisam is where you need very high insert throughput, and you're not doing any updates/deletes concurrently. You want the crash safety and data integrity that comes with InnoDB. Even more so as your dataset grows. It's performance is far better than myisam tables for most OLTP users, and as your number of concurrent readers and writers grows, the improvement in performance from using innodb over myisam becomes more pronounced. Regards, Gavin Towey -Original Message- From: Carsten Pedersen [mailto:cars...@bitbybit.dk] Sent: Friday, April 02, 2010 12:58 PM To: Mitchell Maltenfort Cc: mysql@lists.mysql.com Subject: Re: MyISAM better than innodb for large files? InnoDB won't give you much in terms of disk crash recovery. That's what backups are for. Where InnoDB does excel is if your database server dies while updating rows. If that happens, your database will come back up with sane data. For both table types, once the data has been flushed to disk, the data will still be there if your db server crashes. It does indeed sound like you will be better off using MyISAM. This will also reduce your disk space usage considerably. / Carsten Mitchell Maltenfort skrev: I'm going to be setting up a MySQL database for a project. My reading indicates that MyISAM (default) is going to be better than InnoDB for the project but I want to be sure I have the trade-offs right. This is going to be a very large data file -- many gigabytes -- only used internally, and once installed perhaps updated once a year, queried much more often. MyISAM apparently has the advantage in memory and time overheads. InnoDB's advantage seems to be better recovery from disk crashes. Should I stick with MyISAM (MySQL default), or does the recovery issue mean I'm better off using InnoDB for an insurance policy? Inexperienced minds want to know -- ideally, from experienced minds. Thanks! -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=gto...@ffn.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you are notified that reviewing, disseminating, disclosing, copying or distributing this e-mail is strictly prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any loss or damage caused by viruses or errors or omissions in the contents of this message, which arise as a result of e-mail transmission. [FriendFinder Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MyISAM better than innodb for large files?
In the last episode (Apr 02), Gavin Towey said: I disagree. There's nothing about his requirements that sounds like MyIsam is a better solution. InnoDB should be your default for all tables, unless you have specific requirements that need myisam. One specific example of an appropriate task for myisam is where you need very high insert throughput, and you're not doing any updates/deletes concurrently. You want the crash safety and data integrity that comes with InnoDB. Even more so as your dataset grows. It's performance is far better than myisam tables for most OLTP users, and as your number of concurrent readers and writers grows, the improvement in performance from using innodb over myisam becomes more pronounced. His scenario is perhaps updated once a year, though, so crash recovery and multiple writer performance is not important. -- Dan Nelson dnel...@allantgroup.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
[Mysql-server-5.0]Missing socket files and denied acess to root user
Hello MySQL Community, I'm new around, and I'm a new mysql user. I use mysql mostly together with Moodle to support many courses on a public university in Brazil (UFBA). Recently, I was trying to use Reverse Engineering on Workbench to catch a relationship diagram for moodle, and so I've attempted to make foreign keys there on. For that, I need to make mysql logs be saved as tables instead of file. This is where my trouble started. According to a windows user, he could do that on my.ini , and I didn't find that on Ubuntu 9.04, so I've tried to run a command I found on Mysql Reference manual, 5.1. located on ( http://dev.mysql.com/doc/refman/5.1/en/log-tables.html). So I attempted something like #mysql -umydbrootid -pmydbrootpass --log-output=TABLE After that and other few tempts trying that, suddently my root was not able to acess mysql anymore. I tried to delete, move, reinstall and everything you can imagine but it just seems I made things worse, so I tried to purge every mysql file from my PC, together with php5-mysql and apache2. After that I installed apache2, and then tried to install by aptitude mysql-server-5.0 In this point, i'm stucked, I get the following error while on the mysql-server-5.0 install process: r...@midgard:/etc/init.d# apt-get install mysql-server-5.0 Lendo listas de pacotes... Pronto Construindo árvore de dependências Lendo informação de estado... Pronto Os pacotes extra a seguir serão instalados: libdbd-mysql-perl libdbi-perl libhtml-template-perl libnet-daemon-perl libplrpc-perl mysql-client-5.0 mysql-server-core-5.0 Pacotes sugeridos: dbishell libipc-sharedcache-perl mysql-doc-5.0 tinyca mailx Os NOVOS pacotes a seguir serão instalados: libdbd-mysql-perl libdbi-perl libhtml-template-perl libnet-daemon-perl libplrpc-perl mysql-client-5.0 mysql-server-5.0 mysql-server-core-5.0 0 pacotes atualizados, 8 pacotes novos instalados, 0 a serem removidos e 0 não atualizados. É preciso baixar 874kB/35,9MB de arquivos. Depois desta operação, 110MB adicionais de espaço em disco serão usados. Você quer continuar [S/n]? S Obter:1 http://br.archive.ubuntu.com jaunty/main libnet-daemon-perl 0.43-1 [46,9kB] Obter:2 http://br.archive.ubuntu.com jaunty/main libplrpc-perl 0.2020-1 [36,0kB] Obter:3 http://br.archive.ubuntu.com jaunty/main libdbi-perl 1.607-1 [791kB] Baixados 874kB em 10s (83,6kB/s) Pré-configurando pacotes ... Selecionando pacote previamente não selecionado libnet-daemon-perl. (Lendo banco de dados ... 185830 arquivos e diretórios atualmente instalados). Desempacotando libnet-daemon-perl (de .../libnet-daemon-perl_0.43-1_all.deb) ... Selecionando pacote previamente não selecionado libplrpc-perl. Desempacotando libplrpc-perl (de .../libplrpc-perl_0.2020-1_all.deb) ... Selecionando pacote previamente não selecionado libdbi-perl. Desempacotando libdbi-perl (de .../libdbi-perl_1.607-1_i386.deb) ... Selecionando pacote previamente não selecionado libdbd-mysql-perl. Desempacotando libdbd-mysql-perl (de .../libdbd-mysql-perl_4.008-1_i386.deb) ... Selecionando pacote previamente não selecionado mysql-client-5.0. Desempacotando mysql-client-5.0 (de .../mysql-client-5.0_5.1.30really5.0.75-0ubuntu10.3_i386.deb) ... Selecionando pacote previamente não selecionado mysql-server-core-5.0. Desempacotando mysql-server-core-5.0 (de .../mysql-server-core-5.0_5.1.30really5.0.75-0ubuntu10.3_i386.deb) ... Selecionando pacote previamente não selecionado mysql-server-5.0. Desempacotando mysql-server-5.0 (de .../mysql-server-5.0_5.1.30really5.0.75-0ubuntu10.3_i386.deb) ... Selecionando pacote previamente não selecionado libhtml-template-perl. Desempacotando libhtml-template-perl (de .../libhtml-template-perl_2.9-1_all.deb) ... Processando gatilhos para man-db ... Configurando libnet-daemon-perl (0.43-1) ... Configurando libplrpc-perl (0.2020-1) ... Configurando libdbi-perl (1.607-1) ... Configurando libdbd-mysql-perl (4.008-1) ... Configurando mysql-client-5.0 (5.1.30really5.0.75-0ubuntu10.3) ... Configurando mysql-server-core-5.0 (5.1.30really5.0.75-0ubuntu10.3) ... Configurando mysql-server-5.0 (5.1.30really5.0.75-0ubuntu10.3) ... * Stopping MySQL database server mysqld [ OK ] 100402 17:36:21 [ERROR] /usr/sbin/mysqld: Can't find file: './mysql/user.frm' (errno: 13) 100402 17:36:21 [ERROR] /usr/sbin/mysqld: Can't find file: './mysql/user.frm' (errno: 13) ERROR: 1017 Can't find file: './mysql/user.frm' (errno: 13) 100402 17:36:21 [ERROR] Aborting 100402 17:36:21 [Note] /usr/sbin/mysqld: Shutdown complete * Reloading AppArmor profiles ... [ OK ] * /etc/init.d/mysql: WARNING: /etc/mysql/my.cnf cannot be read. See README.Debian.gz * Starting MySQL database server mysqld [fail] invoke-rc.d: initscript mysql, action start failed. dpkg: erro processando mysql-server-5.0 (--configure): sub-processo post-installation script retornou estado de saída de erro 1 Configurando libhtml-template-perl (2.9-1) ... Erros foram encontrados
Re: MyISAM better than innodb for large files?
You want the crash safety and data integrity that comes with InnoDB. Even more so as your dataset grows. It's performance is far better than myisam tables for most OLTP users, and as your number of concurrent readers and writers grows, the improvement in performance from using innodb over myisam becomes more pronounced. His scenario is perhaps updated once a year, though, so crash recovery and multiple writer performance is not important. And the concurrent reader and writer number is set at one, unless I undergo mitosis or something. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MyISAM better than innodb for large files?
Ah, if you are single-user and updating really is a special occasion that is completely in your control, you could even use compressed MyISAM. That makes the table read-only though, but it does give performance benefits: http://dev.mysql.com/doc/refman/4.1/en/myisampack.html good luck! Walter Heck Engineer @ Open Query (http://openquery.com) On Sat, Apr 3, 2010 at 08:50, Mitchell Maltenfort mmal...@gmail.com wrote: You want the crash safety and data integrity that comes with InnoDB. Even more so as your dataset grows. It's performance is far better than myisam tables for most OLTP users, and as your number of concurrent readers and writers grows, the improvement in performance from using innodb over myisam becomes more pronounced. His scenario is perhaps updated once a year, though, so crash recovery and multiple writer performance is not important. And the concurrent reader and writer number is set at one, unless I undergo mitosis or something. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=li...@olindata.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: MyISAM better than innodb for large files?
Didn't even know that one existed. It has an attraction, esp. in terms of backing up the data. But the link refers to the performance benefit in accessing one line at a time. Supposing I was doing a search for all records where a particular string is present -- what would the overhead be in the searching of the compressed file? On Fri, Apr 2, 2010 at 9:24 PM, Walter Heck - OlinData.com li...@olindata.com wrote: Ah, if you are single-user and updating really is a special occasion that is completely in your control, you could even use compressed MyISAM. That makes the table read-only though, but it does give performance benefits: http://dev.mysql.com/doc/refman/4.1/en/myisampack.html good luck! Walter Heck Engineer @ Open Query (http://openquery.com) On Sat, Apr 3, 2010 at 08:50, Mitchell Maltenfort mmal...@gmail.com wrote: You want the crash safety and data integrity that comes with InnoDB. Even more so as your dataset grows. It's performance is far better than myisam tables for most OLTP users, and as your number of concurrent readers and writers grows, the improvement in performance from using innodb over myisam becomes more pronounced. His scenario is perhaps updated once a year, though, so crash recovery and multiple writer performance is not important. And the concurrent reader and writer number is set at one, unless I undergo mitosis or something. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=li...@olindata.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
