新版本支持从BugFree 1.1, 2.0 RTM或2.0.X升级，具体安装可以参考BugFree 2.0.3使用帮助。

BugFree 2.0.3主要更新是增加项目管理员和用户组管理员角色。

项目管理员只能由系统管理员指派，指定哪些用户组可以访问当前项目。该角色负责维护Bug和Case的模块结构，把系统管理员解放出来。

用户组管理员可以由系统管理员或者其他用户组管理员指派，负责维护一个用户组。一般情况下，用户组管理员和项目管理员可以是同一个用户。但是在大型的组织，在人员很多的情况下，可以指派专人对用户组进行维护。技术负责人则担当项目管理员的角色，负责维护Bug和Case的模块结构。

系统管理员、项目管理员和用户组管理员三种角色的详细权限如下表所列。

	系统管理员	项目管理员	用户组管理员
项目管理	可以添加项目 可以查看和编辑所有项目 可以修改项目名称和显示顺序 可以指派项目用户组 可以指派项目管理员 可以编辑Bug或Case模块	不可以添加项目 仅可以查看和编辑自己是项目管理员的项目 不可以修改项目名称和显示顺序 可以指派项目用户组 不可以指派项目管理员 可以编辑Bug或Case模块	无权限
用户管理	可以查看所有用户 可以添加用户 可以编辑、禁用或激活所有用户	可以查看所有用户 可以添加用户 可以编辑、禁用或激活自己创建的用户或本人	可以查看所有用户 可以添加用户 可以编辑、禁用或激活自己创建的用户或本人
用户组管理	可以查看所有用户组 可以添加用户组 可以编辑或删除所有用户组	可以查看所有用户组 可以添加用户组 可以编辑或删除自己添加的用户组	可以查看所有用户组 可以添加用户组 可以编辑或删除自己添加的用户组或自己是用户组管理员的组

作者 Google 广告管理系统小组 李小轲

您可能已经知道，今年10月23日我们在北京举办了谷歌2008发布商峰会上，会上正式发布了一套商业网站广告管理解决方案 - Google 中文广告管理系统（中文版）。产品一经推出，在广大发布商中造成热烈的反响，很多人向我们写信咨询这个产品的相关信息。应大家的要求，我们将在未来通过一系列的文章向大家详细介绍这一产品。今天，我先从总体上向大家介绍一下什么是Google 广告管理系统。

Google 广告管理系统是一种在线托管型广告管理解决方案，它可以帮助网站更好的销售广告资源，一旦有具体的广告订单需要投放时，它可以帮助您排期和投放到具体的广告位，最后提供关于这个广告的详细的报表。通过这个系统，我们希望为发布商带来以下三个方面的价值（对于以下每一点，我们在日后都会通过一个系列的文章来介绍）：

• 通过这个系统，发布商可以一站式管理旗下网站的所有广告位，目前系统支持互联网上大部分的广告形式（文字，图片，Flash，和视频），可以自定义广告大小
• 系统按照一个商业网站在真实世界中从广告销售到最后投放的流程，来定义了一套系统化的流程，提高整个过程（可能涉及到跨部门合作）的效率
• 系统集成了一系列的技术手段，帮助网站提高营销的水平，如按照地理位置（如北京，上海）投放广告 （另外，我们的工程师还在根据本地需求，持续加入新的功能）

在了解了 Google 广告管理系统的基本功能之后，大家可能会问我的网站是否适合使用这个系统呢？考虑到这套系统主要是帮助网站更好的销售广告资源，提高广告上下线的效率，我们认为Google 广告管理系统可以最大程度的帮助以下发布商：

• 网站具备一定的规模，在业内属于行业领先水平，具备高质量的内容和流量
• 网站具备可以销售的广告资源或联盟广告资源
• 网站具备广告销售人员，或计划未来向广告客户直接销售广告资源

因为拥有一个 Google AdSense 账户是登录Google 广告管理系统的前提条件。如果您已经拥有 AdSense 账户，现在就可以登录Google 中文广告管理系统。如果您还没有 AdSense 账户，您可以在线提交申请。

为了方便您的使用，以下是一些您可以使用的资源：

- Google 广告管理系统帮助中心，其中按主题列举了所有关于Google 广告管理系统的信息
- Google 广告管理系统使用入门指南 （PDF文档）

希望以上介绍能够帮助您了解这个产品。关于一些具体的功能如何实现，我们将在以后的文章中详细介绍。

How much space would empty MyISAM table take ? Probably 8K for .frm file, 1KB for .MYI file and 0 for MYD file. .MYI file can be larger if you have many indexes.

How much space will Innodb take:

Check out files (using Innodb File Per Table)

-rw-rw---- 1 mysql mysql 8578 Dec 16 20:33 test_innodb.frm
-rw-rw---- 1 mysql mysql 98304 Dec 16 20:33 test_innodb.ibd

So we get about 100K and so about 10 times more for MyISAM. This is ignored space which needs to be allocated in main tablespace for Innodb data dictionary. But that one is pretty small.

This is the good reason to avoid having very small Innodb tables - they will take much more space than MyISAM.

So .ibd file we get in case of table having no indexes (besides clustered key) - takes 6*16K pages. I wonder why as much as 6 pages are required for start ?

If we add more indexes to this tables - each further index will take additional 16K page even if it contains no data. This is understandable - each index has to have at least one page allocated to it.

Now it is very interesting - SHOW TABLE STATUS does not seems to show everything:

Such table's .idb file takes 128K from the start while we only see 16K of data+32K of index, so another 5 pages are invisible. This tells me you can't use this information to reliably identify space tables take on disk, especially for large number of very small Innodb tables.

Also note amount of free space - even though pages contain no data they are not considered free.

Avg_row_length is another field which may need an explanation. This value is computed by dividing Data_Length (exact number) by number of rows (estimated number) which means this value is going to be changing back and forth and it would be very inaccurate for small tables. For example it will show 16K as average row size for table with one row:

Free Space for tables created in innodb_file_per_table mode is interesting question on its own.

As we populate table we will see Free space will remain at zero as Data_length is small:

When at certain point you will see Innodb Free space to become non zero:

And the file size also jumps significantly (to 9MB):

-rw-rw---- 1 mysql mysql 8578 Dec 16 20:58 test_innodb.frm
-rw-rw---- 1 mysql mysql 9437184 Dec 16 21:06 test_innodb.ibd

If you do the math here you can see there is only about 1MB out of 9MB seen as Index_Length+Data_Length while another 4MB are visible in the "Innodb Free Space" and almost 5MB more is not visible at all.

This tells you it is not about tables which contain couple of rows which can take a lot of space in Innodb. Tables showing as using 1MB of Innodb Data can also really be taking almost 10 times more on the disk.

It is not quite clear to me what is happening here. According to documentation each index should get 2 segments one for non-leaf an one for leaf pages. However the space allocation should happen page by page until whole 32 pages allocated. In the case above no single segment should require more than 32 pages so It is surprising why all of them take 5MB (because 4MB are free)

What is clear however is what if some pages from segment are allocated it goes in the interesting space regarding space reporting - it will be gone from the free space, while only pages actually allocated will be shown in Data_Length and Index_Length fields.

Doing more tests with Inserts I can see Innodb seems to always try to keep at least 4MB free in the tablespace - populating table with more and more data I see free space never falls below 4MB while data file on disk continues to grow.

Finally it is worth to note if you're using innodb_file_per_table the per table tablespaces are not going to grow by innodb_autoextend_increment - instead file will grow by 1MB to 4MB increments. There is a bug reported about it.

As a Summary I should not the following:

• Small Innodb tables will take more space on disk than one may anticipate.
• Using innodb_file_per_table can cause significant space use overhead if small tables are used
• The information in INFORMATION_SCHEMA can't be used to judge how much space table is really taking on disk.

---

Entry posted by peter | No comment

Add to: | | | |

Today we officially announce our new storage engine, "Percona XtraDB", which is based on the InnoDB storage engine. It's 100% backwards-compatible with standard InnoDB, so you can use it as a drop-in replacement in your current environment. It is designed to scale better on modern hardware, and includes a variety of other features useful in high performance environments.

Percona XtraDB includes all of InnoDB's ACID-compliant design and advanced MVCC architecture, and adds features, more tunability, more metrics, more scalability on many cores, and better memory usage. We choose features and fixes based on customer requests and on our best judgment of real-world needs. We have not included all the InnoDB patches available. For example Google's well-known InnoDB patch set is omitted (at least for now).

The first version of our new storage engine is 1.0.2-1, which is forked from InnoDB-plugin-1.0.2. Percona XtraDB is released under GPL v2, as is InnoDB-plugin base source code. Percona XtraDB is released only under the GPL v2 with no dual-licensing, and commercial support is available from Percona.

So what's new in the engine? Here is a list of new features and enhancements:

• INFORMATION_SCHEMA.XTRADB_ENHANCEMENTS. This table contains information about the differences between the Percona XtraDB and the same version number of standard InnoDB, so you can always learn what your engine can do. documentation
• Improvements to SHOW INNODB STATUS. We've added more memory information and lock information, and fixed problems with lock information. documentation
• Improvements to InnoDB IO. Improvements of InnoDB IO subsystem, such as multiple read and write threads, read-ahead control, control io capacity and adaptive checkpointing. documentation
• InnoDB RW-lock fixes Improvements to scalability for systems with 8+ cores. documentation
• Buffer pool fixes Improvements of buffer_pool scalability. documentation
• innodb_buffer_pool_pages Information about content of buffer_pool pages. documentation

Documentation is on http://www.percona.com/docs/wiki/percona-xtradb:start.

Percona XtraDB available :
* in source code from Launchpad https://launchpad.net/percona-xtradb, the version 1.0.2-1 you can get as bzr branch lp:percona-xtradb -r tag:percona-xtradb-1.0.2-1 percona-xtradb-1.0.2-1
* as source code in tar.gz http://www.percona.com/mysql/5.1.30/source/percona-xtradb-1.0.2-1.tar.gz
* as binaries, percona xtradb is compiled in into MySQL-5.1.30 RPMS
* as separated shared library, to use as drop-in plugin for existing MySQL-5.1.30 installation http://www.percona.com/mysql/5.1.30/binary/percona-xtradb-1.0.2-1-5.1.30.x86_64.tar.gz
* OurDelta will also be using Percona XtraDB for its upcoming 5.1 builds.

XtraDB is fully compatible with existing InnoDB tables and we are going to keep compatibility in further releases.

We are open for features requests for new engine and ready to accept community patches. You can monitor Percona's current tasks and further plans on https://bugs.launchpad.net/percona-xtradb. You can also report bugs there. Also have setup two maillists http://groups.google.com/group/percona-discussion for General discussions and http://groups.google.com/group/percona-dev for development related questions.

We are looking for 6-month release cycle of XtraDB. First several releases may come faster, as many features are planned.

Why do we say it's a new storage engine, and not just a patchset? Because we are taking this as a serious project to evolve a new storage engine that will eventually become much more than just small variations from standard InnoDB. Percona will improve this storage engine using our own ideas, as well as incorporate improvements specifically sponsored by customers. Please contact us if you would like to sponsor any specific features. Contact form: http://www.percona.com/contacts.html

---

Entry posted by Vadim | No comment

Add to: | | | |