一、前言 前几天在Python最强王者交流群【群除我佬】问了一个Pandas处理的问题，提问截图如下： 代码如下所示： songid_tags_df['tblTags'].map(lambda x :..., x) if isinstance(x,str)) 二、实现过程 后来我自己给了一个示例代码，如下所示： songid_tags_df['tblTags'].map(lambda x: re.findall..., x) if isinstance(x, str) else x) 后来【隔壁山楂】也给了一个可行的代码，如下所示： songid_tags_df['tblTags'].astype(str).str.extract...三、总结 大家好，我是皮皮。这篇文章主要盘点了一个Pandas处理的问题，文中针对该问题，给出了具体的解析和代码实现，帮助粉丝顺利解决了问题。...最后感谢粉丝【群除我佬】提问，感谢【皮皮】、【瑜亮老师】、【隔壁山楂】给出的思路和代码解析，感谢【Python进阶者】、【孤独】等人参与学习交流。
大家好，之前向大家介绍并跑通了腾讯开源的老照片修复算法（AI 黑科技，老照片修复，模糊变高清），同时我也提到官方提供的3个线上试玩版体验都不好。...下面我就将整个实现过程详细介绍一下 克隆官方Demo GFPGAN 的官方 Demo 就属 Huggingface 体验还行，缺点是只输出人脸且使用的是老模型。...Gradio 的定位类似于 Streamlit，但是更轻量(一行代码)，因为它推荐的应用场景都是对“单个函数”进行调用的应用，并且不需要对组件进行回调。...https://www.gradio.app 我也是第一次接触 gradio ，它的安装很简单：pip install gradio 从零学起我只看了官方文档，用法也只看了 Interface ，耗时半个小时...： 修改model_path,直接将下载好的V1.3预训练模型放到了experiments/pretrained_models下。
今天在梳理一套环境的时候，发现了一个奇怪的问题，应用端连接正常，但是服务端却有些问题。...-12541: TNS:no listener 是监听没启动吗，查看监听进程存在，确实是启动了，但是查看监听状态却抛出了错误 LSNRCTL> status listener_1528 Connecting...这个问题立马勾起了我的兴趣，我使用域名解析的方式查看是没有问题的。...^C 但是ping服务器的IP是有问题的。...这个参数其实的设定其实也是一种安全策略，如果能够扫描到我们的端口，但是却没法得知我们的网络访问是否在防火墙控制下，当然这个地方的设置伤害到“自己人”了。所以暂不需要。
作为一名资深数据摸鱼师，看到这个设计的第一反应是：太妙了！看似平淡无奇，实则暗藏玄机。今天就带大家一起探秘Doris AUTO_INCREMENT背后的故事，领略技术设计之美。...自增列的应用场景 记得前几天和一位数据分析师朋友聊天,他吐槽道:"每天要分析上亿用户数据,光用户ID去重就头大。要么内存爆炸,要么性能拉胯。" 我笑着说:"这不巧了吗?...Doris的自增列简直就是为这种场景量身定制的。" 让我们一起看看在实战中如何玩转这个功能。...实战小贴士 使用中还发现一个有趣的现象:由于每个BE节点缓存一段序列号,新导入数据的自增值可能比老数据小。这让我想起量子物理中的"叠加态" - 在你观察之前,X既可能是活的也可能是死的。..."你说Doris这个自增列设计得怎么样?"我问道。 他笑着说:"就像太极拳,看似简单,实则暗藏玄机。牺牲一点连续性,换来分布式系统的高性能,这种取舍很漂亮。" 确实如此。
前几天，我和系统运维的同事处理一个看似诡异的问题,他找到我说应用服务器启动的时候报了DB的Error,但是错误信息有限，他也没法完全定位到错误的原因，所以就希望我来帮忙看看这个问题是怎么回事，怎么解决...是这个PDB有问题吗，我看PDB的状态是READ WRITE,连接没有任何限制，而且我使用已有的一个用户名和密码做连接测试是没有问题的。...况且在这位同事范酷IDE那个时间点，我们也没有做什么操作，这样想来就很奇怪了。 而问题的分析一下子陷入了僵局，系统运维的同学找不到更多的信息，而我也得不到很多明确的信息。...当然问题既然反馈，还是可能存在的，于是我开始逐个梳理这些信息，当查到这个关联用户的状态时，我感觉应该是哪里出了问题。...那么问题来了，这个业务是个长连接的场景，哪怕失效了，在当前的会话里面还是能够保持连接的，这个问题我就可以回答了，因为前一天晚上碰到了一个PGA的报警，我做了重启，而应用层面有了重连机制，所以大部分的会话连接都没有问题
Adapter could not establish the connection 这个问题让我有奇怪，因为这个时间段我们也没有做数据库维护的工作，带着疑问我登录到了这个环境，发现网络确实有一些卡顿...，这就有些奇怪了。...那么这个问题到底该怎么解释，我认真梳理了下df -k的全部结果，发现/var目录竟然满了，多么低级的一个错误，当然看到这里，问题的解决思路也一下子清晰起来。...为什么会有这种情况呢，系统层面应该是有一个调度任务去删除额外的空间，但是频率还是不高，就在这个间隙出了这个问题，我想看看到底是哪里的日志溢出了，很快就发现是/etc/adm下的日志。...，经不起这么折腾，但是通过这个日志该怎么分析原因呢。
这个很明显看出来数据库是没启动。我把源端的数据库已经停了，自然是连不进去了。 但是开发的同学反馈说，IP已经修改了。那么这个问题就和DB层面的配置有关了。 比如我配置了一个1525的端口。...，修改之后以为就万事大吉了，但是查看v$session没有对应的会话，开发同学说这次错误变了。...:listener does not currently know of SID given in connect descriptor 如此一来，我就感到有些奇怪了，服务端的配置是没有任何问题了...结果很快就得到了开发的确认和反馈，修改IP到原来的服务器IP就没有任何错误了。...我回过头来开始查看监听日志,可以明显看到TNS-12505的错误，和开发反馈的是一致的。
所以这种问题的排查也是比较棘手的。 首先查看了metalink，看是否有一些特殊的设置引起。但是从目前查到的结果来看，大多是由于bug引起，和目前的这个问题还是不太一致。...因为问题已经发生了好久，需要查看的地方就是tns的日志。日志还是最有说服力的。 但是查了半天，奇怪的是日志竟然都找不到。...然后和开发做了确认，让他们帮忙提供其它时间点的错误信息。 结果通过tns日志和alert日志查看，时间点都是完全吻合的。都在指定的时间点做了kill session的操作。...这个时候问题就有些奇怪的了，倒底是什么原因导致的这种问题呢？一种可能是schedule job，这个 是数据库层面的，一种可能是crontab，这个是操作系统级别的设置。...简单排查了下，发现在crontab中的一处设置引起了我的注意。
PDB也是同样的错误。...，比如1526 lsnrct status listener_12c_1526,输出也全然没有什么问题，所以自己感觉这问题越发奇怪，甚至还想，莫非又碰到了12c的一个bug了。...如果备库在ADG模式，备库TNS不可用，那备库就没有什么其他的意义了。 这个时候我们还是来看看监听日志，到指定目录下，发现了下面的内容。...查看MOS，和主库反复做监听配置的比对，也没有发现问题，一筹莫展的时候，决定从头开始来看待这个问题。 监听的配置没有问题，根据错误只能指向监听的状态了。...原来我这个库上最早是安装了11g的ORACLE_HOME,没想到后来整合系统的时候，用了12c,搭建备库的时候，因为主备库的连接配置只设置了1526的端口，其它的都没动，所以n多天后用起来的时候，栽在了这里
对昨天提出的问题做了一个简单的分析和排查，也算是有了一个交代，上一篇文章在 dg broker校验失败的一个奇怪问题 我查看了最近的日志，发现在半个月以前有一行日志引起了我的注意。...Thu Mar 03 17:32:12 2016 ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; 关于这个DEFER的设置，让我想起了之前的一个设置...原来的主库发生了硬件电源故障，启用备用电源之后，勉强撑了几个小时，因为数据库之前使用的异机逻辑备份，恢复起来还是需要些时间，直接就找了台机器搭建 了dataguard,然后做了switchover,把数据库迁移到了新的服务器上...，然后在新的备库上又搭建了一套相应的dataguard环境，在搭 建新的dataguard之前，原有存在电源故障的机器还是可用，但是因为硬件已经过保，就直接做了服务器退还。...，可以看到这个问题其实不奇怪，备库重启，但是备库在nomount阶段导致了这个奇怪的现象，但是对于dataguard而言，归档路径的状态有defer,reset,enable几种情况，可能会以reset
看样子是心跳的检测失败了，看来主库和备库之间的网络可能出现了延迟之类的问题，在最大性能模式下，这个还是能够接受的，当时就没有在意。...查看实例也存在，但是监听器给停掉了。自己也感觉挺奇怪，监听怎么会自动停掉呢。就手工启动，结果启动就报了下面的错误。...Error: 32: Broken pipe 对于这个问题还是有些陌生，启动监听失败，启动其它的监听也是同样的错误，这个时候还是来看看日志里面是怎么描述的吧。...结果切换到监听日志的路径下，使用ll命令就得到了下面的错误。...通过这个案例可以看出，对于dg中的警告信息也不要掉以轻心，很可能一个不经意的ora错误其实已经在警示重大的问题，如果及时关注，就为我们保证数据的安全提供了最快的补救措施。
所以我也是借这个机会来完善规范一些我们做的不好的地方。举个例子来说明就具体多了。...我在备库配置网络的时候，把主库的listener.ora拷贝到备库，修改了HOST信息，就准备启动监听，但是奇怪的是监听怎么都启动不了。...所以根据错误，看起来和空格还没有关系，但是我排除再三，排除了字符集，空格，DB信息错误等，还是没有找到问题的症结。...而这种问题说实在的解决了对自己 的技术提高有多少，我看未必，但是又厄待解决。 所以这也更加坚定了我简化Data Guard配置的一个决心。...在主库运行两个命令即可搞定,这个步骤手动完成，因为是最后的收官阶段，一旦有问题，这个阶段一定会抛出异常。
大家好，我是皮皮。 一、前言 前几天在Python星耀群【我喜欢站在一号公路上】问了一个Python库安装的问题，一起来看看吧。...下图是他的一个报错截图： 二、实现过程 这里【对不起果丹皮】提示到上图报错上面说要你安装pep517，但是这个好像还挺难的。后来【莫生气】提示别省事，一个一个的去安装。...主要txt文件里边的库太多了，而且格式不太规则，挨个安装后，后来暂时没有发现问题。 三、总结 大家好，我是皮皮。...这篇文章主要盘点了一个Python库安装的问题，文中针对该问题，给出了具体的解析和代码实现，帮助粉丝顺利解决了问题。
最近看了一个问题，看问题的表现着实比较奇怪，困扰了我好一会儿。 问题的背景是帮助开发的同学解决一个数据库问题，最后问题解决之后，我想做一个操作系统级的检查，帮他们看看还有什么需要注意的地方。...00:45:46 ora_smon_cytj 但是这个时候，奇怪的问题就发生了。...当然这个地方和sqlplus / as sysdba 应该没有直接关系，但是通过这个可以说明网络服务配置都是合理的。...ERROR: ORA-28000: the account is locked 然后换做tns连接的方式，发现错误也是一样，说明走网络连接的方式也起作用了。...ERROR: ORA-28000: the account is locked 然后对于这个错误，在这个系统中摸索了一番，发现这个路径着实够乱，竟然存在两个ORACLE_HOME, 当前的是： /U01
今天开发的同事找到我，让我帮他们补一部分数据，因为有一个表的数据已经快一个月没有增量数据了，这个需求听起来有些奇怪是不？...问题的背景是在统计库中存在一个表，供部分应用做统计分析，每天会根据时间生成一条记录，这条记录汇总的数据会作为统计分析所用。但是每天的这一条增量数据的源头来自于另外两个在线交易库。...当然对于DBA而言，这部分逻辑还是未知的，可能跨业务部门的原因，开发的同事也是一头雾水，所以这个问题还得我来捋一捋。 有了基本的思路，这个问题的分析其实也是水到渠成。...信息显示在最近两天JOB确实都执行了，但是抛出了ORA-12541的错误，相关联的一个错误是TNS的错误。...发现原来是某一台OLTP的库做了灾难切换，但是在这个统计库中没有修改对应的连接IP地址，导致了JOB从那个时候起就不再同步增量数据了。
我想你的脑海中已经有了答案。我换一个角度来说明是否可以。通过一个蛮有意思的DG配置问题。 我在使用RMAN的duplicate搭建备库的时候抛出了下面的一个错误。...但是实际上查看数据库进程，是没有问题的。 而我根据服务名尝试连接，下面的结果让我大跌眼镜。...而这个数据库环境我只安装了一个版本的数据库环境，所以不存在多个ORACLE_HOME,所以这个问题让我很纠结，我们继续来看看ORACLE_HOME的情况，可以查看环境变量的值。...而问题到了这里还是有些奇怪，因为/home/U01和/U01是指向的同一个目录。他们代表的含义是一样的。...我们在RMAN使用duplicate的时候是使用TNS连接方式的，那么TNS连接在连接本地实例的时候指向了另外一个实例（尽管刚开始这个实例不存在），那么本地的连接配置其实还是在listener.ora里面
最近新建了好几个测试库，有一个库在过了一段时间之后，出现了很奇怪的问题，有时候能够登录，有时候又登不上。...ERROR: ORA-12537: TNS:connection closed 但是通过tnsping来判断，可以ping通，而且查看listener也是起来的。...ERROR: ORA-12537: TNS:connection closed 查看alert日志也没有发现相关的的错误。 在反复尝试之后，尝试使用sysdba来登录。终于报了一个ora错误。...ERROR: ORA-00020: maximum number of processes (150) exceeded 有了这个错误，就有了查找问题的方向。...查看processes的参数和sessions，显示只有150个，当前session有146个左右。 但是记得当时把这些类型的参数都调整了，但是现在又有问题了。查看原来是把spfile的功能没有启用。
奇怪这里为什么选择不到数据库的TNS呢？我是先安装数据库，再安装PL/SQL Developer。...按理说安装PL/SQL Developer时，就已经识别到了Oracle Home和OCI Libaray了。管它呢？...还是选择不到数据库TNS，尝试无数据库登录，看看报什么错误。 终于找到问题的关键点了，安装的PL/SQL Deleloper只能识别32的oci.dll。...目前下载地址：http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html 这个一个绿色版的Oracle...4.验证Oracle Client 打开新的PL/SQL Developer，输入用户名和密码，在database选项下，可以看刚才配置的TNS了。 等待奇迹时刻...........
数据库连接的问题 首先是数据库连接的问题，这两天四个同事遇到了同样的问题，但是问题原因也是五花八门。...netmgr和netca中的图形配置，看起来这个问题是 不是windows上的某些奇怪的问题，按照他所说，这些配置都完成了，但是数据库就是连接不了，我使用cmd进入命令行，如果是linux可以直接运行...当然这个问题看起来非常简单，但是能够折射出对于数据库层面的一些知识，开发还是不够了解。 最后一个是jdbc连接数据库的问题。开发有个同事反馈说有一个备库连接的时候报了错误。...然后提供了以下的错误信息，而且还诚意满满附了日志，我打开日志的瞬间就后悔了，因为这个日志好几十M，其实这个问题确定ip就可以基本判定问题。...说完数据库的连接问题，再来看两个小案例，这个其实也可以和开发的同学好好聊聊。 我收到了一个开发同事的工单，说需要给一个表增加一个列，看起来需求很简单也很明确，而且给出了完整的语句和环境。
昨天开发的同事找到我说，生产有个job处理数据的速度很慢，想让我帮忙看看是怎么回事，最近碰到这种问题相对比较多了，但是问题的原因也是五花八门。...我还是大体找他们了解了下情况，说有一个Job是处理文件传输的，但是从目前的运行情况来看，处理速度很慢，基本没什么进展，我向他们确认这几天是否有数据变更的操作，他们说没有。...得到这个确认查看问题的方向就有明显的不同，我还是照例查看了一下数据库负载，锁情况。但是么有发现什么信息。 从数据库的负载来看，负载倒不高。...但是仔细查看会发现一个奇怪的现象， Rows Processed却是0.这是一个比较特殊的情况，这个参数代表的意思是SQL在快照时间内累计执行所处理的总行数。...，一看这个表，我就恍然大悟了，这个表是在这两天才做的变更，在最新的需求中需要创建这个表，从目前的需求来看，这个表需要同步一些数据，但是数据的同步机制还没有达成共识，所以最后临时决定先把这个表创建好，让job
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
