在多用户模式下,如何保证数据的实时性和数据库的安全呢?
24 个解决方案
#1
你使用 ib 什么版本?连接软件是什么?错误信息?
出错原因?...
出错原因?...
#2
错误信息就是数据库文件不可用了。
版本是6.5
dephi的interbase组件,号称原生api连接。
版本是6.5
dephi的interbase组件,号称原生api连接。
#3
根据我以前用的经验
1:当正在写数据库的时候,如果发生死机或者停电的情况,基本上都会损坏数据库。
2:norton和瑞星的杀毒软件好象有时会误报interbase的数据库有病毒,如果杀毒软件设置了自动清除病毒,数据库肯定损坏。
损坏了的话,用gfix或者ibconcle或者ibexpert都很难修好,大概只有20%的机会能修,所以用interbase数据库要尽量避免上面的情况发生,同时记得多备份数据库。
目前我还没有看见什么好的interbase数据库的修复工具,如果哪位有好的工具,请告之,不胜感激!我倒是在网上看见一家香港的公司帮别人修interbase的数据库,不过是要收费的,呵呵
1:当正在写数据库的时候,如果发生死机或者停电的情况,基本上都会损坏数据库。
2:norton和瑞星的杀毒软件好象有时会误报interbase的数据库有病毒,如果杀毒软件设置了自动清除病毒,数据库肯定损坏。
损坏了的话,用gfix或者ibconcle或者ibexpert都很难修好,大概只有20%的机会能修,所以用interbase数据库要尽量避免上面的情况发生,同时记得多备份数据库。
目前我还没有看见什么好的interbase数据库的修复工具,如果哪位有好的工具,请告之,不胜感激!我倒是在网上看见一家香港的公司帮别人修interbase的数据库,不过是要收费的,呵呵
#4
ib 采用 OS 提供的文件接口操作数据库文件的。现代操作系统 windows/unix/linux 等都提供异步缓存的写文件。6.0 以前的 ib(我不清楚 6.5)是让 OS 自动 flash 缓存里的数据到硬盘上(fb 稍改进了这点,增加了一个缓存大小参数),而 windows 中一般很多时候只有程序退出时才 flash 数据。如果知道数据库实现的东西就不难发觉,其中突然掉电数据库被损坏的原理。不过我认为不会像 SuperTitan001 说的那样大机率。:)
所以在没有 UPS 的情况下,建议不要打开异步写方式。
无论是 gfix或者ibconcle或者ibexpert 都是使用 ib 提供的一个 fix 服务实现的。我不知道 SuperTitan001 的 20% 的统计数据从哪里来的。但我发现有时多来几次 gfix 就可以了。我想可能是 fix 是每次只修复一个地方的原因吧(没看过原理,只是猜想)。
最保险的方法就是要有定时备份/还原的习惯。
所以在没有 UPS 的情况下,建议不要打开异步写方式。
无论是 gfix或者ibconcle或者ibexpert 都是使用 ib 提供的一个 fix 服务实现的。我不知道 SuperTitan001 的 20% 的统计数据从哪里来的。但我发现有时多来几次 gfix 就可以了。我想可能是 fix 是每次只修复一个地方的原因吧(没看过原理,只是猜想)。
最保险的方法就是要有定时备份/还原的习惯。
#5
我的数据库坏倒不是断电引起,主要是多客户连接在同一数据库上,结果服务器重启了,而客户端不知情,结果就坏了,ib如何防止和保护这种情况呢。
#6
CuteBit(康) :
你前面提到的当interbase数据库损坏的时候,有时多来几次gfix就修好了,不知道是你自己的实践结果还是从inerbase帮助中得来的?我一直也很奇怪,我从interbase的帮助中也看到过同样的话,不过,我自己从来没有试验成功过!以前我自己遇到的interbase数据库损坏,一般都是因为停电或者死机的情况导致的,在修复的时候如果能修好,一般一次就修好了,如果不能修,就始终不能修。(我前面讲的20%的情况,是我自己统计的)也就是在用gfix修的时候,如果ingore checksum errors,报告可以修好,但实际上没有修好,如果不ingore checksum errors,则无法修下去,好象是报error while reading错误。
不知道老大有没有碰到过这种情况?
你前面提到的当interbase数据库损坏的时候,有时多来几次gfix就修好了,不知道是你自己的实践结果还是从inerbase帮助中得来的?我一直也很奇怪,我从interbase的帮助中也看到过同样的话,不过,我自己从来没有试验成功过!以前我自己遇到的interbase数据库损坏,一般都是因为停电或者死机的情况导致的,在修复的时候如果能修好,一般一次就修好了,如果不能修,就始终不能修。(我前面讲的20%的情况,是我自己统计的)也就是在用gfix修的时候,如果ingore checksum errors,报告可以修好,但实际上没有修好,如果不ingore checksum errors,则无法修下去,好象是报error while reading错误。
不知道老大有没有碰到过这种情况?
#7
hi, peiweiwei,
你是指多客户会造成 ibserver 当掉?还是人为的关闭服务器?人为的关闭服务器不会造成数据库损坏的(即使当时有客户连接操作).
你所说的"坏"是指数据库打不开?出错信息(英文原版信息)是什么?
hi,SuperTitan001,
"老大"?!不要吓我了(难道是技术黑帮?) :))
多几次 gfix 是我实践中发现的. gfix 的参数很多,具体用哪个我也没有主意.
一般我是这样 用 gfix 修理后 用 gbak 备份/还原
有时由于错误(被修复后)会造成数据丢失,这样的诱发问题造成子表外键失败,这样需要更耐心了.先不激活索引.找出丢失数据,补齐,激活索引.
我建议使用 ib6.0X 以后的 ib/fb 版本.之前的版本 bug 较多.
你是指多客户会造成 ibserver 当掉?还是人为的关闭服务器?人为的关闭服务器不会造成数据库损坏的(即使当时有客户连接操作).
你所说的"坏"是指数据库打不开?出错信息(英文原版信息)是什么?
hi,SuperTitan001,
"老大"?!不要吓我了(难道是技术黑帮?) :))
多几次 gfix 是我实践中发现的. gfix 的参数很多,具体用哪个我也没有主意.
一般我是这样 用 gfix 修理后 用 gbak 备份/还原
有时由于错误(被修复后)会造成数据丢失,这样的诱发问题造成子表外键失败,这样需要更耐心了.先不激活索引.找出丢失数据,补齐,激活索引.
我建议使用 ib6.0X 以后的 ib/fb 版本.之前的版本 bug 较多.
#8
CuteBit(康):
你是这里的斑竹,当然也就是老大了,呵呵!
我以前碰到的数据库坏的情况比较特别,用gfix修复的时候,只要不用-i参数,也就是ingore checksum errors,就告诉你error while reading(好象是这样),用-i参数,怎么修都可以,但就是修不好!检测的时候好象是说****页数据的checksum出错。
哪天我弄坏一个发给你看看?
你是这里的斑竹,当然也就是老大了,呵呵!
我以前碰到的数据库坏的情况比较特别,用gfix修复的时候,只要不用-i参数,也就是ingore checksum errors,就告诉你error while reading(好象是这样),用-i参数,怎么修都可以,但就是修不好!检测的时候好象是说****页数据的checksum出错。
哪天我弄坏一个发给你看看?
#9
SuperTitan001,
呵呵,好,
你最好能说明弄坏的方法(当然,非暴力的~~),以及 ib 的版本(我希望是 fb1.X) .
呵呵,好,
你最好能说明弄坏的方法(当然,非暴力的~~),以及 ib 的版本(我希望是 fb1.X) .
#10
还可以通过影子文件来帮忙。
#11
CuteBit(康) :
其实弄坏的方法很多,比如写一个循环写数据库的程序,然后将其强行终止(类似死机,停电),不知算不算暴力?呵呵!
我以前碰到的情况我用的是interbase 6.01,现在用的版本是从TR@SOE那里下的7.01,不过好长时间没有用interbase了。
TR@SOE() :
能否讲详细一点,谢谢!
其实弄坏的方法很多,比如写一个循环写数据库的程序,然后将其强行终止(类似死机,停电),不知算不算暴力?呵呵!
我以前碰到的情况我用的是interbase 6.01,现在用的版本是从TR@SOE那里下的7.01,不过好长时间没有用interbase了。
TR@SOE() :
能否讲详细一点,谢谢!
#12
hi,SuperTitan001,
你说的例子方法出错率高的原因我认为有两个
1)你可能打开了数据库写缓冲.
2)你是每条记录保存是均提交事务.
这样的出错机率比较大.
因为数据库事务中总存在一个关键点(数据在这点上被真正才进入数据库),一般来说在数据库关键点上系统当机都会造成数据库文件损坏.
ib 影子文件其实是一种数据库镜像技术.影子文件是数据库的一个实时"克隆",双保险.你可以在建立数据库的时候指定,也可以用 gfix 加入.
你说的例子方法出错率高的原因我认为有两个
1)你可能打开了数据库写缓冲.
2)你是每条记录保存是均提交事务.
这样的出错机率比较大.
因为数据库事务中总存在一个关键点(数据在这点上被真正才进入数据库),一般来说在数据库关键点上系统当机都会造成数据库文件损坏.
ib 影子文件其实是一种数据库镜像技术.影子文件是数据库的一个实时"克隆",双保险.你可以在建立数据库的时候指定,也可以用 gfix 加入.
#13
CuteBit(康):
就是你说的情况,呵呵!pfpf
因为我的程序很有可能就是放在win98中,所以我不敢关闭数据库写缓冲,因为怕死机丢数据,所以,我一般每条记录保存都提交事务。
你说的影子文件我再看看资料,有什么问题再向你请教,呵呵!
就是你说的情况,呵呵!pfpf
因为我的程序很有可能就是放在win98中,所以我不敢关闭数据库写缓冲,因为怕死机丢数据,所以,我一般每条记录保存都提交事务。
你说的影子文件我再看看资料,有什么问题再向你请教,呵呵!
#14
CuteBit(康):
我刚刚查了一下资料,原来可以用create shadow来创建影子文件,以前一直没有注意,总是静不下心来看书,呵呵!
不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
我刚刚查了一下资料,原来可以用create shadow来创建影子文件,以前一直没有注意,总是静不下心来看书,呵呵!
不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
#15
大哥们,这个气氛才叫棒,csdn上经常有这种讨论,个个都能成高手。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
#16
大哥们,这个气氛才叫棒,csdn上经常有这种讨论,个个都能成高手。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
#17
另外我使用的是delphi的interbase组件连接数据库文件,各位能否针对此提供些优化建议
#18
peiweiwei(一指残):
按照你说的情况,数据库损坏的情况不算严重啊,我的数据库一损坏就连connect都不行了,我估计你的应该还有希望修好,下次再出现这种情况,千万记住先保存一份坏的数据库,拿出来大家一起研究,呵呵!
按照你说的情况,数据库损坏的情况不算严重啊,我的数据库一损坏就连connect都不行了,我估计你的应该还有希望修好,下次再出现这种情况,千万记住先保存一份坏的数据库,拿出来大家一起研究,呵呵!
#19
hi,SuperTitan001,,
>>不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程
>>句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
恩,当然,还是有可能出现"悲惨遭遇"的 :( 但我想概率会更小.
BTW: 影子会影响部分数据库性能.
hi,peiweiwei,
关于优化,看看
http://expert.csdn.net/Expert/topic/2175/2175125.xml?temp=.5072443
>>不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程
>>句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
恩,当然,还是有可能出现"悲惨遭遇"的 :( 但我想概率会更小.
BTW: 影子会影响部分数据库性能.
hi,peiweiwei,
关于优化,看看
http://expert.csdn.net/Expert/topic/2175/2175125.xml?temp=.5072443
#20
因为,一般情况下使用 ib/fb 作服务器的机器相对其他数据库服务器来说很可怜的.甚至还是 win98 P1 级别,无论是 OS 还是硬件都容易"熄火".由此造成数据库文件损坏.
这容易让大家有个误区, ib/fb 很不稳定.
当然,低版本的 ib 确实在软件中存在不少严重的 bug
也许这个对大家有帮助
http://community.borland.com/article/0,1410,29515,00.html
这容易让大家有个误区, ib/fb 很不稳定.
当然,低版本的 ib 确实在软件中存在不少严重的 bug
也许这个对大家有帮助
http://community.borland.com/article/0,1410,29515,00.html
#21
CuteBit(康) :
情况确实如此,其实很多人认为ib/fb速度慢,不稳定,主要原因我想还是和服务器的配置与重视程度有关系。
情况确实如此,其实很多人认为ib/fb速度慢,不稳定,主要原因我想还是和服务器的配置与重视程度有关系。
#22
to:CuteBit(康)
哥们,怎么把我的帖子发给我了:)
你那篇e文我也在看,真累。
那个中文帮助大家都下了吧,的确不错啊。
to:SuperTitan001(除了黑龙,我怕谁!)
下次再有坏库,一定给你研究研究。
哥们,怎么把我的帖子发给我了:)
你那篇e文我也在看,真累。
那个中文帮助大家都下了吧,的确不错啊。
to:SuperTitan001(除了黑龙,我怕谁!)
下次再有坏库,一定给你研究研究。
#23
的确坏的不严重,GIFX 轻松搞定。
谢谢各位。
谢谢各位。
#24
-------------------------------------
被损坏数据库修复工具 (试用版)
-------------------------------------
http://www.officerecovery.com/interbase/download_demo.htm
试过修复过一个坏数据库,还可以,只是有试用版限止
被损坏数据库修复工具 (试用版)
-------------------------------------
http://www.officerecovery.com/interbase/download_demo.htm
试过修复过一个坏数据库,还可以,只是有试用版限止
#1
你使用 ib 什么版本?连接软件是什么?错误信息?
出错原因?...
出错原因?...
#2
错误信息就是数据库文件不可用了。
版本是6.5
dephi的interbase组件,号称原生api连接。
版本是6.5
dephi的interbase组件,号称原生api连接。
#3
根据我以前用的经验
1:当正在写数据库的时候,如果发生死机或者停电的情况,基本上都会损坏数据库。
2:norton和瑞星的杀毒软件好象有时会误报interbase的数据库有病毒,如果杀毒软件设置了自动清除病毒,数据库肯定损坏。
损坏了的话,用gfix或者ibconcle或者ibexpert都很难修好,大概只有20%的机会能修,所以用interbase数据库要尽量避免上面的情况发生,同时记得多备份数据库。
目前我还没有看见什么好的interbase数据库的修复工具,如果哪位有好的工具,请告之,不胜感激!我倒是在网上看见一家香港的公司帮别人修interbase的数据库,不过是要收费的,呵呵
1:当正在写数据库的时候,如果发生死机或者停电的情况,基本上都会损坏数据库。
2:norton和瑞星的杀毒软件好象有时会误报interbase的数据库有病毒,如果杀毒软件设置了自动清除病毒,数据库肯定损坏。
损坏了的话,用gfix或者ibconcle或者ibexpert都很难修好,大概只有20%的机会能修,所以用interbase数据库要尽量避免上面的情况发生,同时记得多备份数据库。
目前我还没有看见什么好的interbase数据库的修复工具,如果哪位有好的工具,请告之,不胜感激!我倒是在网上看见一家香港的公司帮别人修interbase的数据库,不过是要收费的,呵呵
#4
ib 采用 OS 提供的文件接口操作数据库文件的。现代操作系统 windows/unix/linux 等都提供异步缓存的写文件。6.0 以前的 ib(我不清楚 6.5)是让 OS 自动 flash 缓存里的数据到硬盘上(fb 稍改进了这点,增加了一个缓存大小参数),而 windows 中一般很多时候只有程序退出时才 flash 数据。如果知道数据库实现的东西就不难发觉,其中突然掉电数据库被损坏的原理。不过我认为不会像 SuperTitan001 说的那样大机率。:)
所以在没有 UPS 的情况下,建议不要打开异步写方式。
无论是 gfix或者ibconcle或者ibexpert 都是使用 ib 提供的一个 fix 服务实现的。我不知道 SuperTitan001 的 20% 的统计数据从哪里来的。但我发现有时多来几次 gfix 就可以了。我想可能是 fix 是每次只修复一个地方的原因吧(没看过原理,只是猜想)。
最保险的方法就是要有定时备份/还原的习惯。
所以在没有 UPS 的情况下,建议不要打开异步写方式。
无论是 gfix或者ibconcle或者ibexpert 都是使用 ib 提供的一个 fix 服务实现的。我不知道 SuperTitan001 的 20% 的统计数据从哪里来的。但我发现有时多来几次 gfix 就可以了。我想可能是 fix 是每次只修复一个地方的原因吧(没看过原理,只是猜想)。
最保险的方法就是要有定时备份/还原的习惯。
#5
我的数据库坏倒不是断电引起,主要是多客户连接在同一数据库上,结果服务器重启了,而客户端不知情,结果就坏了,ib如何防止和保护这种情况呢。
#6
CuteBit(康) :
你前面提到的当interbase数据库损坏的时候,有时多来几次gfix就修好了,不知道是你自己的实践结果还是从inerbase帮助中得来的?我一直也很奇怪,我从interbase的帮助中也看到过同样的话,不过,我自己从来没有试验成功过!以前我自己遇到的interbase数据库损坏,一般都是因为停电或者死机的情况导致的,在修复的时候如果能修好,一般一次就修好了,如果不能修,就始终不能修。(我前面讲的20%的情况,是我自己统计的)也就是在用gfix修的时候,如果ingore checksum errors,报告可以修好,但实际上没有修好,如果不ingore checksum errors,则无法修下去,好象是报error while reading错误。
不知道老大有没有碰到过这种情况?
你前面提到的当interbase数据库损坏的时候,有时多来几次gfix就修好了,不知道是你自己的实践结果还是从inerbase帮助中得来的?我一直也很奇怪,我从interbase的帮助中也看到过同样的话,不过,我自己从来没有试验成功过!以前我自己遇到的interbase数据库损坏,一般都是因为停电或者死机的情况导致的,在修复的时候如果能修好,一般一次就修好了,如果不能修,就始终不能修。(我前面讲的20%的情况,是我自己统计的)也就是在用gfix修的时候,如果ingore checksum errors,报告可以修好,但实际上没有修好,如果不ingore checksum errors,则无法修下去,好象是报error while reading错误。
不知道老大有没有碰到过这种情况?
#7
hi, peiweiwei,
你是指多客户会造成 ibserver 当掉?还是人为的关闭服务器?人为的关闭服务器不会造成数据库损坏的(即使当时有客户连接操作).
你所说的"坏"是指数据库打不开?出错信息(英文原版信息)是什么?
hi,SuperTitan001,
"老大"?!不要吓我了(难道是技术黑帮?) :))
多几次 gfix 是我实践中发现的. gfix 的参数很多,具体用哪个我也没有主意.
一般我是这样 用 gfix 修理后 用 gbak 备份/还原
有时由于错误(被修复后)会造成数据丢失,这样的诱发问题造成子表外键失败,这样需要更耐心了.先不激活索引.找出丢失数据,补齐,激活索引.
我建议使用 ib6.0X 以后的 ib/fb 版本.之前的版本 bug 较多.
你是指多客户会造成 ibserver 当掉?还是人为的关闭服务器?人为的关闭服务器不会造成数据库损坏的(即使当时有客户连接操作).
你所说的"坏"是指数据库打不开?出错信息(英文原版信息)是什么?
hi,SuperTitan001,
"老大"?!不要吓我了(难道是技术黑帮?) :))
多几次 gfix 是我实践中发现的. gfix 的参数很多,具体用哪个我也没有主意.
一般我是这样 用 gfix 修理后 用 gbak 备份/还原
有时由于错误(被修复后)会造成数据丢失,这样的诱发问题造成子表外键失败,这样需要更耐心了.先不激活索引.找出丢失数据,补齐,激活索引.
我建议使用 ib6.0X 以后的 ib/fb 版本.之前的版本 bug 较多.
#8
CuteBit(康):
你是这里的斑竹,当然也就是老大了,呵呵!
我以前碰到的数据库坏的情况比较特别,用gfix修复的时候,只要不用-i参数,也就是ingore checksum errors,就告诉你error while reading(好象是这样),用-i参数,怎么修都可以,但就是修不好!检测的时候好象是说****页数据的checksum出错。
哪天我弄坏一个发给你看看?
你是这里的斑竹,当然也就是老大了,呵呵!
我以前碰到的数据库坏的情况比较特别,用gfix修复的时候,只要不用-i参数,也就是ingore checksum errors,就告诉你error while reading(好象是这样),用-i参数,怎么修都可以,但就是修不好!检测的时候好象是说****页数据的checksum出错。
哪天我弄坏一个发给你看看?
#9
SuperTitan001,
呵呵,好,
你最好能说明弄坏的方法(当然,非暴力的~~),以及 ib 的版本(我希望是 fb1.X) .
呵呵,好,
你最好能说明弄坏的方法(当然,非暴力的~~),以及 ib 的版本(我希望是 fb1.X) .
#10
还可以通过影子文件来帮忙。
#11
CuteBit(康) :
其实弄坏的方法很多,比如写一个循环写数据库的程序,然后将其强行终止(类似死机,停电),不知算不算暴力?呵呵!
我以前碰到的情况我用的是interbase 6.01,现在用的版本是从TR@SOE那里下的7.01,不过好长时间没有用interbase了。
TR@SOE() :
能否讲详细一点,谢谢!
其实弄坏的方法很多,比如写一个循环写数据库的程序,然后将其强行终止(类似死机,停电),不知算不算暴力?呵呵!
我以前碰到的情况我用的是interbase 6.01,现在用的版本是从TR@SOE那里下的7.01,不过好长时间没有用interbase了。
TR@SOE() :
能否讲详细一点,谢谢!
#12
hi,SuperTitan001,
你说的例子方法出错率高的原因我认为有两个
1)你可能打开了数据库写缓冲.
2)你是每条记录保存是均提交事务.
这样的出错机率比较大.
因为数据库事务中总存在一个关键点(数据在这点上被真正才进入数据库),一般来说在数据库关键点上系统当机都会造成数据库文件损坏.
ib 影子文件其实是一种数据库镜像技术.影子文件是数据库的一个实时"克隆",双保险.你可以在建立数据库的时候指定,也可以用 gfix 加入.
你说的例子方法出错率高的原因我认为有两个
1)你可能打开了数据库写缓冲.
2)你是每条记录保存是均提交事务.
这样的出错机率比较大.
因为数据库事务中总存在一个关键点(数据在这点上被真正才进入数据库),一般来说在数据库关键点上系统当机都会造成数据库文件损坏.
ib 影子文件其实是一种数据库镜像技术.影子文件是数据库的一个实时"克隆",双保险.你可以在建立数据库的时候指定,也可以用 gfix 加入.
#13
CuteBit(康):
就是你说的情况,呵呵!pfpf
因为我的程序很有可能就是放在win98中,所以我不敢关闭数据库写缓冲,因为怕死机丢数据,所以,我一般每条记录保存都提交事务。
你说的影子文件我再看看资料,有什么问题再向你请教,呵呵!
就是你说的情况,呵呵!pfpf
因为我的程序很有可能就是放在win98中,所以我不敢关闭数据库写缓冲,因为怕死机丢数据,所以,我一般每条记录保存都提交事务。
你说的影子文件我再看看资料,有什么问题再向你请教,呵呵!
#14
CuteBit(康):
我刚刚查了一下资料,原来可以用create shadow来创建影子文件,以前一直没有注意,总是静不下心来看书,呵呵!
不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
我刚刚查了一下资料,原来可以用create shadow来创建影子文件,以前一直没有注意,总是静不下心来看书,呵呵!
不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
#15
大哥们,这个气氛才叫棒,csdn上经常有这种讨论,个个都能成高手。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
#16
大哥们,这个气氛才叫棒,csdn上经常有这种讨论,个个都能成高手。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
看来我这回有得学了。
interbase我还是很喜欢的,毕竟便宜嘛,性能也可以。以后会经常来向各位请教。
我的坏数据库早就被我覆盖了,所以出错信息我提供不了,只记得当时好像是同事数据读不到了,我看了一下控制台,数据库还能连,表结构也可见,就是数据没了,约束也没了。
因为当时是在测试,都是凌晨了,不敢耽误,立马覆盖了坏库,后来又陆续有过几次这样的问题,所以才有了这个帖子。
经常的情况是,数据库所在的主机重启,其它客户机还在使用库,因为是内部测试,数据的使用比较频繁,结果开机后数据库就出现了如上的情况。
#17
另外我使用的是delphi的interbase组件连接数据库文件,各位能否针对此提供些优化建议
#18
peiweiwei(一指残):
按照你说的情况,数据库损坏的情况不算严重啊,我的数据库一损坏就连connect都不行了,我估计你的应该还有希望修好,下次再出现这种情况,千万记住先保存一份坏的数据库,拿出来大家一起研究,呵呵!
按照你说的情况,数据库损坏的情况不算严重啊,我的数据库一损坏就连connect都不行了,我估计你的应该还有希望修好,下次再出现这种情况,千万记住先保存一份坏的数据库,拿出来大家一起研究,呵呵!
#19
hi,SuperTitan001,,
>>不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程
>>句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
恩,当然,还是有可能出现"悲惨遭遇"的 :( 但我想概率会更小.
BTW: 影子会影响部分数据库性能.
hi,peiweiwei,
关于优化,看看
http://expert.csdn.net/Expert/topic/2175/2175125.xml?temp=.5072443
>>不过,看完资料以后还是有点疑问,既然影子文件与数据库文件是同步的,由数据库的进程
>>句柄控制,那是否有可能在损坏数据库文件的同时也损坏影子文件?
恩,当然,还是有可能出现"悲惨遭遇"的 :( 但我想概率会更小.
BTW: 影子会影响部分数据库性能.
hi,peiweiwei,
关于优化,看看
http://expert.csdn.net/Expert/topic/2175/2175125.xml?temp=.5072443
#20
因为,一般情况下使用 ib/fb 作服务器的机器相对其他数据库服务器来说很可怜的.甚至还是 win98 P1 级别,无论是 OS 还是硬件都容易"熄火".由此造成数据库文件损坏.
这容易让大家有个误区, ib/fb 很不稳定.
当然,低版本的 ib 确实在软件中存在不少严重的 bug
也许这个对大家有帮助
http://community.borland.com/article/0,1410,29515,00.html
这容易让大家有个误区, ib/fb 很不稳定.
当然,低版本的 ib 确实在软件中存在不少严重的 bug
也许这个对大家有帮助
http://community.borland.com/article/0,1410,29515,00.html
#21
CuteBit(康) :
情况确实如此,其实很多人认为ib/fb速度慢,不稳定,主要原因我想还是和服务器的配置与重视程度有关系。
情况确实如此,其实很多人认为ib/fb速度慢,不稳定,主要原因我想还是和服务器的配置与重视程度有关系。
#22
to:CuteBit(康)
哥们,怎么把我的帖子发给我了:)
你那篇e文我也在看,真累。
那个中文帮助大家都下了吧,的确不错啊。
to:SuperTitan001(除了黑龙,我怕谁!)
下次再有坏库,一定给你研究研究。
哥们,怎么把我的帖子发给我了:)
你那篇e文我也在看,真累。
那个中文帮助大家都下了吧,的确不错啊。
to:SuperTitan001(除了黑龙,我怕谁!)
下次再有坏库,一定给你研究研究。
#23
的确坏的不严重,GIFX 轻松搞定。
谢谢各位。
谢谢各位。
#24
-------------------------------------
被损坏数据库修复工具 (试用版)
-------------------------------------
http://www.officerecovery.com/interbase/download_demo.htm
试过修复过一个坏数据库,还可以,只是有试用版限止
被损坏数据库修复工具 (试用版)
-------------------------------------
http://www.officerecovery.com/interbase/download_demo.htm
试过修复过一个坏数据库,还可以,只是有试用版限止