浏览模式: 普通 | 列表
11月, 2008 | 1

庄子, 大奔和其它

[ 2008-11-24 20:21:23 | 作者: progame ]
老子说, 大道无形, 不是大奔无形

易中天不讲三国, 讲诸子百家了
前些天讲到儒道之争, 说庄子因为无为, 所以无所为, 颇有些穷困的意思
于是便有些对手跑他面前来炫耀讥笑他
身为读书人的我们深知, 书生都是要面子的, 并且心理极其阴暗
庄子心里挺上火, 想骂人, 又不好意思骂
于是就说, 我跟你讲个故事吧
在庄子的故事里, 他自己就成了圣人, 成了鲲鹏, 凤凰
别人就成了小麻雀,猫头鹰, YY得相当可以

当然我们今天不是来坐而论道讲庄子的
只是也一样先来讲个老掉牙的故事
某奥拓,被奔驰超,奔驰司机问他:开过大奔吗?后扬长而去
奥拓大怒,猛超之,不久,奔驰又超:开过大奔吗?又扬长而去,奥拓服之
一会,前方车祸,奥拓看热闹
见大奔司机躺在地上:哥们儿,开过大奔吗?刹车在哪?

前文书刚说过, 看文章听故事别去挖掘这个影射那个寓意的
讲这个故事纯属想借用里面一句话布局

现在天气冷了, 再穿拖鞋跑步实在有伤风化成何体统,于是周六去买了双运动鞋
当然不会去品牌店里买, 一向不习惯为广告买单,从拖鞋到名牌跑鞋, 会有点暴发户的感觉

所以买了一双很普通的鞋, 到手后却暂时无法到脚
因为周末连续两天下雨, 跑不了步, 只能神游

今天周一了, 天晴了, 可以跑步了
第一次穿新鞋跑步, 正所谓人不如旧, 衣不如新
没有了把鞋甩掉的担心, 跑起来果然轻松多了
在起点就是终点的跑道上奔驰着, 我不由得也在想:
刹车在哪?

小王子的童话

[ 2008-11-24 00:09:41 | 作者: progame ]
这是网站

无意中听MOP电台, 里面有在朗读这篇童话, 吸引我的是小王子的星球, 很小
三棵猴面包树可以长得把整个星球撑破, 搬个椅子转一转就可以从日落转成日出
于是在网上搜索, 找到这本童话并下载到了手机上看
几万字的童话很快就看完了

一个叫小王子的人来自另一个星球
孩子似的天真, 喜欢上了一朵花却不自知
因为受不了花的骄傲而离开了自己的小星球去探险
到了别的星球, 最后来到了地球
碰到了一些很正常的人和动物

这个故事想告诉我们什么?
想这个问题太累了, 我们就不如相信真的有这样的一个小王子存在
他最在乎的是那朵花, 为自己小星球的整洁而忙碌

小学时每篇课文总要总结中心思想, 每个寓言都要有寓意
麻烦就是把简单的事情搞复杂, 或者把复杂的事情想简单了
为了让匮乏的想像力不要衰老得那么快, 多看看童话, 科幻吧

是什么折断了想像的翅膀?

[ 2008-11-20 22:56:05 | 作者: progame ]
想像力总是和天真的孩子联系在一起, 捞月亮摘星星, 总有那么多的异想天开
那么是什么把我们大人想像的翅膀给折断了?

无知者无畏, 无畏所以不用去考虑可行性, 心有多大, 世界便有多大
然而知识, 宝贵的知识, 却会让我们在考虑事情时不断地去想可行性
很多时候, 我们因为所谓丰富的知识, 会只看到5年后10后的东西
千百年后的场景是那么遥不可及, 总没有眼前的房子票子来得真实

在中国的一介小民, 如果被问及如果你想在白宫担任一个什么职位
可能大多数人会说想当总统, 而在白宫的一个小文员, 可能理想不过是一个主管
近处能够看到的真实会阻碍你的想像, 所以IT人员中软件的样子永远没有客户想像中的那么酷那么炫

种过地的农民不敢去想亩产万斤, 越接触计算机的人越不敢想像人工智能
公理, 定理, 一个个地禁锢着你的思想, 当我们认知的越多, 才发现我们的可想像的越少
别人敢想像让地球当成飞行器在宇宙中做星际航行,我却只能偶尔幻想一下我的个人飞行器
而且还要受到一群人的打击, 越长越大, 越长越老的现实生活就是这么残酷
Article by Nigel Maneffa

Introduction: A Brief History of Metadata Table Cleanup
Those using merge replication will know that it uses several system tables, three of which are particularly important: MSmerge_genhistory, MSmerge_contents and MSmerge_tombstone with the first 2 holding all the metadata relating to inserts and updates, and Msmerge_tombstone maintaining metadata on deletes.

Early adopters of Merge replication (introduced in SQL Server 7.0) found that these merge replication metadata tables would consistently grow over time, causing ever increasing slowdowns and intense locking/blocking issues. One possible 'fix' was to completely remove replication and subsequently reinstall it from scratch, which shows that this was without doubt real “version 1.0” stuff. Also, the fact that servers at that time were dramatically less powerful further magnified these issues.

Soon after there followed unofficial, non-Microsoft stored procedures (eg Michael Hotek) to clear out the unnecessary metadata, and ultimately an official MS stored procedure (sp_mergecleanupmetadata) which had the same aim. Having to run these type of procedures manually at infrequent intervals was a real pain as I remember – many years ago now thankfully. There was also the added problem that the system had to be quiesced during this process.

Eventually everyone's prayers were answered when SQL 2000 SP1 introduced automatic metadata cleanup at every synchronisation. The parameter “–MetadataRetentionCleanup” was added to the Merge profile and everyone was home and dry – cleaned up metadata by default and no more manual work.

Performance Implications of Cleaning up the Metadata
Like most things in computing you never get something for nothing, and my findings are that the metadata cleanup process absorbs very large amounts of system processes so if you are running merge synchronizations on a frequent schedule the performance hit on the servers in question can be very noticeable and we ...

阅读全文...
分类: | 评论: 0 | 浏览: 45

[转]关于sql server数据同步msmerge表的说明 [私人]

[ 2008-11-16 11:00:31 | 作者: progame ]
MSmerge_contents causes problems for anyone that is running merge replication for any length of time. The problem is that MSmerge_contents will grow forever unless you manage it. Merge replication makes very heavy use of MSmerge_contents which can cause problems as the size grows. This is normally manifested by deadlocking and the entire replication system slowing down. This occurs, because the time to locate the appropriate rows increases as the size increases.
Before getting to the script itself, you have to understand what is going on and why we are purging the metadata.

The main tables for merge replication are MSmerge_contents, MSmerge_tombstone, and MSmerge_genhistory. In addition to these, there is a set of tables in distribution. For merge replication, distribution is NOT important. It simply contains status messages such as: agent started, agent stopped, agent retrying, etc. Don't bother to backup distribution and if you lose it, simply recreate it. MSmerge_tombstone contains a row for each row that was deleted from a published table. Each publication is configured with a retention period. The clean up jobs will remove anything older than this retention period. This applies to the messages in distribution and the rows in MSmerge_tombstone ONLY. It does not apply to anything else. When you issue a transaction against a published table, a trigger fires and makes entries in the merge metadata tables. Inserts and updates go into MSmerge_contents. All new rows get a generation of 0 (zero). MSmerge_genhistory is the keystone to the merge system and is what provides the power and flexibility. It contains a row for each row modified in each article in each publication. When the merge agent fires, it grabs all of the rows with a generation of zero. It then looks in the MSmerge_genhistory table and gets the highest generation value applied. It then sets the generation to the next highest value based on what was returned from MSmerge_genhistory ...

阅读全文...

程序员的肚, 是仓库

[ 2008-11-04 22:04:06 | 作者: progame ]
为什么这样说呢? 因为今天去仓库了

仓库还没有正式启用, 空荡荡的
最近一直在做WMS, 需求在哪里? 也是空空如也
没有需求, 只有对照着别人的软件来猜需求
猜出来的东西和实际的有多大的差异?
不知道, 试了就知道了, 到时再改吧

最近因为总得赶这个赶那个, 严重缺乏睡眠
偏偏睡眠质量一如既往地差, 于是精神又萎靡了些
不过晚上跑步的圈数慢慢增加了
还是跟老头老太在一起的时候觉得自己年轻点

记忆力现在每况愈下, 不得不设置必要的闹铃提醒
也不知是仓库的可存储容量小了, 还是因为库存周转周期加快了
很多东西记不住, 或者给其它的事一干扰就把原来的给忘了

居然今天是TechED第一天, 本来有两场想听的, 结果去仓库了
幸好我们程序员的肚是仓库, 没有永远存储的东西
记住现在要记的, 忘掉现在不用的
容纳的东西是有限的, 不把旧的扔掉, 就不能接受新的
1