1.装好Postgres
2.开启远程访问
配置postgresql.conf文件
listen_addresses = '*'
配置pg_hba.conf文件
host all all 0.0.0.0/0 trust
3.下载npgsql 引用2个dll
4.code
string strConn = ConfigurationManager.ConnectionStrings["npgsql"].ConnectionString;
var conn = new NpgsqlConnection(strConn);
string sql = "select * from test";
var dt = new DataTable();
var cmd = new NpgsqlDataAdapter(sql, conn);
cmd.Fill(dt);
foreach (DataRow row in dt.Rows)
{
Console.WriteLine(row["xxxx"].ToString());
}
conn.Close();
Console.Read();.csharpcode, .csharpcode pre{font-size: small;color: black;font-family: consolas, "Courier New", courier, monospace;background-color: #ffffff;/*white-space: pre;*/}.csharpcode pre { margin: 0em; }.csharpcode .rem { color: #008000; }.csharpcode .kwrd { color: #0000ff; }.csharpcode .str { color: #006080; }.csharpcode .op { color: #0000c0; }.csharpcode .preproc { color: #cc6633; }.csharpcode .asp { background-color: #ffff00; }.csharpcode .html { color: #800000; }.csharpcode .attr { color: #ff0000; }.csharpcode .alt {background-color: #f4f4f4;width: 100%;margin: 0em;}.csharpcode .lnum { color: #606060; }
本文链接
当一个SQLServer实例运行得很慢的时候，应该做一些检查，如检查等待状态。最好的方法是一开始就建立一个性能基线，以便做性能对比。当发现与性能基线对比后，存在内存压力的话，就要找出是什么原因导致的。可以检查事务的等待状态，其中Resource_semaphore等待可能出现最多。下面是如何去处理这个问题：
当检查事务的所有等待类型后，可能会发现Resource_semaphore这个等待类型出现非常多，这会增加一些页面的IO等待。因为这些事务没有足够的内存来处理它们的操作，所以到这了页面的IO等待。
Resource_semaphore等待：
首先我们来弄清楚一下什么是Resource_semaphore等待。当SQLServer收到一个用户请求（或者查询时）。首先会创建一个编译后的计划，然后在这个基础上创建一个执行计划。当SQLServer创建一个编译后的计划时，它会计算两个内存授予参数，成为：请求内存（required memory）和额外内存（additional memory）
请求内存是运行排序和hash连接的所需最少内存，之所谓成为“请求”，是因为查询不需要在一开始就申请这部分的内存。而额外内存是存放临时数据到内存中所需的那部分内存。如果没有足够的内存，查询所需的数据将会存到硬盘当中。
首先，服务器会计算运行特定查询所需要的内存。这部分通常等于请求内存和额外内存的总和。但当实例使用并行执行时，所需的内存为（请求内存*并行度）加上额外内存的总和。服务器会检查是否有足够的内存来运行每个查询，然后会降低额外内存的量，知道所有总内存需求量刚好达到内存的限制量。这部分修改后的内存成为需求内存（requested memory）。在SQLServer内不能，有一个叫Resource Semaphore的设置，用于授予需求内存用于查询。当查询没有得到足够的内存，就会把等待状态改为：Resource_Semaphore。可以从sysprocesses系统表或者sys.dm_exec_request DMV中查询。
当Resource_semaphore接受一个新的请求时，首先检查是否有查询还在等待中，如果发现有，那么会把这个新请求放到先进先出的队列中，Resource Semaphore会尝试对未等待的查询授予内存，这部分内存可能是之前的查询执行完毕后返回的内存。如果发现有足够的内存，那么就会把内存赋予给处于Resource Semaphore等待状态的查询，让其开始运行。如果不够，那么会把查询放入等待队列并标记为Resource_Semaphore等待。因此，看这个等待状态可以发现内存存在压力。
执行以下语句，并筛选Resource_Semaphore等待的数据：
SELECT * FROM sys.SYSPROCESSES WHERE lastwaittype = 'RESOURCE_SEMAPHORE' ORDER BY lastwaittype
由于这种情况不好模拟出来，所以没有截图。
从步骤1中得到的结果,可能会看到很多的事务处于ResourceSemaphore 等待状态，现在可以运行下面语句来查看已分配到内存的查询的目前状态，和未被分配内存的查询的数量。这个DMV会返回两行，一行是resource_semaphore_id为0的大查询，另外一些是为1的小查询，这里的小是内存小于5M。在这里可以获得总授予内存和实例上总可用内存。可以查看grantee_count和waiter_count，grantee_count是已经分配了内存的总查询数量，而waiter_count是在队列中等待授予内存的总查询数量：
SELECT * FROM sys.dm_exec_query_resource_semaphores
步骤3:
然后使用DMV：sys.dm_exec_query_memory_grants来获得在等待队列中的查询所需要内存的详细信息。这些查询的grant_time和granted_memory_kb可能为null。也可以从这个DMV中得到plan_handle和sql_handle：
SELECT * FROM sys.dm_exec_query_memory_grants
我们要关注的是下面3列：
现在将要找到集中消耗内存的查询，可以查看所有等待查询中的需求内存。当看到这部分内存太大的时候，然后找到这些查询的plan_handle，并查看它们的执行计划：
SELECT TOP 10
*
FROM sys.dm_exec_query_memory_grants
步骤5： 把步骤4中查询的plan_handle的数据复制，然后执行：
SELECT * FROM sys.dm_exec_sql_text(sql_handle)
注意替换括号中的sql_handle。然后查看其执行计划。
总结： 通过上面的步骤找到耗费内存的查询后，应该调整语句，使其占用更少的资源。以便解决内存压力。
MySQL 设定写入 Master 后, 自动 Replication 到 Slave 去, 运作基本原理是:
操作系统：Linux
Master端IP：192.168.2.122
Slave端IP：192.168.2.123
注意：在做配置的过程中，最好不要向 Master 数据库做写入操作。
1. 建立名为test1的数据库
create database test1;
2. 建立表名为test1的表
CREATE TABLE `test1` ( `id` bigint(20) unsignedNOT NULL AUTO_INCREMENT, `name` varchar(100) , PRIMARY KEY(`id`) );
3. 在表test1中插入3条测试数据
INSERT INTO `test1` VALUES (1,'name1');
INSERT INTO `test1` VALUES (2,'name2');
INSERT INTO `test1` VALUES (3,'name3');
1.2 设置Mysql Replication1. 增加一用于数据库同步的用户root
mysql>GRANT REPLICATIONSLAVE,REPLICATION CLIENT,RELOAD,SUPER ON *.* TO'root'@'192.168.2.123' IDENTIFIED BY 'password';
(授与从192.168.2.123主机上登录用户root数据复制权限)
2. 使权限生效，这步可不做，因为过会要重启mysql
mysql>flush privileges;
3. 退出mysql命令行界面
mysql> exit
4. 停止mysql服务
service mysqld stop
5. 更改Mysql配置文件/etc/my.cnf
1) 打开mysql配置文件
vi /etc/my.cnf
2) 在配置文件中添加以下内容
#bind-address = 127.0.0.1