MYSQL 新版出现 Client does not support authentication protocol requested by server时的解决办法zz MYSQL 帮助： A.2.3 Client does not support authentication protocol MySQL 4.1 and up uses an authentication protocol based on a password hashing algorithm that is incompatible with that used by older clients. If you upgrade the server to 4.1, attempts to connect to it …
Client does not support authentication protocol… Read More »
SELECT * FROM sys.dm_exec_sessions
如果设为0，则代表最大连接数无限，连接数从0开始，来一个加一个 如果设为一个固定的值，如800，则代表最大连接数不能超过800，但连接数也是从0开始的
这个问题经常出来： 减小日志的方法： 一、用如下步做了： 1、DUMP TRANSACTION 库名 WITH NO_LOG 2、BACKUP LOG 库名 WITH NO_LOG 3、收缩数据库 (对数据库点右键 –任务 –收缩–选文件–日志文件 ) 二、 分离数据库,删除日志文件,再附加,OK! 右击数据库－－所有任务－－分离or 附加 ==================================================== 6.如果想以后不让它日志增长得太大: 企业管理器->服务器->右键数据库->属性->事务日志->将文件增长限制为xM(x是你允许的最大数据文件大小)。->SQL语句的设置方式: alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)。 ================================================== 大师L [9:26]: 好 菜鸟 [9:27]: 数据库已经设了自动收缩，为什么还会满日志？ 大师L [9:28]: 日志是无法自动收缩的 大师L [9:28]: 只能设大小 菜鸟 [9:28]: 那日志只能手动收缩？ 大师L [9:29]: 对，但日志收缩也没用，你要先清空日志才行
alter table 子表 add constraint 外键约束名 foreign key (子表外键字段) references 父表(父表主键字段) on update cascade on delete casde
收集了一些资料后，我想谈谈自己这三个概念的理解，请大家指教： 首先，我认为 历史表与数据清理和备份恢复并没有直接的关系，它们的目标并不相同。下文分别进行说明。 历史表============================================ 关于历史表，我们要先分析一下业务数据的类型。一般来说，业务数据可能有三种作用： 1. 业务操作执行前的准备数据，或者执行后的结果数据。比如转账前 先要 查看客户 是否有足额人民币，转账后再从 客户账户中 减去 一定数额。 2. 记录业务操作本身的数据。如操作流水。 3.主要 用于查询或统计分析、在日常操作中很少删改、且时效性要求不太高的数据。如 客户两年前的交易记录。 业务操作的准备数据和结果数据，常常会随时间越积越多，这就会使数据的存取越来越慢，影响到日常操作的即时响应。如果越早的数据使用越少，则可以把比较早的数据放到历史表中。当需要存取时，先在当前表中操作，如果当前表操作得不到结果，再到历史表中去操作。通过这种手段，可以提高日常操作的性能 操作流水之类的数据，如果有重要的审计作用而且数据量比较大，也可以采用与上相同的处理方案 这两种数据放到历史表后，即构成上文所说的第三种数据，即仅用于查询或统计分析的数据。由于历史表数据查询很多、变动很少，因此可以多用于一些索引，或采取其他的一些查询优化方案 综上所述， 历史表出于性能需求而建立，并 直接影响到程序逻辑(如存储过程，JAVA代码)，对系统设计有显式的影响，因此，历史表的设计应由 开发人员负责。 数据清理============================================= 如果较早的数据允许直接丢弃，则可以将这些数据 清理掉。而且 1.多久以前的数据才可以清理，这应由软件用户决定，要在需求分析时确定 2.数据太多不清理，既会影响查询速度，也会对硬盘空间形成压力 3.历史表和当前表都应该进行数据清理。不过，如果合适的话，也可以把“转移当前部分数据到历史表”和“清理当前表”当成一步 4.数据的清理，可以通过程序逻辑直接实现，如调度线程清理持久化对象，或者在执行新业务操作时清除历史操作的数据（如在新增订单前清除最早的若干订单）；也可以在日常运维时采用数据库工具定期清理 总之，数据清理跟 业务需求、 系统性能、 磁盘空间都有关系。 可以让开发人员在程序里实现这些目标， 也可以让运维人员在日常维护操作时手工进行操作 备份与恢复=========================================== 备份大概有两种作用：一是保存历史数据，二是在灾难后恢复。不管是哪种，备份后的复本都 与生产系统脱钩，这就是它与历史表的区别。 …
–非聚集索引 CREATE INDEX au_id_ind ON authors (au_id) –唯一聚集索引 CREATE UNIQUE CLUSTERED INDEX employeeID_ind ON emp_pay (employeeID) –简单组合索引 CREATE INDEX emp_order_ind ON order_emp (orderID, employeeID)
有三种备份策略：全量数据备份、增量数据备份、日志备份。不过，这三种备份策略相互之间并不是完全独立的，后两种备份机制必须与第一种机制配合使用。 1. 全量数据备份 备份整个数据库，恢复时恢复所有。优点是简单，缺点是数据量太大，非常耗时 2. 增量数据备份(Differential Backups) 所谓增量，就是以某个起始时间点的全量数据为基础，备份该时间点以后的数据。而起始时间点的全量数据，就是通过全量备份而为的。 如果有人告诉你“每周一进行全量备份，每天进行一次增量备份。”，这就意味着，星期一作一次全量配份，形成一个起始时间点的全量数据；星期二备份星期一以来的数据；星期三也备份星期一以来的数据；…….星期天也备份星期一以来的数据。到第二周的星期一时，又执行一次全量配份，再开始新的备份周期。 如果要恢复星期三的数据，则要先恢复星期一的全量数据，然后再恢复在星期一到星期三之间的增量数据。 详见本文附图。 3. 日志备份 周一做一次全量数据备份，周二时备份 周一至周二 的日志，周三时配份 周二至周三 的日志……。 若要恢复周三的数据，则先恢复到周一的全量数据，再按 周一至周二的日志、 周二至周三的日志 进行数据库操作 详见本文附图 4. 增量数据备份与日志备份相结合 详见本文附图
也就是说备份时仍可以提交事务，且备份过程不会破坏事务的一致性，具体来说： 当备份过程完成时： 1.已提交了的事务将在副本数据中得到体现 2.未提交的事务，在副本中会被回滚，数据仍然保持一致性 原文是这样的： The term consistent state means that all transactions that are committed while the backup is being performed are applied and all transactions that are not finished are rolled back.
SQL SERVER的备份可以手动地执行，但在生产系统中，它的备份应该按周期自动执行。 在SQL SERVER中，可以利用SQL Maintenance Plan Wizard ，配置一个SQL Server Agent Job，来完成日常的备份