我正在运行一个PostgreSQL数据库，它有几个存储日志信息的表。 此信息仅用于报告目的，如果超过30天，将被转储到文件并从数据库中删除。 可以删除数百万行，并且每次删除后我们都会运行一个REINDEX。 这是足够的，还是我们也应该运行VACUUM或VACUUM ANALYZE？ 或者REINDEX不是必需的，我们应该运行VACUUM或VACUUM ANALYZE？ 我们正在使用PostgreSQL 8.2.3，我相信它不允许自动清空。
我有一个廉价的慢磁盘和昂贵的快速磁盘服务器。 我想把昂贵的磁盘用于所有重要的事情，比如我的数据库。 为了省钱，我想使用慢速磁盘来进行快速或慢速的备份等没有太大区别的任何事情。 现在，我的问题是，我应该在缓慢还是快速磁盘上安装 Microsoft SQL Server？ （要清楚的是，无论如何，我都会将我的数据库放在快速磁盘上，所以我的问题只涉及到安装本身的位置）
是否有规则或我可以用来计算max_connections ， default_pool_size和max_client_conn一个好的数字？ 默认值是奇数。 PostgreSQL默认为max_connections = 100，而pgbouncer默认为default_pool_size = 20。 不应该default_pool_size总是高于max_connections？ 否则，有什么意义？ 我认为pgbouncer是为了让我们通过降低开销（通过重用PostgreSQL的连接）来处理更多的连接。 我很困惑。 我正在寻找类似于在PostgreSQL wiki中find的build议，比如“这个参数应该是你内存的50％”。 我记得有一个MySQL的电子表格，可以让你计算这些参数。 对于PostgreSQL / pgbouncer来说，这将是非常棒的。
我在这里和那里读到，使用utf8_unicode_cisorting规则可以更好地处理unicode文本（例如，它知道如何将字符扩展为“oe”以进行search和sorting），与默认的utf8_general_ci相比，变音符号。 不幸的是，这两个来源都表明utf8_unicode_ci比utf8_general_ci稍慢。 所以我的问题是：“略慢”是什么意思？ 有没有人运行基准？ 我们是在谈论一个-0.01％的performance影响，或者更像是-25％？ 谢谢你的帮助。
我们即将推出双Web /内部交易应用程序，每个客户端都有自己的数据库。 每个数据库都非常小 – 每个都不到50MB，所以我们想知道使用SQL Express 2008而不是完整的SQL Server是否合理。 这似乎具有在服务器之间分配磁盘I / O的优点，同时节省了大量的$$$（因为小型15K驱动器和使用的双核服务器都不贵）。 如果在某个时候我们需要太多的服务器，我们可以升级到SQL Server …但是对于几十个内部用户来说，现在看起来太贵了（特别是因为我们需要一个故障转移框）。 考虑到我们的小型数据库大小，1GB内存和4个内核在单个处理器上的使用情况听起来不太严格。 我们永远不会有超过200个并发用户，而且大多数操作将会更具事务性（这似乎赞成大量的高速磁盘而不是重的RAM / CPU，对吧？） 我是否错过了SQL Server Standard的任何优势，可以certificate最初额外的$ 5-20K的投资？
所以 – 我们有一个内部的公司数据库，通常是这样的：pipe理客户，电话，销售交易和客户协议/计划。 这是一个Access 2000前端和一个SQL Server 2000 Standard后端。 单服务器，双至强3.2GHz，2GB内存，Windows Server 2003，整天占用40％的CPU负载，分布在OS（HT）可见的4个内核中。 后台数据库devise不佳，已经有超过10年的有机增长，由不太熟练的人维护。 这是严重的规范化，一些显而易见的问题包括成千上万的行没有主键或索引的表，这些也在系统中使用最多的一些部分的多表连接中大量使用（例如，呼叫pipe理器应用程序，每天在每个人的第二台显示器上工作8个小时，每隔几秒钟运行一次大量低效的查询）。 前端并不好，这是几百个表单的典型混乱，嵌套保存的查询，VBA代码中embedded式SQL写得不好，几十个“怪癖”等等，每当一个变化被做出时，不相关的东西似乎就破坏了。 我们已经解决了一个“足够好”的多边开发银行，现在有一个不变的政策，因为我们在内部没有访问权重（也没有计划雇用）。 现在公司正在慢慢成长，客户数量不断增加，电话用户数量不断增加，并发用户数量也有所增加，而且最近的performance也变得越来越糟糕（等待表单之间的移动，等待列表填充等）。 ） Perfmon说： 每秒磁盘传输：0到30之间，平均4次。 当前磁盘队列长度：徘徊在1左右 SQL Server的分析器每分钟都会看到成千上万的查询。 客户端的CPU使用率几乎为零，表示正在等待服务器端查询执行。 我已经通过数据库引擎优化顾问把这个工作量，将其build议应用于testing备份，但这并没有太大的差别。 顺便说一句，我们有一个100MB和千兆以太网的组合，全部在一个子网上，两个楼层有40个用户。 对于这个问题。 正如我所看到的，我们有两个select来解决/改善这种情况。 我们可以取消它，并用一个全新的客户关系pipe理系统取而代之，可以定制或部分定制 我们可以通过硬件来延长这个系统的寿命。 我们可以构build一个性能数字惊人的英特尔i7系统，其成本比replace软件的成本低一个数量级。 当一个新的系统最终被开发出来，它可以被托pipe在这个盒子里，所以没有浪费的硬件。 一个新的客户关系pipe理系统不断推迟，closures和closures – 我至less有一年没有看到这种情况发生。 任何关于这种情况的想法，特别是如果你一直在这里，将不胜感激。 谢谢